Hacker News Reader

Comment by sandGorgon | Hacker News Reader

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.

View on HN

I 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) 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

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.

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.

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

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.

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.

Do 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-gu...

I 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).

Any chance you can go into detail how you bundle your 3rd party dependencies separately? I have tried that, without much luck.

Using 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.

For 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.

SystemJS is dog slow if you load all your JS upfront. When mostly lazy loading, SystemJS performs reasonably, at least in my case.

You 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/

We solved this with https://github.com/jackfranklin/jspm-dev-builder

It's so fast now.

I'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.

we looked at jspm and switched to webpack. detailed comparison here: http://blog.dripstat.com/why-we-switched-from-jspm-to-webpac...

hey 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. ?

well 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

I 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_s...

Reply on news.ycombinator.com