esbuild VS swc

I created this little repo to be very barebones but just enough to get started. Esbuild is lighting fast and it's a great jump point to test out some ideas and just start developing without any headache!

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.

They actually have a discussion board for asking questions about the project; I would suggest going there first. It's possible someone has already asked this question!

One of the key features of Next.js 12 is performance optimization. To boost performance, Next.js replaced the Babel compiler with an extensible Rust compiler and enabled it by default using Next.js 12, the compiler is built on top of — SWC — which stands up for Speedy Web Compiler. It does consume TypeScript/JavaScript and emits JavaScript code that can be executed on old browsers.

SWC is not a "TypeScript type-checker project", it's a bundler and compiler.

The type checker in the title refers to the author's work porting the tsc to Go, which is a different/additional project.

> Vercel is sponsoring and funding the work to port tsc to Go. We’re planning to open-source this work in the future. I’ll also be creating a bridge to use this new version of tsc with SWC.

From the author's blog post "I'm porting tsc to Go" - https://kdy1.dev/posts/2022/1/tsc-go

The author has gone back and forth on whether the work will be open-sourced.

> It will be developed as a propriety software.

Mar 2021 - https://github.com/swc-project/swc/issues/571#issuecomment-8...

> I'm considering withdrawing the plan for open-sourcing it.

Apr 2022 - https://github.com/swc-project/swc/issues/571#issuecomment-1...

Yeah I meant speed of execution. Sorry for the letdown! But https://github.com/swc-project/swc is a very fast Typescript compiler written in Rust :)

It's not official, but swc includes an existing TypeScript parser written in a lower-level language. Swc is specifically designed for AST transformations. Currently the plugin system for custom transformers uses JS plugins which might not be fast enough for you. They are discussing implementing a Rust plugin system that would be faster. In the meantime you could pull out the parser code, and incorporate it into your own code.

One of the advantages of using Nx over - say CRA or a custom starter template - is that your Nx workspace is evergreen. What do I mean by that: by now we all know how fast the frontend space is moving, and so are the corresponding devtools. Today you might be using Rollup to build your libraries, tomorrow you use swc, vite or esbuild. Same with Webpack. Webpack 5 has been around for a while already, and still, a lot of projects are stuck at v4.

Here is link number 1 - Previous text "SWC"