In 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.<p>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 <i>dis</i>-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.<p>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.<p>For some other reading I really like on software performance in the real world:<p>- <a href="https://blog.nelhage.com/post/why-sorbet-is-fast/" rel="nofollow">https://blog.nelhage.com/post/why-sorbet-is-fast/</a><p>- <a href="https://blog.nelhage.com/post/reflections-on-performance/" rel="nofollow">https://blog.nelhage.com/post/reflections-on-performance/</a>
Esbuild 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.<p>[0]: <a href="https://github.com/evanw/esbuild/blob/master/internal/js_parser/js_parser.go" rel="nofollow">https://github.com/evanw/esbuild/blob/master/internal/js_par...</a>
Evan 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.
I 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!
I just serve my ESM modules directly from the filesystem. It works well, builds in literally 0 seconds.<p>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.<p>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.
There'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.<p>[1]: <a href="https://github.com/evanw/esbuild/blob/master/docs/architecture.md" rel="nofollow">https://github.com/evanw/esbuild/blob/master/docs/architectu...</a>
Slightly 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?
I 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.<p>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.
Esbuild 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.<p>Its two biggest shortcomings are:<p>1. It can't compile const enums (TypeScript feature)<p>2. It can't compile down to ES5 (with some exceptions)<p>So I still need to run TypeScript + esbuild side-by-side. TypeScript compiles to ES5 and esbuild bundles the ES5 files.<p>Anyway, it is a massive improvement over TypeScript + webpack.
I 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.
Vite 2.0 (a build tool like Webpack or Rollup, and powered by Esbuild) was just released earlier today. It's seriously awesome.<p>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.<p>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 <i>very</i> fast and feel instantaneous (where in Webpack projects they would take anywhere between 1-20 seconds). This has <i>HUGE</i> 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.)<p>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!<p>[1]: <a href="https://twitter.com/uninen/status/1230673711910576130" rel="nofollow">https://twitter.com/uninen/status/1230673711910576130</a>
[2]: <a href="https://github.com/Uninen/vite-ts-tailwind-starter" rel="nofollow">https://github.com/Uninen/vite-ts-tailwind-starter</a>
Three things need to be pointed out:<p>1. You can support IE11 without Babel (I got rid of it many years ago already): Typescript has transpilation, and you can add polyfills<p>2. As much as I like JSDoc-augmented vanilla JS, it doesn't catch nearly as much as real TS<p>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.
Esbuild 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)
I'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:<p>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.<p>Does anyone know if that is supported?
I recently switched to using esbuild [0] and certainly is fast for minifying js and even css!<p>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).<p>[0]: <a href="https://twitter.com/thexpaw/status/1358124690347339778" rel="nofollow">https://twitter.com/thexpaw/status/1358124690347339778</a>
<i>Go 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.</i>
Untrue when using sharedArrayBuffer
> Every time you run your bundler, the JavaScript VM is seeing your bundler's code for the first time without any optimization hints.<p>Not necessarily so: <a href="https://v8.dev/blog/code-caching" rel="nofollow">https://v8.dev/blog/code-caching</a>
For 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?
can 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?
swc (<a href="https://github.com/swc-project/swc" rel="nofollow">https://github.com/swc-project/swc</a>) is a rust equivalent to babel and has a bundler under development. Not sure how far along it is.<p>That would be an interesting comparison of performance and features.