ES6 modules VS Meteor packages

core
1

I’ve been away from Meteor and JavaScript for a year, but since then support for ES6 modules has been added, and I guess it’s the future, since it’s part of the language. I’ve been using it for a package I’m working on, but boy what a pain. What I really love with JavaScript is its simplicity (les code, more functionality), but that’s something I no longer recognize in the module system in ES6.

Maybe I’m doing something wrong? I write classes and put one class in each file (just as in Java), since that’s a proven structure that works great. However, each time I need to use a class (in my own package) I need to import it, and that’s like adding an additional line with 25 characters. It’s worse than Java, where classes in same packages can be used with no explicit imports.

I really liked the traditional way of writing a meteor package: global variables become package variables, and you can specify which package variables that should be exported (usually a single variable containing an object with all the classes you want to share). So little code to write, and there is no additional syntax to learn!

To me it seems like Meteors package system is much more convenient to use than ES6 modules. Am I wrong?

2 Likes
2

Although Java allows us to use import packagename.* it isn’t recommended and at least we have tooling that would do it for us. ES6 on the other hand does not allow wildcard imports and as tooling goes I haven’t found one myself that I would trust.

One nice thing about Meteor (though not recommended by the guide) is it loads up all the JS files that are in the application short of imports/ folder. I personally liked and disliked that capability. I like that it prevents me from dealing with importing explicitly, I disliked that load order is done through directory/file names rules rather than being smart to which files should be loaded first (but at the moment JS does not support that logic anyway).

What you can do is to create index.js files which will import all the files in the module folder. That way you can import just the index.js file without having to load up each individual ones. You don’t even need to say /index.js

https://github.com/trajano/meteor-boilerplate/blob/angular/client/main.js#L6

However, that in itself has it’s own flaws namely it will not export anything and the only UI framework that would load this up properly is Angular1 because it has it’s own module system. Although you can use it with FlowRouter if you’re using React/Blaze

3

They did sacrifice convenience for the new features moving towards NPM Meteor.

My worry is that the backwards compatibility is supposed to only be temporary. I think that is very unfair to us Meteor developers that have been using Meteor for years. We are basically being punished for supporting Meteor early, as our large projects are going to be hell to upgrade to modules.

Although some of the MDG staff has stated they will again be looking at the convenience factor of Meteor. I just hope they stand by the 7 principles Meteor was built upon, and do not lose themselves in the transition.

It’s a very mixed bag for me. I still love to work in Meteor. But some of the things I enjoyed most will be gone once backwards compatibility is dropped, and I am worried Meteor will stray further and further from those 7 principles over time.

I really don’t see why Meteor’s backwards compatibility simply doesn’t help us transition to imports (or remove the necessity of having to do imports unless if you want to manually set them for load order issues etc). I mean, popular IDE’s have similar functionality. If an IDE that is external to the platform can do it, the platform itself should be able to do it too. At least for the Meteor API/templates. Outside of a very few special case scenarios, I don’t see a reason why Meteor can’t simply automatically add import API calls that are used in a js file and/or import related templates. For any external NPM packages it makes sense to import… But it really does not make sense to be required to import Meteor’s own API’s on build, or template files used by Meteor.

It’s kind of like they forgot about one of their 7 principles… “Simplicity = Productivity”. Maybe that’s why they removed the 7 principles from the website completely…

Hence, my worry that Meteor is losing itself just to try to meet some arbitrary standards. Even though those standards could easily be met by making (most of) the newly required imports to be optional only for special cases.

2 Likes
4

Don’t take it personally. Plus, you have to kind of expect as an early adopter that there’s some level of risk of your codebase becoming out of date. I’ve been building a SaaS since August of last year, and I’ve had to refactor some major stuff more than once! But it’s fine, because it means that Meteor is growing and improving, and I’m ok with that! You shouldn’t see it as a negative thing IMO.

2 Likes
5

Completely understand that (and have thought it myself). I’m aware of the situation.

Thing is, I onlythink it’s negative in the context that Meteor is losing touch with their principles they are built on. Without those, it loses the benefits that brought me to choose Meteor. Once those are gone, for what reason would people actually have to choose Meteor over the competition?

The more of their principles Meteor gives up in order to compete with the competition, the more it becomes one of the pack, rather than actually standing out (or leading) the pack. You can clearly see if you watch these forums, the question is being asked more and more “Why should I choose Meteor over the competition?”.

