11 ms·

So you want to build a browser engine

225 points by zmodem 2y ago

purple-leafy 2y ago
Great read :)
ZeroGravitas 2y ago
I was going to suggest: > initially try just being a faster, lighter or lower-power Electron or WebView. But he mentioned it himself, though maybe someone might want to try this with no intention to become a full browser. Can you skip any of the tricky security requirements if it'll be bundled into an app? Or is that just asking for trouble?
- jraph 2y ago
  > Or is that just asking for trouble? With the interactions an electron-like app might be doing with external services and the ton of JS third party library it could use, I think it would be indeed risky.
  - cxr 2y ago
    None of the security mitigations described in the post (nor any of those implemented in any browser engine) are aimed at protecting developers against themselves when they run an agglomeration of third-party modules as a single bundle under the same policy.
    - jraph 2y ago
      CSPs and mechanisms against cross site scripting are such protections. They would block a script from calling home or executing arbitrary scripts or displaying images that could exploit vulnerabilities. So browser engines definitely protect developers against themselves a bit. Although I agree with you that there's only so much you can do for the devs bundling crap themselves, I was wrong on this indeed. Still, I would not be overly confident with web code running in a browser where security is not well studied if it has any network capacity. Especially if the app displays any external content in something like an iframe.
- giancarlostoro 2y ago
  So basically what Sciter does?
- giantrobot 2y ago
  > Or is that just asking for trouble? The average Node project pulls in hundreds of dependencies. While you'd hope these would have some security vetting because of the Many Eyes theory, you have no fucking idea what your project is doing. Even a trivial Electron app is running a ridiculous amount of unreviewed third party code. Just one module able to exercise some local exploit in your engine because you didn't fix Security Footgun #8176 screws over all of your users. A browser engine that's been developed with a billion dollars of person hours runs that same untrusted third party code but has security guardrails everywhere.
  - ameliaquining 2y ago
    Aren't those dependencies trusted anyway? If they want to do something evil, they can just do it, they don't need to look for a zero-day in the engine they're running on.
    - giantrobot 2y ago
      The LCE doesn't need to be in the engine, the engine just needs to lack protections for the code to run something locally. As for Node dependencies being trusted, they are trusted but that's largely unearned trust.
- ramon156 2y ago
  Tauri basically?
  - IshKebab 2y ago
    No. Tauri is not a web browser. It uses the existing platform browser. This would be more like Servo which I believe is focusing on embedded use cases. It makes sense because for Electron/embedded you don't need it to work for every site (really really hard), you only need it to work for one site. (Or a few hundred/thousand if you count all your users.) That is several orders of magnitude easier.
- roca 2y ago
  I think sooner or later you're going to want to load lower-trust content --- IFRAMEs of third-party Web content, or sandboxed extensions, or something like that. Building your entire architecture on the assumption you'll never have to do that is very risky.
  - ameliaquining 2y ago
    You could use the system webview for embedded third-party web content while using your own framework for trusted content.
oldpersonintx 2y ago
[dead]
amelius 2y ago
This makes writing a compiler or writing an OS kernel look like child's play.
- Paul-Craft 2y ago
  A browser engine is a compiler. Or, more properly, it's at least two compilers (HTML + CSS -- you can outsource JS to V8 or whatever).
  - jsheard 2y ago
    The DOM stuff, JS, WASM, WebGL, WebGPU... at least five compilers, with JS and WASM needing two distinct frontends (baseline/optimizing) and at least two backends (x86/ARM), and WebGL and WebGPU needing three backends each (D3D/VK/Metal).
    - rice7th 2y ago
      Isn't webGL's GLSL directly delegated to the driver just like normal OpenGL? Also one could easily write a lot of frontends and a single massive centralised backend with multiple processor targets and optimisation profiles. Think about V8 which works for both JavaScript and WebAssembly. This would create a much simpler codebase and if you're going to use a parser generator it could very well be a breeze.
      - jsheard 2y ago
        > Isn't webGL's GLSL directly delegated to the driver just like normal OpenGL? Perhaps you could in an MVP implementation, but in practice no, none of the serious implementations do that by default. First because native OpenGL drivers are generally a mess, so browsers actually implement WebGL on top of DirectX, Vulkan or Metal wherever they can, and even when those aren't available the browsers still parse, validate and reconstitute the GLSL rather than passing it straight through to OpenGL as a layer of insulation against driver bugs. Chrome and Firefox do have hidden feature flags which bypass that behavior and call the native GL implementation directly, but you probably shouldn't enable those unless you're really into ShaderToy and want it to compile faster.
