I was a little surprised that Vite, which depends on esbuild and thus should know better, is written in Javascript.
I presume this is a considered choice, and that what Vite does is unlikely to be on the critical path for edit/build/view cycle time…
I presume this is a considered choice, and that what Vite does is unlikely to be on the critical path for edit/build/view cycle time…
I would posit that perhaps they know better than you.
When pure performance is the concern it makes sense to go to a more performant language, like Go. But every time your JavaScript build tool moves away from JavaScript you close yourself off to a huge pool of potential code contributors and make it a lot more difficult to customise. So I think Vite has it just right: optimise the really intensive stuff, leave the rest more available and more editable.
This reads as a very acrimonious, biased take. Authors choose the tools they use based on a number of criteria and personal preferences. It's one thing to disagree with them, it's another to project judgement without knowing the why.
The new transpilers have worked around this problem by introducing various limitations. esbuild plugins literally can't modify the AST. It's basically a way for you to run a command on a string/file. So sure, if you redefine the problem as string transforms rather than AST transforms, you can get an O(N) speedup...
* Transform the file using esbuild first
* Then use Babel with that one specific plugin (Loadable Components, Styled Components, Apollo, React Refresh...)
This is much faster than letting Babel do all the work.