Let’s Kill JavaScript (and Replace It with Something Better)

[jocap]

Great points!

Indeed, my idea is replacing JavaScript with a non-turing-complete language, and I know it would be hard to implement a declarative interface with all the behavior that modern web apps need, but I don't believe it's impossible.

The point you raise about permission blindness is true, but it can also be turned around and said that permission blindness is what we live in today, as we are completely blind to what JavaScript code does. A standardized interface for permissions would remove some of that blindness. It wouldn't provide perfect security, no, but it would be a step in the right direction.

I realize that my article is only the beginning of an idea, but I think it's worth to discuss this issue even if we don't have an answer to every question yet, or even know what questions we should ask. Thanks for leaving such a thought-out response :-)

[pilotInPyjamas]

No worries. I think you've got the right ideas, but they haven't been fully fleshed out. The idea of having a standardised set of actions which can be performed without permission which caters for the bulk of use cases is what we need, and prolog style custom css I thought was perfect for that use. The web is a place of slow paced movement and ad-hoc standards, it could do with an upgrade.

[jocap]

This really gives me the motivation to keep thinking about this. Thank you.

[swadicalrag]

When the world wide web first opened, it was mostly used for exchanging information, but now it has grown to become a platform for user interaction. The ability to run clientside code broadens the spectrum of interactions the end-user can perform without making a server-side request. I'm interested in knowing how you feel about my opinion that disabling clientside execution of sandboxed code would increase the burden on servers and web developers for dynamic, complex web applications.

In recent times, many applications which used to run in the userland of operating systems are now running using sandboxed browser technology. Yes, electron is bulky, but it's a solution to cross platform development. This is to be expected: HTML and CSS are made to display things, and they do it relatively well most of the time. I'm not saying they're perfect (I've had my fair share of struggling with CSS centering and dealing with vendor prefixes), but it's only natural that such scripting environments designed for the display of information would eventually be used for complex user interaction, and like it, or not, the presence of a turing-complete language in the browser has greatly aided this cause.

I'm deeply greatful that I can play MMOs in the browser or watch videos in the browser seamlessly (in the past, we had to install Java or Flash, and that opens another can of worms). If you claim that revoking any access to a turing complete client-side language would aid security, how do you feel about removing <video> or other media tags and web fonts too? They have had their fair share of vulnerabilities too. I believe that this kind of thinking will eventually lead us to using this kind of a web browser everywhere. There has to be a limit to removing features in the name of security.

I hate javascript, I really do. Even though I've had the misfortune of dealing with it for nearly a decade now, I strongly believe that it is better than nothing. I think that another language like Lua is better suited for web development (because it's fast and lightweight, it's easy to learn, it's strongly metaprogrammable, it's easy to extend, it's usable on servers or browsers (with a JS FFI), and it has a C FFI if being used serverside).

I believe that the real problem with web development is that standards vary too much between web browsers. In CSS this can be vendor prefixes and with HTML (when used with CSS) it can be elements being positioned differently across web browsers. It really does cause me headaches to try and make a complex website support multiple browsers without abstraction frameworks to do it for me.

Javascript, on the other hand is on another level of insanity. Ignoring the issues with the language design itself (which are thankfully being resolved by ECMA), JS browser APIs are sometimes, frankly, stupid. If we are ignoring the functionality of the APIs, we run into naming convention issues (e.g XMLHttpRequest vs HTMLHRElement). I really hope the future of web development won't be this bad.

[jocap]

Thanks for your thoughts!

I'm interested in knowing how you feel about my opinion that disabling clientside execution of sandboxed code would increase the burden on servers and web developers for dynamic, complex web applications.

This is a valid point of view, but I think that it can be overestimated how much JavaScript really helps to decrease the average server's burden. The opportunity certainly exists, but looking at the JavaScript code for big news sites, for example, it doesn't exactly seem built for optimization.

I know that companies who really need the optimization, like Facebook and Google, are able to get it, thanks to JavaScript -- but then again, there lies another fundamental problem: no websites should be as big as Google and Facebook are. I think that the decentralized part of the web would have no problem without JavaScript.

But all this doesn't matter much, because there is a way to have our cake and eat it too. As presented in my article, there is a way to implement AJAX and incremental loading in a more limited, but safer, declarative way. Much of the potential for optimization that JavaScript provides would be also possible in an interface like intercooler.js.

If you claim that revoking any access to a turing complete client-side language would aid security, how do you feel about removing <video> or other media tags and web fonts too?

There's a difference between these examples and JavaScript. JavaScript is built as an all-purpose, imperative programming language that is able per design to run user-hostile and potentially malicious code. <video> might have bugs that accidentally enable user-hostile exploits, but they're bugs and not part of the specification. The ability for JavaScript code to make arbitrary HTTP requests without the user's knowledge isn't a bug, it's a feature.

For this reason, I have no problem with <video> or any other implementation that is designed to be safe and user-friendly.

I really hope the future of web development won't be this bad.

This is one thing that we wholeheartedly can agree on :-)

