4 ms·

This post doesn't contain an argument so much against require.js as against module systems as a whole. I think that is short-sighted for any project where perfo

This post doesn't contain an argument so much against require.js as against module systems as a whole. I think that is short-sighted for any project where performance is important because the fact is, most projects of that kind are still using Closure Compiler which in spite of being slow, produces much smaller, more efficient code than does Uglify. Particularly, the project will be compiled with ADVANCED_OPTIMIZATIONS which can break code that will work when uncompressed (when literal property names are not written as strings or externs are not defined properly, mainly). I think any compiler with really high quality output will probably be somewhat finicky with its inputs, so Closure Compiler is not unique in that regard. But if you don't buy into compilation as a step in your frontend development cycle, I'm not sure there's much point in using require.js, goog.provide/require, or any other module system.

awkward 13y ago
It's interesting that you see module systems and optimizing compilers as two parts of a whole. My impression of the two systems has always been that they're at best complimentary, with some impedances between the two. For example, in the last large js project I was on, we found that the closure compiler by itself - even without ADVANCED_OPTIMIZATIONS - did well enough at optimizing the code that a separate module system wasn't worth it in terms of additional time to refactor.
- lifeisstillgood 13y ago
  Could you expand on that please? You had a set of modules and compiled them into one file and did not use a module system - I am still naive on modern JavaScript work so any guidance gratefully etc.
  - awkward 13y ago
    We had a large codebase already, written with just script tags in mind, and we were being murdered by blocking loads of the javascript. I looked into refactoring to use something like require or labjs that loads without blocking, but would have taken a substantial amount of development time (this was a problem with the existing codebase of 8k lines or so, not the tools.) While we were looking at that, I found that we could make our performance target by concatenating all the source together, running them through closure, and just serving up one monster js file a little under 1MB in size. This was an enterprise system, so we could assume certain levels of client performance that cat picture industry applications probably can't, as well as having a lower bar for performance in the first place - a five second load time on a low performing system was firmly ok, so YMMV.

awkward 13y ago

It's interesting that you see module systems and optimizing compilers as two parts of a whole. My impression of the two systems has always been that they're at best complimentary, with some impedances between the two. For example, in the last large js project I was on, we found that the closure compiler by itself - even without ADVANCED_OPTIMIZATIONS - did well enough at optimizing the code that a separate module system wasn't worth it in terms of additional time to refactor.

lifeisstillgood 13y ago
Could you expand on that please? You had a set of modules and compiled them into one file and did not use a module system - I am still naive on modern JavaScript work so any guidance gratefully etc.
- awkward 13y ago
  We had a large codebase already, written with just script tags in mind, and we were being murdered by blocking loads of the javascript. I looked into refactoring to use something like require or labjs that loads without blocking, but would have taken a substantial amount of development time (this was a problem with the existing codebase of 8k lines or so, not the tools.) While we were looking at that, I found that we could make our performance target by concatenating all the source together, running them through closure, and just serving up one monster js file a little under 1MB in size. This was an enterprise system, so we could assume certain levels of client performance that cat picture industry applications probably can't, as well as having a lower bar for performance in the first place - a five second load time on a low performing system was firmly ok, so YMMV.