You disagree that it should be “optional”!? So you’re advocating for slowly weening the Meteor community off the current system completely? That’s an option.
First off just, so you know my stance: you’re not talking to someone that wants to personally use the old easy way. I have barely been coding in Meteor the last few months and haven’t had that luxury. However, I understand and respect the needs of new developers. I can still remember the days where any bit of extra verbositiy had the potential to derail me. In fact I’m also worried about the effect all the new ES6 and beyond features will have on new developers. Less is more, especially for new developers. I think the current system has been ideal for those developers, and if we can keep it as an option, we should.
Now that said, I think it’s a bit outrageous that what you wanna do is take away what we already have, when we can have both. That’s one of the things that bothers me by all the stuff happening in the React Stack–they promote non-optional low-level coding, almost denouncing any higher level abstraction. Who are you or anyone to say that I shouldn’t have the option? I’m not coming around and saying to you, you can’t have your way–in fact I’m saying the opposite: we should have both ways. That’s a very different proposition.
Now that said, I do get the importance of such decisions psychologically in terms of culture and whatnot. But still recognize, one party is saying lets have both, and the other is saying essentially “fuck you, my way or the highway.” Such decisions are important, and perhaps I could be sold on non-optional imports as well, for culture, etc. But I do think Meteor is going to be in a very convenient place if they can catch up with the NPM community on other fronts, while still seeming super appealing to new developers. Automatic imports is one very key avenue to pursue/achieve that.
Regarding non-optional imports, maybe that’s true at the language level, but when you work in Rails, most your classes start out like this:
class Person < ActiveRecord::Base
That doesn’t seem “non-optional” to me. It’s been many years since I even opened a Rails project, but I assume apps there launch via a similar mechanism to Meteor’s where they control the environment. The environment I remember being made for me was a simpler environment and I appreciated that. In addition to being something we’re already doing, it’s something I think JS developers need now more than ever. If you’ve read the various articles about 2016 predictions and 2015 recaps, basically the #1 problem has been too much choice and the #1 thing that will change/happen in 2016 is consolidation and simplification, i.e. what Meteor has always done well. Reference the "Javascript Fatigue" article:
I don’t think we should forget that as Meteor goes into the new year. Rather than letting go of this “feature” at the precise time it’s most needed, we should double down on it. I’ve myself been one of the advocates for taking on all the new stuff and looking more like NPM. But that said, we shouldn’t switch too far to the other side because of our coming to jesus. My assessment is that the smarter choice is somewhere in the middle. In other words, we shouldn’t drop the ball here and lose the opportunity we have to be the source that consolidates things and makes things easier for all these NPM/Javascript developers getting slaughtered by choice and compositional-only procedural code stuffed in all these NPM packages. Our timing would essentially be backwards. The year that just occurred is the year where complexity/choice in the javascript community exponentially grew. Now, choice/complexity is a problem more than ever that needs a solution.
A novel idea is: Meteor does a rebranding, a “reboot” of sorts, coming to the rescue to all these developers struggling with NPM style code–once we have gotten module support, react, etc, right of course (since we gotta provide the upgrade path to pro apps as well). MDG has always toted they have done barely any marketing. Well, it’s time they do. It’s time they take control of their perception. If you go to the Meteor homepage: https://www.meteor.com you will see they say basically nothing about the major benefit that you have way less boilerplate code; the only benefit noted (over and over again) is that it combines everything you need full stack. In the New Year, it’s my predictions that there’s a huge market opportunity for a full stack solution that wants to come out and say: “look, you have the option to code in a way simpler boilerplate-less way, similar to Rails.”
In addition what I’m saying is that clean pure class-as-the-only-thing-per-file approach is very conducive to beginners getting up and running. There’s basically no denying that. All the imports at the top of files is definitely a hindrance to new developers getting started. Javascript not doing the one class per file like Java or Ruby is definitely slowing down new developers. It just is. There’s way more readability when there is one type of thing you’re looking at, a Class. It’s a lot easier to reason about a bunch of files when you know to always expect a Class in it. Opening up different packages and looking at a new rendition of the module pattern in some spagetti code is already hard enough. Since we barely do classes, at least give new Meteor developers something to make their life easier–keep the imports out (unless they want t).
Now, I’m not saying down the line there isn’t tremendous benefits from the composition-only module-based approach promoted by NPM, nor the benefits from friggin using Haskel and going 100% side-effect free thanks to FP. But for new programmers (programmers in their first 1-3 years programming), my opinion is that there is no doubt that looking at class files like in Rails is many times easier than all this nonsense, imports included. It’s no wonder functional programming has taken so long to take off: it isn’t just a paradigm shift foreign to long-time OOP programmers, it’s fundamentally more complex; composing functions of functions, transducers, etc, is super challenging to grasp.
PS. what I proposed to @benjamn in that Meteor 1.3 thread is that if a file is imported or imports other files, it’s taken out of the auto-import scheme. That way you don’t need to stuff your auto-import files in one /import folder and even have to make a decision here. Once you start using ES6 modules in relation to a given file, it’s no longer automatically required, and when and if it is imported, it not longer has the usual global variables in scope, i.e. it operates normally.
Maybe you address this question of full state serialization in it?
