ES6 modules VS Meteor packages

Well, just write your application as you used to and it will still work.

This is true, but that functionality is supposedly going to be deprecated in 1.5 (which is the cause for concern)

Have source for that concern?

MDG staff has mentioned it themselves on forums to confirm it, I forgot in which topic but a search should pull em up.

Also, the guide indicates this directly as well:

Since this is a new feature introduced in Meteor 1.3, you will find a lot of code online that uses the older, more centralized conventions built around packages and apps declaring global symbols. This old system still works, so to opt-in to the new module system code must be placed inside the imports/ directory in your application. We expect a future release of Meteor will turn on modules by default for all code, because this is more aligned with how developers in the wider JavaScript community write their code.

Again, I understand the intent of it wanting to align with Javascript as a whole. But my issue with this is Meteor used to be around making development more productive (including the 7 mentioned principles that it was built around) and Meteor was leading the path for Javascript developers. Now Meteor seems to be conforming to the Javascript path, and letting productivity take the back burner. Now it’s Javascript leading the path for Meteor, and not Meteor leading the path for Javascript,

In my opinion, the best approach would be to support the functionality that Javascript developers may expect, but it’s also very important to keep the Productivity principles that Meteor was built on, or else it’s a bittersweet trade-off, rather than an “awesome new addition”. By all means it “should” be an awesome new addition (and that’s what many of us expected prior to 1.3) but instead, almost immediately after release the forums blew up with confusion - especially since the tutorials even got multiples longer.

Automating systems like this (for at least the Meteor API and associated template files) should not prove difficult at all, and could both preserve the original (more productive) Meteor way of doing things, while also providing the deeper functionality for those who actually need it.

Since my project is very large and doesn’t actually gain anything noticeable from modules, I would be surprised if >10% of the Meteor population actually is able to see any gains from the functionality. For most of the population, it’s simply slowing down the productivity a bit.

2 Likes

@debergalis spoke about ease of use changes recently: