7 ms·

Reinventing the browser should be simplifying it to only what it needs to be: executing + rendering remote code in a sandboxed window. Make a new browser that

Reinventing the browser should be simplifying it to only what it needs to be: executing + rendering remote code in a sandboxed window. Make a new browser that is just WebGPU + WebAssembly, no more DOM. Would already run the next wave of games that will come targeting that. Then for regular websites, have them deliver a HTML rendering engine written in Webassembly for how they want to be rendered. No more need to test websites on a range of browsers

0xCMP 4y ago
There was an idea for this in 2011: "Atlantis" https://www.microsoft.com/en-us/research/publication/atlantis-robust-extensible-execution-environments-for-web-applications/ https://www.microsoft.com/en-us/research/publication/atlanti... https://scholar.harvard.edu/files/mickens/files/atlantis.pdf https://scholar.harvard.edu/files/mickens/files/atlantis.pdf https://www.youtube.com/watch?v=1uflg7LDmzI https://www.youtube.com/watch?v=1uflg7LDmzI
deleted 4y ago
[deleted]
caslon 4y ago
That sounds genuinely awful and detestable. "Oh, you're bored of a tenth of a gigabyte of React and TypeScript every time you load a web page? Here, we're going to ship you the entire browser every time you reload!"
- Vermeulen 4y ago
  Why couldn't it cache?
  - joshuamorton 4y ago
    Same reason cross origin caching is limited today, it's a stuffed channel that can harm privacy and allow tracking.
phailhaus 4y ago
> Then for regular websites, have them deliver a HTML rendering engine I think this is a dealbreaker, that is simply too much data to have to send over every time you want to load a webpage. It kills mobile immediately since most users have data caps.
- enos_feedler 4y ago
  The idea is you cache a rendering engine. It just isn’t core in the system layer
  - phailhaus 4y ago
    Having to store all the different versions of rendering engines out there doesn't really solve the problem, because space isn't unlimited either. Imagine: Facebook just upgraded to v1.3.2 of PopularEngine but Google still lags at v1.3.0, now you have to store both!
    - enos_feedler 4y ago
      What your saying is I should thank browserland for saving me all this disk storage. Looking over at you Electron
      - phailhaus 4y ago
        Yeah exactly. It's not great, because getting a website to work consistently across browsers is a bit of a pain, but it's gotten much better in recent years. Especially after IE was finally shut down.
  - drowning-secs 4y ago
- wwweston 4y ago
  As if that isn't enough, it isn't really the web if you can't "view source" and get roughly useful semantics for documents. The browser didn't beat out a handful of VMs because it was just another VM.
wruza 4y ago
I don’t think this is a good idea. We’ll run into a situation with many different not-dom guis having the same set of problems that existing not-dom guis had for all these years. Think gnome-like drama for the half of the internet. Dom/css is no doubt a mountain of something stinky, but at least it is a slow moving standard and never had any politics or bdfl opinions involved. Also it has a set of features (e.g. accessibility, ad blocking) which would be hard to implement everywhere in the same way. Maybe something more low-level than dom but still integratable with higher-level apis and features could be built into a new browser paradigm.
xnx 4y ago
Sounds like you're advocating turning browsers into something like a dumb terminal or television. Websites will soon do this anyway in an attempt to lock down content and avoid ad blocking.
bogomipz 4y ago
>"Make a new browser that is just WebGPU + WebAssembly, no more DOM." I'm not familiar with WebGPU and WebAssembly, can you say is there something in that combination that replaces the DOM? I'd also be curious to hear what's the issue with the DOM.
Latty 4y ago
My instant thought is that this is an accessibility nightmare of an idea.
- postalrat 4y ago
  That's always my first thought when I hear this idea.
stuntkite 4y ago
I've been poking at doing something like this lately. I'm so sick of browsers and I agree with your thesis. It's a lot to think about putting together a browser project from first principles so I've only done a few tests and flowed some stuff out. WebGPU really is the future especially because you can pipe around remote rendering and data. Is there an existing open project moving in this direction? Do I have to start it? Would you like to help?
Arnavion 4y ago
>Make a new browser that is just WebGPU + WebAssembly, no more DOM. At the very least you'll also need a WebAccessibility API for the HTML rendering engine to hook into so that the OS sees your rendered textboxes as textboxes.
marssaxman 4y ago
How about... exactly the opposite? An HTML rendering engine only, with no client side code? That's the reinvented browser I would prefer. The best sandbox is no need for a sandbox.
- wruza 4y ago
  Pushing all computations and interactions to the cloud has a number of downsides. Realistically, most sites would turn into a instant-rendering battery-saving untrackable privacy-respecting distraction-free ads for their own app.
