<story><title>ESbuild – A fast JavaScript bundler and minifier in Go</title><url>https://github.com/evanw/esbuild/</url></story><parent_chain><item><author>alipang</author><text>I believe &lt;i&gt;something&lt;/i&gt; like this project is inevitable. You&amp;#x27;re probably thinking &amp;quot;Where&amp;#x27;s the Rust version of this?&amp;quot;. I&amp;#x27;ll save you a roundtrip to Google that&amp;#x27;ll find you SWC. [1]&lt;p&gt;SWC is already more mature, at least more so than this project. Using rust does also seem to have some advantages compared to Go.&lt;p&gt;Still, nothing wrong with some competition, just think it&amp;#x27;ll be pretty hard to replace the &lt;i&gt;entire&lt;/i&gt; ecosystem around Typescript&amp;#x2F;Babel&amp;#x2F;Webpack in one go. Not going to work for existing project - probably way too high of a risk for new ones, sadly.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;swc-project&amp;#x2F;swc&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;swc-project&amp;#x2F;swc&lt;/a&gt;</text></item></parent_chain><comment><author>constexpr</author><text>Author here. I think the Rust vs. Go question is interesting. I actually originally wrote esbuild in Rust and Go, and Go was the clear winner.&lt;p&gt;The parser written in Go was both faster to compile and faster to execute than the parser in Rust. The Go version compiled something like 100x faster than Rust and ran at something around 10% faster (I forget the exact numbers, sorry). Based on a profile, it looked like the Go version was faster because GC happened on another thread while Rust had to run destructors on the same thread.&lt;p&gt;The Rust version also had other problems. Many places in my code had switch statements that branched over all AST nodes and in Rust that compiles to code which uses stack space proportional to the total stack space used by all branches instead of just the maximum stack space used by any one branch: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;rust-lang&amp;#x2F;rust&amp;#x2F;issues&amp;#x2F;34283&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;rust-lang&amp;#x2F;rust&amp;#x2F;issues&amp;#x2F;34283&lt;/a&gt;. I believe the issue still isn&amp;#x27;t fixed. That meant that the Rust version quickly overflowed the stack if you had many nested JavaScript syntax constructs, which was easy to hit in large JavaScript files. There were also random other issues such as Rust&amp;#x27;s floating-point number parser not actually working in all cases: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;rust-lang&amp;#x2F;rust&amp;#x2F;issues&amp;#x2F;31407&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;rust-lang&amp;#x2F;rust&amp;#x2F;issues&amp;#x2F;31407&lt;/a&gt;. I also had to spend a lot of time getting multi-threading to work in Rust with all of the lifetime stuff. Go had none of these issues.&lt;p&gt;The Rust version probably could be made to work at an equivalent speed with enough effort. But at a high-level, Go was much more enjoyable to work with. This is a side project and it has to be fun for me to work on it. The Rust version was actively un-fun for me, both because of all of the workarounds that got in the way and because of the extremely slow compile times. Obviously you can tell from the nature of this project that I value fast build times :)</text></comment>
<story><title>ESbuild – A fast JavaScript bundler and minifier in Go</title><url>https://github.com/evanw/esbuild/</url></story><parent_chain><item><author>alipang</author><text>I believe &lt;i&gt;something&lt;/i&gt; like this project is inevitable. You&amp;#x27;re probably thinking &amp;quot;Where&amp;#x27;s the Rust version of this?&amp;quot;. I&amp;#x27;ll save you a roundtrip to Google that&amp;#x27;ll find you SWC. [1]&lt;p&gt;SWC is already more mature, at least more so than this project. Using rust does also seem to have some advantages compared to Go.&lt;p&gt;Still, nothing wrong with some competition, just think it&amp;#x27;ll be pretty hard to replace the &lt;i&gt;entire&lt;/i&gt; ecosystem around Typescript&amp;#x2F;Babel&amp;#x2F;Webpack in one go. Not going to work for existing project - probably way too high of a risk for new ones, sadly.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;swc-project&amp;#x2F;swc&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;swc-project&amp;#x2F;swc&lt;/a&gt;</text></item></parent_chain><comment><author>_bxg1</author><text>Note that what Babel does and what Webpack does are orthogonal. They&amp;#x27;re frequently used together and the challenges of converting them from JS to native are similar, but the OP isn&amp;#x27;t really in &amp;quot;competition&amp;quot; with SWC.</text></comment>