Meteor 1.3 + ES2015 Modules for dummies

core
1

Hi there!

I am quite new to Meteor (and to the latest trends in JS in general), but I have already managed to get familiar with Meteor 1.2 (FlowRouter, React).

Previously I was trying to learn React via Nope.js/Npm/Webpack/Babel/ES2015 way and found it irritatingly overcomplicated. But then I came across Meteor and instantly fell in love with it’s simplicity: no importing/exporting, no hassle with libraries, Meteor’s DDP felt like a gift from above. This is how it felt for a newbie.

Now with Meteor 1.3 I feel (probably totally unduly) like those nightmares of “cool and too advanced” java script are getting back :sweat:

There is a lot of hype around ES2015 and its modules, but usually its advantages are presented as granted, nobody really explains to dummies like me why is that thing so useful. I read it helps to structure the code, but I didn’t have so much trouble with it in Meteor 1.2. Another thing is loading order — what’s that and why is it so important?

Thanks!

6 Likes
2

@mrkvs you can safely “ignore” whatever you find “advanced” in meteor because the platform is fully backwards compliant.

You can continue using all the ideas you’ve liked in the past about meteor and in time, when you feel more comfortable, sprinkle in those new features and as you grow even more comfortable, you may decide for yourself what you are most productive with.

3 Likes
3

Thanks for your reply!
You see, I feel like I’m missing something. I’m certain the hype isn’t groundless, that’s why I’m trying to get into this thing.

1 Like
4

Well, the “missing” part is open to debate.

These new advanced javascript (and meteor) features allow you more
control on your application structure as your app grows, but you can
certainly live without them since they were not around (at least not as
readily available) last year and e were just fine developing apps back
then :slight_smile:

And everything you see on meteor is backwards compatible, so don’t let
the “hype” - which certainly is not hype - intimidate you. Do ignore
them now and embrace them later when you feel comfortable.

3 Likes
5

Have had the same feeling too, and still have when I look to all those shiny new ‘bloat’. One of the great things of Meteor is it’s simplicity. Now all the import/export stuff is there again. To me it’s a bit like “Okay, we have new toys, lets (over)use them no matter what!”. So I have decided to ignore it until it’s really clear why I would want to use it…

1 Like
6

I know that feel, mrkvs.

I’m pretty new in meteor and development at all and just figure out how to use meteor 1.2, blaze, flow-routes and felt in love with it for its simplicity. I’m somewhere in the beginning of writing my first app and would like to put all the best approaches in its basement. And you know, when everyone screaming around about modules, death of blaze and how cool is react, you don’t want to put all these “old” approaches in the core of your future app. Even MDG suggests to use imports and to choose a react for a long run.

And suggestion like just ignore this stuff, feels like to chose the wrong path on a long run for your app.

P.S. If someone write a blog post or write a video how to use meteor 1.3, react and all modern approches in dev I sure a lot of people will be gratefull to you.

1 Like
7

For benefits, see: https://forums.meteor.com/t/what-is-the-advantage-of-using-es2015-modules/

Load order is the order in which your files are executed. This is important when sections of your code have dependencies like:

// file1.js (loaded first)

global.a = function () {
  console.log('a');
};

b(); // undefined

// file2.js (loaded second)

global.b = function () {
  console.log('b');
};

a(); // 'a'

I feel Meteor packages solved load order problems just fine but having an official js standard will provide semantics with the rest of the js ecosystem in future.

1 Like
8

The main advantage of modules is that your app becomes well… modular.

With a standard Meteor app, all the files get concatenated (with division to client/server) no matter how many users actually use particular parts of your application. So that if you have a huge admin dashboard that only 1-10 people use and all the casual 100000000 users don’t, it will still be sent to all casual users.

The standard way to deal with such thing is to structure your application into microservices. You create separate smaller app for just a dashboard admin etc. It helps to scale your application and it becomes faster for users.

Now the modules. With modules and import/export, you get the option of code splitting. This means that when the user loads an application, only the parts of code that he needs at the moment are loaded onto his computer. Then, when the user clicks on some link with new templates and stuff, this stuff gets downloaded.

It makes for a much faster initial loading, which is crucial for large applications.

But I’m with you, I don’t like all these import/export dependency bullshit, I’ve had enough of it in the past. Even if I know how to use it and did it for years, I simply love how Meteor is free of it. And I do not plan to make large apps anyways.

3 Likes
9

This one is Meteor-centric but very helpful: https://voice.kadira.io/getting-started-with-meteor-1-3-and-react-15e071e41cd1

1 Like
10

@Maxx, I’m glad to hear someone else shares similar feelings :relieved:

Exactly! People are excited about modules, so there must be something to it that eases Meteor developer’s life, right?

@reoh, @brajt, thank you very much for your inputs, it helped a lot!

11

@mrkvs you can get many of modules’ advantages by structuring your Meteor apps as packages. See http://experimentsinmeteor.com/package-based-architecture/ for further details. It’s a step between pure Meteor approach and modules and current official recommendation for medium and large Meteor apps.

1 Like
12

One of the important questions will be what kind of app you’re building. Will it be a MVP, or will it have a long lifespan? Will it be for a large audience or used within an organization?
Do you want to use bleeding edge or more ‘proven’ ways for your development cycle?
I’m also quite fresh with Meteor, and I was struggling with it as well. Eager to start using 1.3 and React, to ensure my newly gathered knowledge won’t be obsolete after a couple of months. But after tinkering around a lot with the gazillion possible ways I’ve decided for myself to just use ViewModel (thanks @manuel!) and optionally make it package-based or microservices if needed.
One of the advantages of Meteor is still backwards compatibility, so it will be pretty painless to use modules and React later, and be able to use several great packages now.

2 Likes
13

With modules and import/export, you get the option of code splitting.

@brajt are you sure we get code splitting with imports on meteor? I believe there still is a single entry point and the whole bunch still gets sent to the client on first load. Or am I wrong there?

14

@serkandurusoy you’re right, we don’t get it yet with Meteor. That’s why i talk about an option. But it’s already available for other build systems with modules and will be available with Meteor in the future. For now, we get code splitting with Meteor+Webpack.

1 Like
15

I got a little excited for a minute there :smile:

16

I would like to know when that comes… THAT would be a be a fantastic reason for jumping into export/import/

17

@brajt Yeah I am with you on imports… I do think it makes sense for NPM, but I really dislike it for the Meteor API & templates.

I believe this is one area that could eventually receive some attention by MDG. It should not be hard to create an automated system that provides the benefits of modules without the user having to manually import everything, as long as they stick to naming conventions & do not create multiple templates with the same name, as well as automatically add the Meteor API imports on build.

Should not be too hard to implement. But if for whatever reason that did not work, I would hope IDE solutions such as WebStorm would add those automatically. JetBrains IDE’s offer similar functionality for other languages.

I would prefer Meteor to just be as user-friendly as possible, with time spent on actually developing the app, rather than toying with the language/imports.

1 Like