AMD Support

[ShuoC]

Hi, there,

I saw the example is based on CommonJS (correct me if I am wrong). Just wonder if we could have example based on RequireJS.

Thanks.

[icholy]

Since this is a brunch skeleton, it uses brunch's baked in commonjs support.

[icholy]

Using RequireJs would defeat the purpose of using brunch. But maybe I'm missing something. You have a use case in mind?

[ShuoC]

We have a really big stack of js and even after minification. So we decide to load some js file on demand and require js seems pretty friendly. I guess there is no way I could do loading on demand in CommonJS, right? (Or you guys have some other tricks to do it.)

Thanks, Shuo

[icholy]

hmm, so basically some type of lazy commonjs module loading. Not sure how good that would be because there's no way of unloading them (that I know of at least).

[seankeating]

Do you see an issue with loading many modules? I don't know if such a way exists in CommonJS. I have dabbled with RequireJS but not enough to have a working Ember-RequireJS project working yet.

[ShuoC]

I do like the whole ember-brunch skeleton. However, stacking every js module into one app.js seems a little bit dangerous when the code base grows. By the way, is there some way we could hook RequireJS with brunch?

[ShuoC]

@seankeating We haven't seen it yet. But we do see the init loading time gets longer and longer which hurts the UX, doesn't it.

[icholy]

I was originally using RequireJS before moving to brunch. But it (requirejs) also concatenates/minifies everything into one file for production. The separate loading is just there for development so it's easier to debug. I've had an ember app grow to about 5mb of js. I just use a loading animation in situations like that.

[ShuoC]

@icholy For RequireJS, at least we could specify a few base modules inside the config and the code will be concatenated/minified into these base modules (which finally will be a few seperate js files). In this sense, we could do lazy loading on these modules and they do not need to be one file for production.

I agree the animation does help somehow. However, taking two much unnecessary js code in browser memory seems a little unoptimized. What do you think?

[seankeating]

I was under the impression that the modulization (separate loading) existed even for production apps for requireJS.

@ShuoC - I hear you on the UX problems. We are tackling a lot ourselves with tons of data. Data is easier to handle than a single page application which we are looking into moving towards this year.

[icholy]

@seankeating r.js modularization yes, separate loading not so much. It incurs a pretty significant performance hit. As mentioned before, separate loading is primarily for easy debugging. But that will become pretty much obsolete with source maps.

@ShuoC you have to be very careful when you start adding complexity in an attempt to optimize. Build first, optimize second. Probably preaching to the choir here, but don't forget what Knuth said.

[icholy]

I'm closing since this is unrelated to ember-brunch. But I'm still open to further conversation.