Hacker News Reader

Comment by sandGorgon | Hacker News Reader

well i like jspm, but as others have mentioned - it is too slow. is there a way to compile all the dependencies and cache-buster-fingerprint them ? I serve my app statically using nginx and cloudfront.

View on HN

What's your full build/bundle time like? May be faster to just bundle the parts you need and build them (and use the compiled output). Also ensure caching is enabled for the stuff you want to cache (deps, I assume).

Cachebusting is possible with systemjs. Looks like this project is a good start:

https://github.com/stealjs/cache-bust

Here's a quick-n-dirty fix for this same problem when working with Aurelia:

https://github.com/aurelia/framework/issues/94#issuecomment-...

Here's where SystemJS devs are discussing adding cachebusting:

https://github.com/systemjs/systemjs/issues/172

i was looking at the last issue. it seems inconclusive - I like to serve my js from CDN, so this is very very important.

what is your opinion of webpack in general though ?

Ahh unfortunately I don't one worth sharing -- I've only used webpack once, most other projects (big or small) I've worked on have used RequireJS, JSPM, or Ember CLI.

Also, please look at the other responses, bundling deps seems to be the definitive answer to how to speed up JSPM. Though of course your cache busting issue is separate.

so im a little confused. coming from the Rails world I thought cache busting was pretty fundamental.. especially if you want to use CDN.

Is this not baked into every build tool out there ? How does one take care of caching while serving assets .. or is the general philosophy of JS right now around SPA (so dont care to cache) ?

Caching is definitely important for front end tooling, but it depends on which tooling you're having perform the job. It is also generally considered a deployment worry. Cache busting can be implemented in various ways-- by using a templating language (ex. ERB), by using a build tool like grunt/gulp, by using you JS bundler, or by using your module resolver (in the case that the bundler and resolver are not the same entity).

JSPM just doesn't take a built-in stance on it (as of now, as I noted there is a ticket to get it included), but it certainly is configurable enough to allow you to add cache busting (by changing the loader). Not trying to apologize for JSPM -- it would certainly be better if they had some sort of cache busting option that was easily available and obvious.

I think the thought here is that when you're ready to push to production, and you build your actual bundle, you name that file whatever you need to to bust caches.

It is pretty slow, but I'm guessing that's from the Babel compilation.

I ended up compiling the 3rd party dependencies into a single bundle, then letting JSPM run only on my app's code.

Gulp-rev-all (https://github.com/smysnk/gulp-rev-all) works well for me.

are you using this with systemjs ? can you point out how ?

Well, I use SystemJS to build a stream of in memory files and pipe them to gulp-rev-all. My gulpfile is a bit complex but feel free to use it as reference: http://pastebin.com/zgBsx7Zj

Reply on news.ycombinator.com