I've noticed that every time a CLI project is presented here, regardless of how good/useful it is, there's inevitably a comment along the lines of "too bad it's js".
Makes me wonder why you never see comments like that with languages where you have to manage the memory yourself, which is very error prone unless you really know what you are doing. Or with interpreted languages that are famously slow, like ruby or python. It doesn't even matter when it's typescript, it's just the fact that JS is what will run at the end.
If you ever got this feeling of "too bad it's js", may I ask: Why?
JavaScript is different, as it is the only language that can reliably run on modern-day browsers, which gives it a kind of reach that no other language can match. If you want to do anything interesting on the web, you have to deal with JavaScript, even if you don't like the language.
Deleted Comment
What I hate about them is two things:
1. Rules for semicolons. Sometimes you feel like a nut; sometimes you don't.
2. = and ==. Ugh. The Bug Maker.
3. + for concatenation. Yikes!
4. Arrays are objects except when they're not but objects aren't arrays. :-(
JS is essentially Lisp w/o parens. Everything is an object. Everything is by reference. And everything is mutable. Lisp is what we use on the backend and these two are kissing cousins.
You mean == and === ?
Sure it has its quirks, but with modern tooling, the idea that you can't build good software in JS is ridiculous.
I feel with pure js you’d need more test coverage and better comments. My experience on larger js code bases it’s hard to know what to pass into a function “oh now I’ve read all the code I see you want an object with a couple of promises and a number” can be bad for productivity.
But I imagine in disciplined hands JS can scale without static type safety.
[ ] Will probably be abandoned in less than a year
[ ] If it does not get abandoned, it will not follow semantic versioning and introduce breaking changes outside of major releases. A routine `npm upgrade` may or may not break everything
[ ] If it follows semantic versioning, there will probably be a major release with breaking changes every few months
[ ] Probably has a 500MB+ dependency tree
[ ] Frequently has security issues with a dependency 4 levels deep and you can't upgrade without conflict with another library or because a dependency 2 levels deep is abandoned
Do these issues exist in other languages? Sure but those incidents are quite rare and isolated. But these issues happen *way* too often in the JS ecosystem.
[ ] Requires a Javascript interpreter, maybe even a full browser engine to run. May consume 2gb of RAM just to show me a screen.
Java, Python, Erlang and some other languages come with detailed documentation of the language and runtime which is sufficient to use the language. You are NOT at the mercy of StackOverflow and Google SEO Spammers if you want to answer simple questions.
In Javascript they blew up the tower of babel and dispersed the manual to the 4000 corners of a hypercube.
There are ways to compensate (MDN, the official ECMA docs punch above their readership weight, ...) and I have a feeling that the frenetic progress has slowed in the last two years but I dread teaching anybody else Javascript since I can't ground it in a epistemology the way I can with Python and Java.
I do say though, I find the modern tool chains we have to use to effective leverage modules & use them on the web to be a bit of an abomination. There are much much better tools now, and it's a legit hard real problem, one faced by few other languages, but it has sullied what used to be an elegant & clear what-you-see-is-what-you-get (WYSIWYG) system with something arcane & difficult.
Also, async/await made it tolerable for people that are not used to callback/promise chains (which is anyone that didn’t do comprehensive JavaScript before 2015). It’s like skipping the rough years, lucky y’all: