3 ms·
We are using jspm on an inherited codebase that was concatenated "by hand" with Rails' asset-pipeline (it has lots of old libraries and the overrides are very g
by pgz 11y ago
We are using jspm on an inherited codebase that was concatenated "by hand" with Rails' asset-pipeline (it has lots of old libraries and the overrides are very good to handle them).
What we hate is jspm is extremely slow in development for us. There are two main causes:
- The amount of xhr. This is solvable with http2's server push (but
our dev server is in Ruby, and there's no http2 webserver yet).
- Apparently jspm doesn't cache the result of Babel's compilation,
so for each page refresh every file has to be recompiled again.
We will look at Webpack2 when it's released, if it allows us to use these legacy libraries and wins us some development speed we will not look back.
- hardwaresofton 11y agoDo you have cache disabled? Also, how long does your actual bundle time take? For small projects, I actually get away with just triggering the bundle command when appropriate files in the project change. I highly doubt it would work for you, but if you're spending 10 seconds waiting for stuff to come in over the network, and your bundle command runs in 5, you could just do that instead, and actually work with the bundled code (and generated source map) Looks like I'm not the only one who thinks it's sometimes a good idea: https://60devs.com/optimizing--default-jspm-workflow-with-gulp-and-nginx.html https://60devs.com/optimizing--default-jspm-workflow-with-gu...
- ravicious 11y agoI think JSPM should stress the part about bundling. It's the second person that I see who says "JSPM is slow" and the reason behind this slowness is that they didn't bundle the files or bundled them incorrectly. We do the same in our project: we bundle all the 3rd party libs when they change, so only our own code gets retranspiled on each page load. During deployment, we bundle all the JS in a single bundle (which is good for us, as we don't have too much JS in that project).
- darkmagnus 11y agoAny chance you can go into detail how you bundle your 3rd party dependencies separately? I have tried that, without much luck.
- roblabla 11y agoUsing bundle arythmetic. jspm bundle src/app.js - src/[/*] This will tell jspm to bundle src/app.js with all its dependencies, excluding everything in the src/ directory. This will result in JSPM bundling only your dependencies.
- true_religion 11y agoFor me it's like this: > jspm bundle app//* - [app//*] js/tmp/dependency-bundle.js --inject --no-runtime That tells JSPM to bundle everything except your application if your app lives within the app/ directory. > jspm bundle babel js/tmp/bundles/babel.js --inject --skip-source-maps --minify This tells it to bundle the Babel dependencies which aren't considered in the above.
- circlingthesun 11y agoSystemJS is dog slow if you load all your JS upfront. When mostly lazy loading, SystemJS performs reasonably, at least in my case.
- MatthewPhillips 11y agoYou should check out StealJS which is a fork of JSPM[1]. The biggest difference between StealJS is that it uses NPM so you don't need a separate package manager tool. Aside from that, we have built in hot module swapping so dev can be really fast (less than 200ms per change usually). Also on the roadmap is caching using Service Workers. [1]http://stealjs.com/ http://stealjs.com/
- pgz 11y agoWe solved this with https://github.com/jackfranklin/jspm-dev-builder https://github.com/jackfranklin/jspm-dev-builder It's so fast now.