Nested currently uses webpack as its bundler of choice for its front-end projects. This is a community norm, but has some drawbacks that lead to a strictly timeboxed investigation of an alternative.
Webpack is best known for bundling JavaScript files, however it also has an extensive system for plugins, loaders, and general configuration that can make it an incredibly flexible tool.
Flexibility is not without cost, however, which primarily manifests in time required to understand and maintain the webpack configuration. As many engineers at Nested are still becoming comfortable in the modern front-end ecosystem, adding an understanding of webpack complexity removes time that could be spent developing features that deliver customer value.
This particular investigation sprung from spending time with the team reviewing a 21 day old PR to upgrade webpack from 3 to 4, which highlighted time invested in the tool.
Time with webpack is primarily spent on the following tasks
Webpack is a very powerful tool that can handle tasks such as bundling, productionising code, code splitting, hot module reloading and other steps. For certain kinds of bugs it is required to understand the pipeline the code is going through to deduce errant behaviour.
As the webpack API continues to evolve documentation is often slow to keep up at times. This can lead to searching of github issues or medium articles for solutions that should be centralised in one place.
Webpack is exceedingly flexible which can lead to the need to experiment with different settings and libraries to achieve the desired metrics such as bundle size or bundling time.
Nested's use of webpack is confined mostly to bundling a client-only javascript application on some projects, such as admin-react. However, marketing-react has a number of more complex requirements including
- Server-side rendering
- Code splitting for both client and server
- Hot module reloading for both client and server
- Source mapping on chunks for debug and logging
The result of this is marketing-react having 5 separate configuration files for webpack to separate core configuration from client/server and development/production.
Parcel touts itself as a "zero configuration" bundler with an emphasis on performance. It has been up-and-coming within the front-end community for a number of months, and advertises itself on meeting all of the requirements we need out of the box. Its approach has spurred webpack to attempt similar features, but with a lack of success so far.
If working as advertised, this would remove the overhead for Nested engineers to learn, update, or tune a bundler as the configuration, its upgrades, and its settings are taken out of the hands of engineers and are just done.
Parcel also makes bold claims about performance, which are worth considering as the cumulative time spent waiting for things to bundle can break flow for engineers focused on a task.
| Bundler | Time |
|---|---|
| browserify | 22.98s |
| webpack | 20.71s |
| parcel | 9.98s |
| parcel - with cache | 2.64s |
Source - Parcel's own benchmarks (so pinch of salt potentially)
Tom Bowden and I timeboxed approximately 4 hours to get a small project started that would fulfil all of the needs of Nested's most complex front-end project - marketing-react. The intention was to mirror the most challenging aspects within marketing-react to discover whether Parcel could be a viable solution for all of Nested's front-end codebases.
We started from a blank project and added the required components individually.
// The TODO list
SSR
SSR with hot reloading
Styled components
Code splitting
Redux
Router
We managed to achieve SSR with a little bit of thought about how client bundle should be served by express which ended up requiring the running of two Parcel instances - one for the client and one for the server. This was functional and we could render and hydrate content as expected.
Hot reloading worked out-of-the-box initially and so did styled components. Altering the CSS within a component lead to a prompt browser reload with the updated styles.
An additional bonus was that we found errors were nicely pretty printed into the browser to speed up debugging, which was a pleasant improvement to the developer experience.
Code splitting was achieved with Parcel's inbuilt dynamic imports and a library called react-imported-component. Chunks were made and they were correctly rendered on the server and the client.
At this point we were quite impressed with the capability of the Parcel, considering no configuration of any kind had been made so far.
However, we did notice that occasionally hot-module-reloading would feel inconsistent. Investigating further, it became apparent that reloading on the server was not behaving as we wanted.
This became our sticking point, attempting to ensure that server reloaded in a way that also caused the correct chunks to regenerate without entering an infinite loop was difficult. Attempts were made to do all kinds of tricks using nodemon and watchers of different sorts, but at the end of our time block we could not achieve the outcome we wanted.
Parcel is a fantastic piece of software that lacks all of the features Nested requires on the server side. Our attempt to make it work lead to an incomplete and overly complex package.json invocations that felt brittle and difficult to grok - which is the original goal to transition from.
It may be worth revisiting Parcel in the future, but for now the best approach is to continue spreading webpack resources and knowledge among the team.