{"slug": "esbuild", "name": "esbuild", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "Fast JavaScript and TypeScript bundler and minifier written in Go.", "recommenders": 5, "commenters": 5, "warners": 0, "score": 4.408, "rising": -0.31, "first": "2025-12-30", "latest": "2026-08-13", "why": "Recommended for its speed and narrow, single-purpose scope, and for working as a Go library for type stripping and custom build pipelines.", "why_is_quote": false, "has_verdict": true, "sentiment": {"recommend": 5, "neutral": 0, "compare": 0, "warn": 0}, "spark": [0, 1, 1, 0, 1, 0, 0, 0, 1, 1, 0, 0], "listed": true, "loved": ["Go integration", "Speed"], "caveat": "Go module setup", "short_quote": "Esbuild is amazing. You can write entire dev servers and build pipelines in a couple hundred lines of Go", "icon": true, "domain": null, "github_repo": "github.com/evanw/esbuild", "official_url": "https://esbuild.github.io/", "pricing": "open source", "aliases": ["esbuild"], "verdict": [{"text": "Recommended for its speed and narrow, single-purpose scope,", "cites": [{"id": 788669328, "item_id": 49291833, "url": "https://news.ycombinator.com/item?id=49291833", "by": "10000truths", "date": "2026-08-13", "stance": "recommend", "quote": "I use the non-JS ones (esbuild, parcel, bun, etc.) and they're fast enough for me to not care.", "excerpt": "> Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo Can you elaborate more on the slowness you've seen with deploying TypeScript codebases? My experience is that it's improved significantly over the past decade or so. tsc is still kinda slow for large projects, but the rewrite to Go should improve things significantly. Pre-install/post-install scripts can also be slow, but I'v", "context": "", "use_case": "bundling TypeScript", "switched_from": "", "story": "Choose Boring Technology (2015)"}, {"id": 759829153, "item_id": 47489322, "url": "https://news.ycombinator.com/item?id=47489322", "by": "warpspin", "date": "2026-03-23", "stance": "recommend", "quote": "I love single-use tools with limited scope like e.g. esbuild", "excerpt": "I especially like that it's a single executable according to the docs. Recently evaluated other testing tools/frameworks and if you're not already running the npm-dependencyhell-shitshow for your projects, most tools will pull in at least 100 dependencies. I might be old fashioned but that's just too much for my taste. I love single-use tools with limited scope like e.g. esbuild or now this. Will give this a try, soo", "context": "", "use_case": "JS bundling", "switched_from": "", "story": "Bombadil: Property-based testing for web UIs by Antithesis"}]}, {"text": " and for working as a Go library for type stripping and custom build pipelines.", "cites": [{"id": 782540448, "item_id": 48908778, "url": "https://news.ycombinator.com/item?id=48908778", "by": "umvi", "date": "2026-07-14", "stance": "recommend", "quote": "In golang I use the go package github.com/evanw/esbuild[1] to do type stripping on the fly.", "excerpt": "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 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/ev", "context": "Go developer using vanilla TS on the front end", "use_case": "on-the-fly TypeScript type stripping", "switched_from": "", "story": "Why Vanilla JavaScript"}, {"id": 745026960, "item_id": 46564185, "url": "https://news.ycombinator.com/item?id=46564185", "by": "llmslave3", "date": "2026-01-10", "stance": "recommend", "quote": "Esbuild is amazing. You can write entire dev servers and build pipelines in a couple hundred lines of Go", "excerpt": "I was wondering why stuff was written in JS in the past - it seems obvious to use a faster language for these tools, but I then realised that these massive sprawling Typescript codebases are a modern phenomena. I sort of wonder if the tooling is just step one, and step two is not just the tooling but the other codebases going from TS to a faster lang (like Go). Speaking of Go, Esbuild is amazing. You can write entire", "context": "", "use_case": "dev servers and build pipelines", "switched_from": "", "story": "The Performance Revolution in JavaScript Tooling"}, {"id": 742909232, "item_id": 46431827, "url": "https://news.ycombinator.com/item?id=46431827", "by": "llmslave2", "date": "2025-12-30", "stance": "recommend", "quote": "esbuild can be used directly inside a Go program", "excerpt": "I love it. I'm using Go to handle building full stack javascript apps, which actually works great since esbuild can be used directly inside a Go program. The issue is that it's a dependency, so I settled for having a go mod file and running it directly with Go. If somehow these dependencies could be resolved without an explicit module configured (say, it was inline in the go file itself) it would be perfect. Alas, it", "context": "", "use_case": "building full stack JavaScript apps", "switched_from": "", "story": "Go Away Python"}]}, {"text": " Commenters raise few complaints, and it best suits Go developers building JavaScript or TypeScript apps.", "cites": [{"id": 782540448, "item_id": 48908778, "url": "https://news.ycombinator.com/item?id=48908778", "by": "umvi", "date": "2026-07-14", "stance": "recommend", "quote": "In golang I use the go package github.com/evanw/esbuild[1] to do type stripping on the fly.", "excerpt": "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 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/ev", "context": "Go developer using vanilla TS on the front end", "use_case": "on-the-fly TypeScript type stripping", "switched_from": "", "story": "Why Vanilla JavaScript"}, {"id": 742909232, "item_id": 46431827, "url": "https://news.ycombinator.com/item?id=46431827", "by": "llmslave2", "date": "2025-12-30", "stance": "recommend", "quote": "esbuild can be used directly inside a Go program", "excerpt": "I love it. I'm using Go to handle building full stack javascript apps, which actually works great since esbuild can be used directly inside a Go program. The issue is that it's a dependency, so I settled for having a go mod file and running it directly with Go. If somehow these dependencies could be resolved without an explicit module configured (say, it was inline in the go file itself) it would be perfect. Alas, it", "context": "", "use_case": "building full stack JavaScript apps", "switched_from": "", "story": "Go Away Python"}]}], "praise": [{"label": "Go integration", "summary": "It can be used directly inside Go programs, for example to strip TypeScript types on the fly.", "quotes": [{"id": 782540448, "item_id": 48908778, "url": "https://news.ycombinator.com/item?id=48908778", "by": "umvi", "date": "2026-07-14", "stance": "recommend", "quote": "In golang I use the go package github.com/evanw/esbuild[1] to do type stripping on the fly.", "excerpt": "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 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/ev", "context": "Go developer using vanilla TS on the front end", "use_case": "on-the-fly TypeScript type stripping", "switched_from": "", "story": "Why Vanilla JavaScript"}, {"id": 742909232, "item_id": 46431827, "url": "https://news.ycombinator.com/item?id=46431827", "by": "llmslave2", "date": "2025-12-30", "stance": "recommend", "quote": "esbuild can be used directly inside a Go program", "excerpt": "I love it. I'm using Go to handle building full stack javascript apps, which actually works great since esbuild can be used directly inside a Go program. The issue is that it's a dependency, so I settled for having a go mod file and running it directly with Go. If somehow these dependencies could be resolved without an explicit module configured (say, it was inline in the go file itself) it would be perfect. Alas, it", "context": "", "use_case": "building full stack JavaScript apps", "switched_from": "", "story": "Go Away Python"}, {"id": 745026960, "item_id": 46564185, "url": "https://news.ycombinator.com/item?id=46564185", "by": "llmslave3", "date": "2026-01-10", "stance": "recommend", "quote": "Esbuild is amazing. You can write entire dev servers and build pipelines in a couple hundred lines of Go", "excerpt": "I was wondering why stuff was written in JS in the past - it seems obvious to use a faster language for these tools, but I then realised that these massive sprawling Typescript codebases are a modern phenomena. I sort of wonder if the tooling is just step one, and step two is not just the tooling but the other codebases going from TS to a faster lang (like Go). Speaking of Go, Esbuild is amazing. You can write entire", "context": "", "use_case": "dev servers and build pipelines", "switched_from": "", "story": "The Performance Revolution in JavaScript Tooling"}]}, {"label": "Speed", "summary": "As a non-JS bundler it is fast enough that build speed stops being a concern.", "quotes": [{"id": 788669328, "item_id": 49291833, "url": "https://news.ycombinator.com/item?id=49291833", "by": "10000truths", "date": "2026-08-13", "stance": "recommend", "quote": "I use the non-JS ones (esbuild, parcel, bun, etc.) and they're fast enough for me to not care.", "excerpt": "> Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo Can you elaborate more on the slowness you've seen with deploying TypeScript codebases? My experience is that it's improved significantly over the past decade or so. tsc is still kinda slow for large projects, but the rewrite to Go should improve things significantly. Pre-install/post-install scripts can also be slow, but I'v", "context": "", "use_case": "bundling TypeScript", "switched_from": "", "story": "Choose Boring Technology (2015)"}]}, {"label": "Limited scope", "summary": "Valued as a single-use tool with a limited scope.", "quotes": [{"id": 759829153, "item_id": 47489322, "url": "https://news.ycombinator.com/item?id=47489322", "by": "warpspin", "date": "2026-03-23", "stance": "recommend", "quote": "I love single-use tools with limited scope like e.g. esbuild", "excerpt": "I especially like that it's a single executable according to the docs. Recently evaluated other testing tools/frameworks and if you're not already running the npm-dependencyhell-shitshow for your projects, most tools will pull in at least 100 dependencies. I might be old fashioned but that's just too much for my taste. I love single-use tools with limited scope like e.g. esbuild or now this. Will give this a try, soo", "context": "", "use_case": "JS bundling", "switched_from": "", "story": "Bombadil: Property-based testing for web UIs by Antithesis"}]}, {"label": "Build control", "summary": "Lets you write dev servers and build pipelines with hot reloading in a few hundred lines of Go.", "quotes": [{"id": 745026960, "item_id": 46564185, "url": "https://news.ycombinator.com/item?id=46564185", "by": "llmslave3", "date": "2026-01-10", "stance": "recommend", "quote": "Esbuild is amazing. You can write entire dev servers and build pipelines in a couple hundred lines of Go", "excerpt": "I was wondering why stuff was written in JS in the past - it seems obvious to use a faster language for these tools, but I then realised that these massive sprawling Typescript codebases are a modern phenomena. I sort of wonder if the tooling is just step one, and step two is not just the tooling but the other codebases going from TS to a faster lang (like Go). Speaking of Go, Esbuild is amazing. You can write entire", "context": "", "use_case": "dev servers and build pipelines", "switched_from": "", "story": "The Performance Revolution in JavaScript Tooling"}]}], "caveats": [{"label": "Go module setup", "summary": "Using it from a Go script requires a go.mod file because it is a dependency.", "quotes": [{"id": 742909232, "item_id": 46431827, "url": "https://news.ycombinator.com/item?id=46431827", "by": "llmslave2", "date": "2025-12-30", "stance": "recommend", "quote": "esbuild can be used directly inside a Go program", "excerpt": "I love it. I'm using Go to handle building full stack javascript apps, which actually works great since esbuild can be used directly inside a Go program. The issue is that it's a dependency, so I settled for having a go mod file and running it directly with Go. If somehow these dependencies could be resolved without an explicit module configured (say, it was inline in the go file itself) it would be perfect. Alas, it", "context": "", "use_case": "building full stack JavaScript apps", "switched_from": "", "story": "Go Away Python"}]}], "who": [{"by": "umvi", "context": "Go developer using vanilla TS on the front end", "url": "https://news.ycombinator.com/item?id=48908778", "date": "2026-07-14"}], "tags": ["for Go developers", "for TypeScript projects", "for custom build pipelines"], "use_cases": ["bundling typescript", "on-the-fly typescript type stripping", "js bundling", "dev servers and build pipelines", "building full stack javascript apps"], "compared": [], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=49289512", "title": "Choose Boring Technology (2015)", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48885705", "title": "Why Vanilla JavaScript", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47436592", "title": "Bombadil: Property-based testing for web UIs by Antithesis", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=46481682", "title": "The Performance Revolution in JavaScript Tooling", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=46431028", "title": "Go Away Python", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {"recommend": 1}, "2026-01": {"recommend": 1}, "2026-02": {}, "2026-03": {"recommend": 1}, "2026-04": {}, "2026-05": {}, "2026-06": {}, "2026-07": {"recommend": 1}, "2026-08": {"recommend": 1}, "2026-09": {}, "2026-10": {}}, "quotes": [{"id": 788669328, "item_id": 49291833, "url": "https://news.ycombinator.com/item?id=49291833", "by": "10000truths", "date": "2026-08-13", "stance": "recommend", "quote": "I use the non-JS ones (esbuild, parcel, bun, etc.) and they're fast enough for me to not care.", "excerpt": "> Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo Can you elaborate more on the slowness you've seen with deploying TypeScript codebases? My experience is that it's improved significantly over the past decade or so. tsc is still kinda slow for large projects, but the rewrite to Go should improve things significantly. Pre-install/post-install scripts can also be slow, but I'v", "context": "", "use_case": "bundling TypeScript", "switched_from": "", "story": "Choose Boring Technology (2015)"}, {"id": 782540448, "item_id": 48908778, "url": "https://news.ycombinator.com/item?id=48908778", "by": "umvi", "date": "2026-07-14", "stance": "recommend", "quote": "In golang I use the go package github.com/evanw/esbuild[1] to do type stripping on the fly.", "excerpt": "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 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/ev", "context": "Go developer using vanilla TS on the front end", "use_case": "on-the-fly TypeScript type stripping", "switched_from": "", "story": "Why Vanilla JavaScript"}, {"id": 759829153, "item_id": 47489322, "url": "https://news.ycombinator.com/item?id=47489322", "by": "warpspin", "date": "2026-03-23", "stance": "recommend", "quote": "I love single-use tools with limited scope like e.g. esbuild", "excerpt": "I especially like that it's a single executable according to the docs. Recently evaluated other testing tools/frameworks and if you're not already running the npm-dependencyhell-shitshow for your projects, most tools will pull in at least 100 dependencies. I might be old fashioned but that's just too much for my taste. I love single-use tools with limited scope like e.g. esbuild or now this. Will give this a try, soo", "context": "", "use_case": "JS bundling", "switched_from": "", "story": "Bombadil: Property-based testing for web UIs by Antithesis"}, {"id": 745026960, "item_id": 46564185, "url": "https://news.ycombinator.com/item?id=46564185", "by": "llmslave3", "date": "2026-01-10", "stance": "recommend", "quote": "Esbuild is amazing. You can write entire dev servers and build pipelines in a couple hundred lines of Go", "excerpt": "I was wondering why stuff was written in JS in the past - it seems obvious to use a faster language for these tools, but I then realised that these massive sprawling Typescript codebases are a modern phenomena. I sort of wonder if the tooling is just step one, and step two is not just the tooling but the other codebases going from TS to a faster lang (like Go). Speaking of Go, Esbuild is amazing. You can write entire", "context": "", "use_case": "dev servers and build pipelines", "switched_from": "", "story": "The Performance Revolution in JavaScript Tooling"}, {"id": 742909232, "item_id": 46431827, "url": "https://news.ycombinator.com/item?id=46431827", "by": "llmslave2", "date": "2025-12-30", "stance": "recommend", "quote": "esbuild can be used directly inside a Go program", "excerpt": "I love it. I'm using Go to handle building full stack javascript apps, which actually works great since esbuild can be used directly inside a Go program. The issue is that it's a dependency, so I settled for having a go mod file and running it directly with Go. If somehow these dependencies could be resolved without an explicit module configured (say, it was inline in the go file itself) it would be perfect. Alas, it", "context": "", "use_case": "building full stack JavaScript apps", "switched_from": "", "story": "Go Away Python"}]}