Closures won over OOP in Javascript a long time ago (eg, React switching from classes to functions + closures), but they still keep trying to force garbage like private variables on the community.

Loads of features have been added to JS that have worse performance or theoretically enable worse performance, but that never stopped them before.

Some concrete (not-exhaustive) examples:

* Private variables are generally 30-50% slower than non-private variables (and also break proxies).

* let/const are a few percent slower than var.

* Generators are slower than loops.

* Iterators are often slower due to generating garbage for return values.

* Rest/spread operators hide that you're allocating new arrays and objects.

* Proxies cause insane slowdowns of your code.

* Allowing sub-classing of builtins makes everything slow.

* BigInt as designs is almost always slower than the engine's inferred 31-bit integers.

Meanwhile, Google and Mozilla refuse to implement proper tail calls even though they would INCREASE performance for a lot of code. They killed their SIMD projects (despite having them already implemented) which also reduced performance for the most performance-sensitive applications.

It seems obvious that performance is a non-issue when it's something they want to add and an easy excuse when it's something they don't want to add.

▲

tracker1 7 days ago | parent | next [-]

I wish I could upvote this more than once. I really liked the F# inspired pipe operator proposal and even used it a bit when I used to lean on 6to4/babel more, but it just sat and languished forever it seems. I can't really think of any other language feature I've seen since that I would have wanted more. The new Temporal being one exception.

	▲	hajile 7 days ago \| parent \| next [-]
		It seems like none of the really good language proposals have much traction. Proper Tail Calls have been in the language for TEN YEARS now, but v8 and Spidermonkey still violate the spec and refuse to implement for no good reason. Record/tuple was killed off despite being the best proposed answer for eliminating hidden class mutation, providing deep O(1) comparisons, and making webworkers/threads/actors worth using because data transfer wouldn't be a bottleneck. Pattern matching, do expressions, for/while/if/else expressions, binary AST, and others have languished for years without the spec committee seemingly caring that these would have real, tangible upsides for devs and/or users without adding much complexity to the JIT. I'm convinced that most of the committee is completely divorced from the people who actually use JS day-to-day.
	▲	jedwards1211 7 days ago \| parent \| prev [-]
		I think it’s mainly because they struggled to get consensus on which syntax to go with for pipelines, since people were divided into three different camps. I wish they would just standardize all three options with a slightly different operator for each one

▲

int_19h 7 days ago | parent | prev [-]

> * Rest/spread operators hide that you're allocating new arrays and objects.

Only in function calls, surely? If you're using spread inside [] or {} then you already know that it allocates.

	▲	hajile 7 days ago \| parent [-]
		It used to be said that "Lisp programmers know the value of everything and the cost of nothing." This applies to MOST devs today in my experience and doubly to JS and Python devs as a whole largely due to a lack of education. I'm fine with devs who never went to college, but it becomes an issue when they never bothered to study on their own either. I've worked with a lot of JS devs who have absolutely no understand of how the system works. Allocation and garbage collection are pure magic. They also have no understanding of pointers or the difference between the stack and heap. All they know is that it's the magic that makes their code run. For these kinds of devs, spread just makes the object they want and they don't understand that it has a performance impact. Even among knowledgeable devs, you often get the argument that "it's fast enough" and maybe something about optimizing down the road if we need it. The result is a kind of "slow by a thousand small allocations" where your whole application drags more than it should and there's no obvious hot spot because the whole thing is one giant, unoptimized ball of code. At the end of the day, ease of use, developer ignorance, and deadline pressure means performance is almost always the dead-last priority.