Ask HN: Why do you hate JavaScript?
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?
34 comments
[ 4.7 ms ] story [ 77.9 ms ] threadI do think Dart is the best of both worlds though. Having real types, not hacked together typescript stuff is very good. That's the other thing the nodejs ecosystem feels like a bunch of duct tape slap together again and again
It seems, through my experience, that Typescript isn’t “hacked together” as you imply. It’s just another Type-system, just like Java or C#’s?
This holds for "high-level" resources.Wwith the multi-threaded model you can share a single large immutable configuration object between all threads, or pass a database connection from one thread to another with close-to-zero cost.
Java and C# languages are a bit more CPU efficient. In the cloud computing world a website publisher pays real money for server CPU and RAM but can use the CPU and RAM on your computer or phone for free.
The weird transpilation system constantly breaks. I guess maybe one day they'll be better tooling around this, but it's not there yet. And I've worked with node in some capacity since 2013, things always feel fragmented and broken
BTW, with modern browsers, why would you need to transpile JS (as opposed to TS)?
[0] https://vitejs.dev/
A vast ecosystem of battle-tested libraries for one.
[ ] 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.
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 === ?
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.
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.
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:
Javascript can't access the file system, what good would it be for most command line programs?
Python seemed like a far better choice until they abandoned 2.x because of their Unicode fetish. There are hints that 4.0 won't happen.
C, C++, C#, Java, Clojure, Rust, Pascal all seem like better ways to go for the command line.
For whatever warts the language may or may not have, command line scripting in JS is a pleasure. Often you don't care about or need the benefits of those other languages. You can write CLIs, web servers, wrangle data or even just replace shell scripting.
I mean, NodeJS has been around for more than 10 years now? Of course you can write CLIs with JS.
What does Node have to do with Javascript? It would be like some random library coming up every time I search for pascal.
Googles node.js (instead of saying -node.js like I did yesterdays search about javascript and command line):
Oh... it's not a library, what a stupid deceptive name for an interpreter.
And server/desktop support (with filesystem access, though the specific mechanism/API was different for different implementations) for JS is much older than Node; Rhino and WSH JScript support came about in the late 1990s.
No, code running in a browser can’t access the file system, because browsers don’t expose an API for that. Other JS environments (e.g., Node, Windows Script Host, etc.) have different capabilities. A CLI app based on JS almost certainly isn’t targeting the browser, so browser limitations that don’t apply elsewhere aren’t relevant.
> Python seemed like a far better choice until they abandoned 2.x because of their Unicode fetish.
I’ve done plenty of CLI tools with Python, both 2 and 3, and its definitely not worse for that purpose now than it was with 2.x.
But matured and grew over most of it’s mistakes and problems.
Without typings it’s still not very scalable, but TypeScript elegantly fixed this issue.
If people hate it it’s their problem, not the language. Either they don’t really know it or they don’t really understand its area of applicability.
All these “java has correct multithreading” arguments is just a big facepalm.
Cmon, people, open your eyes once in a while.
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.