Something a lot of people don’t appreciate is that the past ten years have been an anomaly for JavaScript. They’ve been very tumultuous because there was a ton of evolving that suddenly needed to happen. And I think we’re nearing the end.

Babel was necessary because core syntaxes were changing so fast. Webpack’s sprawling nature was needed because there were so many alternate dialects, module systems to support, etc. Esbuild is only possible because we’ve generally converged on TypeScript, JSX, ES modules, etc. It knows what you probably were going to configure webpack to do anyway, so it can just do it.

So I wouldn’t call it a “treadmill”, I’d call it growing pains

ESBuild’s author and docs[1] are quite clear about its future scope:

> [… a list of features that are already done…]

> After that point, I will consider esbuild to be relatively complete. I'm planning for esbuild to reach a mostly stable state and then stop accumulating more features. This will involve saying "no" to requests for adding major features to esbuild itself. I don't think esbuild should become an all-in-one solution for all frontend needs. In particular, I want to avoid the pain and problems of the "webpack config" model where the underlying tool is too flexible and usability suffers.

That said, now quoting you…

> But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about.

In this respect, ESBuild’s firm stance has a major strength, and a major weakness:

- Strength: the Unix philosophy is easy to achieve, with esbuild-plugin-pipe[2]. There’s just one, simple plugin API, everything follows that same format

- Weakness: since ESBuild doesn’t expose its AST, plugins are often slow which can undermine the benefits of the tool

1: https://esbuild.github.io/faq/#upcoming-roadmap

2: https://github.com/nativew/esbuild-plugin-pipe

> Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts?

Don't recall perf being the win with Webpack, Webpack was "Web-Pack" because it allowed you to use CommonJS to co-locate external assets (SVGs, CSS, etc) with code, and then being able to produce distinct bundles from that dependency graph. Grunt had no clue what your source dep graph looked like, you had to build your own pipeline (specifying dependent tasks for each task). Of course, now everybody has their own Webpack config that alters some input or output, but it's a considerably more powerful tool than Grunt ever was.

I really don’t, webpack config was was a cluster&€@ from day 1. Also, webpacks goal always was to do everything and the kitchen sink, much different from esbuild.

> Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts?

You're forgetting the 6 months where everyone rewrote everything with Gulp.

The Convention Over Configuration crowd has their arguments.

Figma's tech is mindblowing. Their entire engine is custom-built in C++ : https://www.figma.com/blog/building-a-professional-design-to...

> Instead of attempting to get one of [HTML/SVG/JS Canvas] to work, we implemented everything from scratch using WebGL. Our renderer is a highly-optimized tile-based engine with support for masking, blurring, dithered gradients, blend modes, nested layer opacity, and more. All rendering is done on the GPU and is fully anti-aliased. Internally our code looks a lot like a browser inside a browser; we have our own DOM, our own compositor, our own text layout engine, and we’re thinking about adding a render tree just like the one browsers use to render HTML.

To most people, esbuild would be a full-time job. Based on the above, it seems that to Evan it's a fraction of the work he did in Figma's early days all at once!

Ironically, the Figma tagline is "Nothing great is made alone"

What in the world? And some say 10x engineers don’t exist…

I guess build times were a real issue for Figma and it started as an internal project.

Massively impressive!

Yeah, we actually went through this with Redux itself.

When Redux was first released in 2015, it was deliberately designed to be minimal and extensible. Other Flux libraries at the time had various forms of async handling built in (support for dispatching actions via promises, etc). Dan and Andrew wanted to avoid locking users in to any single form of async handling [0], so the middleware API was designed to let users pick their preferred async approach and syntax.

Similarly, the store setup process was entirely left up to users to add whatever middleware, enhancers, and other configuration users felt was appropriate. The docs were also always unopinionated about preferred file structures, how to organize logic, etc.

Over time, it became very clear that users _wanted_ more specific guidance about how to structure their apps, and wanted Redux itself to build in default setup and configuration.

As a result, we wrote a "Style Guide" docs page [1] that lists our recommended best practices, and created our official Redux Toolkit package [2] as the standard way to write Redux logic. RTK was designed to solve the most common problems and use cases we saw in the ecosystem [3], including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once.

RTK has been extremely successful - we routinely get users telling us how much they enjoy using RTK [4], even if they disliked "vanilla Redux" previously.

We also recently released a new "RTK Query" API [5] [6] in RTK 1.6, which is a built-in data fetching and caching API inspired by libraries like Apollo and React Query. Again, similar theme - we looked at what users were doing and what pain points they were running into, and built an official API to help address those use cases.

[0] https://blog.isquaredsoftware.com/2017/09/presentation-might...

[1] https://redux.js.org/style-guide/style-guide

[2] https://redux-toolkit.js.org

[3] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...

[4] https://www.reddit.com/r/reactjs/comments/px6kxy/redux_toolk...

[5] https://redux-toolkit.js.org/rtk-query/overview

[6] https://redux.js.org/tutorials/essentials/part-7-rtk-query-b...

You can use vite for that, which is an enhanced wrapper for esbuild. I use it on all of my projects except the ones I'm forced to use webpack on for legacy reasons.

> How is the integration with things like a dev server and tools present in create-react-app like react-fast-refresh?

It’s not. It doesn’t do hot reloading, and it’s one of the features the author rejected I think.

This looks promising: https://github.com/pradel/create-react-app-esbuild

Or easily write your own dev server. Once you use the API instead of the CLI, if you have any experience with Express or Connect it's trivial.

There is a short paragraph adressing this on the "Why Vite" page: https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...

I'm also a huge fan of HMR, and esbuild in the past has been anti-HMR.

I guess it depends on your project and workflow preferences. Personally, I'm not a big fan of HMR and the bundling times are negligible even without "pre-bundling" npm dependencies (as Vite puts), so I see little reason for Vite.

Yeah, the funny part is that I have never even been to US of A let alone having anything in common with the said movement. No, to be honest, I don't recall anyone mentioning it here on HN or GitHub. I don't use other social media, though, I guess it would be more of an issue there. However, I was wrongly suspended on Twitter once despite not posting (or even "liking") anything the whole decade of being there. I just used the account for OAuth subscription, one day it stopped working, I had to write a letter and wait for manual "unsuspension.

I chose my now "nom de plume" way back in zeros for its seeming originality and simplicity, when compared to my rather common and unwieldy "real" Polish name.

While he is certainly an excellent developer with great productivity to boot, LOC is an obtuse metric. For example there is a package-lock.json commit which is almost 20K lines. Otherwise I totally agree.

I really wish people would stop idolising so called '10x' developers.

Anyone that is comfortable and familiar with their toolset (e.g. go, .NET, Java, C++) and has a deep understanding of a problem (and has likely solved it once already), can churn out code far, far, faster than an onlooker.

> As a good CTO you shouldn't have anything to do.

Is this for real? I mean, yeah, I don't think a CTO should be debugging build scripts, but hiring a great team, mentoring, aligning teams with a common technical vision, meeting with other company leaders to ensure the technical direction meets the needs of the business is an immense amount of work.

and he's building tools to optimize his teams.

As someone that ran a company while working on side open source projects, don't underestimate the therapeutic value of writing code. (As a CEO, my job had almost no coding, and working on my opensource projects made me happy, and restored a lot of my energy.)

CTO and lead developer on a focused project are very different jobs - my guess would be he relaxes from the very strategy and soft-skill heavy day job by diving into a challenging problem that keeps his dev chops up and lets him focus on a finite problem.

To echo what others have said here, my role as CTO and now CEO has gone from 95% coding to about 5% these days. So some nights I code on ideas and things that have been swirling in my head, just because it’s nice to just quietly write code and solve a finite (but possibly difficult) problem without interruptions. It actually IS therapeutic.

The tool is likely helping Figma pretty directly by cutting developer build times.

Maybe there's not much to do as the CTO of Figma. Throwing time into Esbuild doesn't mean he's neglecting his CTO duties.

I’m pretty sure ESBuild’s creator has agreed that Bun’s performance claims are probably correct, and that there’s still more room for optimization of/beyond both.

Yes 100% - I’m actually using Vite Ruby in a project as I really wanted to use Inertia + React and that was by far the easiest way to get everything up and running.

I’d go so far as to say I wish -j vite was an option in js-bundling :)

>Webpack is a bane of webdev existence.

Modern Web Dev is the cause of Webpack though. Over complicated things.

I cannot count the days I've spend on webpack config breakage during the last years at work. It's never really been good at all either. The gulp setup we had before worked faster, better and didn't break once a month. Webpack really only is a pet project of the idiocratic React-community. Facebook not only screws your personal data over, also your dev workflow!

I'm afraid not, it's all internal and not open-source. :(

My project is small and it's amazing fast to me as well. It's basically just outsource its job to another cli. I used esbuild-plugin-sass

This is the gist https://gist.github.com/v9n/c40a6ad2078d09dd86117924b415b7fb

As far as I know, esbuild has no intention to integrate with CSS and will outsorce it to plugin.

I used

SWC in NextJS is still in canary with experimental settings, but it took me 3 lines of code yesterday to make it work on a fairly large app ( https://labelflow.ai ). Hot reload times instantly went from 10s to 1s. Twitter discussion here https://twitter.com/vlecrubier/status/1448371633673187329?s=...

Overall I’m pretty bullish on Rust tooling and integration within the JS/ Wasm ecosystem !

It's being using to bundle some parts of nextjs itself, but not quite ready to replace babel for users rn afaik

May be in next release we get swc in nextjs?

Consider TypeScript like a linter. ESBuild doesn't run ESLint for you either - you can run it separately, or in parallel.

This means that for example, during development, you can see your running code quickly, while your editor runs tsc to highlight type checking errors. And in your build system, you can produce a production bundle to test while in parallel checking for type errors.

Not blocking on typecheck failures is one of my favorite features of TypeScript -- you can rapidly test/debug/iterate on code with "broken" or incomplete types while in the prototyping stages of feature development.

This is pretty common if you're looking for build performance. E.g. typecheck as a lint step with tsc, build with babel removing your typescript (it doesn't typecheck either), etc. It's true that tsc on its own can replace a build step for some folks, but you'll quickly find it limiting both in the options to rollup or combine files and in its ability to be extended with plugins (unlike Babel), etc. On the other hand, tsc and its language server is a first-class type-checker when run with no-emit. ;-) I haven't played as much with esbuild yet but it's on my todo list.

