Software is hard. Chrome had this in 2008. Firefox had to be rearchitected 14 years for this.
https://www.chromium.org/Home/chromium-security/site-isolati...
http://www.scottmccloud.com/googlechrome/
In early-mid 2008, I created a comic book for Google explaining the inner workings of their new open source browser Google Chrome.
If I'm mixing this up with https://wiki.mozilla.org/Electrolysis, that's still 10 years.
https://chromium.googlesource.com/chromium/src/+/c6f2e67ab40...
Site isolation proved to be the biggest refactor in Chrome's history, and was one of the motivating reasons for the webkit/blink fork. Making site isolation work touched a huge host of features, since handling iframes out of process has a way of making simple things incredibly complicated.
The example I always gave was: imagine how the "find text in page" browser feature would be implemented. With the entire document in-process, it was a simple for loop. With the document and its subframes sharded across multiple processes, it is now a distributed search problem that requires handling of out-of-order results and stitching them into a traversal order. What's more, to achieve Chrome's security goals, you want to avoid introducing functionality that would allow the [presumed-compromised] process of the outer document to query the contents of the inner document via the find in page feature. So you can't simply do this as a peer-to-peer query between the renderer processes; it needs to be coordinated by the main browser process.
Congrats to the Firefox team on this milestone.
And not so related to this, but from what I've heard about cracking competitions a few while ago, Firefox was not even included, it was considered too easy. Maybe my sources were just bad.
And I say this as a Firefox user for the last decade or more.
But yes Electrolysis is the initiative that you should have referred to in the original comment.
How is this bashing? :-)
It literally starts with "Software is hard."
...
As engineers, we should not accept this status quo; we should replace it. We need a new web and new software.
Seems pretty cool tbh
So people imagine splitting off a simpler web, where the main focus is on reading documents, rather than interactive applications, and browsers could be much simpler. But it's pretty hard to see how this could actually work in practice.
So probably the most you can hope for is that we split the document part of the web from the application part, so that it's easier to make a viable document browser. But it's not clear what advantage this offers for anyone who's not trying to make their own browser. Security is probably much simpler for the document browser, but the logins and sensitive data you care about securing are probably in the application browser anyway. And we've spent the last 20 years blurring the lines between documents and applications (think of a Github issue page, for instance), so even if it was possible to access information as a pure document, there would be advantages to looking at it in an application browser.
> it's not an alternative to the web
Right. You can't have a lightweight drop-in alternative to the web, pretty much by definition. Any platform capable of everything modern browsers are capable of, is by definition enormously complex.
> it is a very very small subset
That's not a flaw, it's a design goal. It isn't meant to be a half-baked portable GUI toolkit the way the modern web platform is, it's meant to be a simple and minimal format, stable and easy to implement. There are other formats somewhat like this in common usage, like man pages and, of course markdown.
https://dustri.org/b/the-web-browser-im-dreaming-of.html
Gemini might be a good replacement for the web: