I don't know, why are there so many proposals trying to turn JS into an C#/Java like language? The class syntax, the private fields, TS with its interfaces and abstract classes.
The pipe will lead to more functions and function composition instead of fluent interfaces, which I think is more in line with JS.
> “I was under marketing orders to make it look like Java but not make it too big for its britches. It’s just this sort of silly little brother language, right? The sidekick to Java.”
- Brendan Eich[1]
1: https://thenewstack.io/brendan-eich-on-creating-javascript-i...
Javascript's very OO, deep down in its bones. Its functions are even objects. It was just cursed with an OO model (prototypal) the distinguishing features of which pretty much all fall under "for the love of god, never actually rely on or leverage this functionality in any meaningful way" as far as how good an idea they are for code readability, and with god-awful scoping rules. "Class" and some other changes make the existing OO features usable in a way that won't have your successors cursing you for your "clever" use of prototypes, and saves tons of dumb boilerplate that never should have existed. It also makes it much clearer to the reader when you intend to treat something as an object, and when you're planning to treat it more like a struct.
> "Class" and some other changes make the existing OO features usable in a way that won't have your successors cursing you for your "clever" use of prototypes
That's a strawman, you can write "clever" code with classes that will make your successors curse you just like you can write plain and readable code with prototypes.
It's really far from being ergonomic, unless you're basically just using JS objects as structs. Otherwise you're dancing around its pitfalls and limitations—visibly, in code, not just in your head—to express things that are very simple and clear in pretty much every other commonly-used OO-supporting language.
> I didn't mention OO in general and specifically Java and C#. JS is OO deep down, nobody is denying that, but it's not OO as in Java/C# where writing a function without a class is not idiomatic.
Sure, JS is multi-paradigm, like tons of other languages. Its early design, and early use in the wild, hints at "Imperative with quite a bit of OO and a sprinkling of functional for things like callbacks" being more-or-less its intended style, but of course that can (and has) changed over time, because the core language has half-decent support for all three styles.
Incidentally, I've yet to see a TS codebase that ties itself in knots to avoid defining a function outside a class, to avoid treating functions as first-class when it makes sense to, or even to avoid a little imperative code outside of objects, here and there. They may exist, but I haven't seen it. I have seen a lot of code using HOFs to the point of absurdity, while passing big objects around to a bunch of functions and pretending that's "more pure" than putting those related functions on a class for that object. Or trying to shoehorn runtime-checked immutability into the language, at a performance cost for end users. Or writing their own weird, crippled form of objects in a language that already has them so they can keep things "pure" and let people keep avoiding the Class keyword for... whatever reasons they want to do that (React Hooks).
That might be because I've started OO with JS and mostly did some with it, but in my experience it's fine. I do tend to not use OO as in "object mutating themselves" much though, outside of cases where it's a great fit like a database connection.
> Incidentally, I've yet to see a TS codebase that ties itself in knots to avoid defining a function outside a class, to avoid treating functions as first-class when it makes sense to, or even to avoid a little imperative code outside of objects, here and there.
I haven't seen big codebases like that, but I've had a few collegues coming from Java/C# start every piece of code by writing a class, usually in a "kingdom of names" styles. I'm worried that TS may enable these people even more in the future.
> I have seen a lot of code using HOFs to the point of absurdity, while passing big objects around to a bunch of functions and pretending that's "more pure" than putting those related functions on a class for that object. Or trying to shoehorn runtime-checked immutability into the language, at a performance cost for end users. Or writing their own weird, crippled form of objects in a language that already has them so they can keep things "pure" and let people keep avoiding the Class keyword for... whatever reasons they want to do that (React Hooks).
I'm not defending "functional" (as in ML/Haskell) JS and agree with you here. If people want to do functional programming, there's OCaml, Elm, F#, Scala.js and ReScript, no need to shoehorn that into JS. I think that's an antipattern, just like doing OO everywhere for the sake of it.
JavaScript, in its bones, is a mix between an impure functional programming language like Lisp and a prototype-oriented OOPL like Self; forcing Java-style class-oriented OOP into it is a lot more of an impedance mismatch with its “bones” than FP constructs that are common in the kind of FP languages that influenced it from the outset (though neither is a giant mismatch.)