Consider switching to Parcel

Introduction

[Parcel's website] [Parcel proof-of-concept in my Github repo] [Quick video demo of development speed]

Parcel is a modern web application build tool. It is considerably faster than Webpack with compiling JS and slightly faster with compiling SCSS. Parcel would improve development experience by providing faster change reloads, with JS reloads being almost instantaneous. It would also reduce the need for many npm packages which makes creating and importing projects faster and reduce time needed and problems caused by version updates and the need to change Node versions between projects.

Now with major changes (air-blocks-buildtool) coming to the tech stack in the near future, I thought it would be a good time to suggest these as well and modernize the tech stack at once.

Development speed

Parcel for example tries to cache as much as it can in development and thy will try to avoid building the same code twice.

Using the benchmarking software hyperfine building only JS was roughly 4-5 times faster than on Gulp and Webpack. During development building the JS bundle takes around 30-50 ms, while currently with Webpack it always takes around 6.5 seconds and few more to reload the website.

Building production CSS was about 2 to 2.5 times faster on Parcel. In development CSS times were pretty equal. This is simply because both gulp-sass and parcel's sass transformer use the node-sass library for building. Performance wouldn't be a major improvement for SCSS. The benefits would mostly be the more simplified build process, no need to update tens of packages, tinier bundles and easy browserlist support (see below).

React and other frameworks

React and most frameworks work out-of-the-box without any need for installing dependencies. Parcel can automatically install required dependencies for building during runtime.

Parcel supports HMR and React Fast Refresh which would allow near-instant hot reloads for React code without losing the current state. No need to refresh the whole application. JS builds take up to 7 seconds on Webpack and under 100 milliseconds on Parcel (around 40ms in my quick tests), and the whole application doesn't need to be refreshed.

Parcel also supports Vue Hot Reloading API which for Vue provides similar functionality as described above for React.

React applications like event calendars could be code-split and only loaded on pages that use those components instead of having the same bundle on every page without needing to separate it into an another bundle.

Parcel also would allow SVG's and other assets be in their respective files and be bundle inlined during build instead of having them in React.

Tinier Bundles

Parcel also generates noticeably tinier bundles:

CSS

Gulp 16.8 KB gzipped, originally 124.4 KB
Parcel: 11,6 KiB gzipped, originally 69,6 KB

Gulp 8.6 KB gzipped, originally 28.6 KB
Parcel: 4,72 KiB gzipped, originally 19,25 KB

The CSS compression is powered by their LightningCSS tool:

Also SVGs are automatically minified using SVGO.

Easier maintainability

Like I mentioned above, Parcel has most stuff built-in that we had dependencies for before. This means less dependencies that require updating, could break between updates of other dependencies and Node.js versions, and less waiting for npm install to finish. Currently the POC has 17 dev dependencies less and that's without postcss, as I have not gone through which are included in Parcel. Currently the POC doesn't use any postcss plugins to my knowledge as I don't have a config file.

Parcel is also very simple to configure compared to gulpfiles and webpack configs. The most complicated piece of my proof-of-concept is the custom development server that combines Browsersync and stylelint. And even that isn't that complicated being just a few hundred lines of pretty easy to read Node.js code.

Adjustable browser support

Parcel respects a browserslist value in both SCSS and JS compilation. This makes possible providing wider device support for eg. city and govermental websites while providing smaller bundles for normal marketing websites.

To ignore or not to ignore

As of now the proof-of-concept builds both production and development bundles into the dist directory into dist/js and dist/sass respectively, with the dist directory being .gitignore'd. This would require building the production bundle separately. Changing the proof-of-concept to build into separate prod and dev directories like now is 100% doable.

This part is highly prone to change. Having it like this is the JavaScript ecosystem way and as I have spent much time with frameworks and stuff I have gotten used to it.

Pros of ignored dist:

No merge conflicts
Repos stay as "code repositories" excluding compiled code

Pros of dev/prod in repo:

Backend developers don't need to compile styles just do their work and have to matter about dependencies being outdated
All files required for deployment are always available without having to setup development environment

So if we proceed with this I would probably have to mode the repo to follow the dev/prod directories like we do now. The pros of the dist are minor annoyances at best, while the benefits of having the files in the repo are quite high in the long run. The dist model of course works well in the React and Next.js world where most code is cloned from Git, compiled and deployed by CI (eg. Vercel).

digitoimistodude / air-light