Most websites and apps have an additional advantage of not necessarily caring about backwards compatibility over decades and can cut out features that don't work out or are obsolete, something that may never be possible with JavaScript.
And, just like languages, apps that do become lumbering beasts are often abandoned for rewrites or new apps with similar functionality but streamlined of all that historical baggage.
> why would we ask it of programming languages?
TC39 member Mark S Miller answered this question well in "The Tragedy of the Common Lisp, or, Why Large Languages Explode"
I always like the old saying "it's not done until you can't remove any more". Adding features doesn't make a thing better, it just makes it more complicated.
But in case of languages you don't have to use that feature. And it's there for a reason, and that is that it makes certain class of things much easier to solve/implement/model/approach.
And if you don't work in that subfield, you don't have to know that part of the language. (Just as if you don't do compiler development you don't need to know Assembly mnemonics, and you don't have to know how many cycles a a particular microcode takes, and so on. You just use perf if you want to, and see that duh, it's too much, let's use -O3... or ask an expert. Or look into it yourself.)
But when you encounter something new in a language, you can learn about it. If it's there because it made something elegant, great. If not, refactor it. Make it simpler.
But this is the same Deletionist approach that is plaguing Wikipedia, just now with the tragedy of commons language, JS.
> But in case of languages you don't have to use that feature. And it's there for a reason, and that is that it makes certain class of things much easier to solve/implement/model/approach.
You can choose for your code, sure, but you can't choose for everyone else's code. This is brought up whenever C++ complexity threads start. Sure you can choose to not use template metaprogramming or whatever, but some library will use it, and then pow you're using it too.
And as I've mentioned, that library started to use it for a reason.
If you use a library that just starts using expensive features (like templates in C++), just because they think they're cool, then I regret to inform you, that you already depend on a bunch of script kiddies.
This is the same thing as we always discuss with functional programming and all those extremely complicated category-theory heavy con-fuck-structs. They make sense in a setting for some problems. ( https://stackoverflow.com/questions/5057136/real-world-appli... )
But it's very much like a special weapon that is large, and heavy, and only those can handle it that are blessed by the priests of The Temple of Homotopy Type Theory, or whatever, and so on. So mere mortals should not touch it.
And in a proper library, those beasts are locked up well, encapsulated.
It's the language's (or the lib's) shortcoming if you can't interface with the library, can't apply parameters to the library without knowing the hairy internals.
OK, so let's take the case of the proposed "includes" feature.
This is syntactical sugar. Replacing indexOf(x)=-1 with includes(x) does nothing else than make the code easier to read, allegedly. The new function provides a shorter way of expressing a single case that indexOf already covers. There are no new capabilities introduced to the language here.
So it's a straight-up coin-toss between "easier to read" and "having to be aware of one more method". I tend to come down on the "no thanks" side of this coin-toss.
Ruby suffers from this, imho. My favourite example is select/reject on arrays. They do exactly the same thing, with the logic on the block reversed. Having to know that there's a reject method (and when to use it) is more mental effort than reading the block logic the other way around, in my opinion.
Understandability should be the No1 feature of code. Basically interacting with code should be as smooth as possible. Spending cognitive effort to parse all those != -1 and unless select() takes its toll.
I'm not saying knowing one more function is cheap. And I agree Ruby has interesting constructs, but I think plus one function/method is a lot cheaper than to mentally parse all those inheritance/monkey-patching rules.
The same goes for `new` in JavaScript. It does something, but it uses functions, and don't forget .prototype (and so on), and that was hard to grok, so now we have classes too, but that's not just syntactic sugar. But JS is/was a pretty bad language at the start, so something must "had to be done".
And that's why it's important to consider new features, language complexity and so on while considering the particular language's warts. Just adding classes because classes are cool is foolish, but adding classes to bring some sanity to JS is fine.
Of course, there's also subjective priorities. But even ASM has too many opcodes, but at least the syntax is dead simple, but you lack cross-platform-ness, so there's C, which seems simple and low level, but it comes with a tome of undefined behavior and requires hand-rolling everything, hence higher level languages, that are hard to get right. And computer languages evolved a lot, as computing and programming itself did, a-a-and the big old languages C++/Java (and JS too) tried to handle this change, and that's how we got here. (Think of the Java Modules [JSR-376] process, how it was an uphill battle from the first minute, how it is at the same time too simple to replace OSGi [for example, because it lacks lifecycle management - which was never a stated goal, but sshhh], but too much to introduce without breaking changes [which is actually not true, because "automatic modules" sort of deals with legacy JAR files, but sssh again], and it has almost nothing to do with the language itself, it's just an ecosystem thing. But people are afraid of change, usually understandably. Compared to that TC39 is pretty nice.)
