4 ms·

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.

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.

pmarreck 2y ago
Or perhaps an entirely new platform/protocol, since this one is completely saturated with complexity at this point.
- amjoshuamichael 2y ago
  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.html https://drewdevault.com/2020/03/18/Reckless-limitless-scope.... (2) https://100r.co/site/uxn.html https://100r.co/site/uxn.html (3) https://internet-janitor.itch.io/decker https://internet-janitor.itch.io/decker EDIT: There is Project Gemini (https://geminiprotocol.net/ https://geminiprotocol.net/), but it doesn't support styling or scripting.
  - RodgerTheGreat 2y ago
    For the record, Decker uses a 4-bit palette configured from a 24-bit gamut: http://beyondloom.com/decker/color.html 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.
- niutech 2y ago
  Why not go back to WAP & WML? ;) There is QML (see https://www.canonic.com https://www.canonic.com) and Gemini (see https://gmi.skyjake.fi/lagrange/ https://gmi.skyjake.fi/lagrange/) as alternatives.
  - pmarreck 2y ago
    These are fascinating!
- RodgerTheGreat 2y ago
  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.
vivzkestrel 2y ago
have you by any chance looked into alternative browser engines such as servo, ladybird, goanna, netsurf, sciter, flow etc?
01HNNWZ0MV43FF 2y ago
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
- PaulDavisThe1st 2y ago
  > 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.
  - 01HNNWZ0MV43FF 2y ago
    As opposed to current browsers that run wasm and JS I mean Yes there would be a DOM in addition
- niutech 2y ago
  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?
mike_hearn 2y ago
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.
- btown 2y ago
  Another thing you can feasibly do is implement flexbox or a similar useful subset of layout! https://www.yogalayout.dev/ 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.
- berkes 2y ago
  > 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.

pmarreck 2y ago

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

amjoshuamichael 2y ago
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.html https://drewdevault.com/2020/03/18/Reckless-limitless-scope.... (2) https://100r.co/site/uxn.html https://100r.co/site/uxn.html (3) https://internet-janitor.itch.io/decker https://internet-janitor.itch.io/decker EDIT: There is Project Gemini (https://geminiprotocol.net/ https://geminiprotocol.net/), but it doesn't support styling or scripting.
- RodgerTheGreat 2y ago
  For the record, Decker uses a 4-bit palette configured from a 24-bit gamut: http://beyondloom.com/decker/color.html 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.
niutech 2y ago
Why not go back to WAP & WML? ;) There is QML (see https://www.canonic.com https://www.canonic.com) and Gemini (see https://gmi.skyjake.fi/lagrange/ https://gmi.skyjake.fi/lagrange/) as alternatives.
- pmarreck 2y ago
  These are fascinating!
RodgerTheGreat 2y ago
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.

vivzkestrel 2y ago

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

01HNNWZ0MV43FF 2y ago

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

PaulDavisThe1st 2y ago
> 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.
- 01HNNWZ0MV43FF 2y ago
  As opposed to current browsers that run wasm and JS I mean Yes there would be a DOM in addition
niutech 2y ago
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?

mike_hearn 2y ago

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.

btown 2y ago
Another thing you can feasibly do is implement flexbox or a similar useful subset of layout! https://www.yogalayout.dev/ 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.
berkes 2y ago
> 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.