HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
evanw
esbuild
Go2020–2026
evanw / esbuild

esbuild

An extremely fast bundler for the web

66Distinct people
78Mentions
0Explicit recommenders
40.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

An extremely fast bundler for the web

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year78 dated mentions

Observed mentions: 2020-02-15 15:09:23 UTC to 2026-07-14 15:55:40 UTC.

01020302020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 14 mentions; 3 submissions, 11 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 29 mentions; 3 submissions, 26 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 11 mentions; 0 submissions, 11 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC14311
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC29326
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC11011
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC615
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC422
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC1019
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC404

What Hacker News says

78 sources
You don't need a bundler, just a type stripper. And yeah you need a middleware to perform the type stripping, the server won't do it automatically, but it's like 10 lines of backend code. The basic flow would be something like: 1. Browser requests /js/foo.js 2. Server middleware checks if /js/foo.ts exists 3. If yes, server middleware strips types from the file before returning it In golang I use the go package github.com/evanw/esbuild[1] to do type stripping on the fly. The middleware looks like this: ``` return esbuild.Transform(string(fileBytes), esbuild.TransformOptions{ Loader: esbuild.LoaderTS, Format: esbuild.FormatESModule, }) ``` It only takes a few microseconds and I don't need any bundlers or tsc or anything like that. Everything on my frontend is 100% vanilla TS; I make changes directly to TS and then hit refresh in my
Read the rest
browser and the changes are reflected instantly without needing a bundler or even node/npm for that matter. Note: for this setup to work, your front end TS has to use ES modules import/export which browsers natively support. If you try to use CommonJS or something like that, you would start needing a bundler again because browsers can't resolve "require" statements. In node it should be even easier than Go because Node added native type stripping starting with v22[2] But even on older versions of Node, a type stripping middleware would still be very easy to implement[3][4]. [1] https://pkg.go.dev/github.com/evanw/esbuild [2] https://nodejs.org/api/module.html#modulestriptypescripttype... [3] https://github.com/bloomberg/ts-blank-space [4] https://esbuild.github.io/api/#js-async
In Why Vanilla JavaScript
When the left-pad debacle happened, one commenter here said of a well known npm maintainer something to the effect of that he's an "author of 600 npm packages, and 1200 lines of JavaScript". Not much has changed since then. The best counter-example I know is esbuild, which is a fully featured bundler/minifier/etc that has zero external dependencies except for the Go stdlib + one package maintained by the Go project itself: https://www.npmjs.com/package/esbuild?activeTab=dependencies https://github.com/evanw/esbuild/blob/755da31752d759f1ea70b8... Other "next generation" projects are trading one problematic ecosystem for another. When you study dependency chains of e.g. biomejs and swc, it looks pretty good: https://www.npmjs.com/package/@biomejs/biome/v/latest?active... https://www.npmjs.com/package/@swc/types?activeTab=dependenc... Replac
Read the rest
ing the tire fire of eslint (and its hundreds to low thousands of dependencies) with zero of them! Very encouraging, until you find the Rust source: https://github.com/biomejs/biome/blob/a0039fd5457d0df18242fe... https://github.com/swc-project/swc/blob/6c54969d69551f516032... I think as these projects gain more momentum, we will see similar things cropping up in the cargo ecosystem. Does anyone know of other major projects written in as strict a style as esbuild?
In Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
Yes, as you pointed out, not only can bundlers tree shake namespace imports, but they're literally used in the esbuild documentation to demonstrate the concept of tree shaking. The issue you linked to is referring to the case in which you import a namespace object and then re-export it. Bundlers like webpack and rollup (which vite uses in production) can tree shake this pattern as well, but esbuild struggles with it. If you're using esbuild instead of this: import * as someLibrary from "some-library" someLibrary.someFunction() export { someLibrary } You can still do this: import * as someLibrary from "some-library" someLibrary.someFunction() export * from "some-library" export { default as someLibraryDefault } from "some-library" Tree shaking works as expected for downstream packages using esbuild in the second case, wh
Read the rest
ich someone else in the linked issue pointed out: https://github.com/evanw/esbuild/issues/1420#issuecomment-96...
In Left to Right Programming
> It is possible not to conflict with existing parallel deployments, but depending on your IPC mechanism, it is by no means assured when you're not forking and are instead launching an external process. Sure, some IPC approaches can run into issues, such as using TCP connections over loopback. However, I'm describing an approach that should never conflict since the resources that are shared are inherited directly, and since the binary would be embedded in your application bundle and not shared with other programs on the system. A similar example would be language servers which often work this way: no need to worry about conflicts between different instances of language servers, different language servers, instances of different versions of the same language server, etc. There's also some precedent for this approach since as far as I under
Read the rest
stand it, it's also what the Go-based ESBuild tool does[1], also popular in the Node.JS ecosystem (it is used by Vite.) > For example, it could by default bind a specific default port. This would work in the 'naive' situation where the client doesn't specify a port and no parallel instances are running. ...but if two instances are running, they'll both try to use the same port. Arbitrary applications can connect to the same port. Maybe you want to share a single compiler service instance between client apps in some cases? > Not conflicting is not a property of parallel binary deployment and communication via IPC by default. > IPC is, by definition intended to be accessible by other processes. Yes, although the set of processes which the IPC mechanism is designed to be accessible by can be bound to just one process, and there are cross-platform mechanisms to achieve this on popular desktop OSes. I can not speak for why one would choose TCP over stdin/stdout, but, I don't expect that tsc will pick a method of IPC that is flawed in this way, since it would not follow precedent anyway. (e.g. tsserver already uses stdio[2].) > Jupyter kernels for example are launched with a specified port and a secret by cli argument if I recall correctly. > However, you'd have to rely on that mechanism being built into the typescript compiler service. > ...ie. it's a bit complicated right? > Worth it for the speedup? I mean, sure. Obviously there is a reason people don't embed postgres. ...but they don't try to ship a copy of it along side their apps either (usually). Well, I wouldn't honestly go as far as to say it's complicated. There's a ton of precedent for how to solve this issue without any conflict. I can not speak to why Jupyter kernels use TCP for IPC instead of stdio, I'm very sure they have reasons why it makes more sense in their case. For example, in some use cases it could be faster or perhaps just simpler to have multiple channels of communication, and doing this with multiple pipes to a subprocess is a little more complicated and less portable than stdio. Same for shared memory: You can always have a protocol to negotiate shared memory across some serial IPC mechanism, but you'll almost always need a couple different shared memory backends, and it adds some complexity. So that's one potential reason. (edit: Another potential reason to use TCP sockets is, of course, if your "IPC" is going across the network sometimes. Maybe this is of interest for Jupyter, I don't know!) That said, in this case, I think it's a non-issue. ESBuild and tsserver demonstrate sufficiently that communication over stdio is sufficient for these kinds of use cases. And of course, even if the Jupyter kernel itself has to speak the TCP IPC protocols used by Jupyter, it can still subprocess a theoretical tsc and use stdio-based IPC. Not much complexity to speak of. Also, unrelated, but it's funny you should say that about postgres, because actually there have been several different projects that deliver an "embeddable" subset of postgres. Of course, the reasoning for why you would not necessarily want to embed a database engine are quite a lot different from this, since in this case IPC is merely an implementation detail whereas in the database case the network protocol and centralized servers are essentially the entire point of the whole thing. [1]: https://github.com/evanw/esbuild/blob/main/cmd/esbuild/stdio... [2]: https://github.com/microsoft/TypeScript/wiki/Standalone-Serv...
In A 10x Faster TypeScript
> is this the beginning of a larger trend where JS/TS tooling migrates to native implementations No, it is not. It is a continuation of an existing trend You may be interested in esbuild (https://github.com/evanw/esbuild), turborepo (https://github.com/vercel/turborepo), biome-js (https://github.com/biomejs/biome) are all native reimplementations of existing projects in JS/TS. esbuild is written in Go, the others in Rust. > reveals something deeper: Microsoft prioritized shipping a working solution over language politics Its not that "deep". I don't see the politics either way, there are clearly successful projects using both Go and Rust. The only people who see "politics" are those who see people disagreeing, are unable to understand the substance of the disagreement and decide "ah, it's just politics".
In A 10x Faster TypeScript
> like individual loaders/modules are/were slow, rather than webpack itself tbh this is just nitpicking, I'm not a react developer to do CRA debugging for them. They're paid by Facebook a couple orders of magnitude more than what we're making here, and if they're fine with the intact CRA configuration being that slow, while a third-party alternative rips through the massive pile of shit I'm working on while not bringing any obvious downsides, I'll just switch to the alternative. It's a well known problem: esbuild, which is the base of vite's HMR, boasts of speeds dozens to hundreds of times faster than webpack: https://github.com/evanw/esbuild?tab=readme-ov-file#why
In Modern JavaScript for Django developers

Showing the 15 most recent of 78 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.