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.
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.
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.
This is surprisingly easy. Because the "this is HTML" is both vague and limited. HTML5 is remarkably vague and permissive.
Also, HTML has nothing to do with CSS nor with JS, nor with any DOM apis and not even with how stuff has to be rendered or if it has to be rendered at all.
There are numerous libraries and projects that can parse the WHATWG version of HTML. I'm not saying these are trivial or simple. But far simpler than a full rendering engine will ever be.
sounds like a skill issue
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.
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
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
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.
Yes there would be a DOM in addition
As an alternative for HTML, why not QML with Canonic browser?
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.
Reflowing UIs to suit varying aspect ratios is a challenging puzzle that Decker presently doesn't touch, though I do have some ideas for the future. If decks were embedded as inline "applets" of interactive content within a fluid document container (markdown, gemtext, etc) I think reflow would be considerably less important.
There is QML (see https://www.canonic.com) and Gemini (see https://gmi.skyjake.fi/lagrange/) as alternatives.
There's nothing to say that a Gemini browser (for example) can't choose to display gemtext links to other resources inline; images are a natural choice, but imagine a browser displaying CSV files as nice inline tables with standard affordances like sorting and line highlighting. No special browser support? No problem; lots of tools can work with CSV, and it's not completely unusable when displayed as raw text.
Some things don't currently have great options. We desperately need a standardized vector image format that doesn't have the cancerous complexity of SVG or EPS. A rich, declarative format for describing forms and their validation could be handy. Perhaps a simple self-contained format for interactive visualizations and games, like a stripped-down equivalent of Flash? (I have some ideas there.) As long as new formats are designed to degrade as gracefully as possible without special support and the means of composing formats is flexible enough, an ecosystem as a whole can grow and evolve while each component remains simple enough for one person to understand.
The present web and our universe of broadly supported technologies is very close to this ideal, if developers had a bit more restraint.