5 ms·

Writing a browser means writing a rendering and layout engine. That's a pretty tall order, not that you can't do it. But there's so much you could do that woul

Writing a browser means writing a rendering and layout engine. That's a pretty tall order, not that you can't do it. But there's so much you could do that would be more likely to be fruitful. Port Servo to Nyxt Browser. Fork WebKit or servo or gecko and pull out the invasive web standards that have been injected by the ad company over the last decade that hurt users. It's all work you're going to have to do anyway building from scratch, might as well not start at the bottom and start with an existing community of people already willing to work on it with you.

cookiengineer 3y ago
That's what I did with WebKit [1] because it turns out servo is not as modular as it was before. And Gecko is the definition of monolith, so removing the attack surfaces is impossible, even TOR has a crappy replace-with-stubs approach that breaks with every internal API or bridge change. Need contributors and other maintainers though, because keeping up with upstream is impossible as a single dev. I tried to document the attack surfaces [2] from my cyber security perspective as good as possible, with tasks left to do and which need to be eventually removed. It's probably pretty opinionated because I want to use RetroKit as the webview for my own Browser Stealth which acts as a filtering proxy, scraper and decentralized cache [3] [1] https://github.com/tholian-network/retrokit https://github.com/tholian-network/retrokit [2] https://github.com/tholian-network/retrokit/blob/main/SECURITY.md https://github.com/tholian-network/retrokit/blob/main/SECURI... [3] https://github.com/tholian-network/stealth https://github.com/tholian-network/stealth (ongoing rewrite in golang)
deaddodo 3y ago
Honestly, although it's a heavy task, I don't think it's something worth being dissuaded from. I would argue that, in some ways at least, it's easier to do so today than before since we actually have a comprehensive standard now. That all to say, yes it's a tall order. But it's not the most impossible thing for a small team of dedicated people to do.
davedx 3y ago
But I mean your rendering and layout engine don't need to pass all ACID tests out of the gate, right? You build it up gradually. You start by getting reasonably simple HTML websites to render. There's no rush, and there's no hard and fast rule saying you have to implement every corner of the standard. Web browsers and the web are gloriously human.
nicoburns 3y ago
I maintain a web layout library that is designed to be integrated into other software: https://github.com/DioxusLabs/taffy https://github.com/DioxusLabs/taffy It needs to be combined with a text layout engine (such as https://github.com/pop-os/cosmic-text https://github.com/pop-os/cosmic-text), and it doesn't support everything yet (notable features that are currently missing: "float", "display: inline-block", "box-sizing: content-box", "position: static"). But we have Block, Flexbox and CSS Grid support with more on the way.
PurpleRamen 3y ago
> Writing a browser means writing a rendering and layout engine. Only if you want to write one from scratch. One should remember that a Browser is mainly the userfacing application, not the gears it's utilizing. You could take existing engines and just plug them together, maybe modularized enough to switch them any time, and it would still be a proper browser. And personally I think, people here are too focused on the gears any way, while we really need better interfaces and other gears besides render/layout/scripting.

cookiengineer 3y ago

That's what I did with WebKit [1] because it turns out servo is not as modular as it was before. And Gecko is the definition of monolith, so removing the attack surfaces is impossible, even TOR has a crappy replace-with-stubs approach that breaks with every internal API or bridge change. Need contributors and other maintainers though, because keeping up with upstream is impossible as a single dev. I tried to document the attack surfaces [2] from my cyber security perspective as good as possible, with tasks left to do and which need to be eventually removed. It's probably pretty opinionated because I want to use RetroKit as the webview for my own Browser Stealth which acts as a filtering proxy, scraper and decentralized cache [3] [1] https://github.com/tholian-network/retrokit https://github.com/tholian-network/retrokit [2] https://github.com/tholian-network/retrokit/blob/main/SECURITY.md https://github.com/tholian-network/retrokit/blob/main/SECURI... [3] https://github.com/tholian-network/stealth https://github.com/tholian-network/stealth (ongoing rewrite in golang)

deaddodo 3y ago

Honestly, although it's a heavy task, I don't think it's something worth being dissuaded from. I would argue that, in some ways at least, it's easier to do so today than before since we actually have a comprehensive standard now. That all to say, yes it's a tall order. But it's not the most impossible thing for a small team of dedicated people to do.

davedx 3y ago

But I mean your rendering and layout engine don't need to pass all ACID tests out of the gate, right? You build it up gradually. You start by getting reasonably simple HTML websites to render. There's no rush, and there's no hard and fast rule saying you have to implement every corner of the standard. Web browsers and the web are gloriously human.

nicoburns 3y ago

I maintain a web layout library that is designed to be integrated into other software: https://github.com/DioxusLabs/taffy https://github.com/DioxusLabs/taffy It needs to be combined with a text layout engine (such as https://github.com/pop-os/cosmic-text https://github.com/pop-os/cosmic-text), and it doesn't support everything yet (notable features that are currently missing: "float", "display: inline-block", "box-sizing: content-box", "position: static"). But we have Block, Flexbox and CSS Grid support with more on the way.

PurpleRamen 3y ago

> Writing a browser means writing a rendering and layout engine. Only if you want to write one from scratch. One should remember that a Browser is mainly the userfacing application, not the gears it's utilizing. You could take existing engines and just plug them together, maybe modularized enough to switch them any time, and it would still be a proper browser. And personally I think, people here are too focused on the gears any way, while we really need better interfaces and other gears besides render/layout/scripting.