9 ms·
A curated list of JavaScript tooling not written in JavaScript
- de_keyboard 5y agoMakes sense to me. We should be using the best tool for the job, and JavaScript isn't always the best tool.
- patates 5y agoExactly, 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.
- numlock86 5y ago> compiling/transpiling/whatevering webpack with webpack for webpack development would make no sense as far as I can tell Isn't that the workflow when working with/on TypeScript? (substitute webpack with TypeScript)
- patates 5y agoIt does make sense with TypeScript as it's a language. It, however, does not make sense with "tooling" (IMHO - there may be of course obvious stuff I may be missing). Tooling may also use a transpiled language but again, I, as a developer who's very experienced with JS, don't see a big win there. Someone mentioned Flow + OCaml as a bad example and how it doesn't work out for them, but that's more than tooling. At that point you are not using tools written in other languages to build JS, you are just using other languages.
- de_keyboard 5y agoFlow failed because Microsoft enabled TypeScript by default in VS Code. It had nothing to do with OCaml in my opinion. However, TypeScript is now suffering from long compile-times because it targets JS. If it was implemented in a language with more control over threading etc. I think it could be faster.
- IshKebab 5y agoYeah and Typescript's type checker code is one 41k line file because if they split it into multiple files it will be slower. `tsc` is pretty great to be honest but it feels like the exception.
- capableweb 5y ago> compiling/transpiling/whatevering webpack with webpack for webpack development would make no sense as far as I can tell. Could you explain further why you think so? Dogfooding tooling and bootstrapping runtimes with themselves is a fairly common practice, at least for discovering issues, bugs and future features for your own project.
- patates 5y agoRuntimes, sure, but how do you dogfood tooling that transpiles JS to JS for frontend?
- capableweb 5y agoSupposedly since webpack is using JS, they would also benefit from using later features than what's available in NodeJS stable, so they can use webpack to transpile future ES versions to compatible code so it can run on more NodeJS versions. Then that those features can both be used for frontend or backend code matters less, as the new JS features are usually not geared to a specific environment but for JS as a whole.
- patates 5y agowebpack is web-oriented though. While what you are saying is right, for a project which aims to keep web as its focus, this would perhaps not be the best way forward. When we also look the the codebase, they are not using webpack for webpack development, and using commonjs imports instead. The "modern JS" part of webpack comes from Babel and Babel uses TS (though still in progress). So dogfooding here isn't used by major projects, and I think we can see a pattern. For a formatting tool, I would agree with you more, but again, for a tool, wouldn't the formatting of the code of the tool itself be a distraction? It may be or it may be not, it depends, but the benefits are less clear for tooling.
- capableweb 5y agoThe 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 :)
- de_keyboard 5y ago> The thing is, what the "best" tool is, is relative to your requirements. Yes I agree, but I think my point still stands :)
- capableweb 5y agoOh yes, I wasn't disagreeing with you, more filling out a shared opinion :)
- segphault 5y agoI 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.
- Jcampuzano2 5y agoAgreed, 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.
- wereHamster 5y agoI 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…
- tomxor 5y agoI 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".
- knubie 5y agoI believe Google’s closure compiler is written in Java.
- aloisdg 5y agoIndeed: https://github.com/google/closure-compiler https://github.com/google/closure-compiler
- Cthulhu_ 5y agoIt 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.
- cromwellian 5y agoClosure compiler is much older than that though, it was written for Gmail (and used by most Google web properties). Closure is just the name of the OSS release.
- vaughan 5y agoFlow + 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. 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. Having to switch to a new toolchain to debug something is tedious, and often impossible to reach the same convenience of JS-based tools. I think the future is taking small pieces of JS-based tools and adding native extensions to speed up parts of them.
- q3k 5y ago> 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.
- xwolfi 5y agoHehehe
- sime2009 5y ago> 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.
- brundolf 5y agoI'm not sure what kind of exotic stuff GP is doing but I've never had to do anything like this with webpack or babel
- numlock86 5y agoInteresting 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?
- capableweb 5y agoNope, 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.
- numlock86 5y ago> Nope, the list is implying that "here is a resource of tooling built for JS but NOT made in JS", [...] So the list is indeed arbitrary. > 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. No one ever said you had to.
- devit 5y agoThey 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.
- numlock86 5y ago> They are much faster and memory-efficient than the tools written in JavaScript. Can you show some benchmarks/profiling results?
- pansa2 5y agoReminds me of Pyright - a static type checker for Python, written in TypeScript. https://github.com/microsoft/pyright https://github.com/microsoft/pyright
- sneak 5y agoShouldn't node/v8 be at the top of this list?
- capableweb 5y agoI'm not sure about V8, but NodeJS runtime is actually mostly JS, at least according to the GitHub language statistics.
- Cthulhu_ 5y agoProbably all tests, the `src` folder containing the core NodeJS code is at https://github.com/nodejs/node/tree/master/src https://github.com/nodejs/node/tree/master/src. Also keep in mind it builds on top of V8, which is mostly C++: https://github.com/v8/v8 https://github.com/v8/v8.
- infensus 5y agoSignificant part of the standard library (lib folder) is in JS
- capableweb 5y agoSeems you're mostly right (not counting dependencies at least), I ran cloc while excluding the "test" dir and got the following results: $ cloc . --exclude-dir test 16921 text files. 14173 unique files. 7043 files ignored. github.com/AlDanial/cloc v 1.88 T=35.06 s (354.1 files/s, 160714.9 lines/s) --------------------------------------------------------------------------------------- Language files blank comment code --------------------------------------------------------------------------------------- Perl 315 23880 21499 1180347 C++ 1673 139959 140151 962404 Assembly 351 49707 9182 583298 JavaScript 3935 82192 107644 461467 --------------------------------------------------------------------------------------- SUM: 12414 534479 586681 4513827 --------------------------------------------------------------------------------------- The rest of the output I cut off, as there are ~20 more languages used as well.
- OCISLY 5y agoWhat is a purpose of that list?
- purerandomness 5y agoI think to compile a list of JavaScript Tooling Not in JavaScript.
- macando 5y agoInteresting list. Is there a non JS tool written in JavaScript?
- yakubin 5y agoVSCode.
- macando 5y agoI meant more like a language tool, something like a Go compiler written in JavaScript.
- q3k 5y agoIt’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, ...).
- kelt5120 5y agoGroovy Lint (the only stand-alone Groovy linter afaik) is written in javascript: https://github.com/nvuillam/npm-groovy-lint https://github.com/nvuillam/npm-groovy-lint
- vbsteven 5y agoA 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.
- frou_dh 5y agoThe Pyright typechecker for Python (a Mypy alternative): https://github.com/microsoft/pyright https://github.com/microsoft/pyright
- skrtskrt 5y agoPyright is a full language server, not just a type checker, despite its top-line billing there as a type checker. I use it as the langugae server for Python development in COC for Neovim via coc-pyright. Further down the page it mentions that it implements language server protocol.
- kozak 5y agoWhat might be the reason to care about that?
- ralmidani 5y agoJS 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.
- ducaale 5y agoThis reminds me of https://www.swyx.io/js-third-age/ https://www.swyx.io/js-third-age/ >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...
- fireattack 5y agoThe article is directly mentioned in OP's link. BTW, that scrollbar though..
- millerm 5y agoHardly noticed it at all. In fact I didn’t see anything. ;-) That design is so user unfriendly.
- cromwellian 5y agoWebStorm/IntelliJ is another missing example. GWT sorta should make the list as it did include a complete JS parser and compiler in it via the JSNI declaration mechanism. So technically you could use GWT to compile pure JS by embedding it in a Java file as a native method.
- deleted 5y ago[deleted]
- dj_gitmo 5y agoSlightly tangential, but I can't tell if I love or hate the logo for swc https://github.com/swc-project/swc https://github.com/swc-project/swc Either way, I want to try this next time I'm using TypeScript.
- jokethrowaway 5y agoThis is a godsend, as a mainly JS contributor at work. I can't stand the slowness of JS tooling. Really hoping for rslint to become mature enough for daily usage
- animex 5y agoThanks, that explained why someone would want to maintain such a list.
- Cymen 5y agoWhat 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 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.
- pdimitar 5y agoLet me put it like this: your second paragraph would take me 2-3 hours (as a backend dev). Does that put things into perspective? It's never about "I am an expert and can do it quickly". What frontend devs seem to not realize is that backenders and sysadmins have to occasionally do something quickly on the frontend. And when I visit webpack's site and copy-paste a config and then adjust a few variables and run a command... yeah, it can be faster. Much faster. Not to mention that it rarely works the first time around and the error messages are absolutely not telling me what I do wrong. --- This isn't intended to flame anything or anyone, mind you. --- But please understand that for many the frontend tooling is a bitter disappointment because we intend to do a quick tweak and move on and it of course disagrees and I lost half my workday. And as you can guess, the next time it will take me half of my workday again because enough time has passed that I'll forget those lessons. Why can't the thing just be intuitive? Can I do it better after I become an expert? Absolutely. But that's the whole point: I don't want to become an expert. I want to install the tool, execute 2-3 incantations and get my work done. And most of the web dev tooling fails miserably at that task. (btw, GIT is guilty of the same for like 90% of its commands.)
- christiansakai 5y agoIf 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. Is there a way to unify these? i.e, just one parser that works for all languages that want to implement JS tooling.
- dm33tri 5y agoI don’t think JS has built-in parser API either, but grammars are available that you can use to quickly build parsers and generators.
- tomxor 5y agoI 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.
- pdimitar 5y agoWhat a philosophical take on something super technically strict -- namely language parsing. Yes, there absolutely should be one and best way of doing it. We should get this done and finally move on to more productive activities.
- tomxor 5y agoI disagree, but Evan Wallace (who wrote eslint) puts it better than I could: > Everything in esbuild is written from scratch. > There are a lot of performance benefits with writing everything yourself instead of using 3rd-party libraries. You can have performance in mind from the beginning, you can make sure everything uses consistent data structures to avoid expensive conversions, and you can make wide architectural changes whenever necessary. The drawback is of course that it's a lot of work. > For example, many bundlers use the official TypeScript compiler as a parser. But it was built to serve the goals of the TypeScript compiler team and they do not have performance as a top priority. Their code makes pretty heavy use of megamorphic object shapes and unnecessary dynamic property accesses (both well-known JavaScript speed bumps). And the TypeScript parser appears to still run the type checker even when type checking is disabled. None of these are an issue with esbuild's custom TypeScript parser. https://esbuild.github.io/faq/#why-is-esbuild-fast https://esbuild.github.io/faq/#why-is-esbuild-fast