PostCSS VS esbuild

The second of those two reasons is very disappointing, as PostCSS is a rich ecosystem of plugins to extend your CSS' functionality and build process. PostCSS is what Babel is for JavaScript, and unfortunately styled-components is missing out on an entire suite of new functionality.

postcss and autoprefixer are tools for transforming CSS that Tailwind uses to do its job.

PostCSS is a whole other package. Tailwind can integrate with PostCSS.

Same goes for PostCSS, which I also mentioned. If you don't know what that is, please do take the time to find out. I suggested that you may want to avoid it for the time being while you're still learning, though.

With the pre-processors, you can shrink your CSS and increase reuse through variables. In almost all working cases, it will be an improvement above vanilla CSS. There are also implementations now, via PostCSS, that add vendor prefixes for you. The major drawback is, of course, that you have to compile your CSS beforehand; usually done via part of your tooling such as Grunt or Gulp.

Making your library as modular as possible will aid with the adoption of it. A team should be able to pick and choose which parts they need of your system to keep their application as performant as possible. There are numerous tools you can use to aid with this process such as Sass, PostCSS and TailwindCSS.

PostCSS

esbuild is a general purpose code compiler and build tool that uses golang builds, it is very fast and 1~2 orders of magnitude higher in performance than the existing js toolchain. It's not an out-of-the-box build tool yet, but with its plugin system we can already do a lot of things.

import { Plugin } from 'esbuild' /** * Automatically exclude all dependencies * Some regular expression syntax of js is not supported by golang, see https://github.com/evanw/esbuild/issues/1634 */ export function autoExternal(): Plugin { return { name: 'autoExternal', setup(build) { build.onResolve({ filter: /. */ }, (args) => { if (/^\. {1,2}\//.test(args.path)) { return } return { path: args.path, external: true, } }) }, } }

But then you see stuff like ESBuild, where the Evan Wallace (the author) tried to write in both Rust and Go, and his Go version was faster. According to him, this was probably because Go runs destructors in a parallel thread, whereas Rust runs them in the same thread (source), among other factors. The same performance could theoretically be achieved in Rust, but it would demand a lot more effort.

Use esbuild as a compiler and backend bundler

Will provide an alternative solution for Windows later. (ref: https://github.com/evanw/esbuild/issues/976)

Esbuild is a Javascript build tool written in Go, which pre-bundles dependencies 10-100 times faster than Javascript-based bundlers.

We did this via the npm threads wrapper and esbuild. We first moved all of our compute code into a new file with minimal imports, called imageCompare.worker.js. We then added a pre-compilation step with esbuild to compile this file into a bundle. We then spawn the worker using this generated file as a blob, and interact with it via the threads promise interface.

Though, if you want to use one, do yourself a favor and give esbuild a try. It is orders of magnitude faster, at the cost of less flexibility.

Make my builds faster by forcing myself onto esbuild from the beginning, even if that makes delivering some capabilities harder (like web workers and service workers, Hot Module Replacement, and so on).