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.
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?
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.
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?
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.
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).
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.
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).
* 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.
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?
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.