What is the advantage of using ES2015 modules?

help
1

I’m going to be showing my naivete with this one (I’m relatively new to web development and never had a formal CS background), but I can’t wrap my head around why everyone is so excited about ES2015 modules. I see that it is one of the main features of Meteor 1.3 and pretty much everything new these days has them.

But what is better about ES2015 modules? From a beginner’s perspective, I always hated dealing with RequireJS and never really came around to understanding it. One of the biggest draws to Meteor for me was that you didn’t have to think about any of that - you didn’t have to orchestrate what knows about what. You just wrote your code and it worked. Also, code is so much more readable and cleaner without a large part of the file being taken up by imports and wrapping all of your code for the file in another nest of brackets. I am sort of dreading having to use ES2015 modules for my project, and having to keep track of where everything is that I need in a file.

So what am I missing - what is the draw? Maybe I just don’t understand how Meteor’s magic works, but I love that magic and I will miss the simplicity it provided.

2 Likes
2

Having been in your situation, this is what I learned:

  • Modules solve circular dependencies/make them much easier to use (at least, they will when native support is finally added…)
  • Modules allow you to be rid of global variables (vs Meteor)
  • Modules mean you know exactly where those variables are coming from
  • Modules enforces a strict syntax (must be used top-level) which makes static analysis easier/possible and enabling optimisations

See http://www.2ality.com/2014/09/es6-modules-final.html (Section 4) for more in-depth info.

Meteor certainly made all of this a hell of a lot easier/faster to get started, with less code but for large projects I think modules make it easier to manage, and provide a standard for, maintainability & re-usability.

8 Likes
3

Have you read the Emperor’s New Clothes? (by Hans Christian Andersen)
Do you remember what the child said near the end of the story, about the Emperor?
Well, finally somebody says that about ES2015.

Users (or developers in this case), don’t really know what is Really good for them.
Henry Ford, the inventor of the cars, said: “If I had asked people what they wanted, they would have said faster horses”.
When developers meet a programming language, they are sure that This and That and A and B and C will make this language the Best Thing since the sliced bread, but they are not aware of the price (and I’m not talking about performance).

This is how all of the programming languages became monsters, and were destroyed.
Once in a blue moon, a genius (e.g. Kernigham & Ritchie) invents a brilliant language, and since then, all of us are busy in destroying it.

JS became so popular because it developed wildly, without giving a shit on what the developers demand. So all of us loved to hate it, told jokes about it, but the truth is that it was a great language that allowed us to do things that no other language allowed us, and in a very tiny syntax and libraries.

I used JS 14-15 year ago to develop cool AJAX scripts (though the term “AJAX” had not been invented yet), and even developed my own Server-Side JS (as Apache module, based on SpiderMonkey), much more elegant than NodeJS.
And I was not the first: Microsoft did Ajax in the 90’s (!) (used it in Outlook Web Access), and Netscape used Server-Side JS in 1996.
JS 1.5 (a.k.a EcmaScript 3, Nov. 2000) was almost perfect (except for some minor features from later versions, such as JSON).

But then the bastards decided to kill it.
Well, they didn’t exactly “decided”; they were sure that they helped it and made it better…
And now JS too, like all of the other languages, becomes a monster, and contains all the garbage that exists in other languages.

And the most tragic point (and also the funniest one), is that now everybody and his dog will jump and explain why this is good and that is good, exactly like in the Emperor’s New Clothes.

R.I.P. JavaScript (March 1996 - June 2015).

5 Likes
4

The generally accepted inventor of the modern automobile is Karl Benz.

4 Likes
5

You’re right, of course, and actually I wrote “the inventor of the modern cars” (which is not precise too…), and then thought that one might understand that by the word “modern” I refer to today’s cars, so I removed the word “modern”.
Ford didn’t invented the cars, but he deserves the credit because he is identified more than anybody else with the building of the new car industry and making it huge, serial, off the shelf.
IIRC, he started it before his own factory (he was a co-founder of Cadillac).
And I love what he said about cars and fast horses.
I used it several times in the past in meetings with angel investors, and this power quote always helped me to change their minds.

6

ES6 modules are useful because they allow you to get rid of globals.

1 Like
7

As far as I am aware, you have to opt-in to ES6/ES2015 modules due to it needing to be backwards compatible. You can still use the global variable ‘see everwhere’ version of JS as it is now.

And knowing MDG they won’t suddenly force existing apps to re-write everything into modules or break their app. You should still be able to do it in Meteor.

So, you’re not forced to use them but as your application gains in complexity they will be useful.

1 Like
8

Other benifits not mentioned yet:

  • Logical load order. No longer we need to put our files in deeper directories or change their name to get the right load order. Another option is a package based architecture for load order, but this will no longer be needed.
  • Better support for static type checkers like FlowType and TypeScript
  • Smaller bundels with tools like rollup.js.
  • Faster tests because you import only the code you test.
  • Multiple entry points for one codebase making it easy to create multiple builds (for web, mobile or an admin for example).
  • No need to namespace everything (because everything was global).

