[horsawlarway]

> All of this has made the language worse. Just accreting features doesn't make the foundation less broken.

I see this view a lot - what I rarely ever see is a concrete discussion about what exactly is wrong with the "foundation" of javascript.

Because to me... Javascript is actually a decent-ish solution to the UI space (it nicely balances reactivity and code complexity by presenting an event driven, single threaded context)

It has the same warts that literally every production language accumulates: some operators are overloaded in ways that make for wacky edge-cases, some features were introduced by not great, and so they still exist but mostly gather dust.

JS also has some really incredible work put into it -

---

> ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules.

This is the problem.

---

Frankly - I understand that increasing language complexity is sometimes not the right call - but I think the vast majority of the features you just poo-pooed are pretty damn nice. I don't even mind the classes - just because it makes Crockford and the other enterprise java folks shut up (otherwise - I sort of mind the classes, at least when not using TS).

What I do find particularly impressive is how flexible JS is, and how much support can be added without actually changing the runtime - that's not something all that many enterprise languages can attest to, and it's that same flexibility and simple extensivity that has allowed JS to continue to grow.

Following on: JS (and browsers in general) are actually one of the absolute wins for software freedom (free as in freedom, not as in beer) because absolutely everything is shipped to you in inspectable and modifiable payloads. I can and have edited JS/html/css to make broken sites work.

My single biggest complaint about WASM is that we lose this property for websites, and I think that's a pretty huge fucking loss.

[toastercat]

> I don't even mind the classes - just because it makes Crockford and the other enterprise java folks shut up

This is the second time I've seen in this thread that people lump Crockford in with Java enterprise folks, but Crockford routinely says `class` was the worst addition to JS.

> What I do find particularly impressive is how flexible JS is, and how much support can be added without actually changing the runtime

Funny enough, this sounds a lot like something Crockford would say.

I think Crockford's main gripe with JS these days is that TC39 is more concerned with adding superfluous features than cleaning up footguns. There is a video from 2018 where he goes through some of the more popular ES6 features and mentioned which ones he likes/dislikes. [1]

[1] https://www.youtube.com/watch?v=XFTOG895C7c

[horsawlarway]

> This is the second time I've seen in this thread that people lump Crockford in with Java enterprise folks, but Crockford routinely says `class` was the worst addition to JS.

Because Crockford was one of the people advocating for a particular style of initialization of objects that mirrored classes, but was not directly a class before classes existed in JS. (see: https://crockford.com/javascript/inheritance.html)

It is utterly enterprise and classlike in nature though, and not my cup of tea. Mainly - I just wanted enterprise folks to stop trying to re-invent classes in the language, and the class keyword stopped that behavior.

Big net win for the language in my opinion - even though I personally still don't use classes all that often.

---

His modern take is fairly reasonable, though.

[JBits]

His modern take, advocating prototypes, has been around since 2006 (https://crockford.com/javascript/prototypal.html).

[horsawlarway]

I know - I just keep getting older... hard to believe that was nearly 20 years back now, and not 20 months.

[benrutter]

I might not have the best take since don't have a huge grudge against javascript but I definitely think there are some concrete problems in its foundations.

Specifically js has very unusual attitudes to basic syntax operations that are at this stage undoable without breaking an insane amount of existing code. For some examples:

- Use of == does not do what it does in almost every other language, but won't flag an error if a user thinks if does. Instead very difficult to track bugs will be introduced.

- Calling nonexistent object keys won't flag an error but return None. I've seen this lead to weird errors that are hard to find a lot of times.

- Duck typing in a lot of operators like + and - can create unexpected results.

At a high level, I think these are all choices to bake "truthyiess" into fundamental operations that often end up masking errors. They could pretty easily be solved if js, with those errors present, wasn't such a massive foundation for so much stuff.

I obviously can't speak for anyone else, but I think those are the kind of things most people are referring to when they talk about js having problematic foundations.

[horsawlarway]

But none of those are actual issues with shops that are writing JS today (Literally: Zero items on that list).

> Use of == does not do what it does in almost every other language, but won't flag an error if a user thinks if does. Instead very difficult to track bugs will be introduced.

"==" does basically what it should... (I also avoid it, but it makes a perverted kind of sense for easing into programming) and the bugs introduced aren't difficult to track at all: literally find and replace "==" with "===" resolve places that became too strict, then make it a lint rule.

>Calling nonexistent object keys won't flag an error but return None. I've seen this lead to weird errors that are hard to find a lot of times.

This... is basic dictionary behavior across SO MANY LANGUAGES. Frankly - having worked with languages that make a missing key an exception (looking at you C#/C++) I'd take the JS route any day.

> - Duck typing in a lot of operators like + and - can create unexpected results.

Yes. This is programming. Have you seen Ruby (or python - or god help you custom operator implementations in c++)? Because holy fuck is JS reasonable as all get here when compared to some other popular languages.

----

> I obviously can't speak for anyone else, but I think those are the kind of things most people are referring to when they talk about js having problematic foundations.

Basically - Look: I agree JS has some warts. Literally every language does. I just really don't see those warts as deserving of FUD around foundational problems that so many people talk about.

[bilalq]

These are problems easily solved with tooling today. ESLint + TypeScript literally addresses every example you raised. Static analysis works pretty well these days.

[benrutter]

I agree but I guess we differ in that I wouldn't consider Typescript JavaScript but instead a very closely coupled but different language.

[treis]

>I see this view a lot - what I rarely ever see is a concrete discussion about what exactly is wrong with the "foundation" of javascript.

The things that were added mostly were to fix problems of JS:

arrow functions => because of "this" shenanigans

template literals => I'd say a basic part of a language

async/await => Promise/future hell

destructuring, classes, enhanced object literals => These are all syntactic sugar/nice to haves. Nothing really was broken here.

native modules => Another time I'd say that it's a basic part of a language