5 ms·
has anyone used systemjs + jspm here ? I inherited a codebase using jspm (due to the override registry system that works great with legacy javascript packages -
by sandGorgon 11y ago
has anyone used systemjs + jspm here ? I inherited a codebase using jspm (due to the override registry system that works great with legacy javascript packages - like Handsontabe) and am wondering about webpack.
- pgz 11y agoWe 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.
- pdeva1 11y agowe looked at jspm and switched to webpack. detailed comparison here: http://blog.dripstat.com/why-we-switched-from-jspm-to-webpack/ http://blog.dripstat.com/why-we-switched-from-jspm-to-webpac...
- sandGorgon 11y agohey thanks for that! we are serving our JS files as static assets behind nginx - we dont run nodejs on the server. does webpack allow you to create static assets (htmls,css,js) and serve them ? the big issue is of course the fact that some libraries (Handsontable) are coming from github and are not on npm. is it possible to use them - with overrides,etc. ?
- pdeva1 11y agowell in production u can make bundle from both. the article talks about how development is super slow in jspm since files are loaded individually. yes you can add dependency to github projects with jspm
- ravicious 11y agoI left a comment under your post on reddit. For us, JSPM is fast enough and we don't have to run a second server just to serve assets. And, excuse me for saying that, but I found your post lacking in substance. Writing "It's super slow, we've tried everything" doesn't show us about what you've tried and with a detailed explanation maybe the thousands of eyeballs who saw that post would be able to help you find the problem you had. ;) https://www.reddit.com/r/javascript/comments/42ozl3/why_we_switched_from_jspm_to_webpack/czeyfs2 https://www.reddit.com/r/javascript/comments/42ozl3/why_we_s...
- hardwaresofton 11y agoI regularly use JSPM (with systemJS) for new projects, and I've liked it a lot. Back when webpack first came out, I struggled a little bit with figuring out what it actually did. While I understand now, I am not why I would want to (or you) switch from JSPM to webpack. I don't see any features that webpack has that JSPM doesn't (and JSPM offered ES6 support well before of course, with babel on by default). I like to use JSPM because of how relatively easy everything fits together -- and how straightforward it is to use and configure. For those not familiar, JSPM is a package manager, module bundler, and module loader all in one for javascript applications. This means you can: jspm install <package> And JSPM will look in NPM/Github (and it's possible to add registries, like bower) for stuff . That's the package management facet. jspm bundle-sfx js/main dist/build.js Bundle your code all together, and drop it in a file <import src="system.js"> <script> // set our baseURL reference path System.config({ baseURL: '/app' }); // loads /app/main.js System.import('main.js'); </script> Load your modules on the fly like you would with something like RequireJS. As you may have guessed, JSPM relies on SystemJS (https://github.com/systemjs/systemjs https://github.com/systemjs/systemjs) internally for some of the features above. This video really opened my eyes to what it could do: https://www.youtube.com/watch?v=iukBMY4apvI https://www.youtube.com/watch?v=iukBMY4apvI
- sandGorgon 11y agowell 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 agoWhat'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
- circlingthesun 11y agoI'm using SystemJs + JSPM and it's awesome. I previously made use of bower + requirejs. I love how JSPM automatically populates the config.js file so I can start importing whatever I installed straight away. SystemJS loads pretty much any module format so it was easy to use AMD modules while I was migrating to CommonJS. I recently moved over to ES6 modules without having to touch my SystemJS/JSPM config. I've not really looked into Webpack. It seems to be more popular than SystemJS. When I was considering it, the docs were not that great.