We have used scaleJS to power our app development for many years now, and it continues to be a great tool in developing large apps. However, like most technologies, scaleJS must grow and change, and so we will be moving onto Webpack and ES6 modules for future app development because of the massive benefits they bring to the development workflow.
Webpack – It just works
Functionality issues became apparent when debugging RequireJS issues. AMD and Bower first needed to be configured before they could function together. This required coming up with a tricky solution in Webpack and I realized that for the most part, Webpack just works better. It was designed to be that way, and it’s pretty good at that.
In order for things to “just work”, you do need to follow a few rules. But as the saying goes, “convention over configuration”, and switching to Webpack would be doing just that. We could move all the packages we have to NPM and have them work with Webpack, and then we wouldn’t need to be wiring up configurations for every install. Score!
Continuous build and hot module reload
Webpack comes with a development server that’s smart enough to watch you code and recompile the bundles whenever changes are made. It also runs other steps, such as a transpilation step (via Babel), which allows us to code in ECMA2015. Webpack also enables “hot reloads”, which will send changes to the Dev server allowing you to get the changes instantly. If your application is designed right, it could even update without a manual browser refresh!
Often times with RequireJS you would run into issues where your app worked in development, but broke upon building. Because we never needed to “build” with RequireJS during development, we would run into these tricky bugs just as we were about to deploy. This is never a problem with Webpack, since you are always working with the build files. Source maps are required for this to work well, but once you have them in place, the benefits of the compilation step during the development workflow are plenty.
Code splitting, security, and latency
One of the great things about Webpack is its ability to statically analyze your code base and split it into “bundles” which will only be requested when necessary. This has huge implications on the production application, allowing both for latency improvements and security.
There are two popular ways to get code on clients these days, and neither option is very good. The first is to send all the code in one ginormous file, or send every file individually, which is simply impossible for clients to handle efficiently. Webpack reduces the latency in your load times by solving these problems with bundles. Bundles allow you to load files in smaller chunks, while not having to make separate requests to get every building block in your code.
This means that if you have 1000 assets, you can load 500 assets in one file upon entry, then split the remaining assets into smaller chunks. You then request a file when you need it, instead of making one request for a huge file with 1000 assets, or 1000 requests for one asset.
The second great thing about code splitting is that now you can still use your typical development workflow and ensure that clients only receive the code you want them to. Not only does Webpack support this, but also gives developers the tools they need to leverage this feature easily and intelligently.
Web-packing for the future