17 ms·
Why Is Esbuild Fast?
- jamra 6y agoI wish the Angular team put some work into integrating. They are instead doubling down on webpack which is frustrating. After they back stepped regarding the bazel build system I thought that all was lost. Then this beauty came out. Unfortunately it's not as interesting as the incremental compiler.
- deanclatworthy 6y agoIt's still early days for esbuild. If you follow the commit history there are still some weird bugs. I'd give it a few months to get these things ironed out (along with wider usage) and it'll be good to go.
- jamra 6y agoThat would make my day. I have a 64GB RAM PC because I work on 2 or 3 angular apps at a time and since my PC is the fastest I also use it for CI builds on occasion. It's a nightmare to wait 20 minutes for an optimized prod build. And having to upgrade everyone's RAM so they can contribute to the front end is horrible. We are past 10GB of RAM required to start the dev server.
- nicoburns 6y ago10GB!! How big is this project!? Could you split it up somehow?
- jamra 6y agoWe actually just worked on splitting it up into libraries. The shared library might actually make the ending build larger due to it being potentially duplicated (I'm not certain about this until I test it). Unfortunately that has to go on hold temporarily. It is a large Healthcare application in the therapy space. The ending build is actually fine, but the tooling eats RAM like something else. Little by little I take large third party libraries and rewrite them on my own to drop 5MB includes. I'm sure that is part of it. Devextreme and Syncfusion are libraries I would strongly recommend avoiding.
- jeremycarter 6y agoSyncfusion added 15MB to my bundle size :( I like their components but they aren't lightweight by any means.
- kylecordes 6y agoIncidentally, a new version of the Bazel rules_nodejs, which somewhat confusingly has both browser and no JavaScript support, includes an esbuild rule. As for Angular CLI which relies heavily on web pack, it has years of grinding tweaking bug fixing work getting all the right behaviors for all the cases. It's going to take a lot to re-create that in a non-breaking way using something different under the hood.
- Nathanba 6y agoit's fast because it doesnt do the thing that everyone else does to be useful which is type checking
- nitsky 6y agoThis is dishonest. In esbuild's benchmarks, webpack, rollup, and parcel do not do typechecking either.
- endergen 6y agoI like the idea of having type checking moved out of the watch path, or at least be in a second window watching, so building is faster. But you get your type checking errors too. You also have the editor finding issues for you, which is where I want that caught.
- kylecordes 6y agoYes this seems like an excellent performance boost to development. Parallelize type checking and compilation. We all have these many-core machines now, and so many tools that single thread the world unnecessarily.
- pierreyoda 6y agoYou may want to check out this webpack plugin [1], though I'm not sure how much it could get you there. [1] https://github.com/TypeStrong/fork-ts-checker-webpack-plugin#readme https://github.com/TypeStrong/fork-ts-checker-webpack-plugin...
- vijaybritto 6y agoNope. This is wrong. It clearly mentions that its only a Javascript and CSS bundler and nothing much. It doesnt try to solve every problem in the JS world. None of the other bundlers do type checking by themselves. They are always through plugins.
- dawkins 6y agoI switched from google closure to esbuild and it is amazing how fast and well it works. It even generates smaller code in my use case (200k lines app). Also the creator is really nice. He implemented two features I requested right away, which surprised me a lot. What a great project!
- nitsky 6y agoI submitted a couple PRs to esbuild and also found the author to be kind and helpful.
- ratww 6y agoI've seen other interactions in the issue tracker and the author has been nothing short of responsive and understanding. This is a project worth contributing money to.
- Zacru 6y agoOut of curiosity, was that with closure's simple or advanced optimizations?
- dawkins 6y agoSimple optimizations, Advanced always broke my code.
- alessivs 6y agoImportant distinctions when comparing Closure Compiler's performance to other tools: 1. Regarding bundle size: Optimization level used (SIMPLE optimizations yield output that is at least expected from a minifier these days) 2. Regarding compilation speed: * Whether the JavaScript-only compiler was used over the JVM compiler: besides being slower, a number of optimizations are not available to the former. * In many conditions a pre-heated JVM (or Nailgun), or using the NPM-distributed native compiler binary yields faster compilation. * Which compiler flags have been tuned; e.g. such that the parsing of browser externs is bypassed during compilation for Node.js-targeted bundles. Relevant discussion: https://github.com/evanw/esbuild/issues/425 https://github.com/evanw/esbuild/issues/425
- jarym 6y agoEsbuild is certainly fast but I could never figure out how to get it to preserve some symbols during minification (for when I want to expose some class methods or properties publicly to external consumers)
- vijaybritto 6y agoOpen an issue if you haven't. He is very responsive and thoughtful considering he is the cofounder of Figma a company which is rapidly growing.
- rizky05 6y agoesbuild has keepNames options to preserve that
- roryokane 6y agoIndeed. The relevant documentation: https://esbuild.github.io/api/#keep-names https://esbuild.github.io/api/#keep-names
- qvq 6y agoI wonder if window['exposedObject'] = {... would work.
- mpolun 6y agoswc (https://github.com/swc-project/swc https://github.com/swc-project/swc) is a rust equivalent to babel and has a bundler under development. Not sure how far along it is. That would be an interesting comparison of performance and features.
- nicoburns 6y agoSWC looks cool, but esbuild is more mature I think. The bugs in SWC's changelog make me pretty wary of using it in production just yet.
- nahuel0x 6y agoswc is more ambitious, it wants to re-implement all of tsc type checking, not only transpiling: https://github.com/swc-project/swc/issues/571 https://github.com/swc-project/swc/issues/571
- jannes 6y agoEsbuild is awesome! I tried it on my latest project and the speed has blown me away, even though it doesn't replace the TypeScript compiler for my usecase. Its two biggest shortcomings are: 1. It can't compile const enums (TypeScript feature) 2. It can't compile down to ES5 (with some exceptions) So I still need to run TypeScript + esbuild side-by-side. TypeScript compiles to ES5 and esbuild bundles the ES5 files. Anyway, it is a massive improvement over TypeScript + webpack.
- e12e 6y agoCurious to how you set this up without going crazy (and CI working)? Just a line in package.json that runs tsc, then another one that runs esbuild on the output?
- jannes 6y agoIt's a pretty simple setup for now. For tsc it's a single line in package.json (+tsconfig with outdir: "dist"). For esbuild I am running the following Node script (saved as .mjs): import esbuild from 'esbuild'; let args = process.argv.slice(2); await esbuild.build({ watch: args.includes('-w'), entryPoints: [ 'dist/entry1.js', 'dist/entry2.js', 'dist/entry3.js', ], bundle: true, target: 'es5', outdir: 'bundles/', });
- duderific 6y agoWe really need it to support top level await, and the author doesn't seem to be that interested in supporting it at the moment. Hopefully he will come around soon.
- filleokus 6y agoEsbuild looks amazing. It seems to have been written almost exclusively by one guy (evanw) during 2020. Just the main JS parser file [0] is 12k lines. According to the Github stats he has committed 280k lines, that's almost 1000 lines per day every day since he started. Amazingly productive. [0]: https://github.com/evanw/esbuild/blob/master/internal/js_parser/js_parser.go https://github.com/evanw/esbuild/blob/master/internal/js_par...
- capableweb 6y agoNot to be the one who is the one, but 1k lines per day sounds like the opposite of productive. If you still have to add/remove such large swaths of code, you're surely doing something weird. Still a great achievement to produce a bundler and minifier as a one-person team, but not sure we should use the amount of code line changes as a measure for productivity.
- edoceo 6y agoNot weird, it's early, messy development. Perfectly normal (for me anyway)
- CharlesW 6y ago> …1k lines per day sounds like the opposite of productive. Relevant Macintosh folklore: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
- filleokus 6y agoProductivity might be the wrong word. Discipline, grit, perseverance? I've written parsers/lexers/code generators by hand for much smaller toy languages with no thought about performance at all and those were huge undertakings for me. I was just trying to convey my impressedness with some numbers that we can relate to somewhat. But yeah, he has a "net" loc contribution of 284-148 = 136k lines of code. Assuming the code base is resonable (which I don't doubt), it's a pretty big project which he has built, which I'm impressed by.
- 6y ago
- crtc 6y agoTIL a new word: megamorphic
- christiansakai 6y agoDoes esbuild work with font files that comes with css as well?
- rizky05 6y agothis can be supported using plugin.
- aero142 6y agoSlightly tangential, but I really love the minimal but effective site design here. It is minimal, responsive and easy to read. Is this a theme or just the author being very effective and throwing together a documentation site?
- constexpr 6y agoIt is also all custom: https://github.com/esbuild/esbuild.github.io https://github.com/esbuild/esbuild.github.io. YAML files that get converted to plain static HTML pages. It's designed to work well without any JavaScript. Even the animated graphs on the home page are done without JavaScript.
- Nixinova 6y agoWhy all that instead of just a normal static site generator? Doesn't seem easily expandable.
- xPaw 6y agoI recently switched to using esbuild [0] and certainly is fast for minifying js and even css! For my site I basically only do minifying for js, and bundling+minifying for css, and it all gets done in 0.2 seconds. Right now the longest time in my deploy process is actually just doing a git fetch (with depth=1). [0]: https://twitter.com/thexpaw/status/1358124690347339778 https://twitter.com/thexpaw/status/1358124690347339778
- sknowieowl 6y agoI can confirm that esbuild is very fast - easily bundling my code a hundred times faster than webpack or rollup. And the minified esbuild bundles are only around 10% larger than what is produced by the JS-based bundlers. Considering it saves 30 seconds per build, this is more than an acceptable tradeoff. It's good that this tool is shaking up the JS development ecosystem. It was getting stagnant (babel) and overly complicated (webpack). We can probably expect more tooling to migrate to golang and rust. I think the esbuild author accomplished his goal.
- lefrenchy 6y agoI've really wanted to use Esbuild in my projects but I haven't figured out a great way to get the desired functionality I want: I'd like to be able to transpile my code but keep the same directory structure in the output. For example, I have an index.js file that exports all my components and I'd like to just create a "build" folder output with the same exact file structure, but with all the files exported from index.js having been transpiled. Does anyone know if that is supported?
- joshum97 6y agoEsbuild does have a JS transform API, so you could write a command line tool that walks the file system (Babel, ESLint, Prettier, etc. all do this so you have examples), transforms each file, and writes the code back out. Snowpack's build command also does this.
- keb_ 6y agoHey, I was trying to do this same thing for a TypeScript project I was bootstrapping. Digging around the issue tracker, I recall the maintainer stating that this is currently not in the scope of esbuild, and that swc[0] might be better suited for this. Personally, I wrote a crude JS script using the esbuild transform API + node-watch to compile .ts files and copy files/folders during development. This is all very recent, so I can't ensure that it's bulletproof quite yet. [0] https://swc.rs/ https://swc.rs/
- crazypython 6y agoI just serve my ESM modules directly from the filesystem. It works well, builds in literally 0 seconds. You also don't need a transpiler like Babel if you drop support for IE11. Almost all ES6 features– such as classes, proxies, arrow functions, and async are supported by modern browsers and their older versions. As long as you avoid features like static, private, and ??=, you get instant compile times. It's not 2015. You don't need a transpiler to write modern JavaScript. As of writing, the latest version of Safari is 14 and the latest version of Chrome is 88. These features fully work in Safari 13 and Chrome 70, which have less than 1% of marketshare.
- nicoburns 6y agoAlas, many of us still need to support IE11. We alas get a lot of value out of TypeScript, which needs to be transpiled. <1 second with esbuild is pretty good!
- crazypython 6y agoHere's my suggestion if you want faster builds: In development, use an index.html that loads it directly from the filesystem, using a single-pass annotation remover such as https://github.com/alangpierce/sucrase https://github.com/alangpierce/sucrase A single-pass transpiler doesn't build an AST, instead just looping over everything once, which will surely make it faster than esbuild. In production, use a bundler like snowpack.
- ljm 6y agoWhat you're saying there is: in development, use sucrase. In production, use sucrase. And saying it quite a lot in this thread.
- crazypython 6y agoSorry, I meant to say use snowpack.
- runarberg 6y ago
- nerdponx 6y agoFor the uneducated like me: if I am writing a NodeJS application in Typescript, can I use this instead of the `tsc` Typescript compiler CLI and get faster compile times?
- dindresto 6y agoYes for compiling, but without typechecking. You'll still need tsc for that.
- julian37 6y ago> Every time you run your bundler, the JavaScript VM is seeing your bundler's code for the first time without any optimization hints. Not necessarily so: https://v8.dev/blog/code-caching https://v8.dev/blog/code-caching
- rtsao 6y agoThere's also a substantial writeup on the architecture of esbuild in the repo [1]. It is definitely worth a read if you are interested in some of the inner workings of esbuild or are curious how various bundler features are implemented. High-quality, in-depth architectural docs for complex projects like this are exceptionally rare. [1]: https://github.com/evanw/esbuild/blob/master/docs/architecture.md https://github.com/evanw/esbuild/blob/master/docs/architectu...
- finchisko 6y agocan esbuild used to do quick development builds with some dev server, like serve node pkg? or just for prod builds? if so, how the pipeline looks like?
- deanclatworthy 6y agoYep https://esbuild.github.io/api/#serve https://esbuild.github.io/api/#serve
- jez 6y agoIn posts talking about how someone made something fast, I see the same idea repeat time after time: it has linear time complexity, has great cache locality, and saturates all available processors. It's annoying to me how much time I had to spend outside of school before I realized that this is the real recipe for fast code. In particular, even code that is nominally O(n^2) by standard measures is still a dis-economy of scale: the bigger the problem the slower it gets. In school, there's a premium given for finding a polynomial-time solution, but in practice every job where I've been tasked with making something fast, only linear time complexity was good enough. In practice these linear algorithms tend to also be completely data parallel and have great cache locality. Not only do these properties make the code fast the second you harness them, but then tend to be exceedingly simple architectures to maintain over time. For some other reading I really like on software performance in the real world: - https://blog.nelhage.com/post/why-sorbet-is-fast/ https://blog.nelhage.com/post/why-sorbet-is-fast/ - https://blog.nelhage.com/post/reflections-on-performance/ https://blog.nelhage.com/post/reflections-on-performance/
- tshaddox 6y ago> but in practice every job where I've been tasked with making something fast, only linear time complexity was good enough. But of course we remember from our CS school that some things simply cannot be done in linear time. I’m not sure what happens when your employer tells you to sort a big list and insists that only linear time complexity is good enough.
- jez 6y agoTo that I find that the answer is usually: find ways to avoid needing to sort the list! This is more viable for many problems than you might otherwise think.
- moomin 6y agoThere’s also vastly faster ways of sorting lists of bounded numbers (or tuples), the most linear being: cut straws of the exact right length labelled with an Id, bang them on a table so the ends without the ids all line up, read the ids back in order. I only said it took linear time, I didn’t say it was fast...
- wildpeaks 6y agoThree things need to be pointed out: 1. You can support IE11 without Babel (I got rid of it many years ago already): Typescript has transpilation, and you can add polyfills 2. As much as I like JSDoc-augmented vanilla JS, it doesn't catch nearly as much as real TS 3. Webapps are made of more than just scripts, loaders are even the big reason why Webpack got popular initially. Luckily, Webpack 5 can automatically recognize assets referenced in "new URL()" calls, so you don't need types for images or shaders anymore.
- asciident 6y agoSpeaking of fast, that web page loaded instantaneously for me. Gives me confidence in the product, despite being technically unrelated.
- bambam24 6y agoEvery year some other language claim they are better than JS and they are all unpopular. Just get over it, JS won the war.
- The_rationalist 6y agoGo has shared memory between threads while JavaScript has to serialize data between threads. 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. Untrue when using sharedArrayBuffer
- vhiremath4 6y agoEvan Wallace (the author) is also the co-founder and CTO of Figma. Absolutely remarkable engineer. His co-founder Dylan is an investor in our company, and I can’t seem to get in touch with Evan at all because he’s always super heads down on something meaningful (such as esbuild). Mad respect for him.
- nojvek 6y agoHow does he do Figma CTO-ing and at the same time building esbuild? That’s mad hours. Also one of the things I love about Figma is their obsession on performance. It feels such a joy to use. Runs circles around any Adobe product. It’s written in a browser. Figma and vscode are my inspiration for browser based tools.
- vhiremath4 6y ago>How does he do Figma CTO-ing and at the same time building esbuild? That’s mad hours. My guess is an alignment between purpose, fun, and skillset. I would say (not for the sake of bragging but for qualifying the legitimacy of my position) - I probably pull similar hours across CTO-ing, investing, and learning biochemistry. Then again, I'm commenting on HN and Evan isn't, so maybe not. :P
- deleted 6y ago[deleted]
- Uninen 6y agoVite 2.0 (a build tool like Webpack or Rollup, and powered by Esbuild) was just released earlier today. It's seriously awesome. I first learned of Esbuild early 2020 when I complained on Twitter that JS build tools are awfully slow [1]. Most my (mainly Vue) projects use Webpack and starting the dev server takes typically anywhere between 5-50 seconds. With Vite, cold devserver start in a mid-sized project on my 2015 MBP is ~2-5 seconds, but vast majority of the starts happen almost instantly as the deps are cached. Hot module reloading and most changes is also very fast and feel instantaneous (where in Webpack projects they would take anywhere between 1-20 seconds). This has HUGE affect in developing experience as you can just keep writing and almost never need to wait for any changes. (The one exception being TailWind/PostCSS builds that take few seconds every time the config or main import changes.) I absolutely love Esbuild and Vite. Been using them daily for few months now, and I'm currently in the process of converting all my old vue-cli based projects to Vite using a project template I made that has TypeScript, Tailwind, and e2e tests w/ GitLab and GitHub CI configured [2]. If you work with React or Vue and Webpack and haven't yet tested out Vite or any of the other Esbuild based build tools, definitely do check them out! [1]: https://twitter.com/uninen/status/1230673711910576130 https://twitter.com/uninen/status/1230673711910576130 [2]: https://github.com/Uninen/vite-ts-tailwind-starter https://github.com/Uninen/vite-ts-tailwind-starter