skilled 2y ago
Who is this post intended for? Nobody builds their own browser engines. And I mean nobody. I didn’t get the feeling that he wrote this for pet projects either. Andreas over at Ladybird is probably the only one (and Servo?) who is really doing it the way that this post describes. Still, the last couple of paragraphs made me think that this is more of a reflection of his own time over at Mozilla: could have / would have.
- deleted 2y ago
  [deleted]
- jawerty 2y ago
  Most people don’t need to write their own OS or compiler. Knowing the details of how things work is apart of getting to gaining expertise
- pvg 2y ago
  And I mean nobody. One such project has pretty regular HN chonkthreads, including last week. https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=ladybird&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
  - skilled 2y ago
    Yeah that is what I meant. To my knowledge, Andreas is the only person crazy enough to do it and also do it in the open. You have to watch some of his YouTube videos to appreciate the insanity that goes into getting things to work, but he at least has some help from the OSS community: building automated tests, scripts, etc. As I was reading the post I thought he would at least shout him out too!
    - pvg 2y ago
      Ah that's 'statistically nobody' vs 'nobody'.
      - 2y ago
phendrenad2 2y ago
This post starts with a false dichotomy: You're either making a toy browser for fun, or you're trying to make the next Chrome. There are many points in-between on that spectrum. (Look how long Microsoft IE existed, despite being highly inferior.)
- IshKebab 2y ago
  That's only because it was the "Chrome" (i.e. the dominant browser). Look at what happened when Microsoft eventually tried to catch up with Chrome - they gave up.
  - wizzwizz4 2y ago
    > Look at what happened when Microsoft eventually tried to catch up with Chrome - they gave up. That wasn't because they weren't up to the job. It's because Google was using Microsoft's playbook against them. https://news.ycombinator.com/item?id=18697824 https://news.ycombinator.com/item?id=18697824 > I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't keep up. For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail (should now be fixed in Win10 Oct update). Prior to that, our fairly state-of-the-art video acceleration put us well ahead of Chrome on video playback time on battery, but almost the instant they broke things on YouTube, they started advertising Chrome's dominance over Edge on video-watching battery life. What makes it so sad, is that their claimed dominance was not due to ingenious optimization work by Chrome, but due to a failure of YouTube. On the whole, they only made the web slower. (While this may seem like poetic justice, Google's also been doing this against everyone else, so we shouldn't cheer. Also, unlike when Microsoft pulled these stunts, this might not even be deliberate on the part of the Google webdevs.)
    - mkoubaa 2y ago
      I hate that they did it but I have a hard time sympathizing with Edge/MS
    - 2y ago
atum47 2y ago
I honestly think (I've been thinking about that for a few years now) that eventually a OS will be nothing more than a browser.
- notsylver 2y ago
  Isn't that what ChromeOS is?
- fabrice_d 2y ago
  that was the idea of FirefoxOS. Come help https://capyloon.org https://capyloon.org if you believe in that!
shiomiru 2y ago
I'm writing one for fun: https://sr.ht/~bptato/chawan/ https://sr.ht/~bptato/chawan/ "Fixed-width text to a grid" makes things easier (sometimes), but I think it still qualifies. On the article itself; it might be better to start with more... basic things than the optimizations it talks about: * Cascading & layout must be cached and optimized - far from trivial. Layout is one of the hardest parts to get right at all, to make it fast as well is another level... and I'm just talking caching, not even multi-threading. * The "web platform" contains a very large amount of poorly thought out features harmful for user privacy and/or security. You can choose between convenience (opt out) and privacy (opt in), or try to balance the two as major browsers do. Both is often impossible. * "Serialize the entire application state" sounds like the most complex thing you can come up with as a distinguishing feature. Much more low hanging fruit exists if you give up on writing a Chromium clone. e.g. a fun side project I've had is making my browser "protocol-agnostic", or adding a bunch small QOL stuff for myself. You can probably find new ideas easily once you start out. * Older browsers are useful for inspiration too. The coolest features in mine are often just carbon copies of the same things from w3m, just a bit more polished. Reading about what historical engines did - even IE! - is often enlightening too. Sometimes it's just a smaller scale of what engines do now, and easier to implement. Other times it's a whole different approach. * It's easy to get lost in the details - careful with perfectionism. As you start getting more components interacting, it will slowly become clear when the naive approach is wrong and how to improve it. Overall, it takes time, but is also fun and rewarding - you will learn a lot, even without replacing Chromium.[0] That said, if you want to learn how "modern" browsers work, getting involved with a "modern" engine itself is probably much more productive. [0]: To write a Chromium replacement, you may have to reincarnate as awesomekling ;)
- roca 2y ago
  I guess one of my points is that layout algorithms are not really part of the "most basic" decisions anymore. Replacing layout algorithms is actually a lot less disruptive to the engine architecture than switching to site isolation, say.
  - shiomiru 2y ago
    Fair; re-reading TFA, now I realize you explicitly instructed me to stop reading in the first paragraph :) Trying to redeem myself with an on-topic question: isn't what you want more of a "refactoring of Blink" than "building a browser engine"? I would be surprised if a complete rewrite was really necessary for the features you want, since "saving state" already happens to some extent in all engines (even if it's just reloading from the cache) and I've seen reports about Gecko integrating multi-core cascade from Servo. What makes it hard to incrementally improve upon the current engines?