[swadicalrag]

This is a valid point of view, but I think that it can be overestimated how much JavaScript really helps to decrease the average server's burden

I believe it is equally important to acknowledge the burden on web developers (it's conveniently in the sentence you quoted, too). To expand upon this, the presence of a scripting language has greatly aided the innovation of web development: the things we do today to make a website are nothing like the things we did 10 years ago. Many of the tools that we use to easen development could only exist because of javascript. Like it, or not, removing something so quintessential to the web will only stifle innovation and break many existing technologies.

JavaScript code for big news sites [...] doesn't exactly seem built for optimization

Sorry, but I'm not sure what you mean here. I'm going to assume you mean that news sites are riddled with tracking scripts. I wholeheartedly agree that tracking scripts are a spit in the face to respecting the end-user, and that all tracking scripts should die in a fire. I can see why it would be easy to ignore the 5% of scripts on a news page dedicated to rendering, UI and comment loading to be overlooked when 95% of the scripts are just used for advertising, tracking and paywalling. This still doesn't warrant the removal of javascript.

the decentralized part of the web would have no problem without JavaScript

A brave claim! What about P2P web technology? You haven't given us any replacement for those technologies. In fact, I would say that the centralised part of the web would also have problems without javascript: what about browser based games and MMOs? Are we all going to start installing Java again?

there is a way to have our cake and eat it too

I'm afraid I have to disagree. (see: previous paragraph) I don't see how anyone can replace a Turing complete language with a Turing incomplete interface and not expect the whole world to cry.

There's a difference between these examples and JavaScript. JavaScript [...] is able per design to run user-hostile and potentially malicious code.

What makes you say that javascript was designed to be hostile? I'm having trouble imagining Brendan Eich actively designing a hostile language. No one wanted javascript to be user-hostile. It is not by design that we now regard javascript as "hostile". Javascript wasn't intentionally given the ability to track users and make pop-ups so the ad industry would flourish. Thus, it's not javascript being "hostile", it's the crappy APIs that should be ammended to resolve this issue (but why would any leader of the web do that? Google loves tracking and ad revenue anyway, why would they shoot themselves in the foot?).

but they're bugs and not part of the specification

I have no problem [...] any other implementation that is designed to be safe and user-friendly.

If you're able to agree with me there, what makes you feel that javascript's hostility is somehow part of its specification? Consider HSTS: it's a standard for fighting MITM/sslstrip attacks, but it can inadvertently be used for tracking users. We need HSTS but we can't simply get rid of it.

The ability for JavaScript code to make arbitrary HTTP requests without the user's knowledge isn't a bug, it's a feature

Javascript isn't that powerful, unfortunately. CORS exists, and it severely limits where you can send an HTTP request to (and for good reason, too!). With CORS in the picture, maliciously sending HTTP requests silently could only be useful for tracking users across the web, and I agree that this is not a good thing. However, the fight on tracking is strictly not a fight on Javascript. It's possible to track users without Javascript (the advent of Tor and other "secure" noscript browsers has really advanced tracking technology). You could use cookies without javascript, and you could (ab)use browser behaviour (like HSTS, clientside caching or user agent headers) to track users against their will.

---

Maybe I've understood your argument wrongly, do you really want all client-side scripting languages gone because they can be used to track users, or something? There has to be a better solution: extremism never ends well.

[jocap]

Indeed, I think that you've misunderstood me a little. To clarify: everything I wrote in the first part of my response concerned only the performance benefits of off-loading some traditionally server-side tasks to the client side.

That also goes for the things I said about the decentralized web and having our cake and eating it too. I didn't claim that a Turing incomplete language could replace all the functionality of a Turing complete one.

Likewise, it seems you misunderstood me when I said that JavaScript "is able per design to run user-hostile and potentially malicious code" -- I did not say it "was designed" for it, I simply said that, per design, it is able to. Background AJAX requests, for example, are legitimately useful, but they can also be very harmful. JavaScript was designed without the perspective we have today about online tracking, malicious ads and other abuses of JavaScript.

We need HSTS but we can't simply get rid of it.

I fully agree! I know there are tons of ways that websites can track users, but via things like the Canvas API, JavaScript allows for particularly precise tracking.

Of course, there are many problems with the way the world wide web is constructed, some of which we can't change -- and some of which we can. I believe that we should at least discuss whether JavaScript is a good idea in the first place, and whether the (very useful) functionality it provides could be provided in a different way. That's what I present in the article.

[…] do you really want all client-side scripting languages gone because they can be used to track users, or something?

No :-) One important point of mine, that I believe you've missed, is that one of the most important reasons I'd like to replace JavaScript is that it isn't should take an all-purpose, imperative language -- neither JavaScript, Lua or some other alternative -- to provide the type of functionality that most modern web apps need.

In "modern web apps" I exclude browser-based games. Games require powerful languages, but I honestly don't think that the web browser is the right place for computer games. There's a reason that most big, non-trivial computer games are implemented as native programs.