petmon 4y ago
How would you handle clicks and stuff?
rhaway84773 4y ago
Isn’t this basically the plug-in API that allowed custom HTML renderers that were basically Flash and Silverlight and was vehemently rejected? In modern terms this is basically Flutter. Combine Flutter with Microsoft Blazor and I think that fully describes your idea.
deleted 4y ago
[deleted]
paxys 4y ago
Great idea, every website should write its own WebGPU-based rendering engine from scratch. But that will be way too much effort for every kind of project, so what can really happen is some large players write engines and define interfaces for them, and we can all use them for our sites. But different engines rendering the same data differently is probably going to be confusing (what if I want to swap them to compare performance?), so we should also standardize on some rules for how they do that. Maybe define some kind of document model and styling language? Also, downloading all these engines on every page load might be too wasteful, so we can pick a couple of the dominant ones and bundle them into the browser itself. That way sites just have to send over structured content and the browser can load them all without a problem. If we can ever get to this it will be a great web experience!
- conorcleary 4y ago
  Relevant xkcd: https://xkcd.com/927 https://xkcd.com/927 "How Standards Proliferate"
  - syrrim 4y ago
    Better: https://xkcd.com/1367/ https://xkcd.com/1367/
- Vermeulen 4y ago
  You have definitely missed the entire point. Of course there are some advantages of just putting it all in the browser for rendering current standard web sites. The point is to rethink the browser so it isn't just a single tech company setting what the web is with Chromium. A WebGPU+WebAssembly engine would be simple enough for there to be many.
  - meheleventyone 4y ago
    Right but this misses the point that you’re not removing complexity by shuffling it down a layer. Is it really an advantage to have multiple “thin browsers” if there are only two or three “browser engines” anyway due to their complexity? Further by pushing the complexity down a layer you inevitably make it slower. Aside from which from a market perspective most small browser projects already are a thin layer on top of Chromium. So really what’s gained here? Particularly if you want to write a novel app using WASM and WebGPU/WebGL only you can already with the tiniest amount of glue to spin the handle. And this can be a useful approach but should it be the default?
BeefWellington 4y ago
You're describing essentially Flash and Silverlight.
musicale 4y ago
This is one of the endgames of the ad blocking arms race (another being server-side rendering.) In both cases ad blockers become computer audiovisual processing systems.
raxxorraxor 4y ago
I think the net would become far less accessible. WebAssembly has its uses in certain applications. For high quality streaming or similar use cases it can really help to speed things up. But for the average website? Not keen on having binary blobs executed for everything. That will at some point come with its own perils and in certain points would be a step back. For this I have applications. For what would you need a browser then? Want to develop an ad blocker? Too bad...

0xCMP 4y ago

There was an idea for this in 2011: "Atlantis" https://www.microsoft.com/en-us/research/publication/atlantis-robust-extensible-execution-environments-for-web-applications/ https://www.microsoft.com/en-us/research/publication/atlanti... https://scholar.harvard.edu/files/mickens/files/atlantis.pdf https://scholar.harvard.edu/files/mickens/files/atlantis.pdf https://www.youtube.com/watch?v=1uflg7LDmzI https://www.youtube.com/watch?v=1uflg7LDmzI

deleted 4y ago

[deleted]

caslon 4y ago

That sounds genuinely awful and detestable. "Oh, you're bored of a tenth of a gigabyte of React and TypeScript every time you load a web page? Here, we're going to ship you the entire browser every time you reload!"

Vermeulen 4y ago
Why couldn't it cache?
- joshuamorton 4y ago
  Same reason cross origin caching is limited today, it's a stuffed channel that can harm privacy and allow tracking.

phailhaus 4y ago

> Then for regular websites, have them deliver a HTML rendering engine I think this is a dealbreaker, that is simply too much data to have to send over every time you want to load a webpage. It kills mobile immediately since most users have data caps.

enos_feedler 4y ago
The idea is you cache a rendering engine. It just isn’t core in the system layer
- phailhaus 4y ago
  Having to store all the different versions of rendering engines out there doesn't really solve the problem, because space isn't unlimited either. Imagine: Facebook just upgraded to v1.3.2 of PopularEngine but Google still lags at v1.3.0, now you have to store both!
  - enos_feedler 4y ago
    What your saying is I should thank browserland for saving me all this disk storage. Looking over at you Electron
    - phailhaus 4y ago
      Yeah exactly. It's not great, because getting a website to work consistently across browsers is a bit of a pain, but it's gotten much better in recent years. Especially after IE was finally shut down.
- drowning-secs 4y ago
wwweston 4y ago
As if that isn't enough, it isn't really the web if you can't "view source" and get roughly useful semantics for documents. The browser didn't beat out a handful of VMs because it was just another VM.