djbusby 2y ago
Seems a good place to mention https://sciter.com/ https://sciter.com/ It's been on HN loads of times. A "browser" engine but very narrow scope. Works a treat for LOB type apps.
- Buttons840 2y ago
  I was sad when the creator tried to raise enough funds to open-source Sciter and there wasn't much interest. If 1% of the people who complain about Electron had pledged something, we would have it as a good alternative today.
  - sneak 2y ago
    Open sourcing software to which you hold copyright doesn’t cost anything.
    - lopis 2y ago
      False. This is very naive. If this was true, we wouldn't get the regular posts on HN about OSS drama, and how some people gave up OSS. Opening source up is more than showing us the source.
crazygringo 2y ago
> So You Want To Build A Browser Engine The only correct answer is, "don't". I mean, if you want to build a toy browser engine for a CS class or fun or something, then sure. But the idea that "you want to build an engine that’s competitive with Chromium" is, quite simply, nonsensical. If you want your own browser engine, you're going to fork Chromium or Gecko (Firefox). I mean, even Microsoft gave up on maintaining its own independent engine and switched to Chromium. I literally don't understand who the author thinks this post is supposed to be addressed to. Building an independent browser engine could have made sense in 1998. These days it would cost hundreds of millions of dollars in dev time to catch up to existing engines... just to duplicate something that you already have two open-source versions of?
- CoolestBeans 2y ago
  Even Chromium started with WebKit which itself was a fork. This doesn't mean you shouldn't be interested in browser dev but you also don't have to do a totally clean sheet implementation.
  - crazygringo 2y ago
    But that's exactly my point. This article appears to be entirely about an implementation from scratch. It makes very clear that it is not about forking Chromium. But even Google was smart enough not to start from scratch. So again, I don't know who the intended audience for this article is. It's advice on something no sane person or organization would ever do.
    - roca 2y ago
      And yet a few people are doing it. So yeah, it's advice to insane people.
      - cardiffspaceman 2y ago
        I have succumbed to the temptation to implement various aspects of this. I have also tweaked existing implementations for my day job. I even had the assignment to pitch an implementation to a client. So I am sure that some would question my sanity NOW. TFA suggests that I might not have been sane to start with. I admire any team-of-one that takes on this endeavor and publishes their work.
