Problem: web standards are too big so there’s only a few browser engines
Solution: force each website author to implement their own browser in WebAssembly
To me, this doesn’t sound like a solution at all, it sounds like we’re going to make authoring a website an impossible task, or we’ll just end up in the same spot, but now every time I visit a new domain, I’ll need to wait for 200mb of google-chrome.wasm to download before I can view the blog post.
For the authors page alone, today bare html and a handful of kb, we at least need a text rendering engine - stuff like harfbuzz - simple layout, and painting primitives. So maybe 10-20mb of WASM?
How do we handle back/forward buttons? Maybe we need a few more kb to implement history handling ourselves inside our wasm.
If we’re still fetching html but doing so from inside wasm, gotta add at least a few kb of html parser.
No, what’ll happen is this: All our websites will start using WASM web browser frameworks that implement a browser-inside-a-browser for us, so all we have to do is focus on building some simplified flavor of HTML.
And then people will get annoyed at the scope creep of that framework, so someone will get the bright idea of building a browser-inside-a-browser-browser.
I, for one, am looking forward to this Russian doll future.
I don’t think anybody would want that. If every website did its own rendering you’d have to ship several tens, if not hundreds, of MBs of WASM to account for everything that browsers do today, and the result would be an accessibility nightmare. You wouldn’t be able to zoom in and get crisp fonts, no adblock, no browser extensions, no inspector, no screen readers, no consistency between interactions on websites… No, absolutely not. I’d rather live with the duopoly.
I get the motivation, but … Would this have resolution independence built in? (let alone accessibility)
It’s a pretty big deal to use the same site on a tiny screen like iPhone SE and a laptop and a desktop.
I guess that is what Wayland is for, but I haven’t used the APIs directly. The post is light on details. It’s not clear what kind of APIs you would bind from WASM
Either way, it seems like you would end up downloading a ton of redundant code, for uploading forms, JSON encoding/parsing, and whatnot.
HTML/CSS/JS can be very compact if you use them as intended/designed
Computer Science in the 1960s to 80s spent a lot of effort making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The reason for this is that the less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it in many ways.
That is, HTML is data, not code ! That is important, and very explicit in the web’s design!
This design also seems to be penalizing the people who are using the web “right” rather than the ones shipping apps.
So now I have to ship my blog as a WASM blob? Doesn’t make sense.
[1] Not to be confused with the Principle of Least Privilege / Authority
Add an extension that can be accessed via the WASI component model.
Even aside from all the numerous issues of the proposal, this line is why it will quickly lead to a bunch of underdocumented messy additions and a monopoly. Especially once tracking-enforcers hiding under the name of «CAPTCHA» get ahold of that.
(If one’s goal is «most of the text content», not implementing JavaScript at all and spoofing Chrome’s TLS fingerprint gets you like 90% there even nowadays)
I’ve been thinking in a similar direction now that I’ve been working with Wasm almost daily for over a year. I’d replace the emphasis on WASI in this article with an emphasis on Wasm GC for allowing easy , memory-safe exchange of references amongst different modules.
OP just invented Java Web Start.
More like Flash.
I, for one, welcome the return of our java applet nightmares.
Problem: web standards are too big so there’s only a few browser engines
Solution: force each website author to implement their own browser in WebAssembly
To me, this doesn’t sound like a solution at all, it sounds like we’re going to make authoring a website an impossible task, or we’ll just end up in the same spot, but now every time I visit a new domain, I’ll need to wait for 200mb of google-chrome.wasm to download before I can view the blog post.
For the authors page alone, today bare html and a handful of kb, we at least need a text rendering engine - stuff like harfbuzz - simple layout, and painting primitives. So maybe 10-20mb of WASM?
How do we handle back/forward buttons? Maybe we need a few more kb to implement history handling ourselves inside our wasm.
If we’re still fetching html but doing so from inside wasm, gotta add at least a few kb of html parser.
No, what’ll happen is this: All our websites will start using WASM web browser frameworks that implement a browser-inside-a-browser for us, so all we have to do is focus on building some simplified flavor of HTML.
And then people will get annoyed at the scope creep of that framework, so someone will get the bright idea of building a browser-inside-a-browser-browser.
I, for one, am looking forward to this Russian doll future.
I don’t think anybody would want that. If every website did its own rendering you’d have to ship several tens, if not hundreds, of MBs of WASM to account for everything that browsers do today, and the result would be an accessibility nightmare. You wouldn’t be able to zoom in and get crisp fonts, no adblock, no browser extensions, no inspector, no screen readers, no consistency between interactions on websites… No, absolutely not. I’d rather live with the duopoly.
I get the motivation, but … Would this have resolution independence built in? (let alone accessibility)
It’s a pretty big deal to use the same site on a tiny screen like iPhone SE and a laptop and a desktop.
I guess that is what Wayland is for, but I haven’t used the APIs directly. The post is light on details. It’s not clear what kind of APIs you would bind from WASM
Either way, it seems like you would end up downloading a ton of redundant code, for uploading forms, JSON encoding/parsing, and whatnot.
HTML/CSS/JS can be very compact if you use them as intended/designed
The top comments on HN said it better than I did - https://news.ycombinator.com/item?id=43203748
First, the post doesn’t contain enough to detail to say how it’s different than Flash and Flutter. Didn’t we try this already?
And this WASM architecture doesn’t respect the Principle of Least (Computational) Power - https://www.w3.org/DesignIssues/Principles.html#PLP [1]
That is, HTML is data, not code ! That is important, and very explicit in the web’s design!
This design also seems to be penalizing the people who are using the web “right” rather than the ones shipping apps.
So now I have to ship my blog as a WASM blob? Doesn’t make sense.
[1] Not to be confused with the Principle of Least Privilege / Authority
Reminds me of J. Mickens and M. Dhawan’s Atlantis: Robust, Extensible Execution Environments for Web Applications.
Huh. I hadn’t read anything serious from James Mickens, so I had to skim a bit just to be sure it wasn’t a joke.
Even aside from all the numerous issues of the proposal, this line is why it will quickly lead to a bunch of underdocumented messy additions and a monopoly. Especially once tracking-enforcers hiding under the name of «CAPTCHA» get ahold of that.
(If one’s goal is «most of the text content», not implementing JavaScript at all and spoofing Chrome’s TLS fingerprint gets you like 90% there even nowadays)
I’ve been thinking in a similar direction now that I’ve been working with Wasm almost daily for over a year. I’d replace the emphasis on WASI in this article with an emphasis on Wasm GC for allowing easy , memory-safe exchange of references amongst different modules.