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

41–45 of 45 posts

Re: JavaScript Module Loaders Considered Harmful

#41

Post by sdgfnlk »

I don't agree with his point #2 in two ways. For one of our internal applications, we had so much 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 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 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 tags.

Re: JavaScript Module Loaders Considered Harmful

#43

Post by shadowmint »

wyuenho wrote: post #24
awinder wrote: post #21

Earlier quoted context omitted.

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?

You can have external JavaScript dependency tracking, but you're not solving the problem, youre just moving it from one place to another.

If you want to manually manage it (or manage it outside of js), you can... but complaining that there are various tools that automate that process seems pretty nonsensical to me. Tools that automate things are good.

... besides, what are you even talking about. Requirejs config isn't that bad. If you want to grumble we can start with grunt files and (ugh) painfully repurposed make files.

Re: JavaScript Module Loaders Considered Harmful

#44

Post by wyuenho »

shadowmint wrote: post #43
wyuenho wrote: post #24

Earlier quoted context omitted.

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?

You can have external JavaScript dependency tracking, but you're not solving the problem, youre just moving it from one place to another. If you want to manually manage it (or manage it outside of js), you can... but complaining that there are various tools that automate that process seems pretty nonsensical to me. Tools that automate things are good. ... besides, what are you even talking about. Requirejs config isn…

Solving the problem requires ES6 modules and friends to take over this entire space. Which might not happen in a while.

Lot of tools automate things, few do it well.

ReqireJS isn't that bad? Compared to what? Maven's pom.xml?

Re: JavaScript Module Loaders Considered Harmful

#45

Post by hippich »

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

I am glad that you app can be actually served as one packaged piece without download size having any effect on performance. In my case loading everything is slower then loading needed pieces when needed. I am not talking about loading each view separately, i am talking about splitting application into "sections" and load each one when context is switched.

And yes, what we do here does make sense in production.

Post reply on HN