cbxyp 2y ago
interesting how oldpersonintx's comment "thinly-veiled passive-aggressive swipe at Ladybird" was dead'd here when that accurately reflects the authors comments (as roc-robert o'callahan) here on LWN.net: https://lwn.net/Articles/977625/ https://lwn.net/Articles/977625/
- account42 2y ago
  Firefox is also competitive with Chrome when it comes to telemetry and other anti-features. Really being competitive with Chrome is not enough because that still doesn't give anyone any reason to use your browser over Chrome. You need to actually provide some end-user benifit that Chrome doesn't (and ideally won't) and that is more important than being competitiv with Chrome on the features Google wants to push. This is where Mozilla really dropped the ball. 15 years of Chrome lighting fire under their ass and zero innovation in the way we browse the web. Well, less than zero when you consider all the useful extension broken by browser changes over the years. Meanwhile Mozilla keeps gaslighting us how they care about privacy while trying numerous ways to integrate ads in the browser. ... yeah I see why someone would rather create a browser from scratch than support Mozilla.
pizlonator 2y ago
I’m not sure that performance needs to constrain web engine design the way it traditionally has. The world has changed since the browser perf war started. Just try disabling the JIT in a modern browser and you’ll find your UX is not really any worse. HW has gotten faster than when the current browser perf wars kicked off. So it might be that to have a meaningfully useful browser engine alternative, perf won’t be the top concern. Compatibility will though, just because of the sheer number of features a modern browser engine supports. And if you don’t have JIT, then it’s not clear if Spectre is even a meaningful concern.
- roca 2y ago
  Those are interesting points, but disabling the JIT doesn't really change anything unless it means you can forgo site isolation, and that would be a very risky bet. It may be that disabling the JIT is fine for users most of the time. However, that is also a tough call --- so easy for your competitors to beat you up with benchmarks, and there will be real use-cases (e.g. emulators) where it matters to some users. And of course there's a lot more to perf than just the JIT. I barely mentioned JIT in my blog post.
  - coldtea 2y ago
    >and there will be real use-cases (e.g. emulators) Those are so niche as a concern, that might as well not take into account at all when doing a new browser engine.
  - pizlonator 2y ago
    Yeah but you mentioned Spectre. It’s not clear if you can do a Spectre attack on an interpreter. Maybe you can, but it seems super hard and not practical. And without Spectre, the argument for site isolation is much weaker.
esprehn 2y ago
Engine diversity is really important for the ecosystem and continued innovation. While building something competitive with the big three engines is a monumental task there's still a lot of value in building alternative engines to try new ideas even if getting "the whole web" implemented is basically impossible. For example: - Servo vs Blink vs Cobalt do selector matching and style resolution very differently. - WebKit has a selector JIT, no one else does though. - WebKit and Blink do layout super differently (with LayoutNG shipped). - Firefox's html parser is written in Java and converted to C++ at build time. The big value in folks trying to write new engines is finding these alternate paths. We can't depend on the big three for all the innovation. That's what's great about Ladybird. Sure it'll need a lot of sophisticated sandbox improvements to get us to a big four situation, but it's more likely its value will be in finding another road the other engines didn't travel across the huge universe of specs, content and features.
- matheusmoreira 2y ago
  Diversity alone is great but not quite enough. The alternative browsers need to actually see significant usage. Otherwise the developers and corporations will go "this browser has 99% market share so I can just ignore the others", giving the dominant browser makers enormous leverage over the others.
- weinzierl 2y ago
  "- Firefox's html parser is written in Java and converted to C++ at build time." This is surprising. Is it really true in the sense that the code that parses the HTML in a regular Firefox install was autoconverted when it was built?
  - reubenmorais 2y ago
    Yep: https://searchfox.org/mozilla-central/source/parser/html/java/README.txt https://searchfox.org/mozilla-central/source/parser/html/jav... And more info: https://about.validator.nu/htmlparser/ https://about.validator.nu/htmlparser/
    - 2y ago
ilrwbwrkhv 2y ago
If you actually want to build one I cannot recommend https://browser.engineering/ https://browser.engineering/ enough.
IncreasePosts 2y ago
[flagged]
9cb14c1ec0 2y ago
How important is process separation if the browser engine is programmed with a memory safe language like Rust? I am under the impression that things like site separation are to bandage memory safety issues. Is that right, or are there other issues at play?
- hannob 2y ago
  Rust does not give you protection against speculative execution attacks. Entirely different beast than memory safety errors.
bdahz 2y ago
Does anyone have the idea of escaping from HTML/CSS? As these specs are too complicated and not friendly for web developers as well. Maybe we could re-invent a browser engine without conforming to HTML/CSS specs? An (early) alternative spec/engine would be a Figma-compatible vector graphics spec[2] and its rendering engine[3]. It is called VeryGoodGraphics[1]. [1] https://verygoodgraphics.com/ https://verygoodgraphics.com/, the website is built with its own technology (wasm version). [2] https://docs.verygoodgraphics.com/specs/overview https://docs.verygoodgraphics.com/specs/overview [3] https://github.com/verygoodgraphics/vgg_runtime https://github.com/verygoodgraphics/vgg_runtime
- promiseofbeans 2y ago
  Relevant XKCD: https://xkcd.com/927/ https://xkcd.com/927/
- Vermeulen 2y ago
  Yeah - there really is a opportunity now to rethink browsers as just sandboxed rendering windows using WebAssembly + WebGPU. Could still have typical DOM rendering handled with Webassembly delivered by the web sites (ideally cached). The challenge is though still having standards and accessibility options. That VeryGoodGraphics example allows for no text selection - and doesn't at all handle zooming. Still though it'd be a good bottom up way for a new browser to disrupt Chrome
  - coldpie 2y ago
    How would ad blocking work in this world? A browser without ad blocking is useless.
    - gwbas1c 2y ago
      How would ads work in this world? The advertising ecosystem relies on adding a 1-2 line JavaScript blurb to the page, and then the ads are added at display time.
- robin_reala 2y ago
account42 2y ago
> So You Want To Build A Browser Engine > [bunch of things that are only relevant to an application platform] Yeah you really don't need any of this for a web browser to be usable for its intended purpose.
- Sohcahtoa82 2y ago
  I mean, yeah, you can ignore all that and have a functioning web browser. But it would be riddled with security issues.
bobajeff 2y ago
I've wanted to make my own browser by forking chromium. But then I got confronted with the reality of hacking on a Google scale c++ project. I've tried doing it by embedding webkit which is much more doable but I've found that many sites I use don't work my embedded webkit. So now I think if I want to make my own browser it would be better start making my own versions of those sites first and make sure those are good and popular. At which point I'll just make native clients for them and forget about html/js/css.

225 points by zmodem 2y ago

Great read :)

I was going to suggest: > initially try just being a faster, lighter or lower-power Electron or WebView. But he mentioned it himself, though maybe someone might want to try this with no intention to become a full browser. Can you skip any of the tricky security requirements if it'll be bundled into an app? Or is that just asking for trouble?

jraph 2y ago
> Or is that just asking for trouble? With the interactions an electron-like app might be doing with external services and the ton of JS third party library it could use, I think it would be indeed risky.
- cxr 2y ago
  None of the security mitigations described in the post (nor any of those implemented in any browser engine) are aimed at protecting developers against themselves when they run an agglomeration of third-party modules as a single bundle under the same policy.
  - jraph 2y ago
    CSPs and mechanisms against cross site scripting are such protections. They would block a script from calling home or executing arbitrary scripts or displaying images that could exploit vulnerabilities. So browser engines definitely protect developers against themselves a bit. Although I agree with you that there's only so much you can do for the devs bundling crap themselves, I was wrong on this indeed. Still, I would not be overly confident with web code running in a browser where security is not well studied if it has any network capacity. Especially if the app displays any external content in something like an iframe.
giancarlostoro 2y ago
So basically what Sciter does?
giantrobot 2y ago
> Or is that just asking for trouble? The average Node project pulls in hundreds of dependencies. While you'd hope these would have some security vetting because of the Many Eyes theory, you have no fucking idea what your project is doing. Even a trivial Electron app is running a ridiculous amount of unreviewed third party code. Just one module able to exercise some local exploit in your engine because you didn't fix Security Footgun #8176 screws over all of your users. A browser engine that's been developed with a billion dollars of person hours runs that same untrusted third party code but has security guardrails everywhere.
- ameliaquining 2y ago
  Aren't those dependencies trusted anyway? If they want to do something evil, they can just do it, they don't need to look for a zero-day in the engine they're running on.
  - giantrobot 2y ago
    The LCE doesn't need to be in the engine, the engine just needs to lack protections for the code to run something locally. As for Node dependencies being trusted, they are trusted but that's largely unearned trust.
ramon156 2y ago
Tauri basically?
- IshKebab 2y ago
  No. Tauri is not a web browser. It uses the existing platform browser. This would be more like Servo which I believe is focusing on embedded use cases. It makes sense because for Electron/embedded you don't need it to work for every site (really really hard), you only need it to work for one site. (Or a few hundred/thousand if you count all your users.) That is several orders of magnitude easier.
roca 2y ago
I think sooner or later you're going to want to load lower-trust content --- IFRAMEs of third-party Web content, or sandboxed extensions, or something like that. Building your entire architecture on the assumption you'll never have to do that is very risky.
- ameliaquining 2y ago
  You could use the system webview for embedded third-party web content while using your own framework for trusted content.

oldpersonintx 2y ago

[dead]

amelius 2y ago

This makes writing a compiler or writing an OS kernel look like child's play.

Paul-Craft 2y ago
A browser engine is a compiler. Or, more properly, it's at least two compilers (HTML + CSS -- you can outsource JS to V8 or whatever).
- jsheard 2y ago
  The DOM stuff, JS, WASM, WebGL, WebGPU... at least five compilers, with JS and WASM needing two distinct frontends (baseline/optimizing) and at least two backends (x86/ARM), and WebGL and WebGPU needing three backends each (D3D/VK/Metal).
  - rice7th 2y ago
    Isn't webGL's GLSL directly delegated to the driver just like normal OpenGL? Also one could easily write a lot of frontends and a single massive centralised backend with multiple processor targets and optimisation profiles. Think about V8 which works for both JavaScript and WebAssembly. This would create a much simpler codebase and if you're going to use a parser generator it could very well be a breeze.
    - jsheard 2y ago
      > Isn't webGL's GLSL directly delegated to the driver just like normal OpenGL? Perhaps you could in an MVP implementation, but in practice no, none of the serious implementations do that by default. First because native OpenGL drivers are generally a mess, so browsers actually implement WebGL on top of DirectX, Vulkan or Metal wherever they can, and even when those aren't available the browsers still parse, validate and reconstitute the GLSL rather than passing it straight through to OpenGL as a layer of insulation against driver bugs. Chrome and Firefox do have hidden feature flags which bypass that behavior and call the native GL implementation directly, but you probably shouldn't enable those unless you're really into ShaderToy and want it to compile faster.

skilled 2y ago

Who is this post intended for? Nobody builds their own browser engines. And I mean nobody. I didn’t get the feeling that he wrote this for pet projects either. Andreas over at Ladybird is probably the only one (and Servo?) who is really doing it the way that this post describes. Still, the last couple of paragraphs made me think that this is more of a reflection of his own time over at Mozilla: could have / would have.

deleted 2y ago
[deleted]
jawerty 2y ago
Most people don’t need to write their own OS or compiler. Knowing the details of how things work is apart of getting to gaining expertise
pvg 2y ago
And I mean nobody. One such project has pretty regular HN chonkthreads, including last week. https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=ladybird&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
- skilled 2y ago
  Yeah that is what I meant. To my knowledge, Andreas is the only person crazy enough to do it and also do it in the open. You have to watch some of his YouTube videos to appreciate the insanity that goes into getting things to work, but he at least has some help from the OSS community: building automated tests, scripts, etc. As I was reading the post I thought he would at least shout him out too!
  - pvg 2y ago
    Ah that's 'statistically nobody' vs 'nobody'.
    - 2y ago

phendrenad2 2y ago

This post starts with a false dichotomy: You're either making a toy browser for fun, or you're trying to make the next Chrome. There are many points in-between on that spectrum. (Look how long Microsoft IE existed, despite being highly inferior.)

IshKebab 2y ago
That's only because it was the "Chrome" (i.e. the dominant browser). Look at what happened when Microsoft eventually tried to catch up with Chrome - they gave up.
- wizzwizz4 2y ago
  > Look at what happened when Microsoft eventually tried to catch up with Chrome - they gave up. That wasn't because they weren't up to the job. It's because Google was using Microsoft's playbook against them. https://news.ycombinator.com/item?id=18697824 https://news.ycombinator.com/item?id=18697824 > I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't keep up. For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail (should now be fixed in Win10 Oct update). Prior to that, our fairly state-of-the-art video acceleration put us well ahead of Chrome on video playback time on battery, but almost the instant they broke things on YouTube, they started advertising Chrome's dominance over Edge on video-watching battery life. What makes it so sad, is that their claimed dominance was not due to ingenious optimization work by Chrome, but due to a failure of YouTube. On the whole, they only made the web slower. (While this may seem like poetic justice, Google's also been doing this against everyone else, so we shouldn't cheer. Also, unlike when Microsoft pulled these stunts, this might not even be deliberate on the part of the Google webdevs.)
  - mkoubaa 2y ago
    I hate that they did it but I have a hard time sympathizing with Edge/MS
  - 2y ago

atum47 2y ago

I honestly think (I've been thinking about that for a few years now) that eventually a OS will be nothing more than a browser.

notsylver 2y ago
Isn't that what ChromeOS is?
fabrice_d 2y ago
that was the idea of FirefoxOS. Come help https://capyloon.org https://capyloon.org if you believe in that!

shiomiru 2y ago

I'm writing one for fun: https://sr.ht/~bptato/chawan/ https://sr.ht/~bptato/chawan/ "Fixed-width text to a grid" makes things easier (sometimes), but I think it still qualifies. On the article itself; it might be better to start with more... basic things than the optimizations it talks about: * Cascading & layout must be cached and optimized - far from trivial. Layout is one of the hardest parts to get right at all, to make it fast as well is another level... and I'm just talking caching, not even multi-threading. * The "web platform" contains a very large amount of poorly thought out features harmful for user privacy and/or security. You can choose between convenience (opt out) and privacy (opt in), or try to balance the two as major browsers do. Both is often impossible. * "Serialize the entire application state" sounds like the most complex thing you can come up with as a distinguishing feature. Much more low hanging fruit exists if you give up on writing a Chromium clone. e.g. a fun side project I've had is making my browser "protocol-agnostic", or adding a bunch small QOL stuff for myself. You can probably find new ideas easily once you start out. * Older browsers are useful for inspiration too. The coolest features in mine are often just carbon copies of the same things from w3m, just a bit more polished. Reading about what historical engines did - even IE! - is often enlightening too. Sometimes it's just a smaller scale of what engines do now, and easier to implement. Other times it's a whole different approach. * It's easy to get lost in the details - careful with perfectionism. As you start getting more components interacting, it will slowly become clear when the naive approach is wrong and how to improve it. Overall, it takes time, but is also fun and rewarding - you will learn a lot, even without replacing Chromium.[0] That said, if you want to learn how "modern" browsers work, getting involved with a "modern" engine itself is probably much more productive. [0]: To write a Chromium replacement, you may have to reincarnate as awesomekling ;)

roca 2y ago
I guess one of my points is that layout algorithms are not really part of the "most basic" decisions anymore. Replacing layout algorithms is actually a lot less disruptive to the engine architecture than switching to site isolation, say.
- shiomiru 2y ago
  Fair; re-reading TFA, now I realize you explicitly instructed me to stop reading in the first paragraph :) Trying to redeem myself with an on-topic question: isn't what you want more of a "refactoring of Blink" than "building a browser engine"? I would be surprised if a complete rewrite was really necessary for the features you want, since "saving state" already happens to some extent in all engines (even if it's just reloading from the cache) and I've seen reports about Gecko integrating multi-core cascade from Servo. What makes it hard to incrementally improve upon the current engines?

