Let’s Replace JavaScript with Something Better
john.ankarstrom.se
john.ankarstrom.se
The premise here is completely wrong. A modern web browser is a sandboxed application delivery platform. The entire purpose is to execute untrusted code and it does so remarkably well. Take this away and you just have a document viewer -- a sophisticated one for sure -- but one always limited to its original purpose.
This proposed solution would eliminate many of the applications that web users use every single day and many more that haven't even been invented yet. HTML5 games would be impossible. Forget Google Maps. It's not even worth entertaining.
> In the company of the two declarative languages HTML and CSS, the imperative, all-purpose JavaScript always seemed the odd one out.
Declarative languages are extremely limiting and the trend has been to move away from them. For example, the introduction of Service Workers to replace manifest files.
Much of the success of the web has been in defiance of the declarative nature of the formats rather than in support of them. We're building complex applications in a declarative format designed for documents and that's only possible because we can imperatively manipulate those documents with code.
No big deal. When Apple introduced the App store, a maybe-not-new-but-finally-practical way of shipping applications to end-user devices was born. And they weren't webapps. No JS at first, mostly Objective-C and plists. And was still revolutionary in its reach, and consequences. Then Android came. Still no JS, but XML and Java.
So, no, you don't need HTML+JS to deliver rich content application to users.
You could argue that it's not necessary but that's what it is.
The site you're posting to now probably wouldn't even exist if it required installing a different proprietary application for every platform.
Yeah, that's the whole point I'm trying to make. That it's not necessary. That JS it no more special than any other language, and that there are recent, real, practical examples of absolute disruption (Apple/Android app stores) which broke what we thought it was required to deliver content to users.
As per the one single application, that's a gross oversimplification.
The ironic part is that app store you're arguing for wouldn't even exist without the web. The web is what made Mac OS X viable for users to switch to it (and MS Office). The platform network affects that made Windows a monopoly have been drastically cut down by the web.
> As per the one single application, that's a gross oversimplification.
Says another person posting on a web application that runs on every platform out there.
Since the web as a document viewer system appears to be dying, leaving only the distributed application system I don't really want to use anyway, perhaps in a few more years I'll be able to abandon the web thing and do something else.
How many real "distributed applications" do you see on the web, though, versus documents with dynamic content?
Is Medium, which is primarily intended to serve text, but which depends on javascript, an app or a document? What about Facebook, which despite its complexity still looks and acts more or less like a document, albeit with interactivity and asynchronous loading. Is it a matter of static versus dynamic content? Memory usage and computation? Features like AJAX and session storage?
If documents are only static, non-scripted HTML pages, then do they become applications if there is server-side logic involved?
I don't think there is an objective description of "web app" versus "document", I don't think the web is as cleanly cut along those lines and many might like to believe.
I am less concerned about server-side logic than the expectation that I'm just going to be happy to run arbitrary code provided by other people on my machine.
The web browser is your software -- I have mine customized with plenty of plugins, blockers, and reader view. You can take content, remix it, and display it however you like. I can render this site as green text on a black background if I wanted to.
I can write my own web browser if none of the existing ones do what I want.
I just need full module support and I'll be laughing.
So thanks but no thanks.
So thanks but no thanks.
Oh, wait...
You can "compile" languages to JS and pretend you're not actually using JS, though, or wait for the hot mess that is WASM to maybe settle into something sane. Otherwise, if you want to write code that runs in the browser? Yeah, kind of.
Ummm ... is this not how all software works? Is the average person 'aware' of the code that is executing as he/she clicks around in any piece of software? How is a web browser any different?
It happens all the time but for some reason, it's more evil when it's javascript.
JS is much more foisted upon users than MS Word ever was.
No signatures are checked; for none of those sites is there a validation whether it came from a trusted publisher and a prompt to install it.
With regular software, you explicitly download and install and in newer operating systems, there are certificates and signatures to give some modicum of protection. If you install something unsigned, you give your explicit consent.
It actually has First Class Functions that enables declarative programming, there’s a lot of cool libraries out there(ramda as an example) that let you express your apps in declarative way. Not saying that is a Pure functional language nor that was born as a functional language, it is indeed a general purpose language enabling more styles of programming with a plenty of good and bad ideas. However it gets better as it is continuosly improved by a lot of smart guys. Btw as I can see it, the main point or your article is not about javascript but about browser APIs
The entire article is about changing various browser APIs, not Javascript itself
No, it's mostly about browser languages, specifically, extending the declarative languages (HTML and CSS) to reduce (And ideally eliminate) the need for the imperative language (JS).
I'm curious: what's so bad about JavaScript that other languages seem to do better?
Other than that, you're spot-on.
Yes, but most other languages don't use IEEE 754 binsry floating point as their only numeric type. Or even their primary one.
Javascript has next to no standard lib, actually. Let's not forget that the DOM or WebAPI are not part of ECMAScript spec.
For the first category of websites, it's basically an economic problem - sites are including all this junk because it makes money. If this proposal were implemented, most sites would just find ways to work around it - and if you can send network requests in response to events, it's always going to be possible to track users. You could easily just send a network request every time something on the page is clicked, hovered over, etc. and doing that would likely be even less efficient than what we have today. The article mentions alerting people when a network request is made, but if you had to click a button every time a site wanted to make a network request, it would be so annoying that most people would just give up and go back to the old web. Ultimately, the only way to stop tracking is to somehow fix the economic model so that there's no incentive to do it, although it's not entirely clear how that would happen.
For the second category of things that are real apps, this system is probably not going to work in most cases. There's a practically infinite number of actions that a real app would need to do, and if you implement an API for every single one, you'd end up with something that's really similar to what we have today. Most likely, you would just go back to downloading and installing native apps, which provides even less security protections than a web browser does (and it also makes it much harder to distribute your apps, which is the whole reason the web won in the first place).
Rather than getting rid of javascript completely, I think there's a few things that we could do that would solve a lot of the problems present today: * Create a way for sites to easily accept micropayments so that there's an alternative to ads. Brave seems to be the only company attempting this right now; it will be interesting to see whether they succeed or not. * Have your web browser notify you if a site is using too many resources. Firefox already kind of has this with the "x is slowing down your browser" notification, something like "x has used 100MB of data. Stop loading?" would work really well. * Enable first-party isolation by default, which would do a lot to reduce cross-site tracking.
However, I don't think it sufficiently defends the premise of being objectively superior to javascript, given that all of the features mentioned could be implemented in javascript. There is nothing fundamental to the language which prevents designers from being proactive about consent in the way described.
I feel like the author blames the language for what are, essentially, design paradigms with which he disagrees, and I think a lot of people who criticize javascript do the same thing. We don't need to replace javascript to accomplish what the article describes, we just need to write javascript more ethically.
For sites which are already using the paradigm of "compiling to javascript" that might not be an issue, but that doesn't cover all the use cases for Javascript.
Other languages can't really occupy that same space until it's possible to, say, embed Lua or Rust source in script tags and just have it work as easily as Javascript does, and have the browser handle compilation and execution entirely.
If your compiler toolchain both runs on and generates WASM then you’ve removed about 90% of the pain of compiler toolchains. The experience should be on par with something like typescript or one of the ecma compatibility compilers. There’s still potential for classes of issues that would not exist in straight Javascript, but I’d rather debug most of those with browser tooling than gdb.
I have experience embedding lua applications within mobile apps, and it required a fair deal of wiring in C to marshal between java and lua (android) or swift and lua (ios).
To do the same in WASM sounds rather undesirable.
Edit: to finish my thought, I dont see the problem with using a compiler toolchain to create web applications. Can you elaborate on why that isn't a good thing?
It's not a bad thing per se, but it's added complexity without any obvious benefit if that code is still doing what javascript already does, just as a binary blob, especially for simple uses like glue code around jQuery or the sort of JS running on Hacker News.
This can be automated though; it's what we've been working on in Rust, and the approach is fundamentally language-agnostic.
And secondly, it’s going to be a long time before the entirety of the Web API (which is much bigger than just the DOM) is supported in wasm, if ever.
But I also question the purpose. Just use dev tools to help enforce more strict code.
A glibc-style standard binary library might be better to maintain and for production use. Making the 'standard library' modularized so I can customize will be even better.