3 ms·
Tooling Report [1] also goes into detail about which build tools provide the most bang for your buck, in terms of features for optimizing your website code. So
by kaycebasques 6y ago
Tooling Report [1] also goes into detail about which build tools provide the most bang for your buck, in terms of features for optimizing your website code.
So, to circle back to your comment:
> I wonder what the appeal of having the build tools written in JS is, as performance is key here.
Yes, performance is key. But we're presumably talking about two types of performance: performance of the build tool itself, and performance optimization of the website (enabled by the build tool). That could be a key tradeoff. Theoretically there's probably no reason why a feature-rich build tool for the web could not be written in something other than JS, but realistically does it exist right now? (I don't know much about this space so it's a genuine question.)
Also, it seems natural to me that, if you're writing a tool for web developers, you're more likely to be able to build a community around that tool if you write it in a language that web developers are familiar with. Since web developers have the most skin in the game to make that tool great. That's probably a trite/obvious argument, but it's worth mentioning nonetheless.
[1] https://bundlers.tooling.report/ https://bundlers.tooling.report/
Disclaimer: I'm on the same team as the Tooling Report people.
P.S. if any of the esbuild people are here, I believe Tooling Report is open to getting other build tools on the site (you would have to write all the tests). I could be wrong but it's worth reaching out to them.
- maccard 6y ago> But we're presumably talking about two types of performance: Agreed, and you only need to look at C++ linkers for proof this. LTCG can take minutes (or even hours) for marginal gains. That said, this entire article is about migrating the development builds and still being painfully slow. The links I shared to esbuild point to building release-able bundles, I.E. "Optimised". And let's be honest, the optimised bundles here (i.e. the output of webpack) aren't performing inlining, constant folding, expression simplification, dead code analysis, or anything of the sort, they're doing some fairly rudimentary file IO. Only the most invasive optimisations (whole program optimisation) should explain the orders of magnitude of a difference. The reason they're slow is because they're written in JS, single threaded, with no considerations for performance. As esbuild has proven, rewriting in go with consideration for perf can provide a 100x speedup! > but realistically does it exist right now? Yes, it does it's esbuild and I linked to it in my comment above! > That's probably a trite/obvious argument, but it's worth mentioning nonetheless. Honestly it's probably the truth but it's insane how we've managed to get here!