Live data from Hacker News

JavaScript Module Loaders Considered Harmful

techblog.ironfroggy.com

11–20 of 45 posts

Re: JavaScript Module Loaders Considered Harmful

#11
Um... I don't know what module system this guy has been using, but I use Require and none of these complaints gave me any pause.

Point 1: Chrome Dev Tools has no trouble whatsoever with AMD. It remembers breakpoints across page-loads just fine. And there's no mismatch between what I see in my source and what I see in the browser, because I load up the un-minified source files for development. Seriously, if you're trying to debug compressed files, the problem is not your module system.

Point 2: This is an argument in favor of module systems.

Point 3: This is the only one that's even slightly valid, but it's only a problem when starting up a new project. Once your Gruntfile is in order, the workflow is simplified - I no longer have to put that extra script tag in, I simply add more files to source, tie everything together just like I would in a desktop app, and they magically appear in the browser.

Re: JavaScript Module Loaders Considered Harmful

#12
post #6

These complaints ring true for trivial javascript projects, however if you are building complex javascript heavy applications the equation quickly changes. Point 1: You will almost always be transpiling your javascript. In any serious project, you will want to have lots of small files to ease development, and then concatenate into larger files to ensure optimal http loading. If you don't already do this regardless of…

For those devs, like myself, who are unfamiliar with large javascript projects, do you have a link to an open-source javascript-heavy project that fits your points?

jQuery: https://github.com/jquery/jquery/blob/master/src/ajax.js

ACE: https://github.com/ajaxorg/ace/tree/master/lib/ace

Re: JavaScript Module Loaders Considered Harmful

#13
When you JS codebase get bigger, it will benefit loading pieces of code when needed. I.e. instead of loading one giant chunk of minified javascript covering all possible states, you load some "global"/"universal" js file and .js file used to render current state. When state changes - another small .js file get loaded and launched.

While all of this can be done using global variables and inserting tags when you want to load module and wait for callback to fire, or setInterval check for module to be loaded, all this already done for you in libraries like RequireJS.

I would say it this way - yes, on small projects you can get away without using more abstract approach to split your project in pieces, but having module-based framework put into project early will allow you to scale code when you application get bigger.

Re: JavaScript Module Loaders Considered Harmful

#14

What are the supposed benefits of using module loaders over say minifying and concatenating all your JS into one maybe two files which are then placed in script tags at the bottom of your HTML?

There is a distinction to be made between having a module system, and how those modules are loaded. You can still concatenate everything together while using a module loading system, you just don't need to load the modules individually in that case.

One potential problem with concatenating everything without modules is that you then need to maintain your concatenation order based on dependencies using some other system. To his second point, you can certainly do this perfectly easily on smaller apps, but it becomes impossible as systems grow.

Re: JavaScript Module Loaders Considered Harmful

#15
post #9

Modules are evil in my experience, they have many disadvantages, much more than the writer points to. When I looked up for some wrapper to Backbone I came across ChaplinJS: https://github.com/chaplinjs/chaplin/ and it was nice, but using the module system was a nightmare. It was so painful, that I forked it and remove the module system from the code (which was a pain, but still less painful than handling the module s…

Can you elaborate on what kind nightmare/pain you came across using AMD? From my experience requirejs simply gives you a bit of structure, helps you organize your code so you can reference other parts of it easily.

Re: JavaScript Module Loaders Considered Harmful

#16

These complaints ring true for trivial javascript projects, however if you are building complex javascript heavy applications the equation quickly changes. Point 1: You will almost always be transpiling your javascript. In any serious project, you will want to have lots of small files to ease development, and then concatenate into larger files to ensure optimal http loading. If you don't already do this regardless of…

> You will almost always be transpiling your javascript. In any serious project, you will want to have lots of small files to ease development, and then concatenate into larger files to ensure optimal http loading. If you don't already do this regardless of modules, you probably should.

I think he was alluding to browserify and the many AST transformation preprocessors it inspired[1], many are just there to deal with other AST transformations....

You don't need a module loader or packager or whatever to concat or order your scripts, tools like Webassets or Sprockets can do that without any new JS code. Hell, a simple Makefile that calls `cat` does a far better job than most stuff out there.

> If you are intentionally or serendipitously relying on script execution order, that is your bug. The module loader has helpfully exposed a bug in your code for you.

I call nonsense on this one. Scripts almost always have to execute in order. Can you run a jQuery plugin without having jQuery loaded and executed first?

> If you have lots of modules, it is simpler to deal with a module system than mashing together a load of scripts.

It may be simpler to deal with files, but definitely not simpler to deal with JS module loaders. I suspect that the current proliferation of JS module loaders / packagers are due to the long time lack of tools on the PHP side to provide something like Sprockets and the fact that JS has no import/export mechanism built into the language. Tools like RequireJS/Browserify/Bower/Component are all abominations in their own way.

[1]: https://github.com/substack/node-browserify/wiki/list-of-tra...

Re: JavaScript Module Loaders Considered Harmful

#19
post #16

These complaints ring true for trivial javascript projects, however if you are building complex javascript heavy applications the equation quickly changes. Point 1: You will almost always be transpiling your javascript. In any serious project, you will want to have lots of small files to ease development, and then concatenate into larger files to ensure optimal http loading. If you don't already do this regardless of…

> You will almost always be transpiling your javascript. In any serious project, you will want to have lots of small files to ease development, and then concatenate into larger files to ensure optimal http loading. If you don't already do this regardless of modules, you probably should. I think he was alluding to browserify and the many AST transformation preprocessors it inspired[1], many are just there to deal with…

You can blame the people in charge of the ES spec. that's the single most important thing to have in any language,how to properly import external files. Having to rely on the DOM to do that is a horrible hack. Requirejs is a DOM library,not a javascript library.

Re: JavaScript Module Loaders Considered Harmful

#20

These complaints ring true for trivial javascript projects, however if you are building complex javascript heavy applications the equation quickly changes. Point 1: You will almost always be transpiling your javascript. In any serious project, you will want to have lots of small files to ease development, and then concatenate into larger files to ensure optimal http loading. If you don't already do this regardless of…

More like: point 1) source maps
Post reply on HN