Or, if you're thinking server-side JavaScript: would the web have been more secure running PHP and Python?
And it's not fully sandboxed. It betrays its user all the time by abusing unrestricted access to the network, or activating browser functionality that most of us would disable if we could.
I'm not saying it's THE bad decision, but it is the product of a generation of thinkers who were not thinking about threats the way we do now. If we were to go back in time and have the opportunity to do it differently, I think we would take that opportunity.
But we don't actually need a time machine. We can just accept some sunk costs and move forward anyhow.
And before that, whatever Microsoft "macro" or embedded code variant was popular that week in all those document formats...
We aren't going back to a page refresh every time you want to update something any time soon
People will often claim to dislike something, even though they would dislike the alternative even more (and they might even be actively choosing against the alternative). Pay more attention to what people’s actions reveal than what they claim.
(This happens not just in tech.)
2. I'm not going to feel safe if I go make a web site that works that way. I'm going to feel safe if my bank does.
Give me a https://motherfuckingwebsite.com/ instead.
But 99% of web applications are forms and displaying stuff. All JS accomplished is making it look prettier and enhanced tracking.
I mean, Facebook, my bank, Amazon… these can all be created with no client side code. It would be a lot of refreshes, but it can be done.
HN could too - perhaps the biggest use on HN is not refreshing when up (or down) voting something. YouTube could do something similar - refreshing when 'liking' a video or getting more comments. But would you really find those to be a better experience for you? Even on actions that HN does refresh on, such as 'Next page', or submitting a comment, HN doesn't freeze sorts, so posts and/or comments you didn't see will often invisibly end up before the new location HN sent you to (or posts/comments you already saw earlier in the list now showing up "again" later in the list).
Not saying that's exactly what should be done, but an example that there may be another way than full-on generic code execution wrapping XHR.
As what an actual, safe, efficient implementation, of course not.
The point is there could have been a "dynamic HTML" alternate timeline where you could have had interactive pages for 90% of use cases without executing full blown generic computation arbitrary code on the client device.
But worse is better won and now we get insane trackers and cryptominers at every turn because the web can't degrade to exist without JS massaging DOMs.
If you want a wildly interactive art experience, just load the appropriate browser for that.
I think it's just a keeping-up-with-the-jonses sort of thing: If the restaurant down the street has a flashy website then I guess we need one too. Having restaurants in competition over the quality if their website is a negative sum game because it distracts them from the food.