[hippich]

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.

[camus2]

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

[hippich]

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.