wruza 4y ago

I don’t think this is a good idea. We’ll run into a situation with many different not-dom guis having the same set of problems that existing not-dom guis had for all these years. Think gnome-like drama for the half of the internet. Dom/css is no doubt a mountain of something stinky, but at least it is a slow moving standard and never had any politics or bdfl opinions involved. Also it has a set of features (e.g. accessibility, ad blocking) which would be hard to implement everywhere in the same way. Maybe something more low-level than dom but still integratable with higher-level apis and features could be built into a new browser paradigm.

xnx 4y ago

Sounds like you're advocating turning browsers into something like a dumb terminal or television. Websites will soon do this anyway in an attempt to lock down content and avoid ad blocking.

bogomipz 4y ago

>"Make a new browser that is just WebGPU + WebAssembly, no more DOM." I'm not familiar with WebGPU and WebAssembly, can you say is there something in that combination that replaces the DOM? I'd also be curious to hear what's the issue with the DOM.

Latty 4y ago

My instant thought is that this is an accessibility nightmare of an idea.

postalrat 4y ago
That's always my first thought when I hear this idea.

stuntkite 4y ago

I've been poking at doing something like this lately. I'm so sick of browsers and I agree with your thesis. It's a lot to think about putting together a browser project from first principles so I've only done a few tests and flowed some stuff out. WebGPU really is the future especially because you can pipe around remote rendering and data. Is there an existing open project moving in this direction? Do I have to start it? Would you like to help?

Arnavion 4y ago

>Make a new browser that is just WebGPU + WebAssembly, no more DOM. At the very least you'll also need a WebAccessibility API for the HTML rendering engine to hook into so that the OS sees your rendered textboxes as textboxes.

marssaxman 4y ago

How about... exactly the opposite? An HTML rendering engine only, with no client side code? That's the reinvented browser I would prefer. The best sandbox is no need for a sandbox.

wruza 4y ago
Pushing all computations and interactions to the cloud has a number of downsides. Realistically, most sites would turn into a instant-rendering battery-saving untrackable privacy-respecting distraction-free ads for their own app.

petmon 4y ago

How would you handle clicks and stuff?

rhaway84773 4y ago

Isn’t this basically the plug-in API that allowed custom HTML renderers that were basically Flash and Silverlight and was vehemently rejected? In modern terms this is basically Flutter. Combine Flutter with Microsoft Blazor and I think that fully describes your idea.

deleted 4y ago

[deleted]

paxys 4y ago

Great idea, every website should write its own WebGPU-based rendering engine from scratch. But that will be way too much effort for every kind of project, so what can really happen is some large players write engines and define interfaces for them, and we can all use them for our sites. But different engines rendering the same data differently is probably going to be confusing (what if I want to swap them to compare performance?), so we should also standardize on some rules for how they do that. Maybe define some kind of document model and styling language? Also, downloading all these engines on every page load might be too wasteful, so we can pick a couple of the dominant ones and bundle them into the browser itself. That way sites just have to send over structured content and the browser can load them all without a problem. If we can ever get to this it will be a great web experience!

conorcleary 4y ago
Relevant xkcd: https://xkcd.com/927 https://xkcd.com/927 "How Standards Proliferate"
- syrrim 4y ago
  Better: https://xkcd.com/1367/ https://xkcd.com/1367/
Vermeulen 4y ago
You have definitely missed the entire point. Of course there are some advantages of just putting it all in the browser for rendering current standard web sites. The point is to rethink the browser so it isn't just a single tech company setting what the web is with Chromium. A WebGPU+WebAssembly engine would be simple enough for there to be many.
- meheleventyone 4y ago
  Right but this misses the point that you’re not removing complexity by shuffling it down a layer. Is it really an advantage to have multiple “thin browsers” if there are only two or three “browser engines” anyway due to their complexity? Further by pushing the complexity down a layer you inevitably make it slower. Aside from which from a market perspective most small browser projects already are a thin layer on top of Chromium. So really what’s gained here? Particularly if you want to write a novel app using WASM and WebGPU/WebGL only you can already with the tiniest amount of glue to spin the handle. And this can be a useful approach but should it be the default?

BeefWellington 4y ago

You're describing essentially Flash and Silverlight.

musicale 4y ago

This is one of the endgames of the ad blocking arms race (another being server-side rendering.) In both cases ad blockers become computer audiovisual processing systems.

raxxorraxor 4y ago

I think the net would become far less accessible. WebAssembly has its uses in certain applications. For high quality streaming or similar use cases it can really help to speed things up. But for the average website? Not keen on having binary blobs executed for everything. That will at some point come with its own perils and in certain points would be a step back. For this I have applications. For what would you need a browser then? Want to develop an ad blocker? Too bad...