Hacker News new | ask | show | jobs
by reginaldo 1378 days ago
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/...

2 comments

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.

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.

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

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