Now you can see detailed data for individual Pods, Containers and Nodes in your Kubernetes
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
What really happened##
1. Waay too slow
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:
- Generate unique hashname for bundle file
1. Suuuppper fast
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.
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.