5 ms·

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 a

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.

hardwaresofton 11y ago
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 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-102876409 https://github.com/aurelia/framework/issues/94#issuecomment-... Here's where SystemJS devs are discussing adding cachebusting: https://github.com/systemjs/systemjs/issues/172 https://github.com/systemjs/systemjs/issues/172
- sandGorgon 11y ago
  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 ?
  - hardwaresofton 11y ago
    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.
    - sandGorgon 11y ago
      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) ?
      - hardwaresofton 11y ago
        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.
circlingthesun 11y ago
Gulp-rev-all (https://github.com/smysnk/gulp-rev-all https://github.com/smysnk/gulp-rev-all) works well for me.
- sandGorgon 11y ago
  are you using this with systemjs ? can you point out how ?
  - circlingthesun 11y ago
    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 http://pastebin.com/zgBsx7Zj
true_religion 11y ago
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.

hardwaresofton 11y ago

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 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-102876409 https://github.com/aurelia/framework/issues/94#issuecomment-... Here's where SystemJS devs are discussing adding cachebusting: https://github.com/systemjs/systemjs/issues/172 https://github.com/systemjs/systemjs/issues/172

sandGorgon 11y ago
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 ?
- hardwaresofton 11y ago
  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.
  - sandGorgon 11y ago
    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) ?
    - hardwaresofton 11y ago
      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.

circlingthesun 11y ago

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

sandGorgon 11y ago
are you using this with systemjs ? can you point out how ?
- circlingthesun 11y ago
  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 http://pastebin.com/zgBsx7Zj

true_religion 11y ago

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.