A curated list of JavaScript tooling not written in JavaScript

Agreed, I added it to a large project for a client for development builds that were crawling and it is far and away both easy to use and blows all other build tools out of the water when it comes to speed. We still use webpack for prod builds since we need to support legacy browsers (I know... But corporate) but it's blazingly fast for development.

I started extracting code from my project into a shared npm library. esbuild takes 70ms to bundle all files into a single index.js, then I also need to run tsc (TypeScript) to emit the declaration files and that takes ~10 seconds. esbuild is 3 orders of magnitude faster than tsc! Granted, they are not doing the same type of work, but still…

I previously dismissed esbuild thinking it was too limited, until realizing the extreme performance difference allows for far far more simplification than I had initially appreciated... I'm not just talking about the lack of 10k npm dependencies.

When a build process is slow, if we are unable to make it fundamentally faster we start to do loads of crazy workarounds that keep growing tentacles with increasing complexity and optimisation challenges: Incremental builds, caching, different pipelines for development vs production. We've been living with this stuff for so long it's easy to forget that when a full build is humanly instantaneous you can just throw all of this complexity away, you don't need it... that's when I realized I could use esbuild, I don't need those "features".

esbuild changes the game. Before we have a dynamic language with a compile step that compiles slow like a C++ project. All the disadvantages of a dynamic language combined with the disadvantages of a compiled language. In the browser you have no choice, but to use that setup on the server with node or on mobile with react native was questionable. Now with instant builds, you've got a dynamic language back - and one that mops the floor with Ruby and Python in terms of performance. You now have just one language to hire for, all your developers can work on our understand any part of the code, and you can share code between server and client. The time for universal JavaScript is here.

I really love esbuild. Its speed is amazingly fast, and my node_modules folder is so clean.

But not being able to transpile to ES5 makes it a hard choice to use in client-facing projects, where IE11 is not totally dead (yet).

Its doable to integrate with swc (another great tool on the list), but now the build chain is longer, and more things to take care (such as sourcemaps).

I've been meaning to check out esbuild. Question to those who have used it: what's the catch, other than flexibility? If you've got a standard TypeScript/JSX/bundling setup, is there any disadvantage at all to switching to esbuild?

> 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.

This is something I achieve by using multi-languge-aware build systems and/or vendoring. I can then add a log statement to a compiler implemented in C which emits binary shader code that in turn gets parsed by Rust, and immediately see results after running the usual test target. No need to limit myself to 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.

That sounds more like an indictment of Webpack than anything else.

The article is directly mentioned in OP's link.

BTW, that scrollbar though..

Exactly, as when it comes to transpilers, it's unlikely that you can eat your own dog food anyway - as in, compiling/transpiling/whatevering webpack with webpack for webpack development would make no sense as far as I can tell.

The thing is, what the "best" tool is, is relative to your requirements. I much prefer "Use the right tool for the job", as it makes it less cargo-culty and emphasizes that it's not always right.

For example, if your build process is very slow and you for some reason have to have it be very fast, esbuild is probably the right tool.

But if instead your goal is to build a large community of developers who can change their own tooling, webpack is probably the right tool as it's by JS developers, for JS developers.

Overall I agree with you, just nitpicking a bit I guess :)

what a time to be alive

Thanks, that explained why someone would want to maintain such a list.

What tooling are you using that is slow? Sometimes it's all down to configuration and "you could do it that way but it takes eons..."

For example, on a recent project I added prettier to eslint and tried eslint-plugin-prettier however it was very very slow (like multiple minutes for an eslint run). I discovered it's basically a deprecated package and the right way to use it is eslint on it's own (with ruleset for prettier so it ignores what prettier should do) and prettier on it's own. Then each command runs lightning fast and there is no slowdown. Their docs even go into this issue under Notes on this page:

https://prettier.io/docs/en/integrating-with-linters.html

No doubt tooling can be slow but looking for configuration issues or bad practices is a good place to start if things are slow.

Indeed: https://github.com/google/closure-compiler

It came out the same year as NodeJS as well, so the whole JS ecosystem we know nowadays didn't even exist yet. That is, using JS for a tool like that didn't cross anyone's mind yet.

I'm not sure about V8, but NodeJS runtime is actually mostly JS, at least according to the GitHub language statistics.

Tools to manage Node versions (nvm and volta) should also probably be on the list.

I don’t think JS has built-in parser API either, but grammars are available that you can use to quickly build parsers and generators.

I know this sounds more efficient, but this kind of attitude has serious downsides too. There is no "best" of each type of thing, it's subjective, so it's not necessarily duplicated effort to write your own parser. If you always use 3rd party libraries you also have less of a holistic view, it's hard to see different ways to do things... this is basically why the author of eslint didn't use something like the official typescript compiler, it simply has different goals and could never be as fast.

VSCode.

It’s probably selection bias (as I tend to not enjoy working with node.js software, and would probably actively pick alternatives), but I can’t think of any in my bubble (Go, Rust, Python, distributed systems, ...).

Groovy Lint (the only stand-alone Groovy linter afaik) is written in javascript: https://github.com/nvuillam/npm-groovy-lint

A quick search for "rust", "kotlin" and "cpp" on npmjs.com shows a lot of packages. Not all are language tools, but I see stuff like linters, interpreters, compilers and lots of stuff related to WASM compilation and codegen.

The Pyright typechecker for Python (a Mypy alternative): https://github.com/microsoft/pyright

JS is the dominant language on the web, but languages which can compile/bundle/etc. faster than JS can will make for a more pleasant developer experience. Especially when working on a large project.

I think to compile a list of JavaScript Tooling Not in JavaScript.

Nope, the list is implying that "here is a resource of tooling built for JS but NOT made in JS", not sure where you get the other implication from.

Just as "awesome-lists" about security is not implying that you should hack other people and so on.

I think the motivation is to show that just because you want to write a tool for the JS ecosystem, you don't have to use JS if you don't want to. And I like the idea, I think more languages and their communities should cross-pollinate, we can all learn a lot from each other, even though some like types and some do not.

They are much faster and memory-efficient than the tools written in JavaScript.

Part of it is language (e.g. obviously Rust is much better than JavaScript for algorithmic code) and part the fact that someone using another language is likely motivated to do a good job.