
The state of JavaScript modules - thmslee
https://medium.com/webpack/the-state-of-javascript-modules-4636d1774358
======
LeoNatan25
“Most frontend developers still remember the dark days of JavaScript
dependency management.”

As opposed to now, where even the smallest “app” has hundreds if not thousands
of dependencies for the most basic of functionality (‘need to iterate an
array, better bring lodash’), often there being multiple copies of the same
dependency due to conflicting versions?

~~~
bshimmin
You beat me to the punch: I really don't remember "you would copy and paste a
library into a vendor folder, rely on global variables, try to concat
everything in the right order and still would had to deal with namespace
issues" as being all that big of a problem! It was (is!) simple enough, and it
mostly worked; if you were trying to deploy something to a customer site where
they already accidentally had two different old versions of jQuery loaded in
the page, sure, that could be problematic... but deploying stuff to customer
sites is always problematic one way or the other.

(I accept this is something of a rose-tinted over-simplification, but a
paragraph titled "An ancient fear" probably deserves some slightly flippant
commentary.)

~~~
eloisant
I do remember that being a huge pain in the back, as in:

\- You have to maintain a full list of your files, in order, to include them
in your html page (in dev mode) and concat (for prod mode)

\- If you want to know on what other module a given module depends on, you
have to hunt every call in the source code

\- You can never remove a dependency on an external lib as you can never be
sure it's not used somewhere

\- Upgrading a lib was a pain

Compared to every other language, it was a huge pain point. It's not by chance
that so many people started to work on implementing modules for JS, there was
a real need.

------
git-pull
I support innovation and people who like to code and build great things. And
am happy to see JS is getting these features. I even see a downvoted comment
to "just use amdefine". Well that solution worked fine for me, then 5 years of
amazing hop scotch between build tools and libraries happened.

And while some report benefits and advancement, I have to tell you, the amount
of tools you have to pull in these days just get some single page interaction
going... Just stop. And we need to draw a line between "progress" for the
language and its libraries vs introducing features without discipline. The
more features a language has, the harder it will be for open source and
industry to develop consensus on what's idiomatic.

Want to know another language feature? Being stable.

I swear, it's like the language reinvents itself every year. Give me some sort
of promise when you'll leave the standard alone, _then_ I'll wait for the
community to form best practices / libraries to catch up. After the dust
settles, I'll invest time reading up on the standard.

Ain't trying to jab javascript. Love the language, community is top tier, but
everything these days from build tools to libraries seems like a moving
target.

~~~
pas
JS is backward compatible. So it got that too from Java other than the funky
name. So it's stable. jQuery? Works. Good old document.getElementById? Works.
And thanks to the standardization efforts of vendors (and countless
volunteers, who created feature matrices and feature tests and polyfills, and
so on), now using those is easy, because you can look up what's supported,
what will be supported, and what is deprecated. (So for a single page
interaction you don't need tools. Case in point, last week I coded up a HTML
form with a simple <script> tag. I got so nostalgic I almost wanted to watch a
video of FrontPage 97.)

But if you want to minify your code, and bundle it, and use SCSS/LESS/SASS and
compile that to CSS, and if you don't want to execute the various tools
manually every time, then you need tools. And yes, since these are pretty
simple tools, it's easy to reinvent them, to try out a new mix of them. Gulp
vs grunt? Yeah, grunt's config was horrible. But people still like magical
config files, so we are back with them with webpack. And people want to use
better state management, and shadow DOM, and so on, but they still like to
view their sites in browsers, not just through TC39 glasses, so they use
babel, but that itself evolved over the years. And so on.

And WebAssembly. And TypeScript. Because static typing is really helpful. And
isomorphic whatever. And tools for that. And tools for development. (Nodemon,
hot code replacement, unit testing, code coverage, e2e testing, and so on.)

