To reiterate what others said, choosing an unusual syntax that is non-obvious motivated by a synthetic example to solve a problem already solved by many other languages in better ways almost raises the suspicion that we’re deliberately trying to make JS even worse... to kill it? Or is this just indicative of the process that got us to this mess in the first place?
A more reasonable policy for JS would be to (a) contain it - no more changes, no more extending its use outside of its current surface, (b) the development of an alternative approach that would - crucially - support competing languages so that we don’t get stuck in this way again, (c) gradually shrinking eliminating JS with a goal to complete retirement.
The second paragraph you wrote seems to indicate that you believe people only use JS because they're forced to - since browsers don't support anything else.
That's not the case. People choose to use JS in all sorts of places where they could make use of many other options.
Development of the JS spec is complicated somewhat by the strict rules of web compatibility. But imo the benefits of that compatibility guarantee far outweigh the downsides. Having slightly ugly/unusual syntax is not a major issue.
You’re right, I have assumed that people only use JS because they have to. Happy to be convinced otherwise - please respond:
Other places - I guess you mean Node, and VS Code and Electron etc? I’ve always assumed that was either because of the available skill set (web devs know JS, so make their tools on JS) or to reuse JS on the web and elsewhere. So not because it’s a good language, but because people know it or solutions exists in it.
Is that what you meant?
To me, Node (for example) makes sense only if your devs don’t know other languages or you want to hire cheaply - I’d always go for a “proper” (better designed, more stable, elegant, robust) language on the backend given the choice.
I am not - and have never been - a front-end or browser JS developer. I did not have JS skills to bring over, and yet Node was my preferred language for writing commercial applications for many years. Now more on the Go side, but still making plenty of Node applications.
It works fantastically well in IO-bound applications for such a large number of reasons. It's not far off the most lightweight option for making simple systems, the ecosystem focusses very much on composition of smaller libs than using hefty frameworks, its single threaded nature is actually a _huge_ benefit (though you wouldn't want to use it for CPU-bound work).
There's also the fact that JS these days is essentially a completely different language from the JS which browsers supported 5 years ago. I started using Node before those changes, but it has only become better with them.
I think you'd be surprised how common this exact story is. A lot of Node engineers are gradually moving over to Go, but it's still a great system in its own right.
Also, in reality, if you're a pre-existing browser JS developer, you're actually going to be bringing a load of baggage which will not help you get used to Node. I'd almost say you're better moving to it if you don't already know the lang.
A more reasonable policy for JS would be to (a) contain it - no more changes, no more extending its use outside of its current surface, (b) the development of an alternative approach that would - crucially - support competing languages so that we don’t get stuck in this way again, (c) gradually shrinking eliminating JS with a goal to complete retirement.