Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: