Esbuild – An extremely fast JavaScript bundler

573 points14
maga9 hours ago

Often overlooked things when discussing esbuild here:

1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right.

That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of plugins, ask yourself whether you really need to inline css in jsx in png while simultaneously optimizing it for IE 4.0, realize you don't, through out the whole thing, and use esbuild instead.

I have two 50K+ LOC projects using esbuild, and I would use it even if it was slower than webpack/babel/tsc simply not to worry about the build chain breaking due to an update to some obscure dependency or plugin.

2. It is fast because it's written from scratch to do a set of particular things and do it fast, not just because it's Go and parallelized.

If you look at the commit log you will notice a lot of performance tweaks. If you look into the issues, you will find a lot of requests for additional features rejected, often due to possible negative performance impact.

3. The most impressive part about esbuild development is not just that it's one guy writing it: it is the level of support and documentation he manages to provide alongside.

The release notes alone are a good course into nitty-gritty details of the web ecosystem: all the addressed edge cases are explained in detail. To top it all off--all opened issues, no matter how uninformed they seem, find a courteous response.

theptip4 hours ago

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

It seems there’s a feature treadmill at work here where projects inexorably bloat as they get popular. 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. I wonder if there is a middle way that can prevent the tool from giving in to the pressure to add features.

brundolf2 hours ago

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

dgritsko2 hours ago

This is a great point. A "Cambrian explosion" the likes of which the JS ecosystem experienced over the last 10-15 years will slow down eventually. Curious to hear whether other folks agree or not.

jscambrian1 hour ago

I survived the JavaScript Cambrian explosion and all I got was a disenchantment with computer programming

eyelidlessness3 hours ago

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



imbnwa3 hours ago

> 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.

Epskampie4 hours ago

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.

josteink2 hours ago

Seconding that. It’s the one reason I never started using webpack in the first place, at least not from scratch.

Angular ships with a working config out of the box, and I hope I never, ever will have to tweak that to fix a build.

shakezula2 hours ago

The Convention Over Configuration crowd has their arguments.

praveenperera6 hours ago

> 3. The most impressive part about esbuild development is not just that it's one guy writing it: it is the level of support and documentation he manages to provide alongside.

And the one guy writing it is Evan Wallace, co-founder and CTO of Figma. I don't know how he has the time!

btown3 hours ago

Figma's tech is mindblowing. Their entire engine is custom-built in C++ :

> 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!

chipsambos4 hours ago

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

Cyph0n3 hours ago

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

sesm5 hours ago

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

_fat_santa4 hours ago

This seems like a pet project. Reason I say that is if it was built for work, it would likely be from figma. Instead this project is from Evan himself.

capableweb4 hours ago

I'm not so sure about that as you. Not all companies are like Google and "steal" the credit of work done by employees, even if done on work time but unrelated to the core business. Plenty of companies let employees work on open source and still remain the owners of the software produced.

lawn9 hours ago

> I have two 50K+ LOC projects using esbuild, and I would use it even if it was slower than webpack/babel/tsc simply not to worry about the build chain breaking due to an update to some obscure dependency or plugin.

This was the reason that Phoenix 1.6 switched away from webpack to esbuild, apparently half the reported issues were webpack related!

brightball5 hours ago

This is exactly why the Elixir Phoenix team switched from Webpack to esbuild as the new default. They were spending more time responding to Webpack issues than Phoenix issues and it was an endless time sink.

sesm5 hours ago

Number 2 is a common pattern. At first developers are exploring things and changing approaches from time to time, so the most flexible solution wins (express, redux, webpack). Then they understand exactly what they need, so they can make a new tool with focus on particular set of use cases and features from the start.

acemarke5 hours ago

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.








xeromal2 hours ago

Has anyone given you crap for your username? I know you had the username long before MAGA became a popular word in the american lexicon, but I'm still curious!

baxuz8 hours ago

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

Also, in case of working on an Electron project: How well does it handle main/render/preload compile targets and handling of native modules and linking?

Electron-forge is, for instance, the recommended toolchain for building Electron apps and the Webpack stuff is a particular pain in the ass.

brainbag6 hours ago

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.

Aeolun8 hours ago

> 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.

hashkb4 hours ago

You can build very fast reloading yourself, easily. If I'm smart with persisting state on the client, I find I don't really miss "hot" reloading.

magerleagues4 hours ago
hashkb5 hours ago

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.

antihero8 hours ago

We're using Vite and enjoying it, would you say much of Vite could be replaced with pure esbuild?

I guess Vite provides a nice development experience but is built on esbuild.

Rapzid38 minutes ago

There is a short paragraph adressing this on the "Why Vite" page:

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

maga7 hours ago

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.

aidos6 hours ago

We switched over to Vite some time back and it's been pretty life changing. We're using react and tailwind too, so the HMR works really well for us.