Practically, it isn't an issue if you use VSCode which has the Typescript language server built in to catch type errors for you.

If you want, your build script can include

  `tsc -noEmit`

to type check before the build.

By "supporting typescript" it parses typescript code and won't fail. That is what a bundler promises. Bundler doesn't have to do the typechecking. It is actually conventional to set it up that way for any bundler. In my job we have webpack bundling typescript with babel in the "build" step. We could've use ts-loader but we want hot reload to be fast. Then in the "check" step we have ts, linter, unit tests. Those run on CI.

You're likely literally doing the same thing with Webpack. There is only one complete implementation of the TS compiler in existence, so you have to use that to typecheck, it doesn't matter what bundler tool is used. If you need the type definitions as part of the output (eg you are distributing a library), then you have to involve the compiler to construct the output definition files, but for the code itself, it doesn't really matter because you're just generating JS. The TS compiler is very slow (and in any case is not designed to produce code bundles - it just dumbly translates all the TS to JS), so the standard way to speed this up is to use a module bundling tool that ignores the types and compiles the code as JS, and have the TS compiler set to not emit any files itself.

Nothing in the above precludes using the compiler to typecheck the code, that's the primary usecase & what sibling is saying about thinking of it as a linter: if typechecking fails, don't build

`eslint && tsc --noEmit && esbuild` or something like that, just simple process chaining. Means you can build something you know is going to be illegal to the TypeScript compiler, but you want to very quickly test an assumption, for example.

I don't think rejecting a comparison with an uncomplete nightly build is unfair. It looks like it was added a little after this issue was closed because the blocker was fixed.

Parcel 2 was released as stable yesterday though and Evan has already updated comparison.

https://github.com/evanw/esbuild/commit/186446eae8cc8c7439eb...

I felt the same, the industry's shift away from the gulp way of doing things was a real loss.

Indeed, the best build chain is no build chain at all. I've been ridiculed at work for not using node, npm, web pack etc -- but I'm not spending 20% of my time on tooling issues.

Don't forget bun and swc

I would say that's within a believable range of improvement (although on the high end).

We're playing with ESBuild at work, TS/React build that takes 45+ seconds to run with webpack cold, 8 second for a rebuild. With ESBuild/Gulp, the full gulp watch task will refresh in about 1.2 seconds, of which ESBuild ran for about .4 seconds.

So the builds are ~100 times faster with ESBuild, and we're just running it cold every time because it's so fast.

---

It's also really exciting for run-time based compilation. I've been playing around with a server-side React rendering project, and I literally just run esbuild in the controller action in development (some prebuilding for releases) and it's wonderful. Live updates in roughly .6 seconds on average, even for relatively heavy components.

plus, if you're careful with your react code, you can build a react codebase that will actually run if client-side JS is disabled (you can render it all serverside)

Probably not an exaggeration. My build times aren't that long, but I've seen similar speedups in switching the esbuild (our smaller codebases currently build in less than 0.1 of a second with esbuild)

Yeah, Jest is the slowest thing in my build pipeline.

It's not the same thing though, SWC is a different category of tool.

Edit: though I guess if you include the sibling project swcpack, it covers the same ground. SWC itself doesn't though.

I just saw an (internal) presentation where presenter predicted that in a few coming months we will see a lot more RxJS being used in ReactJS projects. Cannot wait to see it included on webpages which would be just fine with zero JS.

On the downside, it will put all the code into one giant script that has to be downloaded upfront.

While a website that loads scripts per page will only load the scripts that are needed on the current page.

That contradicts my experience and what I just described. In my experience, sites do feel instant even if they load dozens of scripts.

I thought HTTP 2 fixed the problem of multiple downloads of small files/dependencies?

The creator of Rails talks about it here: https://world.hey.com/dhh/modern-web-apps-without-javascript...

> Bundling also gives you slatic analysis (typescript and linting),

No it doesn't do that, typescript compiler does the static analysis and whatever linter does the linting, you don't need a bundler for that, a bundler just takes many source files and bundles them into one.

I saw that, but none of that adds up to a 100x speedup.

I'm sure it helps. It doesn't help 100x

> It also doesn't include type checking for typescript.

If you use `@aws/sdk`, you are going to have bad time with Typescript. Resolving its types can easily take >50% of compilation time for small projects.

ah - apparently ESBuild cannot be used for transpilation in React Native. But can be used for minification.

https://www.npmjs.com/package/metro-minify-esbuild

No importmaps are the new default in Rails 7. The menu is still omakase. In case you have different requirements you can use options.

I don't think context (JS build tool) is missing here.

If someone has open mind, they can also google what is Parcel.

> I agree with you in principle, but your comment makes it clear that you didn't actually look into this one at all. This one is actually good.

People have said say that same thing each time a new one pops up since Grunt 10 years+ ago.

If you're going to use a JS bundler written in Go, just stick to MAKEFILE...