Some notes on using esbuild

Do you have any information on how to do this? I've done a quick search but I wasn't able to find any relevant results.

EDIT: think I found it https://github.com/webpack-contrib/terser-webpack-plugin

Unfortunately, my project is still on webpack v4 so I cannot use this until I update.

ESBuild doesn't transpile your code down to ES5.

If you're using any ES6 features - default params, template literals, arrow functions, let/const, spread, etc, your cut-off for browser support will be ~2017 (= no support for IE 11).

swc (https://swc.rs) does transpilation and it's as fast as esbuild. Setup is slightly more complex. I'm hoping esbuild will add ES5 transforms at some point, would much rather have a Go tool underneath.

Plain esbuild is perfect for adding typescript support to node.js projects. We literally just run ’esbuild && node dist/run.js’

I find it fascinating that there are people still using script tags. I have personally become so tied to npm and typescript that it feels that I'm programming in a completely different language and ecosystem, with a build process and IDE-like type checking and linting, a more procedural data-oriented C-like paradigm.

I've never touched the old JS guts, `module.exports`,the prototype chain, ... Babel (and later TypeScript) allowed me to live in ESM land from the beginning. I expect any tool/library to be available using exclusively on npm, in reality, I've been constantly fighting with it over the past few years.

I usually get a shock when I see libraries still offering minified bundles that assign to the global namespace, to me this seems like outdated practice, but I guess that this is still really prevalent in JS, even in 2021. I sometimes want to go back to it, with the amount of configuration and boilerplate necessary to set up a project with npm, Prettier, ESLint, Typescript, Webpack/Parcel/Rollup, SPA vs MPA, React vs Vue vs $SPAFRAMEWORK, it was a lot easier back in the day.

I think the biggest failure in the JS system is the lack of standardisation, it's so versatile that almost anything is possible. A number of different module systems were invented to solve the initial growing pains (the first would literaly replace a `require()` function call with the contents of the given file), and we never escaped them as they became the foundations of Node.js/npm. Then we needed a non-blocking variant, so we just called it `import()`, it returns a promise. Then we wanted proper imports, so we invented the `import ... from ...;` ESM syntax. We made a named import and default import variant (with most bundlers offering a compatibility layer with CJS-type exports, so imports now have a hidden `__esModule: true` key...). In order to stay compatible with legacy CJS, we also added the `import * as ... from ...;` syntax as an escape hatch?

When TypeScript came along, in order to be compatible with JS it became common practice to distribute compiled TS code along with the source code, with an adjacent declaration `.d.ts` file to provide type information. The source code was never leveraged in any way, and so people just stopped shipping the `src` directory, only `dist` and a `package.json`. It makes debugging a pain, but compiling TS libraries would have been tricky, considering the widely varying different feature flags (async, DOM, ...) and strictness options. Perhaps Deno will help with this to some regard. The great thing about Go or Rust (or any other language, really) is that you import source code, not illegible compiled code (unless you're dynamically linking). I believe that Rust is especially good in this regard, it remains compatible with older code by requiring crates to specify a Rust "edition".

Why are we in this mess in this first place?

And why has it remained so darn popular?

> problem 1: libraries that tell you to npm install them

Agreed. I wish `npm install` was just some option for those who wanted it. But no! Somehow it became the defacto standard and everyone just expects everyone else to already be onboard.

I got onboard reluctently because that's the only way to use the libraries I cared about.

> problem 2: I don’t understand frontend build tools

Absolute and total agreement.

I can't agree enough.

I think no one really understands them.

> “webpack” which I will not try to explain much because I don’t understand it, I think it’s a system with a million plugins that does a million things

I haven't worked with anyone who understood webpack. They just use a scaffold-builder to set it up in a pre-configured way and then you just never touch it.

> Recently I learned about esbuild which is a more Unix-style tool.

esbuild is the best thing that happened to frontend development. It finally freed us (well, me anyway) from the messy js build systems.

But I'd like to strongly object to describing it as a "unix-style" tool. Unix style tools to me are tools that deal with plain text and expect you to pipe them with other tools to get the job done. esbuild is nothing like that. It's the entire build pipeline in one tool. You don't work with it by piping its inputs and outputs to other tools. It provides you a programming interface and you write code to make it do what you want.

EDIT:

To clarify, I think it's a very good thing that esbuild is not a unix-style tool. I know the common wisdom on HN is in favor of the unix philosophy, but I don't buy into that.