And even though everything is a moving target, the good bits are still doing
pretty well. (Yarn is pretty good thanks to the lockfile, but obviously npm is
doing well. Webpack lives on but AngularCLI actually works so no need to
handcraft webpack config; and gulp works too, if you want to get simple.)

And you don't need to wait for others to tell you what's best. Look at your
visitors/users, think about their needs, and look at what tools can help you
serve them best. Are you making sites for blind people? Use/support tools that
are thinking about WAI-ARIA/semantic markup. If you deal with mobile users?
Optimize for speed, service workers, write non-chatty [REST] APIs, push
content to CDNs, and think about PRPL (
[https://developers.google.com/web/fundamentals/performance/p...](https://developers.google.com/web/fundamentals/performance/prpl-
pattern/) ). If you serve big enterprises, use tools that provide IE4.01
compatibility, and so on.

~~~
positivecomment
I generally agree, just a small nitpick:

> Are you making sites for blind people? Use/support tools that are thinking
> about WAI-ARIA/semantic markup.

I think developers should always have accessibility in their mind. People (or
organizations they work for) may choose to use IE8 and yes, it makes sense to
draw a line somewhere regards to supporting browsers. They can decide if an
upgrade effort is worth to use your application. However people do not choose
to have less abilities and it's possible that they can't do anything to change
that. I'm not a dictator who says everyone must use _all_ the accessibility
best-practices but usually there's a small effort which can be made with huge
gains.

~~~
pas
Absolutely. But that's still a trade off (between using a tool that might be
better in some other sense, but then you might not have time to add ARIA tags,
or reshape the markup a bit). And usually it's not an explicit requirement. So
it's up to the developer/team.

