Hacker News Reader

Comment by reginaldo | Hacker News Reader

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/...

View on HN

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.

They also need to handle a lot of backwards compatibility as well as gracefully handling syntax errors

> 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?

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.

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

The web is made of links. It's quite annoying to switch browsers when following links.

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.

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.

The counter-argument from the embassies point of view would be that, since you're running the browser on top of the simpler execution environment, you could ship the exact version of the browser that works with your content. That way, only the execution environment (i.e. the simpler APIs) would have to be backwards compatible. So content could theoretically live longer, as we'd ship the interpreter of the content along with the content.

I mean I don't entirely disagree, but XHTML was not very popular and HTML5 demands some wiggle room like many tags can be omitted as per the spec.

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

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.

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.

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

Reply on news.ycombinator.com