←back to thread

Web Browser Engineering (2021)

(browser.engineering)
770 points MrVandemar | 2 comments | 15 Oct 24 09:42 UTC | HN request time: 0.47s | source
Show context
currygen ◴[15 Oct 24 13:35 UTC] 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 #
pmarreck ◴[15 Oct 24 14:06 UTC] 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 #
1. amjoshuamichael ◴[15 Oct 24 18:43 UTC] 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 #
2. RodgerTheGreat ◴[16 Oct 24 16:13 UTC] 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.