I am not the kind of developer who jumps on bandwagons and uses whatever new tool is released or replaces another. However, after using Aurelia for over a year now and putting up with the numerous breaking changes in Jspm and System.js causing issues with Aurelia, I have had enough.
This will not be a guide telling you how to upgrade to Webpack from Jspm or System.js, just detailing my thoughts around switching over to Webpack and the benefits it brings.
Update April 2017: Since writing this, the Webpack implementation has been rewritten from the ground up and supports Webpack 2 and is fully-featured. The original implementation had caveats and some Webpack features couldn’t be used.
I realise, that Webpack has long been the darling of the React world for some time now, I do some React development myself from time-to-time and have worked with Webpack before.
Do not get me wrong, Jspm is still great, but the breaking changes have been painful, using it alongside System.js has introduced notable performance issues (especially in Edge).
Really, the gap is closing. The benefit of Jspm is that it handles all of your dependencies separately in a jspm_packages folder and maps them in a config.js file. However, Webpack can be configured to load your package.json dependencies meaning you can just use npm install to manage dependencies and not worry about two separate folders and commands.
Previously my workflow was something like this:
- npm install
- jspm install -y
- jspm dl-loader –latest
- gulp watch
Now my workflow looks like this:
- npm install
- npm run dev
With the use of Webpack also comes hot module swapping. If you are not familiar with what this is, it means if you make a file change, that file is updated in the browser and you don’t lose your current state. Unlike Browsersync, your page isn’t reloaded. That file is literally swapped out in the page. It is a cool feature that any React developer will rave on about for days.
Yes, using Webpack does require a little upfront commitment of time, however you get all of the benefits of using Jspm without the added overhead of managing separate dependencies or performance issues introduced by using System.js. Developing with a bundle makes for a painless experience.
Great post man. We would love to see a blog showing how to migrate to web pack from jspm and gulp tasks (build, watch, etc )
I’ve also heard whispers that WebPack is much faster to initially load – what’s your experience been with that?
@Forest Marie
I can definitely do that. In my particular scenario I migrated an Aurelia TypeScript application over. I’ll draft something up if people will find it useful.
@Mike
Absolutely, 100%. I can see and feel the difference. The issue with System.js is that there is no easy to way to work with a bundle as you develop, no hot module replacement. If you open up your network tab on a development version of a Jspm/System.js app, you’ll see hundreds of requests.
Page loads feel instant (because you’re working with a bundle) and no added overhead of System which sadly has some performance issues they need to work out, particularly in Edge.
Testing also becomes a whole lot more simpler because you don’t have those annoying System.js issues you might be familiar with.
I second what Forest Marie said
I for one would love to see a post on moving an aurelia typescript app from jspm to webpack. It’s exactly the scenario I’m looking at, for what are probably the same reasons.
migrating to webpack and more info on webpack would be very useful.
I also would like to read a description on how to migrate form jspm to webpack.
I feel your pain, my team has been using systemjs/jspm for about a year and half now.
My team built a bundler ( https://github.com/Swimlane/systemjs-route-bundler ) for auto-magic determining overlapping dependencies and packaging them optimized in production. Its been quite a task to keep our project running smoothly while upgrading. With JSPM, you have to stay on top of the upgrades too because repositories stop working and making anything past a patch update is like a re-write on your end.
Guy Bedford is FREAKIN AWESOME but its really grown past the point of one person being able to manage it. I think it could just use some better PM ( gah! I hate to suggest that ) and stability and it would be great!
Regarding WebPack, I am not sold on it. I think it does too much for a module loader. I have a very specialized workflow for my deployments that I can script into gulp quite well without Webpack plugins. This is almost like comparing Grunt to Gulp, configuration over convention.
I’d love to hear some specific issues you’ve had so we can help move the project forward in a better way instead of just jumping ship. I know thats what you said you don’t do but it kinda seems like your doing it ;). After all this is a open source project and Guy has always accepted my PRs.
Remember the grass is always greener on the other side of the fence ( not always! ).
I would love to try switching.
But before I do, I need to know if aurelia-loader-default (https://github.com/aurelia/loader-default) supports WebPack.
Any idea on this? It is the module that allows me to customize my file names. (My Views are called `widget-view.html` and my View Models are called `widget-vm.ts`.)
I have been working with Aurelia w/Webpack now for a week or so, it is super fast but there are some gotcha’s I would really like it if you would do a post, as well as maybe add a chapter in your book I just bought ;o)
I also wold love to see some advice on using webpack, es6 here but any advice will do, very kind for your article!
There is a post in the works as well as more content inside of my book. But don’t worry, you won’t have to buy my Aurelia book, I will still be writing a blog post to help everyone out.
What is already inside the book in regard to this topic? I will get the book nonetheless. But it would be great to get as much info as possible about using Aurelia + Webpack + Typescript.
What would be your advice for starting a new project by somebody that does not neither know too much about Jspm/Sytem.js nor about Webpack? What would you favor in this case?
Thanks for all your great content!
Nice post! I was in a situation where I needed to choose between these two roads, you made my choice easy, thanks!
Hi, I was having some issues as well with the load times, but now it works at speed of light for me, the web gets FULLY rendered in a second, which is fair enough for me.
You can watch it here.
https://elephantseed.firebase.com
Webpack is amazing as well though, but I find jspm simpler and less configuration needed.
However I still need to speak with the JSPM guys because I am having an anooying warning:
warning.js:25 Warning: React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:
And I want to see what it’s due to before making my final choice.
Sorry I mean
https://elephantseed.firebaseapp.com
Has there been any updates on a tutorial on converting from systems/jspm to webpack?
Webpack feels like gulp to me. It’s just the bundler and a framework, isn’t it? You still have to hook in bower, babel, minify, watcher, etc? And you will do it manually for no reason.
JSPM is like one thing to rule them all. The holy grail.
You’re using it over a year, so you were at the beginning of JSPM journey. If you want to use it, you’d basically be the co-developer and beta-tester.
The same applies to Webpack. No wonder Webpack 2 would be a breaking change. I’d say that in the JavaScript world you always own your dependencies and frequently send a pull request here and there.
So try 0.17.beta, it will surprise you. Don’t use real time loading in the browser, it’s rubbish. Use jspm bundler, so that you compare apples to apples. And don’t forget to add pull requests and add more tests, so that functionality you rely on doesn’t break.