And I agree with doing the minimum. There was a great site that shows sites as
they "look" like to a screen reader, but I can't find it now. (But it was very
much like WAVE [http://wave.webaim.org](http://wave.webaim.org) )

------
sergiotapia
Just like when Meteor was the hottest kid on the block, ES6 came along and
pulled the rug out from under me.

Now that I'm finally used to ES6, here comes some other frankenstein with more
flesh bolted on.

At what point will Javascript relax and stop reinventing itself and what
works? When will stability become a core goal for the Javascript thought-
leaders?

I haven't worked with .NET and C# for years but I bet I could feel right at
home today. I couldn't say the same for Javascript.

~~~
tlrobinson
Before ~2015: "JavaScript is a terrible language!"

After ~2016: "Stop improving JavaScript, I can't keep up!"

(Not a personal attack, just general sentiment I've observed)

~~~
camus2
> After ~2016: "Stop improving JavaScript, I can't keep up!"

The bad parts are still here that's the problem. The language didn't improve
so much that it got new features. But var, ==, type coercion and co still
exist.

~~~
aaron-lebo
So use a linter which disallows var and some of the worst usages and and use
libraries which make up where it's lacking.

It's the price of improving the language + backwards compatibility.

~~~
camus2
A linter never fixed the runtime behavior of a language, this is beside the
point. The point is the assumption that Javascript is a better language today.

~~~
aaron-lebo
You mentioned var, let exists to fix those issues, hence the language just in
that one area is better.

------
dwaltrip
All of the top level comments are complaining...

How many of those people have written at least 10k+ lines of JavaScript?

These changes are hard, but they are undeniably improving the language.

And as many others have stated repeatedly, it is not necessary to chase the
bleeding edge. For example, I just learned React for the first time a few
weeks ago, and I'm glad I waited (I haven't started using Redux yet either).
I'm also still using browserify instead of webpack. And so on.

------
drej
I recently started working on a JavaScript thingy and I'm really glad for two
things:

1\. These package managers and build systems and all that are fairly
replacable in terms of implementation. They all just give you some namespace
management, but the actual JS code is usually the same or very similar.

2\. I'm using vanilla JavaScript, so even though I have to reinvent the wheel
from time to time, I don't have to support outdated APIs, bother people with
further dependencies, and save bandwidth. And given that I'm lucky enough not
having to worry about backwards compatibility, I can leverage all the Maps,
Sets, UintxArrays and other modern JavaScript goodness that was previously
delegated to libraries.

------
robertkrahn01
The work done by Guy Bedford and others in building SystemJS [1] is great.
SystemJS is a practical implementation of the whatwg loader specification
proposal [2]. Using SystemJS you can use es modules in node.js and the browser
right now. On nodejs it provides an escape hatch via System._nodeRequire to
fallback to node.js' require from within an es module if you really have to.

The one thing that I really miss is that most (all?) JS module implementations
really seem to be focused on static compile workflows. Sure, for deployments
you want that, for development JS as a very dynamic language would offer much
better support for live programming systems if the module systems would play
along nicely. One reason why I personally was excited to see that the loader
proposal initially considered custom locate/fetch/define behavior added via
hooks but more recent discussions about bringing it forward seem to dismiss
that. I think for great tooling a module system that supports both deployment
as well as development needs is necessary and would really add to the JS
ecosystem.

[1]
[https://github.com/systemjs/systemjs](https://github.com/systemjs/systemjs)
[2] [https://github.com/whatwg/loader](https://github.com/whatwg/loader)

~~~
_pmf_
> The one thing that I really miss is that most (all?) JS module
> implementations really seem to be focused on static compile workflows.

That's what baffles me coming from Java and C#; I can have dynamically loaded
modules with strongly typed interfaces in these ecosystems, but not in any JS
module system.

~~~
bfred_it
require() is dynamic and import() will be too. What are you talking about?

JavaScript is not a typed language (yet?) so it's like expecting pigs to fly.

~~~
_pmf_
With "dynamic", I mean "pulled in at runtime" vs. "pulled in at compile time".
See [http://2ality.com/2017/01/import-
operator.html](http://2ality.com/2017/01/import-operator.html)

~~~
Vinnl
Isn't that exactly what `import()` is?

------
franciscop
Something I think is not explicit enough: you can _import whatever from
'whatever'_ independently of whenever that package is updated or not. What you
cannot do is require() an exported package.

This is great and in no way the same as Python 3; with this old packages are
compatible with newer ones, it is newer ones the ones that will not be
compatible with older ones (not ideal, but still acceptable IMO).

------
skratlo
One has to admit that exporting to / importing from global namespace, as in
the old days, is for a typical/small project way easier and simpler than to
deal with conflicting module systems and mediocre dependency/build tooling. JS
module/dependency/build ecosystem is sick and fragmented and The solution is
in the cold.

~~~
bfred_it
I've been doing that recently with Web Extensions. It's not "easier". After a
handful of files I just end up implementing rollup.

------
yladiz
Serious question: what benefit does this (.mjs) have over the current way of
doing things?

~~~
Vinnl
It enables you to not package modules that your app's not using, preventing
the dreaded "shipping x MB to your users".

~~~
yladiz
But can't you just do some "tree shaking" with something like Rollup, so it
only sends the code you use?

~~~
Vinnl
You can only do so _thanks to_ the new module system. From the Rollup website
[1]:

> Since this approach is based on explicit import and export statements, it is
> vastly more effective than simply running an automated minifier to detect
> unused variables in the compiled output code.

[1] [https://rollupjs.org/#tree-shaking](https://rollupjs.org/#tree-shaking)

------
btomstrem
Is web assembly going to fix any of these?

------
simooooo
So... Still a nightmare of competing solutions.

~~~
35bge57dtjku
Some lessons are hard learned.

------
pabl0rg
KotlinJS, please add google closure support and save us from the madness of
javascript tooling, modules, etc.

------
partycoder
Given the fact that few npm package authors understand the node.js event loop,
pick your modules very carefully.

------
ausjke
Don't know what to say really, I just dislike JS no matter how hard I tried,
it's a chaos to say the least, other languages, such as C, C++, Java, PHP are
way more cleaner and reliable to me. Also it's so easy to be burnt out by
those JS new advancements...enough is enough