The config is beyond minimal. If you're using webpack you may want to look away now :-)

    import { resolve } from 'path'
    import { defineConfig } from 'vite'
    import reactRefresh from '@vitejs/plugin-react-refresh'
    export default defineConfig({
      plugins: [reactRefresh()],
      build: {
        rollupOptions: {
          input: {
            index: resolve(__dirname, 'index.html'),
        sourcemap: true
      esbuild: {
        jsxInject: `import * as React from "react"`
      resolve: {
        alias: [
          { find: '@', replacement: '/src' },
seumars6 hours ago

God bless Evan Wallace

ksec8 hours ago

Bun [1] is a JS bundler based on esbuild’s source, but written in Zig. And it is about 3x faster than esbuild. I think its author Jarred is on HN as well.

Probably worth a submission on its own but I am just waiting till it is fully open source.

Edit: ( Deleted those Stats, since it may not be a fair comparison and it was probably not meant to be a fair benchmark in the first place. The details are still in the linked tweets. I do not know the author or am I in anyway affiliate with Bun. )

I am also wondering how much of those optimisation could be used on ESbuild. Since Rails 7 and Phoenix 1.6 will be using esbuild and not Webpack.


chakkepolja7 hours ago

The numbers seem cherry picked though, I don't like this type of 197.96432100004x faster claims.

eyelidlessness3 hours ago

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.

beckler7 hours ago

Granted, those stats are for JSX, but it’ll be interesting to check out for sure.

CodeIsTheEnd12 hours ago

Work on esbuild started at the start of 2020. It is primarily authored and maintained by Evan Wallace, who, in addition to making this tremendous contribution to the JavaScript ecosystem, is the CTO and co-founder of Figma. Incredible output.

eloff10 hours ago

I came here too say this. The man authored in the neighborhood of 100k LOC in a year, just on this. There's a living 10x dev, it's not a myth. What is ridiculous is to think someone can 10x a normal developer, it's more like the difference between the top few percent and the bottom 10-20%. Evan Wallace is a beast, no doubt.

mr_pinnen9 hours ago

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.

capableweb4 hours ago

Agree, if anything it should be the reverse, less LOC produced means more efficient developer. But that's also a shit metric, as then people start cramming in as much complexity in every line as possible.

Best would be if we could actually measure "complexity" in a objective manner.

DrBazza9 hours ago

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.

atonse6 hours ago

Ehhh no I don’t think it’s that simple.

I’ve found that in any tech company, while there are many people that write good code and do a great job, there are always a handful (even at a place like Apple) that truly push the industry forward and in certain directions, partly because of how they see years ahead, partly because they are supremely talented, and partly because they attract other really good talent just to work with them.

And we know many of their names. Folks like Brian Cantrill, Yehuda Katz, Fabrice Bellard, John Carmack, Bret Taylor.

They aren’t just good programmers. They’re constantly dwelling in uncharted territory.

I’m not advocating worshipping them, just stating that their talent and output is hell of a lot more than even 10x.

DrBazza5 hours ago

I understand what you're saying, but I'd still argue that they're supremely familiar with their toolchain, and have a deep understanding of the problems they're trying to solve. My comment said they've usually solved the problem at least once already, but I don't discount people solving new problems.

depr8 hours ago

Perhaps that is what makes them '10x developers': a great familiarity with their toolset and a deep understanding of the problems they are solving. In this sense I don't think it's bad to idolize them, as familiarity and understanding are achievable by many people, and they could all become a '10x developer'.

ZephyrBlu8 hours ago
BiteCode_dev7 hours ago

Sure, like anyone can be Usain Bolt if they are familiar with their body and has a deep understanding of running.

leetrout9 hours ago


Add to it being able to work in YOUR headspace and not have to bring other people in a large-ish team along with you and you can get stuff done.

l30n4da56 hours ago

Agreed. I think most developers find themselves more productive on their side projects than they are in the workplace because there is less overhead.

cj7 hours ago

> has a deep understanding of a problem (and has likely solved it once already), can churn out code far, far, faster

Is this a bad thing to discourage? Perhaps one way to increase your output as a developer is to narrow your focus (rather than jumping on the latest framework or build system which require constantly re-learning new solutions to the same problem)

DrBazza7 hours ago

> Is this a bad thing to discourage?

No. It's what I encourage people in my team to do all the time. In fact it's something I was also encouraged to do.

The full quote was:

"Become an expert in at least one thing in your job or preferably career, and do it while you have the time" (e.g. when you're junior and expectations are low, or not a manager).

ksec8 hours ago

I dont think the parent is just about LOC, but the quality of those LOC.

There are people producing JS bundler and are comfortable and familiar with their toolset along with deep understanding of the problem. And they dont even come close to what is being described here.

Scarbutt2 hours ago

Being proficient in your tech stack helps your output sure but it's only one part (and a small one IMO) of the equation for creating something like esbuild. The author of esbuild surely has a strong knowledge of computer architecture, data structure and algorithms, operating systems and some math.

moron4hire4 hours ago

And I really wish people would stop denying that there can be a massive difference in productivity from one individual to the next. It doesn't really matter what the theoretical limits are. What matters is the people you have and are hiring, and whether or not they are moving the needle.

Maybe we can put aside whether or not there is No True 10x Developer. But there are certainly 0.1x developers, and even -1x developers.

hn_throwaway_993 hours ago

I totally agree with you, but I also love the context of this quote with your username ;)

chakkepolja7 hours ago

10xer is not about churning out code.

"Why is DJ Bernstein so great? I too can churn out CRUD apps very fast in ruby rails" - some webshit says this every day on HN.

DrBazza6 hours ago
wetmore3 hours ago

Calling people "webshits" is not really in the spirit of HN imo.

ZephyrBlu9 hours ago

I don't understand this perspective. Everyone only has so many hours in a day, and there's only so fast you can work.

If he's writing esbuild that is taking time away from being the CTO of Figma. Either he's working a shit ton, one of the things (Esbuild or Figma) is being somewhat neglected, or his output is actually not as high as it looks.

zeroxfe7 hours ago

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.)

betageek8 hours ago

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.

ZephyrBlu8 hours ago

So working a shit ton then.

atonse5 hours ago

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.

xal3 hours ago


pixelrevision8 hours ago

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

zerocount9 hours ago

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.

ZephyrBlu9 hours ago

In which case my last option would be relevant:

> or his output is actually not as high as it looks

fvdessen4 hours ago

Frankly most of us would not be able to create esbuild even with all the time in the world.

marton7812 hours ago

Amazing. That means he does his job right! As a good CTO you shouldn't have anything to do. If you're caught up in work, you're doing it wrong.

hn_throwaway_995 hours ago

> 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.

winrid10 hours ago

and he's building tools to optimize his teams.

Aeolun8 hours ago

Sounds like he solved his own problem?

todotask8 hours ago

Surprise, I didn’t know who was the maintainer and was still unheard of back then until I shared on HN and it was a like wildfire.

imjared6 hours ago

I've been trying to figure out how to build JS projects with the evolving tools (grunt => gulp => webpack => parcel => back to webpack) for years. I stumbled on esbuild and thought why not. Within about 15 minutes, I had solved pretty much all our build issues. Admittedly, our use case was simple-- we needed to transpile React-flavored TS to a npm package. In about 6 lines of code, I had a working bundle. There were no .esbuildrc or esbuild.config.js files, no babel dependencies, and no order of build operations to consider. The tool just worked and it was screaming fast. My first impression was that it _didn't_ work because the process closed in my terminal so quickly.

After my first experiment with it, I rewrote our hundreds of lines Cloud Functions deploy script in about 15 lines (most of which is configuration options on the `build()` method).

I'm curious to explore the tool more. Kudos and thanks to the author for an unbelievably useful contribution.

louissm_it13 hours ago

ESbuild is getting fantastic traction. It’s the default in Phoenix from 1.6 and comes as a default option in the current alpha of Rails 7, which you can get with a simple

rails new your_app -j esbuild

The only sort of issue I’ve had with it so far is you can’t use it with Inertiajs[1] as it does not support dynamic imports out of the box. Although I’m hesitant to call it an issue if its not in the scope of the project. Perhaps there are plugins I can use.

[1] -

d3nj4l13 hours ago

Esbuild w/rails 7 is nice, but if you’re using rails, check out vite_ruby [1]. I used it in a side project and it comes with plugins for views HMR + all the good stuff that comes built into vite.


louissm_it13 hours ago

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 :)

deergomoo8 hours ago

Does it not support dynamic imports at all, or does it just not support “dynamic dynamic imports” i.e. dynamic imports where the module path is not constant?

If it’s the latter, you could have your Inertia page resolver be a giant switch statement of every possible page, where each case is a dynamic import call with a constant module name.

Kind of a pain but I think I’d prefer that if it meant I never had to write a webpack config again.

dorianmariefr5 hours ago

You can use esbuild to your existing rails apps via the gem jsbundling-rails

It works really well

qwertox10 hours ago

Why is it so fast? Mainly because:

- It's written in Go and compiles to native code. [...] While esbuild is busy parsing your JavaScript, node is busy parsing your bundler's JavaScript. By the time node has finished parsing your bundler's code, esbuild might have already exited and your bundler hasn't even started bundling yet. [...] Go is designed from the core for parallelism while JavaScript is not.

- Parallelism is used heavily.

dom11111 hours ago

We recently switched on a few of our project from Webpack and the difference is incredible. Running a watch using this is practically instantaneous compared to our previous setup. I've been recommending it to all my colleagues and we're replacing Webpack slowly but surely.

The main draw for me is the simplicity of the config too. Webpack config (even using things like Symfony's Encore) is pretty convoluted and confusing to track. This, at least in my experience, has greater readability and is simpler to understand.

sanderdlm10 hours ago

Do you have a public example of a PHP/Symfony project that you've ported from Webpack to esbuild?

dom1113 hours ago

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

baybal211 hours ago

Webpack is a bane of webdev existence.

Having junior team encounter a webpack breakage === them spending as much time on tooling, as coding itself

ksec7 hours ago

>Webpack is a bane of webdev existence.

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

enjikaka10 hours ago

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!

intruder8 hours ago

what are you talking about, webpack has nothing to do with Facebook or React.

satvikpendem11 hours ago

See also SWC, something similar to esbuild but written in Rust. NextJS uses SWC as well as Deno.

Rome is also being rewritten in Rust, it's more of a complete set of packages that subsume Webpack, Babel and all the other parts of the JS / TS development experience.

o_m11 hours ago

The announcements from NextJS has been really confusing. I don't think they are using SWC yet. They are just working on it. The reason for the confusion is because they write about the progress in the release notes, making it look like they are using it.

crubier6 hours ago

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 ( ). Hot reload times instantly went from 10s to 1s. Twitter discussion here

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

alfonsodev2 hours ago

could you provide a link on how to enable this experimental setting ? thank you.

forsakenharmony10 hours ago

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

cute_boi11 hours ago

May be in next release we get swc in nextjs?

kureikain13 hours ago

esbuild is fast but it has a lot of place you have to figure out yourself and get into your way of doing thing.

1. dev server: you have to write a bit of code for this server to act as webpack dev server 2. scss: need to install plugin, and plugin cannot use from command line then you need to write a bit of JavaScript 3. global function: if you do `process.env` now you need to inject into build script 4. node package: if the package use node stuff you have to define thing like `fs/stream` into package.json

very quickly it get into your way of doing thing.

However, once you get past that base line, the cost is constant, the complexity just stop right there and not adding up.

Plus, the speed is amazing.

Sheepsteak10 hours ago

This is exactly what I found when I tried esbuild a few months ago. I gave up and went with Parcel 2 at the time as I found it easier to get going (although there were teething problems with Parcel being beta at the time).

I need to give esbuild another go I think.

pineconewarrior2 hours ago

How is the SCSS performance? I've tried just about every trick in the book in an attempt to get our bootstrap-based SCSS projects to compile faster, and I'm at my wits end with it.

Any chance you can share your config?

kureikain1 hour ago

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

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

I used

rwieruch5 hours ago

esbuild is partially [0] used in Vite [1] where you get a dev server et al.

- [0] - [1]

eyelidlessness13 hours ago

3. You can inject anything you want without a plugin with `inject`.

4. You can just use `target: node` (or node12, node14.6, etc)

swhitf9 hours ago

You know you are getting old when you watch the arrival of the fourth JavaScript build tool of your career. I still remember when everyone was waving goodbye to Gulp in favour of Webpack. Webpack was going to save us all from the hell of massive convoluted gulp.js files. Fast forward five years and it's the same mess it was supposed to avoid. Slow, bloated and confusing.

I just switched to esbuild on our main project and the build time went from 7 minutes on CI to 1 second. Kinda stupid really. Anyway, here's to the future, let's hope it works out this time!

have_faith8 hours ago

I always found it amusing going from Grunt (unwieldly huge object based config) to Gulp (config is code, pipe transformations together in a simple unix'y way) to being told webpack is the future (huge unwieldly config objects again). Definitely felt like a step backwards although I appreciate the power webpacks gives to people building boilerplates like Create-react-app. I rarely use Gulp anymore but I still appreciate it's UX/DX.

whoisthemachine7 hours ago

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

horsawlarway6 hours ago

I feel like Gulp sort of shot itself in the foot.

As someone who liked Gulp (SOOO much more than Grunt/Browserify) the transition from v3 to v4 felt really, really bad. Lots of unknowns around release timing, poor community support for the new version, "beta" tags sticking around forever long after it should have been released, maintainer turnover, etc...

It was enough at the time to get me to jump to Webpack, since it seemed like gulp was dying, and if I had to pick a configuration based tool it wasn't going to be Grunt.

Now I'm actually swinging back towards a combination of Gulp and ESBuild on my personal projects. I honestly debated trying a mix of Make and ESBuild (Since Gulp still feels pretty dead, and hasn't had a real release in 2+ years), but Make has enough subtle gotchas that I stuck with something familiar.

pineconewarrior2 hours ago

You're right about the community being mostly dead. There are a lot of bugs and performance issues in the underlying libraries, and Gulp's developers have not been able to get the upstream updates integrated.

I just redid our Grunt stuff in Gulp. It was painful - difficult to find up-to-date information, and the result was not that great. I expected a much greater SCSS compilation performance increase compared to FS-based tooling. Maybe I'm doing something wrong.

I'd switch to something like ESBuild and leave SCSS for dead, but it's not an option for me yet :(

jacobsenscott7 hours ago

I remember when we just served the javascript we wrote. Of course we are back to that. You can just write es6 in as many files as you would like and serve it over http/2 without any webpack/esbuild/babble/etc.

The fastest code is no code.

btbuildem6 hours ago

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.

h0h0h0h01114 hours ago

I'm interested to know who you know spends 20% of their time on tooling issues... I use node, npm and webpack pretty regularly (albeit parcel has mostly replaced webpack for me) and other than setting up some npm scripts and a tsconfig to output the right js for my node version at the start of a project, I barely interact with them.

moralestapia8 hours ago

>build time went from 7 minutes on CI to 1 second

I never jumped into that bandwagon and my build times are instantaneous using regular scripts ...

ep1038 hours ago

5 if you include grunt.

6 if you include bash/make for using manual scripts to productionize your yui / jqueryUi / mooTools code with uglify/browserify/gcc/etc

alvarlagerlof6 hours ago

Don't forget bun and swc

koolba8 hours ago

> I just switched to esbuild on our main project and the build time went from 7 minutes on CI to 1 second.

Is that an exaggeration or did it really get 420x faster?

horsawlarway6 hours ago

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)

nicoburns8 hours ago

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)

petethepig12 hours ago

Great job on the landing page — that simple animation tells an incredibly simple and compelling story all in 800x200 pixels.

I wish more products had landing pages that looked like that.

gyosko10 hours ago

It is very easy to be misleading though:

iruoy8 hours ago

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.

phillu13 hours ago

I'm using this to compile typescript lambda functions for AWS with great success. Combined with cdk and its NodeJsFunction you can even deploy/compile without local docker.

tiew9Vii12 hours ago

I looked at using ESbuild and I use Typescript. It was all looking good until reading the docs and it said ESbuild doesn't typecheck Typescript and to rely on your IDE to flag errors.

Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradiction to using Typescript so I set up a Webpack build using the standard ts compiler.

I've been out the loop of client side stuff a couple of years so to start was bit of a rabbit hole. Grunt/Gulp had gone and now Webpack seems common with a growing fanbase for ESbuild because of it's speed.

Vinnl12 hours ago

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.

chrisjc8 hours ago

First, forgive my ignorance of the JS/TS and bundler ecosystems.

> while in parallel checking for type errors.

Why are you suggesting this not be done during development? Is it bc while ESBuild is fast and runs in parallel, it's still only as fast as the slowest parallelized task, and in this case the slowest task is checking for type errors? And I assume checking for type errors is the slowest because it has to invoke an external resource, tsc?

Would it not make sense to have two development bundlers then? One for getting your code up and running quickly, and a second that outputs a dummy build artifact, but allows a more thorough production-like build that includes type checking (or other long running activities)? That way you get all the verification you would like, but don't pay a price on waiting for your code to deploy?

Vinnl8 hours ago

You can absolutely run it during development! In fact, many people will use an editor that automatically does this and highlights any potential errors - which means you don't need your compiler to display them (or even block compiling) as well.

And yes, type checking is relatively slow, and also strictly extra work, since it's not required to make your code runnable.

You'll often see that people do still do a more thorough production build in their CI systems, but not necessarily by using a bundler that includes type checking; rather, they just run type checking and bundling as separate tasks. That way, you do indeed get all the verification you would like without having to delay deployment.

(To make it somewhat more confusing, a project like Vite does use a fast bundler (ESBuild) during development and a more thorough one for production (Rollup), but that's independent of type checking. It's more about the latter doing more optimisations, and the former merely making the code runnable by the browser.)

EugeneOZ11 hours ago

It's not a linter, far from it.

Sammi10 hours ago
acid__12 hours ago

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.

lstamour12 hours ago

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.

kitd11 hours ago

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.
EugeneOZ11 hours ago

Only if a project is pretty small. Change in one place, especially if it's a reusable code, might ruin code in multiple different places and IDE will not recompile the whole project on every change, it will only watch your currently opened files and, maybe, some files in opened folders.

simlevesque10 hours ago
RobertKerans8 hours ago

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

dkdbejwi3838 hours ago

`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.

nsonha10 hours ago

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.

Aeolun13 hours ago

What I need is a similar speedup for my Typescript and eslint checks. Bundling isn’t my main issue.

nuerow12 hours ago

> Bundling isn’t my main issue.


Bundling, and even barreling, have pretty much been solved problems for a while. Right now I feel that unit test frameworks, linters, and type checkers are by far the main bottlenecks in the development workflow.

kitten_mittens_7 hours ago

For ESLint:

For TS, tsc has an —incremental flag. ts-fork-checker-plugin is non-blocking for the rest of the build too.

Zarkaos11 hours ago

For our quite big JS codebase on React + typescript, we switched from Webpack to esbuild earlier this year. It actually changed our daily lives !

The watch rebuild time went from 3-5s (actually a lot when you save your code very often) to something like .5-1 s

The full build time went from 120s to less than 5s

junon11 hours ago

Esbuild actually made writing frontend bearable for the first time in years. It alone reduced our iterative build times from 45 seconds to something like .5 seconds.

sorenjan13 hours ago

Are there any tools that transform HTML and other files? For example, lets say I have an <img> tag with a src attribute that points to a local image. Can I automatically replace that with a <picture> tag with various formats (jpg, webp, avif) and sizes?

M2Ys4U9 hours ago

I think Parcel[0] is what you want for that use-case.[1]



lioeters12 hours ago

Rehype is an HTML processor with an ecosystem of plugins:

tannhaeuser10 hours ago

SGML can transform HTML and all other forms of markup, though it's neither limited to that use, nor does it readily bundle image converters/compressors even though that sure has always been a plausible use case for SGML-based pipelines.

darekkay13 hours ago
eyelidlessness13 hours ago

In ESBuild you’ll need a plugin for this. The plugin API is really simple but you’ll likely be gluing other tools together to achieve it.

talkingtab7 hours ago

I started with webpack using create react app, I tried parcel, I tried esbuild. I tried parcel 2. I use esbuild. As a sole developer it takes no thought, and it still lets me do odd things pretty easily - like I have a particular process for dealing with odd cases in mdx files. Not a ringing endorsement or an exhaustive analysis. I'm just happy I don't have to spend time thinking about it. :-)

XCSme3 hours ago

I am currently using Parcel 2, I like it because I don't have to bother with any configuration. From what I've seen, with esbuild you still have to fiddle with configurations and loaders for specific filetypes? Can I just give it an entry point and let it figure out everything (update production HTML file with bundle links, import external images, target last X browser versions, etc) ?

XCSme3 hours ago

I am using ParcelJS v2 (nightly), and my builds are really fast for a medium-sized project. It takes about 5s from scratch (no-cache) and <500ms to update after a change.

Do I recommend Parcel? Not sure, it feels like every time I update the package something breaks (in their defense, it is still in Beta).

XCSme3 hours ago

I have to note that the project is a TypeScript project.

crubier6 hours ago

Esbuild is amazing, but it’s worth mentioning SWC, which is written in Rust, even faster than Esbuild, and integrated within Deno, NextJS and other leading tools. Overall I am pretty bullish on the Rust/Js/Wasm/Typescript ecosystem.

fabian2k12 hours ago

I had ignored this space for a while as I didn't see any need to fiddle with it. But there does seem to be quite a lot of movement now on Webpack alternatives. The speed improvements do look very interesting, though I'm not so sure how much of the delays I'm seeing with Webpack/Create React App are from the Typescript checking. I mean Typescript is awesome, but it's also not all that fast in building and type checking.

Vite seems to be one of the more interesting CRA alternatives. Though it uses esbuild only for development, and Rollup for production builds. It'll be interesting to see how this develops, and if the fast bundlers keep catching up in terms of features without getting slower.

cypressious12 hours ago

I think vite is using esbuild only for TS transpiling in development and esbuild & rollup for production.

armchairhacker2 hours ago

How does esbuild compare to Bun, snowpack, Vite, and any other JS bundles? In performance, reliability, and extra features?

jerrygoyal11 hours ago
toastal9 hours ago

While useful, it should be noted TypeScript ≠ JavaScript and this build tool is for TypeScript. Many of us are using different compile-to-JS languages, or no language at all.

wdroz10 hours ago

So swc is faster in almost all scenarios

RobertKerans9 hours ago

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.

Tade09 hours ago

Such a shame that Angular doesn't benefit from using such tools:

So I'm currently stuck with a build that takes minutes, even though in principle it should require only seconds.

dugmartin10 hours ago

I switched to it on all of my personal (TypeScript) projects after upgrading to Phoenix 1.6 (where it is required). I normally have a separate lint step during production builds so its lack of type checking isn't an issue during development as VSCode catches and highlights type errors anyway.

It is crazy fast. It feels like the Turbo Pascal 3 of web development.

kohlerm13 hours ago

That's old news or? For complex projects moving to esbuild from say Webpack is not necessarily easy.

onion2k12 hours ago

For complex projects moving to esbuild from say Webpack is not necessarily easy.

Why would things be easy in a complex project? If you've built complexity into your project it seems a little unreasonable to expect someone else's tool to fix that for you. At some point you need to accept that building things that are simple is your own responsibility. But building things that are simple is incredibly hard so don't be too down on yourself if your project is complex. Software complexity is like entropy; it's very easy to add complexity to a system, and very hard to remove it.

It's also worth noting that you probably don't really want a tool to make your complex project appear more simple. That would only hide the complexity from you, but it would still be there. If your project is complex then your best approach to solving that is a lot of documentation, a lot of testing, and a lot of refactoring.

sesm5 hours ago

> Both Go and JavaScript have parallel garbage collectors, but Go's heap is shared between all threads while JavaScript has a separate heap per JavaScript thread.

It actually implies that JS GC can be faster because it doesn’t require global locks and can collect garbage in parallel.

towndrunk6 hours ago

Does esbuild support scss directly yet? I see on the site it mentions css. This is an important limitation for me.

pineconewarrior2 hours ago

Same! I am struggling with SCSS tooling. SCSS/SASS itself even seems like it is in dire need of maintenance and direction.

Personally I'd rather not use it at this point, but it's not viable yet

strzibny8 hours ago

Both Rails 7 and Phoenix 1.6 is going off Webpack by default and I am so looking into the esbuild future. I never really liked Webpack to be honest.

I already replaced Webpack in my Phoenix project (you can compare default steps for building a release here and cannot wait to do the same in Rails.

TekMol13 hours ago

Isn't the browser also an extremely fast Javscript bundler?

How many scripts does a site need to make it feel faster when bundled?

When I visit websites that are rendered serverside, they usually feel instant to me. Even when they load a dozen scripts or so.

throw_m23933911 hours ago

> How many scripts does a site need to make it feel faster when bundled?

It's because people are using these huge frameworks with a lot of bloated code, it's too big, now devs are forced to do tree shaking and what not to trim the fat... front end JS development has become a madhouse of unnecessary complexity, because of node.js as well...

I hope that with the help of DENO that doesn't suffer from all that cargo culting, front-end development can become a healthier ecosystem...

Yes, some apps are complex, but 99% of front-end UI aren't.

rimliu10 hours ago

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.

eyelidlessness13 hours ago

What ESBuild offers over plain ESM is:

- fast TypeScript/JSX compile

- bundling shared code to reduce request waterfall/splitting to reduce redundancy

- bundle optimization (tree shaking/dead code elimination; minification is actually faster than not using it)

- a simple plugin system for use cases like other compiled frameworks like Vue or Svelte, or whatever else you might want in a build pipeline

TekMol13 hours ago

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.

rudian12 hours ago

Unless your site is made of 4 files/modules, you simply must bundle. ESM will download the files in series, as each dependency is discovered. Then compression doesn’t work as well as it will be per-file. Then of course you can’t tree-shake dependencies from npm, so good luck downloading the whole of lodash on your client.

In short you lose the advantages of only download what you need pretty quickly.

TekMol11 hours ago

> good luck downloading the whole of lodash on your client

I never felt the need to use loadash. But even if a site would do that, it does not seem like a big issue. It is 71k. A Twitter profile page is over 5MB. 70 times the size of that loadash library. An appartment page on AirBnB is over 9MB. An Instagram profile page is over 9MB too.

eyelidlessness4 hours ago

ESBuild does support code splitting, in case you weren’t aware.

kryptiskt10 hours ago

I like Snowpack ( because it doesn't actually do any bundling, it just makes sure that the files are in the right place to be loaded (it does compile Typescript files). Because the only thing I actually care about during development is that all the inter-package dependencies are resolved. I don't actually need a fat heap of JS that needs to be rebuilt every time I change something.

Mikeb8513 hours ago

Yes, that's why ES modules and import maps are a thing. For example Deno uses them, and they're the new default on Rails 7.

dmitriid13 hours ago

> How many scripts does a site need to make it feel faster when bundled?

Depends on what you're building. If you have many nested dependencies, you need to bundle them, and not rely on the browser to resolve them at runtime and do dozens of roundtrips to the server to fetch them.

TekMol13 hours ago

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

setr13 hours ago

If your dozens of scripts are top-level (on the html itself) then you can fetch all of them in parallel — so you wait your connection speed roughly twice (roundtripped).

If they’re nested dependencies (where you don’t identify the next necessary js until you have the first one in hand), the dependency won’t start getting fetched until the predecessor is retrieved. So you wait your connection speed multiplied by depth (x2; roundtripped)

The goal of the bundler is to take the second scenario and turn it into the first scenario.

eknkc13 hours ago

If they are not waterfalling then yeah. But when a depends on b and b depends on c you will be fetching those serially.

The bundler will have those preprocessed and bundled together.

_old_dude_13 hours ago

Browsers are good at caching JavaScript files, so it depends if the scripts are already cached or not.

dmitriid13 hours ago

There will definitely be an inflection point, and it's very dependent on many factors: number and size of scripts, how much of the initial content is SSRed, network bandwidth and latency etc.

hivacruz13 hours ago

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

The creator of Rails talks about it here:

beeandapenguin11 hours ago

Khan Academy did a great writeup on their experience (including thoughts about HTTP/2) with various strategies for serving JS, such as:

- Single bundle

- No bundles (all separate files)

- Hybrid

eyelidlessness13 hours ago

You can use the Network tab of your preferred browser to see the waterfall. HTTP2 did improve a lot, but it can’t magically resolve N-deep transitive imports without additional information. It was originally designed to have that information provided at the server level, but HTTP Push has been dead for a while. There are physical limitations at work, optimizing requests on the wire is still important.

nsonha13 hours ago

> When I visit websites that are rendered serverside, they usually feel instant to me. Even when they load a dozen scripts or so

Then they'll be faster doing only one request, this is regardless of ssr or spa

Bundling also gives you slatic analysis (typescript and linting), and frees developers from developing in the dark, like keeping track in their brain what component in what script exposes what global.

throw_m23933911 hours ago

> 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.

mjackson12 hours ago

Although esbuild has been out for a while now, I think it's relevant today because the benchmarks have been updated to include Parcel 2, which was just released earlier today.

pier256 hours ago

Personally I've never found bundling speed to be a major bottleneck.

I do have some complicated Webpack setups that I don't think can be solved with any other bundler.

eezing12 hours ago
moron4hire4 hours ago

Full build with Rollup on all of my bundles for my project took around 10 minutes. IDK what my KLoC count is, but it's probably in the 25 to 50K range, with very few dependencies. I had a lot of complexity in my build scripts to try to subdivide related bundles into individual build commands to get the day-to-day rebuilds down to the 1 to 2 minute range. I had to run TypeScript in watch mode separately to emit individual JS files from my TS code for each module, and then only let Rollup bundle the JS code (the available TS plugins were just too slow), so I had tons of garbage files all over everywhere and occasionally they would get out of synch. It was a mess and it was extremely difficult to explain everything to newcomers.

With ESBuild, everything, all the things, build in 0.25 seconds. Build script has massively reduced complexity, as there's no point in running any command other than "build all". There's just the TS code and the output. I'm still running TypeScript in watch mode separately to get compilation errors on the fly (ESBuild doesn't run the TS compiler itself, it has a custom-built translator that optimistically throws away type information), but I no longer configure it to emit translated code. And did I mention the build script is massively simpler?

escot5 hours ago

So is esbuild vs parcel a bit of an accidental proxy battle between go and rust?

darepublic6 hours ago

It stings being in webpack and there isn't much I can do about it in my current situation

jFriedensreich5 hours ago

also kudos to the esbuild team to have an official mention of deno usage and support. it works great and turned out to be much simpler, flexible and reliable than the current Deno.emit .

conaclos9 hours ago

esbuild is a pleasure to use. Because of its speed you no longer need to separate test/release build for simple libraries. I am using esbuild for transpiling my new TypeScript projects.

However, I am still have to use TSC to generate declaration files(dts). Are anyone aware of esbuold-like tool to do that job?

qeternity11 hours ago

What’s the catch? Do they really have a secret sauce or are there limitations in esbuild to achieve these speed ups?

nusaru10 hours ago

Some section titles from the FAQ[1]:

> Why is esbuild fast? > - It's written in Go and compiles to native code. > - Parallelism is used heavily. > - Everything in esbuild is written from scratch. > - Memory is used efficiently.

> Production readiness > - Used by other projects > - API stability > - Only one main developer > - Not always open to scope expansion


qeternity9 hours ago

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

dbbk9 hours ago

It does

pedrow8 hours ago

It doesn't always work in situations where 'require' can't be statically evaluated at run-time (webpack would work in this situation) - for example I filed a bug recently[0] Even though the bug was closed I was impressed with the thorough and timely response from the esbuild developers which explained the reasoning behind it. For me it was worth changing my project just so I could continue using esbuild, it really is that good!


Kyro3810 hours ago

Well not being written in JS does help -a lot-.

Esbuild is written in GO.

qeternity9 hours ago

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

1_player5 hours ago

It helps to get 80% of the way there, on a logarithmic scale. The remaining 20% is evanw saying no to adding any kind of option, feature and the kitchen sink to this project, which is one of the reason Webpack/Babel & co. are some of the heaviest objects in the universe.

johnnypangs10 hours ago

The catch is that they focus on modern builds (I.e. not IE) it also doesn’t do type definitions, so if you want type defs you’ll need to compile with typescript anyway.

hsn9158 hours ago

The catch is the person behind it cares about performance

calmyournerves11 hours ago

esbuild is awesome! The level of detail in the release notes [1] always impresses me.


terpimost6 hours ago

I must say that this got to be a new standard. Es build is what we need. Great thing. Huge thanks to creators!

Kiro13 hours ago

How is it possible to be so fast?

lioeters12 hours ago

Answered in the FAQ:

Why is esbuild fast?

- It's written in Go and compiles to native code

- Parallelism is used heavily

- Written from scratch with performance as a goal

- Efficient use of memory

leeman201612 hours ago

It also doesn't include type checking for typescript. It just transpiles sources to javascript

Ginden10 hours ago

> 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.

louissm_it13 hours ago

1. It does a few things and does them really well (not taking on the complexity of ie Webpack)

2. It’s written in Go

joshxyz11 hours ago

Yep, moved from webpack to esbuild + postcss. Great results.

ep1038 hours ago

Anyone able to compare this to Vite?

armincerf8 hours ago

Vite uses Esbuild for development builds, and they have an answer for why they don't use it for prod builds here

Aeolun8 hours ago

Vite uses esbuild I think. But the concepts are different.

sandGorgon13 hours ago

has anyone used this in react-native ?

dstaley12 hours ago

Pretty sure the Expo folks are working on this!

sandGorgon12 hours ago

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

lovely_koala8 hours ago

Looks awesome! I'm gonna use it!

hit8run13 hours ago

What do you think of the importmap approach propagated by dhh on rails 7?

Mikeb853 hours ago

I'm using it right now, it's fantastic. Also been playing around with Deno, importmaps are also used there, it's so much nicer than the bundle and compile everything workflow. It's the direction everyone should be going since it actually uses the browser and browser standards to their potential.

Also if people don't want to use CDNs both Rails and Deno do allow you to serve ES modules from your server.

louissm_it13 hours ago

I think it’s a fantastic default. I’d argue most server rendered applications can get away with it. And if you ever need ESBuild you can install the js-bundling gem or pass “-j esbuild” for new Rails 7 apps.

albertgoeswoof12 hours ago

the only problem with this is that it's an option.

As a rails dev, I want one, strong opinion on what the default/best approach is. I don't want to configure anything

hit8run10 hours ago

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

Salu34 hours ago


sAbakumoff9 hours ago

from my PoV Vite.js is much more mature project than esbuild

truth_seeker13 hours ago

I would rather use Parcel.

nsonha13 hours ago

what is the point of the comment? It reads: I have an opinion (and here it is, but who gives a shit if you don't elaborate)

truth_seeker13 hours ago

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

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

wruza11 hours ago

“What is” is a vague question with no clear details in the answer. For example, parcel may have the middleware mode while esbuild may not. But then it’s parcel 1, but not 2, where it was removed to streamline plug-in development, so I better stick with 1 for a while. That is the context. By not providing it, the root comment has zero value, because an interested reader cannot learn at least some of the whys by simply reading the frontpage. Almost everyone knows it and thus will not follow your “open mindness” advice, because it’s pointless in this case.

marton7812 hours ago

Most people who care to read the comments to a post about esbuild will know what Parcel is. Why do you prefer it?

KingOfCoders8 hours ago

On another thread were I said I don't like build tools/compilers in the same language as they work on, when the language is slow, I got voted down.

Here everyone: JS build tool in Go? Great!

+1 for parallelism of esbuild. I have a12 core machine and many tools either use one core or when forced to not benefit from more cores.

I also wish they would waste more memory, I have 32gb which re mostly unused even by large projects.

I stand by my opinion: dev tools should make it pleasant for developers not the tool writers.

throw_m23933911 hours ago

Yet another one of these...

I'm sorry, but the node.js community needs to stop producing these stuff... it doesn't do anything better than all the webpack vs gulp vs parcel vs snowpack vs rollup vs how many bundlers again?

Intrepidd11 hours ago

I recently switched to esbuild and I am delighed. My build time dropped from 30s to 2s and I was able to remove a lot of dependencies. So IMHO they need to continue producing these stuff to push the innovation forward.

phinnaeus11 hours ago

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.

throw_m23933911 hours ago

> 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...

phinnaeus11 hours ago

I certainly didn't.

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


innocenat11 hours ago

    dist.js: $(wildcard *.js)
        cat $? > dist.js
Like this?