←back to thread

Web Browser Engineering (2021)

(browser.engineering)
770 points MrVandemar | 6 comments | | HN request time: 0.658s | source | bottom
Show context
currygen ◴[] No.41848445[source]
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.
replies(4): >>41848575 #>>41848648 #>>41848756 #>>41850985 #
1. pmarreck ◴[] No.41848756[source]
Or perhaps an entirely new platform/protocol, since this one is completely saturated with complexity at this point.
replies(3): >>41851754 #>>41854366 #>>41862168 #
2. amjoshuamichael ◴[] No.41851754[source]
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.

replies(1): >>41860829 #
3. niutech ◴[] No.41854366[source]
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.

replies(1): >>41855118 #
4. pmarreck ◴[] No.41855118[source]
These are fascinating!
5. RodgerTheGreat ◴[] No.41860829[source]
For the record, Decker uses a 4-bit palette configured from a 24-bit gamut: http://beyondloom.com/decker/color.html

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.

6. RodgerTheGreat ◴[] No.41862168[source]
I think multiple smaller formats and protocols would be a better approach than one big new standard, and we already have lots of simple, broadly-supported options to choose from.

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.