djbusby 2y ago

Seems a good place to mention https://sciter.com/ https://sciter.com/ It's been on HN loads of times. A "browser" engine but very narrow scope. Works a treat for LOB type apps.

Buttons840 2y ago
I was sad when the creator tried to raise enough funds to open-source Sciter and there wasn't much interest. If 1% of the people who complain about Electron had pledged something, we would have it as a good alternative today.
- sneak 2y ago
  Open sourcing software to which you hold copyright doesn’t cost anything.
  - lopis 2y ago
    False. This is very naive. If this was true, we wouldn't get the regular posts on HN about OSS drama, and how some people gave up OSS. Opening source up is more than showing us the source.

crazygringo 2y ago

> So You Want To Build A Browser Engine The only correct answer is, "don't". I mean, if you want to build a toy browser engine for a CS class or fun or something, then sure. But the idea that "you want to build an engine that’s competitive with Chromium" is, quite simply, nonsensical. If you want your own browser engine, you're going to fork Chromium or Gecko (Firefox). I mean, even Microsoft gave up on maintaining its own independent engine and switched to Chromium. I literally don't understand who the author thinks this post is supposed to be addressed to. Building an independent browser engine could have made sense in 1998. These days it would cost hundreds of millions of dollars in dev time to catch up to existing engines... just to duplicate something that you already have two open-source versions of?

