I dunno. On one hand, I get the complaint that es15 makes the language fundamentally more complex, but I don’t think you want a situation like what happened with java where the language basically stopped evolving.
I originally was very negative about es15 because I teach a javascript class and I thought it would make things more complicated, but honestly my experience so far is that there are few additional pieces of syntax that work very well with the old specification and provide some much clearer functionality. Teaching beginning programmers how let works is much more intuitive than hoisting with var for example. Just my 2c.
I have a question by the way… Does modules in Meteor have the advantage of lazy loading .css and .html?
I’ve tried to put .html files in my imports directory, but they’re always eagerly loaded anyways… I’ve tried this with the new 1.3 beta #11 release, and had the same issue with earlier beta releases.
My guess is that this has to do with Blaze not having the concept of imports/exports. The templates are all global and the html file doesn’t really export anything. The html is compiled to JS so in theory this is all possible, but maybe something we can expect when Blaze is moved to its own repository: https://github.com/meteor/meteor/tree/split-off-blaze
Maybe @martijnwalraven, who is apparently working on it, can shine his light on this and tell us what the plans are.
I don’t have much to add to that. @benjamn will be able to explain much better what the current state of things is and why, but I suspect you are right.
I’m not actually working on Blaze, I’m just splitting off packages into their own repos to make community involvement easier.
I fully endorse @reoh’s answer above, re: the general advantages of having some kind of module system.
More specifically, here’s a presentation I gave about why ES2015 import and export are an improvement over CommonJS require and exports, which is still the most widely used non-native JS module system, since it’s what Node (and RequireJS) implement: http://benjamn.github.io/empirenode-2015
These slides in particular make the case for why JavaScript needs a standard, native module system, rather than just another library that most (but not all) people have agreed to use: http://benjamn.github.io/empirenode-2015/#/32
Finally, with Meteor 1.3 (and for the foreseeable future) you will still have the option of using automatically imported variables like Meteor and Accounts, without explicitly importing them, so you don’t have to think in terms of modules until you’re convinced of the benefits. And if you really prefer CommonJS to ES2015, you can still use require and exports (and module, too). I don’t mean to suggest I have any doubts about import and export, but I do recognize it’s important to be able to write code the way that makes sense to you, without having to port everything to some new style all at once.
It’s really fantastic that this approach is being taken and is being clearly and consistently communicated across different channels. The takeaway that most people should (hopefully) consider is that there’s a refactor path here: For beginner developers and folks who are quickly prototyping something, they can just drop objects into the global space. And as the project grows and explicit load-ordering, testing, and other features are needed, they can layer in imports/exports.
Thank you for your answer. There was another question by @goatic, about Blaze/html templates and css import and export. Are there any plans on making this possible?
Are there any such plans to support it? It would be nice to import Blaze templates in 1.3 instead of depending on the global Template var (which of course will stay that way for backwards compatibility).
So do Meteor packages, which are in Meteor already and are recommended for medium and large apps. If somebody writes a Meteor app, complains about loading order and doesn’t use packages, imho it’s his own fault.
That’s a cop-out to the actual problem, which is the load order of the application.
Claiming you can just use packages is just masking the problem. Sure, packages might be useful, but in the end, you might was well use imports if you want to dictate load order.
I’ve tried this with the new 