4 ms·

The problem with browsers is that they conflate the execution environment, which should be as small, understandable, analyzable, obviously free of bugs as possi

The problem with browsers is that they conflate the execution environment, which should be as small, understandable, analyzable, obviously free of bugs as possible, with the common APIs, which as developers we want as rich as possible. An interesting alternative was embassies project[1], which got WebKit running on an understandable computing base. The current-day equivalent would be to get WebKit running on top of, say, WebAssembly and the Canvas API. That would be immense impactful, but isn't as sexy or cool as writing your own browser from scratch. That being said, I applaud the Ladybird initiative. Scratching your own itch is the way to go when aiming for maximum enjoyment. [1] https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/howell https://www.usenix.org/conference/nsdi13/technical-sessions/...

everforward 4y ago
I still think the problem underlying the complexity of browsers is inherent in using HTML/CSS as the base language. Most complex languages get interpreted or compiled into a much simpler format, and the simpler format gets executed. This lets the execution environment be small and understandable, as you said. Using HTML/CSS as primitives means the execution environment has to be complicated, because the execution environment itself needs to be aware of things like whether certain attributes get inherited and how they are inherited. I have hope for WebAssembly + Canvas, because it's a simpler set of primitives. There's a clear boundary between the simple execution environment and the tools that translate complex instructions into simple instructions.
- toastal 4y ago
  They also need to handle a lot of backwards compatibility as well as gracefully handling syntax errors
  - lowercased 4y ago
    > as well as gracefully handling syntax errors Do they? Maybe they don't? Maybe we're at a point where people can author html/css, and if there are syntax issues, they just 'break' until someone fixes it. 25 years ago, maybe we needed some laxness, and perhaps today, we don't?
    - fabrice_d 4y ago
      They do, because web content can live for a very long time - that's a strength of the web. So today's and tomorrow's browsers need to be able to process these 25 years old documents, because they are still part of the web, syntax issues included and no one will come to fix them.
      - iopq 4y ago
        You can just load that content in another browser. If your browser handles all of the popular sites, people will use it. Nobody cares about whether Flash loads anymore, do they? Yet there's millions of Flash animations and games never ported to another platform
        fabrice_d 4y ago
        The web is made of links. It's quite annoying to switch browsers when following links.
        dane-pgp 4y ago
        I think the idea would be that when you click on a link to a 25 year old page, the browser brings up a little warning saying "This page is 25 years old and has some errors that may stop it displaying correctly. Press the Refresh button to re-render it using an older browser engine." In the worst case, the browser would then have to download some additional code that contained all the support for invalid HTML/CSS code. In the best case, the 25 year old page would be served with a header containing a cryptographic proof that the site really had been around for 25 years, and it wasn't just some newly created attack site that was exploiting some weird behaviour in old renderers.
        iopq 4y ago
        Again, nobody linked to Flash content in a while. You might still encounter it in the wild and it won't work. I don't hear anyone complaining.
      - reginaldo 4y ago
- beebeepka 4y ago
  I've semi-seriously suggested the canvas road twice. I have little doubt we're going to make the same mistakes yet again but it might end up better overall. Gonna need vulkan, better tooling, and lots front-end brain rewiring. Might happen before the end of the decade
- poisonborz 4y ago
  And then let's throw out all browser extensions and accessibility software as webpages become an unapproachable unmodifyable <canvas> tag, a true corporate dream. People underestimate the importance of webpages being documents. It doesn't translate well to all use cases - see apps and games - but to throw it out and go for sealed binary formats would be a big step back.
  - everforward 4y ago
    That's a valid concern. I think there could be middle-ground approaches, we just don't have them right now. E.g. React is basically entirely interpreted; we could create something like React that used a different set of primitives than the DOM. Browser extensions could act as middleware between React and those new primitives, as a plugin to the execution engine similar to how they currently work. Someone smarter than me probably has a better idea of how that would be implemented, but it seems possible. A lot of webpages I see aren't even really documents anymore. They serve a very basic HTML page and use JS to flesh out the rest. It's not all that conceptually different from Qt to me, except that there's a standards-enforced way to serialize the objects out into text. We could create a middle-ground engine that used simple primitives and could be serialized out into a text format. Qt kind of does that QtCreator, from what I know. I believe it creates XML docs that specify the objects to create.
