7 ms·
The "browser" is a blank execution sandbox with a rendering context. The remote server sends programs (using something like WASM) with a standardized ABI. The p
by tbabb 5y ago
The "browser" is a blank execution sandbox with a rendering context. The remote server sends programs (using something like WASM) with a standardized ABI. The program can use the rendering context to put stuff on the screen or receive user input.
Indexing and page interoperability is done by exposing standard functions which yield the necessary metadata. For example, if you want your site to be indexable by a search engine, you expose a function "contentText()" which crawlers will call (and which the client browser might also call and display using the user's own reader app). In the simplest case, the function simply returns a literal.
Core resources like libraries would be uniquely identified, cryptographically signed, versioned, and shared.
If someone wanted to make use of a browser pipeline like the standard one we have today, they might send code which does something like "DOMLibrary.renderHTML(generateDocument())". But someone else could write a competing library for rendering and laying out content, and it might take hold if it's better, and it wouldn't have to be built on top of the first one.
Also, the browser wouldn't necessarily be a separate app (though someone could make one); it would be a standard built-in feature of operating systems, i.e. the sandboxing would be done at the kernel level. With security properly handled, there'd be no difference between a native app and a web app, except whether you load it from your own filesystem or a remote one.
- nlitened 5y agoWe already have that. It’s called Java
- Nevermark 5y agoJava might have been that, if HTML and all the other web tech had never happened and Mosaic, Netscape Navigator, etc. had started out as Java sandboxes.
- nlitened 5y agoIf Java has obviously not outcompeted HTML, one should reflect, in which way HTML is obviously better in things that matter compared to a code sandbox.
- Nevermark 5y agoI am not promoting Java over HTML. But existing and becoming entrenched as a worldwide standard many years in advance is a huge advantage for HTML over Java that isn't relevant to considerations of redesigning the Internet. So that would be a very big reason Java "lost" a major part of the battle it never showed up to. Very difficult bar to replace a platform so pervasive as HTML after the fact.
- DeathArrow 5y agoJava, Silverlight, Flash, Web Assembly. But the problem is that HTTP is more suited to deliver HTML and browsers were designed primarily to render HTML.
- manx 5y agoMaybe this could be approached by compiling the servo browser engine to wasm...
- EvanAnderson 5y agoI'm shocked there _still_ isn't a browser-within-a-browser that renders to a canvas element "product" available yet. I've been expecting it for years. A cross-platform browser environment that prevents user control (no ad blockers, complete control of the "UX", no copy / pasting, no printing to PDF, etc) would be a hot seller to a particular kind of web property. Your existing development pipeline works (since you're still rendering to an HTML5 "browser") but you don't have to worry about users exerting any control over the experience. Throw some Widevine at it, some DNS-over-HTTPS-over-websockets with pinned certificates, and you've got a VM on most consumer-grade devices today that's completely outside user control. The users don't have to be tricked to install anything-- it'll run inside their existing browser on their PC, Mac, iOS device, Android device, ChromeOS device, etc. It's not "trusted computing" but it's close enough. This sounds completely awful, BTW, but I totally see it happening. Accessibility (and other minimum-viable-product features) are out there in permissively-licensed open source software just waiting to be integrated. It's only a matter of time. Nobody should make this, but somebody will succumb to the easy money and do it.
- wereHamster 5y agoA nightmare for screen readers and other accessibility tools, and anyone who needs to rely on them.
- aaaaaaaaaaab 5y agoUnblockable ads and popups, uncopyable text, yay!
- amelius 5y agoYou can still block ads by recognizing them at the pixel level. Same for copying text. Advantage: you can also select text in images, and block ads that are images.
- aaaaaaaaaaab 5y agoLol, sure mate. if pixel.isAd { pixel.color = black } Or maybe you thought about using some *waves hands* machine learning™?
- amelius 5y agoNot like that. I meant OCR, which uses pixels as input (as opposed to html).
- aaaaaaaaaaab 5y agoYeah cool, so you would only be able to select text that's visible? How would you copy the contents of an article spanning multiple screens? Sorry, but this idea is just dumb.
- amelius 5y agoYou hit Ctrl+A, and the browser uses off-screen buffers to analyze the entire text.
- aaaaaaaaaaab 5y agoOff-screen buffers? So now you’re prescribing a particular rendering architecture for every app to follow? I thought this was supposed to be just a generic sandbox with a canvas, with no strings attached, but now you require everything to be present in off-screen buffers for your OCR to work? Firstly, it won’t be generic anymore, and secondly, it will also be extremely inefficient.
- amelius 5y agoSounds like a "microkernel" approach to building browsers. I like it :)
- brokenmachine 5y agoThere are just so many ways that this won't work or will make things so much worse and nothing interoperable, I can't even begin to.