Ask HN: Why is JavaScript STILL the only choice for browser-side programming
3 mikece 1 8/21/2025, 1:44:30 PM
Earlier this year JavaScript -- and it's integration with web browsers -- turned 30. The combined factors that JavaScript has been "good enough" and that the language and runtime has evolved significantly in the last 20 years has kept JavaScript as the language everyone has to learned "because it's the only one that runs in a web browser." Why is this still the case?
Visual Studio Code was created as a very light-weight text editor and the revolution that has made it the go-to editor for so many languages is the Language Server Protocol: VS Code doesn't need to understand your language, you only need an LSP that does and somewhat magically VS Code and your favorite language will get along as though they were made for each other.
Why can't we do something similar to LSP for browser-side languages? And no, I don't count anything that is implemented in WASM as being valid for what I'm saying: just because you can compile the Python or Ruby interpreter to WASM doesn't mean the browser natively supports it and native support is what I wish other languages had.
* focusing on one language across the several browser vendors reduces the resources required for the different dimensions that each language supports : security, compatibility, performance, communicaton overhead for language standardization
* LSP does not define execution semantics, it defines text markup. A browser need to execute code, not just show it. So, now, a given browser needs to have a language plugin or call out to system programs to handle language X. That was a big hassle when they used to do so with the jvm and flash because of the same issues as above: is the version compatible, is the communication secure, do the different language vendors and browser vendors communicate their changes to each other in a timely and efficient fashion ?