niutech 4y ago
There is already Webkit.js: http://trevorlinton.github.io/ http://trevorlinton.github.io/

everforward 4y ago

I still think the problem underlying the complexity of browsers is inherent in using HTML/CSS as the base language. Most complex languages get interpreted or compiled into a much simpler format, and the simpler format gets executed. This lets the execution environment be small and understandable, as you said. Using HTML/CSS as primitives means the execution environment has to be complicated, because the execution environment itself needs to be aware of things like whether certain attributes get inherited and how they are inherited. I have hope for WebAssembly + Canvas, because it's a simpler set of primitives. There's a clear boundary between the simple execution environment and the tools that translate complex instructions into simple instructions.

toastal 4y ago
They also need to handle a lot of backwards compatibility as well as gracefully handling syntax errors
- lowercased 4y ago
  > as well as gracefully handling syntax errors Do they? Maybe they don't? Maybe we're at a point where people can author html/css, and if there are syntax issues, they just 'break' until someone fixes it. 25 years ago, maybe we needed some laxness, and perhaps today, we don't?
  - fabrice_d 4y ago
    They do, because web content can live for a very long time - that's a strength of the web. So today's and tomorrow's browsers need to be able to process these 25 years old documents, because they are still part of the web, syntax issues included and no one will come to fix them.
    - iopq 4y ago
      You can just load that content in another browser. If your browser handles all of the popular sites, people will use it. Nobody cares about whether Flash loads anymore, do they? Yet there's millions of Flash animations and games never ported to another platform
      - fabrice_d 4y ago
        The web is made of links. It's quite annoying to switch browsers when following links.
        dane-pgp 4y ago
        I think the idea would be that when you click on a link to a 25 year old page, the browser brings up a little warning saying "This page is 25 years old and has some errors that may stop it displaying correctly. Press the Refresh button to re-render it using an older browser engine." In the worst case, the browser would then have to download some additional code that contained all the support for invalid HTML/CSS code. In the best case, the 25 year old page would be served with a header containing a cryptographic proof that the site really had been around for 25 years, and it wasn't just some newly created attack site that was exploiting some weird behaviour in old renderers.
        iopq 4y ago
        Again, nobody linked to Flash content in a while. You might still encounter it in the wild and it won't work. I don't hear anyone complaining.
    - reginaldo 4y ago
beebeepka 4y ago
I've semi-seriously suggested the canvas road twice. I have little doubt we're going to make the same mistakes yet again but it might end up better overall. Gonna need vulkan, better tooling, and lots front-end brain rewiring. Might happen before the end of the decade
poisonborz 4y ago
And then let's throw out all browser extensions and accessibility software as webpages become an unapproachable unmodifyable <canvas> tag, a true corporate dream. People underestimate the importance of webpages being documents. It doesn't translate well to all use cases - see apps and games - but to throw it out and go for sealed binary formats would be a big step back.
- everforward 4y ago
  That's a valid concern. I think there could be middle-ground approaches, we just don't have them right now. E.g. React is basically entirely interpreted; we could create something like React that used a different set of primitives than the DOM. Browser extensions could act as middleware between React and those new primitives, as a plugin to the execution engine similar to how they currently work. Someone smarter than me probably has a better idea of how that would be implemented, but it seems possible. A lot of webpages I see aren't even really documents anymore. They serve a very basic HTML page and use JS to flesh out the rest. It's not all that conceptually different from Qt to me, except that there's a standards-enforced way to serialize the objects out into text. We could create a middle-ground engine that used simple primitives and could be serialized out into a text format. Qt kind of does that QtCreator, from what I know. I believe it creates XML docs that specify the objects to create.

niutech 4y ago

There is already Webkit.js: http://trevorlinton.github.io/ http://trevorlinton.github.io/