Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Module Loaders Considered Harmful

techblog.ironfroggy.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: JavaScript Module Loaders Considered Harmful

#21

Post by awinder »

wyuenho wrote: post #16
spellboots wrote: post #2

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…

I think the question is where you want to say that the jQuery plugin should load before jQuery. If you have 20 jQuery plugins, which cross-leverage some of the same dependencies, and then all rely on jQuery -- do you want to rely on ordering script tags for dependencies in the HTML? Or do you want to leverage a module system that lets you coherently state what the dependencies are?

Also I'm not sure how Bower got dragged into this since it has nothing to do with module systems. It is a nice tool though for just tracking what third party libraries are in a project and their versions. Not sure what they did to prove to be an "abomination" :-)

Re: JavaScript Module Loaders Considered Harmful

#22

Post by mistercow »

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

Re: JavaScript Module Loaders Considered Harmful

#24

Post by wyuenho »

awinder wrote: post #21
wyuenho wrote: post #16

Earlier quoted context omitted.

> 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…

I think the question is where you want to say that the jQuery plugin should load before jQuery. If you have 20 jQuery plugins, which cross-leverage some of the same dependencies, and then all rely on jQuery -- do you want to rely on ordering script tags for dependencies in the HTML? Or do you want to leverage a module system that lets you coherently state what the dependencies are? Also I'm not sure how Bower got dra…

You can declare dependencies outside of JS. Sprockets does this. Linearizing a dependency graph is pretty easy in most languages.

Bower got dragged is because it manages dependencies while providing no other help whatsoever. It's also frequently used with RequireJS/AMD. So the obvious question becomes, why can't they get in a room and make a baby that isn't a horrifying monstrosity that is the RequireJS config file?

Re: JavaScript Module Loaders Considered Harmful

#25

Post by camus2 »

hippich wrote: post #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 t…

> when needed. I.e. instead of loading one giant chunk

IMHO , The problem is the user is waiting for the functionality to be loaded,not a great user experience especially on mobile,where connectivity can be bad."Bulk" loading is usually cheaper than multiple requests to load parts of an application.

I usually load all the code required upfront,even data is fetched and cached in the background so my users dont have to wait while browsing multiple pages of a listing , for instance. I would never use async module loading in production. It often fails according to my tests.

Maybe using amd during development makes sense on some projects but not in production.

Re: JavaScript Module Loaders Considered Harmful

#26

Post by ianstormtaylor »

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.

Re: JavaScript Module Loaders Considered Harmful

#28

Post by christocracy »

guiomie wrote: post #23

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

This is unmanageable for complex, "single page apps composed of many files (eg many tens of files). Often a complex app might deal with role-based features, where only certain sets of controllers are included per role.

Re: JavaScript Module Loaders Considered Harmful

#29

Post by mcantelon »

jamesaguilar wrote: post #18

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

Maybe because "considered harmful" is an unimaginative title component and a lack of thought in the title might be indicative of a lack of thought in general.
Post reply on HN