I personally don’ t believe that autoloading should be kept. It was one of those “wow” things back when meteor was first coming out. But we know it to be problematic with load order and then we have to have weird directory structures to make it the way we want. For me, once I got past the initial “wow” factor of autoloading and saw some of the issues associated with it, it really wasn’t a huge differentiator in the way that I saw meteor. In fact, I began seeing it as a downside.
Honestly, if the autoloading package gets created, it’s not a gigantic deal to me, I just won’t use it. However, if it is, I hope that there is a setting to turn it off for all meteor create's. I would rather not have to run meteor remove autoimport every time i create a new meteor app.
I’ve worked on fairly large projects in Meteor (nothing HUGE, but still reaching many hundreds of templates etc) and haven’t had any issues at all with autoloading. Considering this, I would guess the trade off would not be worth it for at least 80% of the projects out there.
And let’s be realistic here, which is the lesser of 2 evils - having type a single “remove” line, or having to go through hundreds-thousands of files adding import statements in order to upgrade a project if the backwards compatibility is removed?
If your project was pretty large and ran 100% fine with autoloading - no issues whatsoever, would you really want to update it to a version w/o backwards compatibility if there was no gain? Or a better example, if you worked for a business that had a large application that ran fine, would you want to invest the money for the developers to update it to 1.4 if backwards compatibility was removed? I would be willing to guess many people would skip on the update as long as possible in order to not waste money on upgrades that will not improve anything for them.
One final note - you mentioned “we have to make weird directory structures to make it the way we want”… When I look at the new recommended directory structure, I honestly think your statement fits this new structure more than the old directory structure…
I totally understand that upgrading projects wouldn’t be super easy with this. It would take plenty of time to upgrade old projects.
I think it boils down to how much people rely on Meteor to show them the “best way.” Again, personally it doesn’t affect me a whole lot since I can just remove it, and would.
And regarding the directory structure, no, personally I don’t like having an imports directory. However, I have been trying out webpack:webpack recently which alleviates some of those issues. However, the imports directory is most-likely an artifact of autoloading. If autoloading was removed, than we wouldn’t have to worry about eager loading, and therefore could avoid the imports directory.
Thing is, the “best way” is project dependent. I just hope the “best way” could be decided by the developer in charge of the project, rather than forced in to a specific path by MDG. For my project, and with my businesses resources, I don’t believe manual import is the best way for this project, nor is it in this businesses best interests.
I mean, hasn’t it been one of Meteor’s mantras that they will not enforce specific constraints on our projects anyway?
I see it this way: where NodeJS is a Linux, Meteor is an Apple. Linux gives its users much more choices, lets them to tweak everything there is to possibly tweak. Apple keeps things stupid simple with its own worked out way to do things.
Now, the key for Meteor is to progress, but without becoming Ubuntu.
I’m glad someone brought Apple in (and it wasn’t me
It all looks now like pissing my pants over Apple keynote announcing shiny new OS X with all the bells and whistles but delivering Elementary OS instead. Because, ya know, “it’s standard”
Again - it’s 21. century and I want to connect my external drive, enable Time Machine and move on to the next great feature my client wants (and PAYS for); NOT mounting drives, creating filesystems, writing backup scripts and dread over whether next rsync patch will blow the whole setup and leave me backupless…
And all this because of import I think meteor offers more than just global variables. Other than that i see that 1.3 has much more important announcements like full NPM support which was a big problem as we were dependent on atmosphere npm wrappers and there quirks.
I think there needs to be a specific subset of MDG that advocates for the novice and to keep the platform newbee friendly. I’m talking friendly for someone coming from VUE, Rails, Laravel, jQuery. If Meteor tries to do everything other javascript frameworks do then it gets lost in the sea of indecision. Meteor would always have a clear and easy market advantage if it stayed relevant for small beginner projects. I can spin up simple apps using meteor without a second though. A lot of this is because it’s so opinionated on the full stack. If I lose that ability I’m going to start looking into other frameworks.
