Web Browser Engineering (2021)

It's refreshing that browser engineering seems to become a "trend" now. The ecosystem is quite sparse with basically only Google, Apple and Mozilla defining it. I'd like to see forward into a future with more independent browser engines.

Something that uses less RAM would be nice. Other than that and the spyware from Capital-G Google Chrome and Capital-M Mozilla Firefox, I don't have a problem with it being sparse. It's millions of hours of de-duplicated work.

I'd like an alternative to HTML though. If I was to make a browser maybe I'd focus on replacing HTML because I can't stand it, and replacing js just because the runtime is heavy.

Like, a browser that only runs wasm and has nearly no JS runtime would make me giggle

I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch.

The interesting space is really post-HTML UI/document tech. There's another thread running about Typst which is a sort of better LaTeX. Markdown was highly impactful. There's a lot of scope for people to do interesting things in this space that are "HTML but better". It doesn't even have to be a markup format - Typst and React HTML both blur the lines between code and data. Jetpack Compose shows how to use Kotlin's DSL features to make something that looks a bit like a UI description but which is actually code.

Of course it means you have to then either distribute a 'browser' for your format, or find a way to display it in the browser. But compiling down to some JS/HTML/WASM thing is certainly possible. You can also use portable GUI toolkits like JavaFX; that also gives you accessibility. Or do both!

Once you define your own UI language there's a lot of scope to try things that HTML doesn't do well. An obvious one is separation of content and style. HTML tried and never really got there. XSL:T tried harder but was a weird pure functional language with XML as its syntax. React does quite well with going JSON->boxes but the underlying protocols are always ad-hoc and tacked on, so you can't really write useful tooling on top of that.

Another idea would be a format that's natively immune to XSS.

Or perhaps an entirely new platform/protocol, since this one is completely saturated with complexity at this point.

Another thing you can feasibly do is implement flexbox or a similar useful subset of layout! https://www.yogalayout.dev/ is one such library that powers React Native. Letting people bring CSS intuition when writing greenfield code for a simpler engine can be a great way to onboard users.

> Like, a browser that only runs wasm

That's not a browser.

More or less by definition, a browser is an application that can use HTTP (and potentially other protocols) to make requests to other systems and retrieve stuff described using HTML (and possibly other formats).

Sure, a tool that just loads wasm and executes it would be fun (and probably exists, at least for the local case). But it's not a web browser.

> I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch.

This keeps being repeated. But it leans on three false assumptions.

- That is has to be "finished" at all. For many use-cases, a subset (of a subset) might just be fine. The screen in my refrigerator, or the information display in a train, might want to render some HTML, but when the HTML is controlled and constrained, there's no need for "everything".

- That is has to adhere to "the spec". See above, but also if the HTML+CSS+JS is less controlled, quite a few use-cases it's fine to ignore lots of the quirks or even large parts of the specs. Even Chrome and FF don't implement "all", whatever "the spec" might be in the first place. But a browser in a TV set-top box, my e-reader, some dedicated wikipedia-device, or the "help section of an app" are fine if they break on complex sites.

- That is must be implemented from scratch. Even if you forego the big rendering engines, JS VMs and so forth, there's a lot of libs that do DOM handling, CSS parsing, JS runtime etc. There's a lot of shoulders to stand on, aside from "just run chrome headless".

By repeating this mantra that its not worth "building a new browser" or "rendering engine", we only cement the status quo further. And promote the idea that your car, refrigerator, test-runner, help-section, dashboard, e-reader and whatnot must run either a full chrome or firefox. We stiffle innovation.

As opposed to current browsers that run wasm and JS I mean

Yes there would be a DOM in addition

have you by any chance looked into alternative browser engines such as servo, ladybird, goanna, netsurf, sciter, flow etc?

I keep coming back to this idea as the (albeit ideal) future of the web. HTML keeps morphing and changing to fit the increasingly complex requirements of modern web apps. I mean the W3C spec is 114 million words (1). I think that web apps as a concept are a good idea, but I just can't believe that HTML/CSS/JS are the best technologies to fill that out. I'd love to see someone tackle a new, "micro-sized app format", with a much simpler document format, and something like a FORTH as a scripting language. Uxn (2) and Decker (3) are good examples of this, but obviously a proper implementation would have to be built with the full range of possible UI and accessibility in mind, not just monochrome bitmap displays.

A web standard so simple, anyone can implement it!

One can dream...

(1) https://drewdevault.com/2020/03/18/Reckless-limitless-scope.... (2) https://100r.co/site/uxn.html (3) https://internet-janitor.itch.io/decker

EDIT: There is Project Gemini (https://geminiprotocol.net/), but it doesn't support styling or scripting.

> You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch.

sounds like a skill issue

I was an early user of KDE back in 2000 and thought they were absolutely insane for trying to write their own web browser engine when it was controlled by Microsoft and Netscape. The web was just too complex and nothing worked in it, there was just no way a tiny open source project like that could make any useful headway with browser technology.

Of course, jump forward 24 years and the KDE browser engine is basically the only game in town- the basis of both Chrome and Safari. Absolutely no way I saw that coming.

Why not go back to WAP & WML? ;)

There is QML (see https://www.canonic.com) and Gemini (see https://gmi.skyjake.fi/lagrange/) as alternatives.

> I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch.

Andreas Kling, the author of Ladybird browser, proves otherwise.

There is also QML as an alternative for HTML - see Canonic browser: https://www.canonic.com

For less RAM, try: Dillo, Netsurf, Otter Browser, K-Meleon, Pale Moon, Basilisk, Ultralight.

As an alternative for HTML, why not QML with Canonic browser?

These are fascinating!

Andreas hasn't finished. Also, I question to what extent it's worth it.