A battle of bundlers

However, webpack isn’t quite perfect yet and has some drawbacks. We timeboxed a an investigation into an alternative bundler, Parcel, to see if it would fit our workflow better.

TL;DR ⚡👀

Webpack is best known for bundling JavaScript files, a process in which many user created and library javascript files get glued together into one or a handful of big JavaScript files. That would be selling the webpack short though, as it also has an extensive system for plugins, loaders, and general configuration that can make it an incredibly flexible tool.

Even a basic React project will likely have separate loaders for a transpiler like babel, and for styles, as well as options set for productionising code using inbuilt plugins such as uglify.

All this fantastic flexibility is not without cost, which primarily manifests in time required to understand and maintain the webpack configuration. As many engineers at Nested are starting their journey in becoming comfortable in the modern front-end ecosystem, adding an understanding of webpack complexity removes time that could be spent developing features that our customers are shouting for.

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 chasing down certain kinds of unwanted behaviour it is often required to understand the pipeline the code is going through to deduce root causes. This can be quite a lot of learning all at once!

As the webpack API continues to evolve [documentation is often slow to keep up](https://github.com/webpack/webpack.js.org/issues/1897) at times. This can lead to searching of github issues or medium articles for solutions that should be centralised in one place. Stalking [Sean Larkin’s twitter](https://twitter.com/TheLarkInn) isn’t a bad idea either.

Configurability can lead to the need to experiment with different settings and libraries to achieve the desired metrics such as bundle size or bundling time. Which ecma number will give you the best uglification? Which chunking is the most effective? This process can take quite a bit of effort and some discipline on the engineers part as she’ll have to decide when it’s “good enough”.

Nested’s use of webpack is confined mostly to bundling a client-only javascript application, however it has one complex react project with some juicy requirements, including:

The result of these requirements is 5 separate webpack configuration files to separate core configuration from client/server and development/production needs.

If Parcel works 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.

We 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 with its laundry list of bundler requirements. The intention was that if Parcel could fulfil these needs, it would almost certainly be capable of handling all other front-end projects.

We started from a totally blank project and got on our way

We managed to achieve SSR with a little bit of thought about how client bundles should be served by express, which ended up requiring the running of two Parcel instances — one for the client and one for the server.

The client bundle would be generated and its unique hash was injected into the server-side template, allowing us to serve updated client code. This was functional and we could render and hydrate content as expected.

Hot reloading worked out-of-the-box. Adding styled-components next demonstrated this with aplomb, altering the CSS within a component lead to a prompt browser reload with the updated styles. This excited us as traditionally this has been quite a tricky step to get right.

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.

At this point we were rathert impressed with the capability of the Parcel, considering no configuration of any kind had been made so far.

Alas, after stuffing ourselves at lunch we realised all was not well. We noticed that occasionally hot-module-reloading would feel inconsistent. Investigating further, it became apparent that reloading on the server was not behaving as we wanted. Restarting the parcel instances and nodemon could fix this but required doing so in an non-intuitive order

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 wacky tricks using `nodemon` and watchers of different sorts, but at the end of our time block we could not achieve the outcome we wanted.

We let our imaginations run wild with concepts of complex bash scripts to manage this, but that would just be putting the burden of configuration and odd behaviour into an in-house technology that wouldn’t be receiving the same loving open-source care webpack does.

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 — our original goal was to transition away from this.

It may well be worth revisiting Parcel in the future, but for now the best approach is to continue spreading webpack resources and knowledge among the team.

Related posts:

When I look at where I came from, the trailer-park I called home in the deep South, the rows of failing grades on my high school transcripts, the overwhelming smell of hand sanitizer through the…

Look to past failures to unravel how technical design is intertwined with economic and aesthetic objectives. In “Design Paradigms: Case Histories of Error and Judgment in Engineering,” Henry Petroski…

WePower is a trading platform for the purpose of uniting renewable energy producers and investors that is supported by Blockchain. This all happens under the guidance of Nicola Martiniyuk who is the…