I think if they were on the right path, that question would be asked less, rather than more. And I can’t lie, when I look at the road map, I have to ask that question to myself. Most of the most exciting features I wanted from Meteor are already complete. 1.4 looks to have some nice upgrades w/ node version/mongo, but past that, the road map is more scary than anything. For example, being able to install through NPM doesn’t really benefit my project, SQL doesn’t really benefit my project, and the drawbacks that come with those (such as losing backwards compatibility) hurt a lot more than the gains.

Meteor is the right choice now, but in 6 months will Meteor deprecate those reasons? That is a disturbing question to have to ask. In their journey to try to make Meteor suitable for more developers, losing their principles could potentially lose even more developers, as I’m sure I’m not the only one in this situation. Meteor became popular far before these changes precisely because of those 7 principles it was built on. What is expected to happen when those are thrown out the window (which they seem to have been?).

Honestly, is it not happening already? 1-2 years ago all you seen is people talking about how “Meteor is dominating full stacks”. Now I can’t even say that Meteor is more popular than before (Meteor dropped a bit on Github rankings compared to last year, rather than moved up) and the general tone has switched to Meteor is only worth it for very specific scenarios (even on this forum - refer to the post where the user has an article of why & how he switched from Meteor). With new features we’ve been getting (such as NPM support) Meteor should have blown up. But has it? Seems like a slight decline to me. The reason for that I believe is simply because their principles got put on the back burner in order to provide those features.

In the end, it makes me wonder why not make solutions to these problems and stick to the core principles? If an IDE can do it, the platform itself can do it even better.

I feel a bit bad for sounding so negative, as I do love Meteor. It’s because I want to see Meteor actually improve and grow, and most of 1.3 and the road map sound more like a mixed bag rather than an improvement if the trend that started in 1.3 keeps up. Sounds like by the end of it, Meteor (as we know it) may not even exist anymore… and sticking to older versions will not be a viable option forever.

2 Likes
6

Few things from my perspective.

  1. Fast to get a working prototype out which is also fast to get a minimum viable product.
  2. Client/server reactive binding for free when we need it, primarily in lists and views. Your users would really thank you for this.
  3. With Apollo coming soon we can move the minimum viable product to a database that is better managed in the enterprise with global resourcing (such as DB2 or Oracle).
  4. Easier mobile app deployment for minimum viable product.

Even with the last one allowing us to use DB2 and Oracle, the reactive binding isn’t available to other languages (yet). So Meteor would still be the tool for me going forward for any UI application that would require reactive data binding.

Of course if the reactive data binding requirement goes away then it’s more free for all for me because many other tools can do the job and the UI can simply be some SSR server for ReactJS or Angular2 connecting to a REST service. However, that reactive data binding is a very good selling point for user experience it’s hard to let go once you have it.

7

People seem to be speaking of this as if it was a MDG decision to implement modules. I don’t see it that way.

It was an MDG decision to bring support of the latest ECMAScript 6 & 7 into Meteor.

Bringing Meteor up to date is the real focus of virtually everything that has happened this year. We were dangerously behind and suffering for it.

Now, we’ve got ES6 and 7 which brought with it Modules and a whole lot of other goodness. And we’re fixing to get Node 4 and MongoDB 3.2!

As soon as Node 6 is stable, we’ll get that. I’m looking forward to it because I am occasionally having to pick inferior NPM packages because the latest ones only support Node 6.

Many NPM packages I’ve looked at lately are also using Modules.

The decision to catch up and to make changes that should allow them to keep up more easily has been painful, but is right.

Arguments about Modules or not were appropriate when TC39 was in the consideration process. As of last year, they were here. We’re just joining the party.

3 Likes
8

I’d argue that a company or product is not successful due to its principles, but its usefulness. IMO Meteor has only gotten better. And in fact, by being compatible with npm packages and using ES2015 modules, it’s helped bridge the gap to technologies people are more used to working with, hence making it more approachable by traditional JS & Node.js devs.

9

I can understand how usefulness is important. Meteor did become more useful in some ways.

With that said, I can not support giving up their core principles. I believe that would be/is a major mistake. Meteor was built upon that, Meteor became one of the top 10 on Github because of that. Even without the features that increased it’s “usefulness”.