CoolestBeans 2y ago
Even Chromium started with WebKit which itself was a fork. This doesn't mean you shouldn't be interested in browser dev but you also don't have to do a totally clean sheet implementation.
- crazygringo 2y ago
  But that's exactly my point. This article appears to be entirely about an implementation from scratch. It makes very clear that it is not about forking Chromium. But even Google was smart enough not to start from scratch. So again, I don't know who the intended audience for this article is. It's advice on something no sane person or organization would ever do.
  - roca 2y ago
    And yet a few people are doing it. So yeah, it's advice to insane people.
    - cardiffspaceman 2y ago
      I have succumbed to the temptation to implement various aspects of this. I have also tweaked existing implementations for my day job. I even had the assignment to pitch an implementation to a client. So I am sure that some would question my sanity NOW. TFA suggests that I might not have been sane to start with. I admire any team-of-one that takes on this endeavor and publishes their work.

cbxyp 2y ago

interesting how oldpersonintx's comment "thinly-veiled passive-aggressive swipe at Ladybird" was dead'd here when that accurately reflects the authors comments (as roc-robert o'callahan) here on LWN.net: https://lwn.net/Articles/977625/ https://lwn.net/Articles/977625/

account42 2y ago
Firefox is also competitive with Chrome when it comes to telemetry and other anti-features. Really being competitive with Chrome is not enough because that still doesn't give anyone any reason to use your browser over Chrome. You need to actually provide some end-user benifit that Chrome doesn't (and ideally won't) and that is more important than being competitiv with Chrome on the features Google wants to push. This is where Mozilla really dropped the ball. 15 years of Chrome lighting fire under their ass and zero innovation in the way we browse the web. Well, less than zero when you consider all the useful extension broken by browser changes over the years. Meanwhile Mozilla keeps gaslighting us how they care about privacy while trying numerous ways to integrate ads in the browser. ... yeah I see why someone would rather create a browser from scratch than support Mozilla.

pizlonator 2y ago

I’m not sure that performance needs to constrain web engine design the way it traditionally has. The world has changed since the browser perf war started. Just try disabling the JIT in a modern browser and you’ll find your UX is not really any worse. HW has gotten faster than when the current browser perf wars kicked off. So it might be that to have a meaningfully useful browser engine alternative, perf won’t be the top concern. Compatibility will though, just because of the sheer number of features a modern browser engine supports. And if you don’t have JIT, then it’s not clear if Spectre is even a meaningful concern.

roca 2y ago
Those are interesting points, but disabling the JIT doesn't really change anything unless it means you can forgo site isolation, and that would be a very risky bet. It may be that disabling the JIT is fine for users most of the time. However, that is also a tough call --- so easy for your competitors to beat you up with benchmarks, and there will be real use-cases (e.g. emulators) where it matters to some users. And of course there's a lot more to perf than just the JIT. I barely mentioned JIT in my blog post.
- coldtea 2y ago
  >and there will be real use-cases (e.g. emulators) Those are so niche as a concern, that might as well not take into account at all when doing a new browser engine.
- pizlonator 2y ago
  Yeah but you mentioned Spectre. It’s not clear if you can do a Spectre attack on an interpreter. Maybe you can, but it seems super hard and not practical. And without Spectre, the argument for site isolation is much weaker.

esprehn 2y ago

Engine diversity is really important for the ecosystem and continued innovation. While building something competitive with the big three engines is a monumental task there's still a lot of value in building alternative engines to try new ideas even if getting "the whole web" implemented is basically impossible. For example: - Servo vs Blink vs Cobalt do selector matching and style resolution very differently. - WebKit has a selector JIT, no one else does though. - WebKit and Blink do layout super differently (with LayoutNG shipped). - Firefox's html parser is written in Java and converted to C++ at build time. The big value in folks trying to write new engines is finding these alternate paths. We can't depend on the big three for all the innovation. That's what's great about Ladybird. Sure it'll need a lot of sophisticated sandbox improvements to get us to a big four situation, but it's more likely its value will be in finding another road the other engines didn't travel across the huge universe of specs, content and features.

matheusmoreira 2y ago
Diversity alone is great but not quite enough. The alternative browsers need to actually see significant usage. Otherwise the developers and corporations will go "this browser has 99% market share so I can just ignore the others", giving the dominant browser makers enormous leverage over the others.
weinzierl 2y ago
"- Firefox's html parser is written in Java and converted to C++ at build time." This is surprising. Is it really true in the sense that the code that parses the HTML in a regular Firefox install was autoconverted when it was built?
- reubenmorais 2y ago
  Yep: https://searchfox.org/mozilla-central/source/parser/html/java/README.txt https://searchfox.org/mozilla-central/source/parser/html/jav... And more info: https://about.validator.nu/htmlparser/ https://about.validator.nu/htmlparser/
  - 2y ago

ilrwbwrkhv 2y ago

If you actually want to build one I cannot recommend https://browser.engineering/ https://browser.engineering/ enough.

IncreasePosts 2y ago

[flagged]

9cb14c1ec0 2y ago

How important is process separation if the browser engine is programmed with a memory safe language like Rust? I am under the impression that things like site separation are to bandage memory safety issues. Is that right, or are there other issues at play?

hannob 2y ago
Rust does not give you protection against speculative execution attacks. Entirely different beast than memory safety errors.

bdahz 2y ago

Does anyone have the idea of escaping from HTML/CSS? As these specs are too complicated and not friendly for web developers as well. Maybe we could re-invent a browser engine without conforming to HTML/CSS specs? An (early) alternative spec/engine would be a Figma-compatible vector graphics spec[2] and its rendering engine[3]. It is called VeryGoodGraphics[1]. [1] https://verygoodgraphics.com/ https://verygoodgraphics.com/, the website is built with its own technology (wasm version). [2] https://docs.verygoodgraphics.com/specs/overview https://docs.verygoodgraphics.com/specs/overview [3] https://github.com/verygoodgraphics/vgg_runtime https://github.com/verygoodgraphics/vgg_runtime

promiseofbeans 2y ago
Relevant XKCD: https://xkcd.com/927/ https://xkcd.com/927/
Vermeulen 2y ago
Yeah - there really is a opportunity now to rethink browsers as just sandboxed rendering windows using WebAssembly + WebGPU. Could still have typical DOM rendering handled with Webassembly delivered by the web sites (ideally cached). The challenge is though still having standards and accessibility options. That VeryGoodGraphics example allows for no text selection - and doesn't at all handle zooming. Still though it'd be a good bottom up way for a new browser to disrupt Chrome
- coldpie 2y ago
  How would ad blocking work in this world? A browser without ad blocking is useless.
  - gwbas1c 2y ago
    How would ads work in this world? The advertising ecosystem relies on adding a 1-2 line JavaScript blurb to the page, and then the ads are added at display time.
robin_reala 2y ago

account42 2y ago

> So You Want To Build A Browser Engine > [bunch of things that are only relevant to an application platform] Yeah you really don't need any of this for a web browser to be usable for its intended purpose.

Sohcahtoa82 2y ago
I mean, yeah, you can ignore all that and have a functioning web browser. But it would be riddled with security issues.

bobajeff 2y ago

I've wanted to make my own browser by forking chromium. But then I got confronted with the reality of hacking on a Google scale c++ project. I've tried doing it by embedding webkit which is much more doable but I've found that many sites I use don't work my embedded webkit. So now I think if I want to make my own browser it would be better start making my own versions of those sites first and make sure those are good and popular. At which point I'll just make native clients for them and forget about html/js/css.