[HN Gopher] A curated list of JavaScript tooling not written in ...
___________________________________________________________________
A curated list of JavaScript tooling not written in JavaScript
Author : kantord
Score : 109 points
Date : 2021-04-20 09:24 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| numlock86 wrote:
| 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?
| devit wrote:
| 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.
| capableweb wrote:
| 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.
| pansa2 wrote:
| Reminds me of Pyright - a static type checker for Python, written
| in TypeScript.
|
| https://github.com/microsoft/pyright
| aloisdg wrote:
| what a time to be alive
| Scarbutt wrote:
| Not surprising, a primary goal is vscode integration.
| IshKebab wrote:
| Also to be fast. You can't write it in Python if that is a
| goal.
| sneak wrote:
| Shouldn't node/v8 be at the top of this list?
| curun1r wrote:
| Tools to manage Node versions (nvm and volta) should also
| probably be on the list.
| capableweb wrote:
| I'm not sure about V8, but NodeJS runtime is actually mostly
| JS, at least according to the GitHub language statistics.
| Cthulhu_ wrote:
| Probably all tests, the `src` folder containing the core
| NodeJS code is at
| 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.
| infensus wrote:
| Significant part of the standard library (lib folder) is in
| JS
| capableweb wrote:
| Seems 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 wrote:
| What is a purpose of that list?
| purerandomness wrote:
| I think to compile a list of JavaScript Tooling Not in
| JavaScript.
| dj_gitmo wrote:
| Slightly tangential, but I can't tell if I love or hate the logo
| for swc https://github.com/swc-project/swc
|
| Either way, I want to try this next time I'm using TypeScript.
| [deleted]
| jokethrowaway wrote:
| This 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 wrote:
| Thanks, that explained why someone would want to maintain such
| a list.
| Cymen wrote:
| 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.
| pdimitar wrote:
| Let 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.)
| IshKebab wrote:
| No amount of configuration tweaking is going to make Webpack
| fast.
| kozak wrote:
| What might be the reason to care about that?
| ralmidani wrote:
| 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.
| cromwellian wrote:
| WebStorm/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.
| de_keyboard wrote:
| Makes sense to me. We should be using the best tool for the job,
| and JavaScript isn't always the best tool.
| capableweb wrote:
| 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 :)
| de_keyboard wrote:
| > The thing is, what the "best" tool is, is relative to your
| requirements.
|
| Yes I agree, but I think my point still stands :)
| capableweb wrote:
| Oh yes, I wasn't disagreeing with you, more filling out a
| shared opinion :)
| patates wrote:
| 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.
| capableweb wrote:
| > 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 wrote:
| Runtimes, sure, but how do you dogfood tooling that
| transpiles JS to JS for frontend?
| capableweb wrote:
| Supposedly 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 wrote:
| webpack 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.
| numlock86 wrote:
| > 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 wrote:
| It 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 wrote:
| Flow 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.
| patates wrote:
| I think there were attempts to rewrite a subset of TS in
| another language. I don't mean assemblyscript, no.
|
| Also, if I could use TS on the backend without node (say,
| with the lib/runtime of another language), that would be
| amazing.
| guipsp wrote:
| Deno exists, I guess
| IshKebab wrote:
| Yeah 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.
| segphault wrote:
| 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.
| sntran wrote:
| 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).
| hnarn wrote:
| Even if I guess IE11 is technically not EOL'd by Microsoft,
| they will stop supporting it for 365 services on Aug 17 this
| year, so I'm curious what kind of businesses are still using
| it.
| emteycz wrote:
| I'm simply using Webpack for my production builds.
| [deleted]
| wereHamster wrote:
| 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...
| xcambar wrote:
| "I have 10k followers on FaceTwitterStagram but my family is
| only 4 members. Yes, people love me more on social networks
| than in my own family."
|
| In other words: apples and oranges. :)
| mb7733 wrote:
| What is the point of that comparison?
| eloff wrote:
| 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.
| Jcampuzano2 wrote:
| 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.
| tomxor wrote:
| 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".
| knubie wrote:
| I believe Google's closure compiler is written in Java.
| Cthulhu_ wrote:
| 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.
| cromwellian wrote:
| Closure 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.
| aloisdg wrote:
| Indeed: https://github.com/google/closure-compiler
| ducaale wrote:
| This reminds me of 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 wrote:
| The article is directly mentioned in OP's link.
|
| BTW, that scrollbar though..
| millerm wrote:
| Hardly noticed it at all. In fact I didn't see anything. ;-)
| That design is so user unfriendly.
| christiansakai wrote:
| 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.
|
| Is there a way to unify these? i.e, just one parser that works
| for all languages that want to implement JS tooling.
| tomxor wrote:
| 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.
| pdimitar wrote:
| What 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 wrote:
| I 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
| dm33tri wrote:
| 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.
| vaughan wrote:
| 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.
|
| 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.
| sime2009 wrote:
| > 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.
| q3k wrote:
| > 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 wrote:
| Hehehe
| macando wrote:
| Interesting list. Is there a non JS tool written in JavaScript?
| yakubin wrote:
| VSCode.
| macando wrote:
| I meant more like a language tool, something like a Go
| compiler written in JavaScript.
| q3k wrote:
| 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, ...).
| vbsteven wrote:
| 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.
| frou_dh wrote:
| The Pyright typechecker for Python (a Mypy alternative):
| https://github.com/microsoft/pyright
| skrtskrt wrote:
| Pyright 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.
| kelt5120 wrote:
| Groovy Lint (the only stand-alone Groovy linter afaik) is
| written in javascript: https://github.com/nvuillam/npm-groovy-
| lint
___________________________________________________________________
(page generated 2021-04-20 23:02 UTC)