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

31–40 of 45 posts

Re: JavaScript Module Loaders Considered Harmful

#31

Post by seldo »

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…

Agreed. On the front-end, module loaders eventually come in handy but their utility isn't immediately useful. If an "anti-pattern" is something that seems useful but eventually isn't, and a "pattern" is something that seems useful and immediately is, we need a phrase for this third state, where it's a pain in the ass to start with and only becomes useful later.

Re: JavaScript Module Loaders Considered Harmful

#33

Post by yuhong »

camus2 wrote: post #19
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…

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.

Reminds me of these:

https://hsivonen.fi/script-execution/

http://ln.hixie.ch/?start=1296711456&count=1

Re: JavaScript Module Loaders Considered Harmful

#34

Post by ttty »

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.

Re: JavaScript Module Loaders Considered Harmful

#35

Post by tieTYT »

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…

Could you elaborate on Point 2? What causes this bug, and how do you fix it? I'm looking for a low level explanation rather than, "Use a Module Loader" because I want to fundamentally understand what's going on when my code depends on load order and how to fundamentally fix it.

Re: JavaScript Module Loaders Considered Harmful

#36

Post by masklinn »

tieTYT wrote: post #35
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…

Could you elaborate on Point 2? What causes this bug, and how do you fix it? I'm looking for a low level explanation rather than, "Use a Module Loader" because I want to fundamentally understand what's going on when my code depends on load order and how to fundamentally fix it.

> Could you elaborate on Point 2? What causes this bug, and how do you fix it?

Unless @async is specified, the scripts linked in a page will be executed in that order. This means it's easy to unknowingly create implicit (and possibly unexpected) dependencies between scripts.

Because a module loader will perform asynchronous loading and execution of scripts, if dependencies are left unspecified the loading order is essentially random (mostly driven by the script's source size and how fast the server happens to respond to that request). A module loader requires that dependencies be explicitly spelled out, or changes are the application will randomly blow up at loading.

Re: JavaScript Module Loaders Considered Harmful

#37

Post by kybernetikos »

tieTYT wrote: post #35
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…

Could you elaborate on Point 2? What causes this bug, and how do you fix it? I'm looking for a low level explanation rather than, "Use a Module Loader" because I want to fundamentally understand what's going on when my code depends on load order and how to fundamentally fix it.

Unlike some languages, javascript files execute as they are loaded. In large projects relying on js files to take actions beyond the most basic definitional type things is usually a mistake because it means that there is evolving global state (always difficult to keep track of) with implicit semantics. It's very distressing to move some code around in the include order for an unrelated reason and then suddenly find that hundreds of unit tests start breaking with bizarre errors.

The way to avoid this is to limit your js files to definitions, and then finally kick everything off with a single call. Module loaders enforce this, but you can follow this advice without them.

It's reasonable to have one file that must be loaded first - this provides the mechanisms you're going to use to define your objects and nothing more. Then everything else can be done in whatever order seems good, before finally kicking off the action. Even registering code with factories and registries should be left until the end. There are some ordering requirements that are legitimate - if you inherit from another class, then the super class will typically need to be ordered before the subclass.

If you're doing a small project where you don't mind having up to 10 script tags in a page, then you'll do better following the 'separate definition from execution' advice than not. You'll do better still using some form of module loader that makes concerns of order obsolete and will let you scale. I like browserify, but there are lots of options, ranging from the very simple to the complex.

Re: JavaScript Module Loaders Considered Harmful

#39

Post by Chris_Newton »

seldo wrote: post #31
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…

Agreed. On the front-end, module loaders eventually come in handy but their utility isn't immediately useful. If an "anti-pattern" is something that seems useful but eventually isn't, and a "pattern" is something that seems useful and immediately is, we need a phrase for this third state, where it's a pain in the ass to start with and only becomes useful later.

If an "anti-pattern" is something that seems useful but eventually isn't, and a "pattern" is something that seems useful and immediately is, we need a phrase for this third state, where it's a pain in the ass to start with and only becomes useful later.

Technical investment, by analogy with technical debt?

Re: JavaScript Module Loaders Considered Harmful

#40

Post by jwarkentin »

seldo wrote: post #31
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…

Agreed. On the front-end, module loaders eventually come in handy but their utility isn't immediately useful. If an "anti-pattern" is something that seems useful but eventually isn't, and a "pattern" is something that seems useful and immediately is, we need a phrase for this third state, where it's a pain in the ass to start with and only becomes useful later.

I disagree that it's really even that hard to start with. It's like any library or framework. You have to learn it initially, but then it's just not that hard. I've been using RequireJS for a couple years as well as node.js and none of the complaints really resonated with me.

I would go so far as saying that the author has probably been using them wrong. If you follow the right patterns and write good code it should be a non-issue.

Post reply on HN