Meteor for me has always been about not only the results you could achieve, but the amazing amount of productivity. So it is extremely difficult for me to be able to say Meteor is “Better”, when the productivity has went down in most cases.

If what you said were true, and it has ONLY gotten better, and has become approachable by more JS and Node.js devs, shouldn’t the popularity be way up? As mentioned earlier, if you look at the statistics, it seems Meteor has been in a slight decline compared to a year ago.

If it successfully became more approachable by JS and Node devs, why would the numbers have not soared? Seems that aspect was not a success.

And let’s be honest, overall Meteor became less approachable. Now you actually need to be a prior Node dev to really understand what’s going on. This was not the case before (the employees we hired can attest to that).

In the journey to become more approachable, it has become less approachable. That is my point. And the reason? Giving up that core principle of “Simplicity = Productivity”.

If this trend keeps up, do you think Meteor will grow, or decline in to the future?

1 Like
10

I can’t agree there. I was definitely not a Node.js dev before Meteor. In fact, I actually wound up learning Node.js as a side effect, and I’ve become more knowledgeable and therefore marketable as a result. Sounds like a good thing to me! :slight_smile:

You can’t base it solely on GitHub rankings. I’ve actually seen more Meteor jobs pop up now, there are way more course materials on it than there used to be. You see services like Bluemix and NodeChef specifically have guides on deploying Meteor. And when I talk with fellow devs now and mention the word “Meteor,” instead of hearing “what’s that?” they actually acknowledge it! So I would argue that Meteor is far more popular than it used to be.

2 Likes
11

Just as some background for the Node dev thing, I had to hire assistants to help with development of our software. The job listing went up months prior to 1.3’s release, and based upon Meteor 1.2, we searched for primarily front end developers who are comfortable with js. At the time, this was completely suitable for the job - I learned Meteor originally alongside a friend of mine who was a front end dev and had no problems picking it up.

After we accepted the applications and hired some employees, 1.3 released. Even the tutorials changed. When the employees started, they were NOT suitable. I ended up having to train them myself. 1.3 actually confused them more than anything.

So I have personal experience with employees that directly indicates what I stated earlier - that the job requirements are not the same as they were Pre-1.3.

In response to your first comments… The question is when did you learn Meteor. Considering you have been around the forums awhile, you learned it Pre-1.3. So your situation completely makes sense. All I can say is things are definitely not the same now days.

Now for the popularity discussion… of course our mileage may vary in our experiences, but 1 year ago Meteor was discussed everywhere. Articles about how it is so much more productive than Express, about why it’s dominating stacks, etc. Even here on the forums, things were generally very positive.

Fast forward to 2016… I was honestly shocked by coming to these forums after not coming in awhile. Morale was way down, and the general tone was much more negative than it was in 2015. Even now, there’s many more negative comments here, much more confusion with the direction of Meteor, more worry, more questions of “why?”. Even more posts on why people switched from Meteor. When a year ago it was why people switched TO Meteor.

Outside of these forums, the general tone I see now is Meteor is “a very specialized tool”. Which is drastically worse than the discussions about it 1 year ago praising it’s productivity and explaining why it makes the other stacks obsolete.

I actually haven;t seen more Meteor jobs pop up, the most I seen (locally at least) were near the end of 2015 ironically.

So it does come down to perception a bit, I see a slight decline, while you sees growth. The reality is probably a mixture of both - growth in some areas decline in others. But if things have improved so much, shouldn’t it be noticeable growth? Isn’t it kind of worrisome that the discussion went from “replacing a whole stack” to a “very specialized tool that is only useful if you absolutely need a lot of real time reactivity”?

In the end, I just hope Meteor continues to be the platform that made me love using it. The direction & apparent dropping of the core principles makes me extremely worried. I do not know what Meteor will sacrifice next in order to achieve their goals. For my position, there’s much more that could potentially be lost than it seems will be gained in the updates that are coming after 1.4.

Productivity is my top priority. Productivity used to be one of the principles Meteor was built on. If that’s sacrificed, this isn’t really Meteor anymore.

12

I just found definitive proof that using Meteor’s ES2015 module support, and native npm support, is the only way to go:

If for some crazy reason you don’t believe the above graph, then look at it this way: that graph was generated using a Meteor app built in a few minutes, levarging an npm based xkcd style plotting package … because of course an xkcd style plotting package exists … Good luck finding that on Atmosphere (embrace the wider Node/npm ecosystem is right!).