This is true in the beginning, but when dealing with a seriously large app with many people working on it, it slowly starts to just not work. So indeed, for beginners it might feel like useless extra work. For people who’ve been at the dark side of Meteor there finally is a solution coming.

As stated in other places: The beginner/hobby projects have different requirements then the professional/enterprise projects.

4 Likes
9

Only, there’s no proof he ever said this.

But to respond to your point: changes to JS are almost always 100% backwards compatible. So you can still program like you’re in the 90s if you think that’s the best way to do it. So what’s the problem if stuff gets added that doesn’t affect you?

10

To give you a practical example, I was working on Telescope the other day and I happened on a getSlug function. I searched my codebase for the string but couldn’t find it. It took me a while to finally find which of the ~30 or so packages used by Telescope actually provided that function.

With modules, there would’ve been an import getSlug from 'xyz' statement at the top of my file that lets me know exactly where this function came from.

(But yeah, like others have said modules are completely optional. You don’t have to use them if you don’t see the need for them)

1 Like
11

This is an interesting idea. How might this work in practice in the Meteor context? Could it be done in a way that would be easy to reason about?

12

Right. “Garbage”.

You can use stuff like this in JS: if (x = 10)
“Garbage” languages tell you that this is a bad idea.

You have to use stuff like this if (x === y) because if (x == y) is not good enough.
But doing switch/case will use the === operator by default.

String concatenation is always fun because of the implicit casts. And there’s fun stuff like this:

Input: "hi"+ +"mom"
Output: "hiNaN"

Or consider this:

var a = 10;
var b = 20;
console.log('result is ' + a + b);

And of course:

"3" * "5" => 15
"3" + "5" => "35"

Further stuff: http://www.12robots.com/enclosures/JavaScriptConfusingBitsKeynote6.pdf

So, please don’t talk about “garbage”. It would be a severe case of the pot calling the kettle black.

1 Like
13

You could have multiple main files that import different modules:

web.js

import '/web/main.js';
import '/web/analytics';

admin.js

import '/admin/main.js';
import '/heavy/module/only/needed/for/admin';

Something like that. How easy it is to reason about, I’m not sure yet. It should be simple because whatever you need in your admin you have imported using modules. Things like “Why didn’t it load my module?” would be answered with: “Well you didn’t ask to load it anywhere in your admin code so why should it? Aparently you do not need it… Or do you :smirk:…”.

Maybe something for a different thread (just like talking about car inventors is), but I’m curious of what you are thinking about that might be hard to reason about with this setup.

2 Likes
14

One of the biggest draws to Meteor for me was that you didn’t have to think about any of that - you didn’t have to orchestrate what knows about what.

Meteor autoloaded files in for you, which you didn’t have to worry about.

Until one day you did have to worry about it because one file wasn’t being loaded in before another. Suddenly, you need to restructure your files just to get them to load correctly.

ES2015 modules helps you with loading in files. I think @reoh’s comment really nails why ES2015 is so great at solving this problem.

15

I’m wondering if it would be more difficult to orient oneself around an app based on the project directory setup.

An advantage today is if you look in, e.g., lib/methods you have some base understanding of methods available to that app. Other methods may come in from packages, and some of the local methods might never get called, but at least all of the local methods were written for the app, which suggests they were intended to get called.

In a structure where only certain files are cherry-picked, much of the code may not be relevant to a given build. Would that add a layer of mental maintenance to working in that app/apps? It’s similar to the problem of how to organize a ‘universal’ codebase for webapp + cordova today.

I don’t know. Thinking about it for the first time :smiley:. It definitely opens up some powerful possibilities.

1 Like
16

[quote=“jeremy_s, post:15, topic:18169, full:true”]
In a structure where only certain files are cherry-picked, much of the code may not be relevant to a given build. Would that add a layer of mental maintenance to working in that app/apps? It’s similar to the problem of how to organize a ‘universal’ codebase for webapp + cordova today.[/quote]

You do realize that’s how Java and C/C++/c# works, right?

1 Like
17

Thanks so much for all of the replies. I can see advantages of modules now, especially when working on a larger-scale app/codebase. I suppose I’ll get used to them and be glad I used them in the future when my project grows!

2 Likes
18

HAHAHA. Oh, you were being serious?

I hate to break it to you, but JavaScript is the future. And I can actually see languages like PHP slowly fading away into obscurity. Are there growing pains with ES6, ES7, etc? Of course. But at least it’s moving now, and I only expect it to improve with time.

3 Likes
19

That’s not true. You don’t have to use ===. In fact there are situations where using == makes more sense. It’s nice that JS offers us the option of using either.

1 Like
20

That’s a matter of philosophies. I’m a rather strong proponent of strong typing and explicit conversions.

Much easier to find errors, much easier to see the actual intention and much easier to not getting it wrong later on just because an implicit conversion bit you in the ass.

This here is a symptom of that: http://docs.meteor.com/#/full/check