I understand that JS is a flawed language. I didn’t actually use JS before until it matured enough (or actually, the elegance and the ability of the browsers have matured) to the point that I can manipulate the DOM easier than just using
document.querySelector(‘#this-element’).innerHTML = “new content”.
I agree there are safer languages, and I could have chosen one. The question of why wouldn’t I choose one is at least simple for me: it adds another task to my build and another complexity to my team.
I made a mistake before of switching one front-end framework to another just because the other framework is better in terms of code elegance, better code management, etc… in the middle of trying to ship the MVP. If the team is fast in getting “how things clicked” on the new framework, then it wouldn’t be a problem. But they are not and I have to use up a lot of time re-training them just to use the new framework.
For me, safer languages that are just an alternative to JS on the front-end doesn’t do much. They are just “special kind of linters”. It just scopes up the good parts of JS so that developers will not use the bad parts of JS. I agree on the additional cognitive load that will be added to people trying to learn the good parts instead of just using safer languages. But we are just shifting that focus from learning the good points to something else, and it doesn’t change the fact that these will just be tools for developers who want to implement code that is manageable for them.
Don’t stop though (and I know you won’t stop telling how bad JS is). JS is bad, but it will stay, at least for most of the foreseeable future, as a W3C standard. And people will still try to make it better. And people will still make more features for it (see VR). If you want anyone to stop using JS though, you can try and submit to W3C to add an additional language for anyone to use. Much like an RFC for WebAssembly or for adding routing and data-loading just by the use of HTML. This way, the discussion evolves from just pointing out bad things in a standard language to opening up another way to implement code using an elegant language.
Going back though, regardless if our front-end code was coded in a safer JS-alternative language or hardcore JS itself, it’s all about how we improve the user experience.