Item — HN Reader

Sorry to see you downvoting a comment which doesn't please your expectations.

1) You are ignoring the notion of some, if not most, of the incriminated features being also present in highly regarded languages.

2) "Most of the rants" (please mind the plural) doesn't address your post, but is on certain communities which are producing anti-JavaScripts post in series.

3) "easy answer" is quite what it means. There are so many patterns that are just reproducing approaches to be found in other languages for things that are already built in or are overriding built-in features. (My favorite one is using "var self = this;", while `self` is a predefined variable in JS, pointing to the global object. What does this mean for code maintainability? What is "self.location" in a browser? Mhm. Just read the whole code to know.) At least some of these pattern do in deed reflect some laziness in coping with the language. Also, "easy answer" was meant to address the stereotypical use of "sucks". (P.e.: There is much criticism on the behavior of `this` in the DOM-interface, which is, by the way, not part of the language. So, read the specs and use "Object.handleEvent". Criticize deprecated implementations of the DOM-interface in older IE for lacking this, but do not qualify the language for this by "sucks"...)

4) "à la mode", again, isn't specific on your post, but on various historic positions and utterances on JavaScript to be found over the last 19 years. If you would try to read this carefully, you would find them to be contradictory and mirroring the popular notions of programming styles of the day. This is, what "à la mode" means. Take the criticism on the semicolons, for example: In the times when JS was critiqued for not requiring them (à la "a serious language has explicit statement delimiters as a requirement"), CoffeeScript would have been regarded as being even worse. Obviously, this perspective changed over time.

5) The notion of test suites (and the tradition of having analysis tools especially for C/C++) is not deliberately, but reflects a real raison d'être of most of the frameworks attempting to fix the "problems". While these frameworks highly depend on late binding themselves, the most critiqued feature -- which is also a real problem for analysis tools -- is late binding. I would be optimistic that these issues could be theoretically overcome, based on the concept of "Turing completeness". (There is no reason, why paths that can be resolved by a runtime wouldn't be to be resolved by an analysis tool. Modifying the language instead of adapting the analysis tools is what I would call an "easy answer".)

I would be grateful, if you would bother to read a comment, or just would simply ignore it, rather than just taking it as an apparent aggression. There are developers who have committed to this language and who are quite happy with its working. (As another recent post, on JS framework reproducing the schemes of enterprisy backend schemes, put it: "You are ruining it".) There are different notions on this issue and there is no need of demonizing contrary perspectives.

So you didn't read this (again)? Yes, it's a carefully worded criticism on my side, too. And as is clearly stated in the intro of the initial post, it's on criticism on a language from the point of view of a community formed around an other language in general. (I'm in the JS-business for 18 years now and have contributed some to its use, so I would appreciate it, if you would consider this to be more than just a deliberate utterance.)

And BTW, you accused me of things (in the post above) that weren't in my statement at all. I was just pointing out that there was in deed a point made by briantakita by noting that the various articles on JS published lately are mostly originating from communities grouped around other languages. And that perspectives may vary. Even the criticism on JS varies over time.