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 modules, you probably should.

Point 2: 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.

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

This complaint should come with a severe disclaimer that it only applies to trivial applications, because as soon as you start building something complicated the arguments are just plain wrong.

Software engineering is hard, and robust software engineering practices usually only pay off once you get beyond trivial examples. The ones that work, however, pay off massively once you do use them for more complex use cases.

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.

Load order is a lot of what modules are there for. If A depends on B, B needs to load first. If you are depending on side effects of the module load or other undocumented dependencies, you should Google "considered harmful" and spend a few days reading the results.

All of the issues in #1 and #3 don't actually come from modules, but from "doing it wrong" -- preprocessors and forced dependencies and all the other bad practices that have been tacked on top.

I'll bite, is this article supposed to be serious?

Ad #1, maybe my projects have been too small, but I never felt lost even when using CoffeeScript as the source. I mean I can see in the comment above the module which file it relates to.

Ad #2, not sure this applies to CommonJS.

Ad #3, there are really just 2 standards. Not sure that just saying what the heck, I'll just use the global `window` object is a better solution when trying to integrate multiple different vendor libraries and your code.

The author makes the mistake right at the very beginning of conflating module loaders and specifications for modules (like CommonJS).

Module loaders, that is code that loads other modules onto the page after page load, are overkill. Most sites just don't have enough JavaScript logic to make the size of their JavaScript (compared to the two huge images on their landing page) the biggest problem they should be worrying about. Just concatenating all of your modules into a single script and call it a day.

But module loaders have nothing to do with the module definitions themselves, like CommonJS. Separating code into small modules is useful for 90% of projects too, basically everything other than single page, or completely static sites. And if you're thinking that modules are overkill then you're probably using a poorly designed system for organizing them, that adds too much friction to the creation or installation process.

Unfortunately that confusion in the introduction is going to make this comments thread go all over the place, for what could have been a could argument against complex module loaders.

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 <script> 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.

To the point of module loaders making it difficult to understand load order, I'm not sure I understand the problem. The load order is pretty much trivial since I'm loading modules that don't execute on load. They execute on the order that I've defined, so all should be expected there. When you need an expected load order as when you're defining scripts in the document as synchronous loads, you're defining implicit dependencies. One of the great strengths of AMD systems like requirejs is that it turns implicit dependencies into explicit ones.

>However, the fact is that the vast majority of our projects don’t have such complicated intra-module dependencies to really justify this.

I feel like this sentence is revealing. The problem isn't with module loaders at all. The problem is with using the wrong tools for the job.

The author clearly simply does not work on the kind of projects for which module loaders are intended. If you are working on small projects with few dependencies, your debugging, loading, and workflow are going to be uglier for adding a module loader.

But the bar for when that situation reverses isn't very high. Even a medium-sized project can quickly reach the point where you have dependencies that are difficult to manage by hand.

And if you opt to do manual script tags in that case, you're in for headaches. Debugging improperly ordered scripts is a pain, understanding the required load order is difficult, and your workflow is bogged down when it comes to adding new libraries. It isn't as simple as adding a new script tag, because you have to figure out where to put it.

On the other hand, pretty much none of the gripes listed in this article matter if you use something like browserify.

I don't agree with his point #2 in two ways. For one of our internal applications, we had so much <script> tags embedded into our single-page-app index.html that it was very hard to keep track of dependencies. If you have a straight dependency order, sure it won't matter, but if you start refactoring things out and one module has a bunch of dependencies that also has dependencies, this essentially degrades into rolling out a manual topological sort of the javascript files you include. On top of this more than one engineer works on the application, and different engineers inserting <script> tags at the same time caused a few headaches.

To mitigate this, we introduced RequireJS to our internal app, and now the dependency is declared at module definition so you don't have to sift through a list of <script> tags. You don't fear breaking dependencies of each script files because you put one on top of the other. IMHO it is much better to declare the dependencies to your module explicitly than implicitly through a very carefully topologically sorted series of <script> tags.

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 system). the fork is here: https://github.com/snird/Mildred and I use it in production now.

Cross post from the site comments:

I really can't see the problem of harm #1. If you use require.js, by default the same javascript file you are editing will be used by the browser, not changed in any way. You don't even need source maps for this.

The order of the modules don't really matter. For example you have module A and in order to work properly requires "module B" and "C". You don't care when the modules A, B or C are loaded because when you use the module A, the module B and C are already available to be used (thanks to the module loader). For example:

// moduleA define(['moduleB', 'moduleB'], function(A, B){ // here you have module A and B // and I don't really care the real download order. // That's the job of the module loader })

In require.js you can also define the dependencies of third party libraries and which variable they export (check require.js config). For just 20 lines a library can work with require.js AMD modules and with Commonjs. This is nothing compared with the total lines of the libraries, when you take in account the benefits.

I never liked to have multiple script tags in my html files because when you need more than 20 it really get messy. You also have to take care about dependencies at a global level, which is harder.

From what are you saying you write some big javascript files that contains your whole application. I prefer to keep each class in their javascript file and keep it as organized as possible. The order of the loading of the modules is not up to me to think about.

I just want to define a module and it's dependencies. I also don't want to manually select the files I need to have in the build file (a file that contains all the small files). Require.js allows you to create a big javascript file for deployment with only the modules you required, not more.

It's just crazy to not use some kind of module loader today. Check my explanation on how to use require.js with yeoman (http://www.webdesignporto.com/3-steps-to-fully-automatized-j...). It's just a lot more easier to develop big web applications, if this is what you want. Of course if you only build some websites that requires jquery to show up some popups and this kind of stuff, is overkill to use a module loader.

Hope you might change your mind about module loaders.

I hate them . JS modules literally break any tool you throw at them. And the gains in code "modularization" aren't really that significant. Namespaces in JS are decent.

Don't worry it only gets better soon with ECMAScript 6 Modules http://wiki.ecmascript.org/doku.php?id=harmony:modules

or does it? http://calvinmetcalf.com/image/75296462861

Sorry but no.

Any language intended for large scale development has to support modules.

Until ES 6, this is what we have. I surely will keep on using them.

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?

Somehow, "considered harmful" has become a strong signal that the arguments in the so titled article will be weak. Why is that?

I've never understood why I should use a module loaders ?

I simply declare my .js files in my main html page and the is it ...

I would never do a large JS project with out modules. But I also never use "module loaders".