I have been really impressed with esbuild. It is lightning fast and trivially easy to configure. Instead of using a crappy React boilerplate that stitches together a thousand fragile, poorly-maintained npm packages, you just install one tiny binary implemented in performant, reliable Go.
Flow + OCaml is a great example of this approach failing IMHO. I ran into tons of issues that were difficult to debug myself, and things like the regex format and config file conventions being different were also problematic. Compile times are also annoying.<p>Something undervalued is the debuggability of using a single language. There are so many times I need to debug some tooling, and being able to to just open the stack trace and place a breakpoint/console.log is incredibly valuable. I do it all the time for webpack/babel.<p>Having to switch to a new toolchain to debug something is tedious, and often impossible to reach the same convenience of JS-based tools.<p>I think the future is taking small pieces of JS-based tools and adding native extensions to speed up parts of them.
This reminds me of <a href="https://www.swyx.io/js-third-age/" rel="nofollow">https://www.swyx.io/js-third-age/</a><p>>The other assumption going away is that JavaScript tools must be built in JavaScript. The potential for type safety and 10x-100x performance speedup in hot paths is too great to ignore...
Reminds me of Pyright - a static type checker for Python, written in TypeScript.<p><a href="https://github.com/microsoft/pyright" rel="nofollow">https://github.com/microsoft/pyright</a>
This is a godsend, as a mainly JS contributor at work.
I can't stand the slowness of JS tooling.<p>Really hoping for rslint to become mature enough for daily usage
Slightly tangential, but I can't tell if I love or hate the logo for swc <a href="https://github.com/swc-project/swc" rel="nofollow">https://github.com/swc-project/swc</a><p>Either way, I want to try this next time I'm using TypeScript.
WebStorm/IntelliJ is another missing example.<p>GWT sorta should make the list as it did include a complete JS parser and compiler in it via the JSNI declaration mechanism.<p>So technically you could use GWT to compile pure JS by embedding it in a Java file as a native method.
If you want to create these kinds of tooling, would that mean you have to create your own parser first? Seems like multiple effort wasted on multiple environment.<p>Is there a way to unify these? i.e, just one parser that works for all languages that want to implement JS tooling.
Interesting list, but I don't quite get the idea. Is it implying JavaScript shouldn't be used to work on JavaScript, just for the sake of it? To me it almost sounds as arbitrary as "JS tooling not including the letter T in the project's name". What's the motivation of this list?