TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why Is Esbuild Fast?

320 点作者 mef超过 4 年前

24 条评论

jez超过 4 年前
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&#x27;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&#x27;s a premium given for finding a polynomial-time solution, but in practice every job where I&#x27;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:&#x2F;&#x2F;blog.nelhage.com&#x2F;post&#x2F;why-sorbet-is-fast&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.nelhage.com&#x2F;post&#x2F;why-sorbet-is-fast&#x2F;</a><p>- <a href="https:&#x2F;&#x2F;blog.nelhage.com&#x2F;post&#x2F;reflections-on-performance&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.nelhage.com&#x2F;post&#x2F;reflections-on-performance&#x2F;</a>
评论 #26158324 未加载
评论 #26159593 未加载
评论 #26159200 未加载
filleokus超过 4 年前
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&#x27;s almost 1000 lines per day every day since he started. Amazingly productive.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;evanw&#x2F;esbuild&#x2F;blob&#x2F;master&#x2F;internal&#x2F;js_parser&#x2F;js_parser.go" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;evanw&#x2F;esbuild&#x2F;blob&#x2F;master&#x2F;internal&#x2F;js_par...</a>
评论 #26157534 未加载
评论 #26156778 未加载
评论 #26156911 未加载
评论 #26156726 未加载
评论 #26157481 未加载
评论 #26157521 未加载
评论 #26157080 未加载
评论 #26158411 未加载
评论 #26159102 未加载
vhiremath4超过 4 年前
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.
评论 #26166667 未加载
dawkins超过 4 年前
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!
评论 #26156174 未加载
评论 #26156162 未加载
评论 #26160162 未加载
评论 #26158536 未加载
crazypython超过 4 年前
I just serve my ESM modules directly from the filesystem. It works well, builds in literally 0 seconds.<p>You also don&#x27;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&#x27;s not 2015. You don&#x27;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.
评论 #26157326 未加载
评论 #26157301 未加载
评论 #26157150 未加载
评论 #26157414 未加载
评论 #26177706 未加载
评论 #26157953 未加载
rtsao超过 4 年前
There&#x27;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:&#x2F;&#x2F;github.com&#x2F;evanw&#x2F;esbuild&#x2F;blob&#x2F;master&#x2F;docs&#x2F;architecture.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;evanw&#x2F;esbuild&#x2F;blob&#x2F;master&#x2F;docs&#x2F;architectu...</a>
aero142超过 4 年前
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?
评论 #26159862 未加载
sknowieowl超过 4 年前
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&#x27;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.
jannes超过 4 年前
Esbuild is awesome! I tried it on my latest project and the speed has blown me away, even though it doesn&#x27;t replace the TypeScript compiler for my usecase.<p>Its two biggest shortcomings are:<p>1. It can&#x27;t compile const enums (TypeScript feature)<p>2. It can&#x27;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.
评论 #26157124 未加载
评论 #26156732 未加载
jamra超过 4 年前
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&#x27;s not as interesting as the incremental compiler.
评论 #26156435 未加载
评论 #26158336 未加载
Uninen超过 4 年前
Vite 2.0 (a build tool like Webpack or Rollup, and powered by Esbuild) was just released earlier today. It&#x27;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&#x2F;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&#x27;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&#x2F; GitLab and GitHub CI configured [2]. If you work with React or Vue and Webpack and haven&#x27;t yet tested out Vite or any of the other Esbuild based build tools, definitely do check them out!<p>[1]: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;uninen&#x2F;status&#x2F;1230673711910576130" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;uninen&#x2F;status&#x2F;1230673711910576130</a> [2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;Uninen&#x2F;vite-ts-tailwind-starter" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Uninen&#x2F;vite-ts-tailwind-starter</a>
wildpeaks超过 4 年前
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&#x27;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 &quot;new URL()&quot; calls, so you don&#x27;t need types for images or shaders anymore.
jarym超过 4 年前
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)
评论 #26156315 未加载
评论 #26165021 未加载
评论 #26157791 未加载
lefrenchy超过 4 年前
I&#x27;ve really wanted to use Esbuild in my projects but I haven&#x27;t figured out a great way to get the desired functionality I want:<p>I&#x27;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&#x27;d like to just create a &quot;build&quot; 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?
评论 #26157915 未加载
评论 #26157550 未加载
xPaw超过 4 年前
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:&#x2F;&#x2F;twitter.com&#x2F;thexpaw&#x2F;status&#x2F;1358124690347339778" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;thexpaw&#x2F;status&#x2F;1358124690347339778</a>
asciident超过 4 年前
Speaking of fast, that web page loaded instantaneously for me. Gives me confidence in the product, despite being technically unrelated.
The_rationalist超过 4 年前
<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&#x27;s heap is shared between all threads while JavaScript has a separate heap per JavaScript thread.</i> Untrue when using sharedArrayBuffer
julian37超过 4 年前
&gt; Every time you run your bundler, the JavaScript VM is seeing your bundler&#x27;s code for the first time without any optimization hints.<p>Not necessarily so: <a href="https:&#x2F;&#x2F;v8.dev&#x2F;blog&#x2F;code-caching" rel="nofollow">https:&#x2F;&#x2F;v8.dev&#x2F;blog&#x2F;code-caching</a>
nerdponx超过 4 年前
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?
评论 #26157387 未加载
christiansakai超过 4 年前
Does esbuild work with font files that comes with css as well?
评论 #26157799 未加载
finchisko超过 4 年前
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?
评论 #26158764 未加载
crtc超过 4 年前
TIL a new word: megamorphic
mpolun超过 4 年前
swc (<a href="https:&#x2F;&#x2F;github.com&#x2F;swc-project&#x2F;swc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;swc-project&#x2F;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.
评论 #26156984 未加载
评论 #26159123 未加载
Nathanba超过 4 年前
it&#x27;s fast because it doesnt do the thing that everyone else does to be useful which is type checking
评论 #26156146 未加载
评论 #26156363 未加载