5 Likes
13

@hwillson lol

I just want to clarify.

I’m not against Modules at all. My issues are solely with the implementation of modules in to Meteor. They were implemented at the price of productivity, and in exchange they threw away the core principles including the ones about productivity (and removed them from site completely).

That’s my real issue. It’s completely possible for modules to be implemented in a way that will offer better productivity than the current implementation (at least for Meteor API and template imports). But it seems like that will not ever happen, as the whole productivity principle has been thrown out.

I do not want to see productivity be reduced any more than it already has.

14

No need to clarify, you’ve explained your points very well. To be honest I really just wanted to draw a graph using a random xkcd package, because, well … Friday :slight_smile: .

2 Likes
15

You’re right, and yes, everyone’s experiences are different, depending on when they learned, their previous experience, what they’re working on, if they have a team or not, etc. I started with Meteor when it was 0.9. And I’ve got two projects, one is my own SaaS on which I’m the only dev, and I also do consulting work for an agency, but it’s a very small team.

16

I picked up Meteor having not programmed for years as a way to try and make a fun site and do some learning. I made good progress over several months, did plenty of refactoring as part of the learning process, and finally started getting a project that actually looked and felt like I wanted. I had to step away for a few months and during that time the move to 1.3 happened. As a side project that I could give a few hours a week I felt like I was so productive, now I look at all the work that must be done to move to ES6 standards and my motivation has been zapped away. I do need a good amount of hand holding and Ive only found one decent guide by TMC about the transition ( I do not find the meteor guide to be helpful!!). My code gets slowly better, but Ive been moving through quicksand to make changes while if I was using that time still doing 1.2 I would be actually advancing. I think all the changes make sense to move to npm and i understand why MDG did what they did. I’m just dissatisfied with the changes and another person venting.

1 Like
17

I agree a lot with @Spyridon; Meteor isn’t as easy to use as it once was.

One of the reasons is ECMAScript modules. I do see the benefits with using them (avoiding global variables, make code dependencies easier to track), and I’m glad that Meteor has added support for them (one can’t expect anything else), but life was so much simpler without them, and that’s why I love JavaScript; it’s simple. But maybe Meteor shouldn’t force us to use modules? Maybe Meteor should allow us to to use modules, but also keep supporting their own excellent package system?

Another reason is that Meteor has become more general and less specific. For example, we do not only have Blaze, but also Angular and React. There are more decisions that needs to be taken when starting a new project now compared to a year ago. Just as with modules, this is not a bad thing, but it sure makes life more complicated and reduce productivity. Being a “Meteor programmer” is no longer enough, you must say “I’m a Meteor programmer who knows that and that”. Meteor has become more of a build tool than a specific way of implementing web applications, and I find that a bit sad.

1 Like
18

Some more statistics to back up the issues I was describing: https://www.google.com/trends/explore#q=%2Fm%2F0t545zt

You can pretty clearly see how I mentioned 1 year ago Meteor had so much momentum. It seems to have peaked immediately prior to 1.3 release, and 1.3 release actually was alongside the first 4 consecutive month decline ever.

You would expect that 1.3 would invigorate Meteor. But, no evidence of 1.3 bringing any actual momentum back to Meteor, clearly the opposite.

We could call it coincidence, but the combination of the major decline coinciding with release, as well as the release not actually sparking more interest, seems to be a pretty clear indicator that the new direction is causing some problems and likely not positive for Meteor in to the future.

As someone using Meteor through the transition it’s not hard to understand the problem, either. Even for experienced users, productivity has went down. But it seems hard to convince those advocating the new direction that there actually is a problem.

Meteor can easily bring back the productivity, which with the upcoming features I believe would bring that momentum from 2015 right back. But on the current path, upcoming features alongside reduced productivity? Seems more likely that reduced productivity will cause more of a decline than the momentum the new features will bring. Productivity was one of the top things Meteor had going for it. And you can clearly see that once the productivity went down, so did interest. There’s some sort of correlation at the very least.

19

You can ignore modules completly and still use meteor globals in Meteor 1.3 and 1.4 (with the old file order rules still applying).

1 Like
20

Hi @akryum I interest with this. Can you explain more technically?

Thank You!