JSPM vs Webpack: Why we switched from JSPM to WebPack

We recently began using ReactJS for our new UI. While initially we started with JSPM for our javascript build, we had to switch to WebPack eventually.

Why JSPM in the first place?

1. Good documentation

The first impression of JSPM is great. The website and documentation is nicely laid out. Everything is well explained. Webpack's shoddy website didn't get any points compared to it.

2. No manual config script

Apart from an auto generated config script from JSPM, there is no need for a separate manual config file. Compared to Webpack's configuration, which felt very confusing at first, it seemed like a huge leg up in simplicity.

3. No background builder process

Unlike Webpack, we didn't need to have JSPM running in the background. It felt like the 'right' approach. No background process, just native support for modules. And we could create a bundle for production use. Felt like the best of both worlds.

4. Seemed like evolution from Webpack

Considering that JavaScript build tools move super fast, going from Grunt > Gulp > Browserify > Webpack, we felt that JSPM was the next step in that evolution.

What really happened

1. Waay too slow

As we began to add dependencies and our codebase started to grow, we saw the fatal flaw of JSPM. It was waaay too slow. A single refresh would take about 15-20 seconds as the browser would load 100s of different javascript files! It was faster to restart our Java app server than to refresh the browser.

We tried all kinds of methods listed on JSPM github discussions like bundling all dependencies during dev, but it was still really, really slow.

We feel this is just an inherent problem with JSPM's architecture and simply cannot be solved unless JSPM becomes more like Webpack.

2. Gulp still needed

We still required gulp for:

  • Minification
  • Envification
  • Generate unique hashname for bundle file

Enter Webpack

1. Suuuppper fast

Using Webpack's dev-server with React Hot loader plugin is just super fast. Changes are now shown in milliseconds. Webpack's dev server is just designed for speed. Not only does it support incremental builds, it doesn't even generate the bundled javascript file on disk, it just serves it directly from memory.

Combine that with React Hot loader and the experience from JSPM to Webpack is like going from bicycle to airplane.

2. No need for gulp

Webpack itself takes care of doing all the tasks we had to use Gulp for above with JSPM. So that's one less thing we have to deal with.

3. Designed for large apps

It really seems that Webpack was designed from the ground-up for large application and it shows while using it. This is exactly what we needed since DripStat is not a small codebase by any means.

Conclusion

Using ReactJS with Webpack + React Hot loader is how we believe frontend development should be done. We can move very, very fast due to the quick iteration it allows.

Show Comments