7 ms·

+1 Personally I'm more optimistic about Servo - because originating at Mozilla, I imagine more web browser experience and expertise went into its architecture,

+1 Personally I'm more optimistic about Servo - because originating at Mozilla, I imagine more web browser experience and expertise went into its architecture, and also because Rust.

ricardobeat 11mo ago
I don't know.. Servo has been in development for a decade and still has quite underwhelming performance and UX. The binary is 100MB+ on Mac, scrolling is janky, a google image search takes 10+ seconds to render and goes through very buggy states. Meanwhile Ladybird renders a legacy UI, but feels really fast and stable.
- 01HNNWZ0MV43FF 11mo ago
  Seeing Servo and full-fat Electron [1] both at 100 MB made me wonder if that's the minimum for an "Everything bagel" browser engine that does WebRTC, video playback, etc., etc. How big is Ladybird? [1] I believe you can make Electron smaller by cutting parts of Chromium out, but the default is around 100 MB
  - nerdponx 11mo ago
    Is some kind of a browser microkernel possible? Could you ship, say, JS Canvas support in a separate optional module?
    - nicoburns 11mo ago
      A separate module that is configurable at build time would probably be doable. A separate module that is loaded at runtime probably isn't feasible.
    - shiomiru 11mo ago
      I've done something like that in my TUI browser: https://codeberg.org/bptato/chawan/src/commit/3f2fffd882ff472df6b98af62e79c84d3f2d4ad9/src/html/domcanvas.nim#L90 https://codeberg.org/bptato/chawan/src/commit/3f2fffd882ff47... It just spins up a background process when a canvas context is created and sends drawing commands through IPC. As a result, you can rm the 970k canvas binary (most of it is just Unifont) and with some luck you will only break canvas rendering. Of course this only works for things that are relatively self-contained. So you can add/remove image decoders or protocol handlers without recompiling (the main binary has zero networking code), but the JS API is still baked in. (I imagine you could also implement some less performance-sensitive APIs in JS and load the bytecode on demand, but I haven't tried.)
  - nicoburns 11mo ago
    There are ways to slim it down, but WebRTC and video playback would probably be one of the first things I'd remove if I were looking to do that! The other obvious target is the JS engine. IIRC V8 is 90mb just by itself. I don't think SpiderMonkey is quite so large but definitely still in the 10s of megabytes. A slower simpler JS engine (QuickJS, hermes, etc) could be quite a bit smaller.
    - cardanome 11mo ago
      Meanwhile Lua is under 200kb. Imagine if you could use it as a browser language, no more bloat and churn.
      - ricardobeat 11mo ago
        QuickJS is about 200kb as well and has similar performance to Lua, it's not about the language itself. V8 performance is closer to C in some areas.
    - johannes1234321 11mo ago
      That however would limit the browser to small audiences. Many users won't accept movies not playing and many sites require a JavaScript engine with all those optimisations, even SpiderMonkey loses too much in that space. Binary size however is less of an issue for most users.
      - nicoburns 11mo ago
        Yeah, I think these kind of setups don't make much sense for the main "browser application that end-users use" use case. They can make a lot of sense in the Electron "I'm wrapping a browser to use as an app framework" use case though.
  - niutech 11mo ago
    It's not minimum. Custom WebKit builds could weight less, depending on features. Also Sciter is more lightweight.
- Y_Y 11mo ago
  > binary is 100MB+ on Mac If you're worrying about that size then Mac OS is not the platform for you.
  - ricardobeat 11mo ago
    Not sure what your point is? Chrome for example is much smaller on Mac than other platforms. And it's not about absolute size, but compared to Chrome/Electron you'd expect a fresh modern codebase to be somewhat slimmer and faster.
    - deleted 11mo ago
      [deleted]
    - niutech 11mo ago
      Chrome is still bigger than Servo. For a really small size, go for Sciter, Netsurf or Dillo.
- evolve2k 11mo ago
  “Servo is more than a browser engine—it’s a collection of crates used widely across the Rust ecosystem. Maintaining these libraries benefits not just Servo, but the broader web platform.“ Per: https://www.igalia.com/2025/10/09/Igalia,-Servo,-and-the-Sovereign-Tech-Fund.html https://www.igalia.com/2025/10/09/Igalia,-Servo,-and-the-Sov...
- Hemospectrum 11mo ago
  > Servo has been in development for a decade I was curious how you arrived at that figure so I checked the dates. Servo began in 2012 as a Mozilla skunkworks project, died off in 2020, and was revived in late 2023. If you simply subtract the "dead" period, sure, it doesn't look like it was going anywhere fast, but that's ignoring the multiple major changes in direction and the 5+ years during which Servo development was fully subordinate to Firefox development. It only became a fully independent browser development effort after the project was revived by Igalia.
nicoburns 11mo ago
> originating at Mozilla, I imagine more web browser experience and expertise went into its architecture Andreas Kling who created Ladybird had prior experience working on KHTML/WebKit so there is expertise there too.
ionelaipatioaei 11mo ago
I think Ladybird will beat Servo at making an usable and good product, Mozilla might have more resources but that's not the only thing that you need if you want to build great software.
- tracker1 11mo ago
  Agreed. Servo is emphatically not anything resembling a priority at Mozilla and hasn't been for a long while.
  - lawn 11mo ago
    Mozilla gave up on it a while ago. It somehow survived after years with little progress and has relatively recently gathered speed again under new stewardship.
  - zargon 11mo ago
    Servo is not part of Mozilla any more.
- echelon 11mo ago
  Servo's value is that it's written in Rust. Ladybird is C++ and that still has the same issues as every other engine. I suspect Ladybird will/has already leapfrogged Servo in performance and usage due to the Ladybird team and its momentum. Mozilla isn't doing anything with Servo anymore. But I also don't really see a compelling reason for Ladybird's existence - we already have Chromium, Blink, Gecko, etc. It's hard for me to imagine a world where Ladybird is a healthy contender for marketshare. The only real novel thing to do in this space is "rewrite it in Rust".
  - nicoburns 11mo ago
    > The only real novel thing to do in this space is "rewrite it in Rust". Ironically Chromium is now starting to include quite a bit of Rust. And of course Firefox has for some time.
  - deleted 11mo ago
    [deleted]
F3nd0 11mo ago
I’m more hopeful about Servo because it’s released under a copyleft licence, whereas Ladybird chose a pushover one.
- Imustaskforhelp 11mo ago
  Can you elaborate what you mean by pushover license? Ladybird uses bsd-2 license which is OSI, I mean its not fsf/copyleft but permissive which should be better sometimes for things like embedding etc. no? It looks like servo uses mozilla public license 2, can you please explain me the difference and why you think one is pushover and other is not?
  - F3nd0 11mo ago
    ‘Pushover’ is another term for ‘permissive’. It emphasises the fact that, unlike copyleft licences, pushover licences don’t make an attempt to protect the freedoms they grant their users. In other words, they allow anyone to make and distribute derivative works without preserving any of the freedoms which came with the original work. As far as I can see, for an author of derivative work, permissive licences are only really preferable when you either can’t or don’t want to grant or preserve the freedoms which a copyleft licence would require you to grant and preserve. (Which, to be fair, may often be the case.) From a different point of view, copyleft can be seen as better for embedding, since it means that Free Software in question will only be used to make more Free Software. The MPL is a copyleft licence, but it’s known as a ‘weak copyleft’ licence. That means it preserves only the freedom of the program it initially covers; any changes made directly to that program can only be distributed as Free Software, but the program itself may be used and distributed as part of a larger work, which as a whole does not have to be Free. (This is in contrast to ‘strong copyleft’ licences like the GPL, which require the entire larger work to be Free.) Weak copyleft is a kind of compromise which lets you e.g. embed a piece of software without having to grant all your users freedom to use, share and modify your entire work, but you're still required to grant them those freedoms in regard to the piece you’re embedding.

+1 Personally I'm more optimistic about Servo - because originating at Mozilla, I imagine more web browser experience and expertise went into its architecture, and also because Rust.

ricardobeat 11mo ago

I don't know.. Servo has been in development for a decade and still has quite underwhelming performance and UX. The binary is 100MB+ on Mac, scrolling is janky, a google image search takes 10+ seconds to render and goes through very buggy states. Meanwhile Ladybird renders a legacy UI, but feels really fast and stable.

01HNNWZ0MV43FF 11mo ago
Seeing Servo and full-fat Electron [1] both at 100 MB made me wonder if that's the minimum for an "Everything bagel" browser engine that does WebRTC, video playback, etc., etc. How big is Ladybird? [1] I believe you can make Electron smaller by cutting parts of Chromium out, but the default is around 100 MB
- nerdponx 11mo ago
  Is some kind of a browser microkernel possible? Could you ship, say, JS Canvas support in a separate optional module?
  - nicoburns 11mo ago
    A separate module that is configurable at build time would probably be doable. A separate module that is loaded at runtime probably isn't feasible.
  - shiomiru 11mo ago
    I've done something like that in my TUI browser: https://codeberg.org/bptato/chawan/src/commit/3f2fffd882ff472df6b98af62e79c84d3f2d4ad9/src/html/domcanvas.nim#L90 https://codeberg.org/bptato/chawan/src/commit/3f2fffd882ff47... It just spins up a background process when a canvas context is created and sends drawing commands through IPC. As a result, you can rm the 970k canvas binary (most of it is just Unifont) and with some luck you will only break canvas rendering. Of course this only works for things that are relatively self-contained. So you can add/remove image decoders or protocol handlers without recompiling (the main binary has zero networking code), but the JS API is still baked in. (I imagine you could also implement some less performance-sensitive APIs in JS and load the bytecode on demand, but I haven't tried.)
- nicoburns 11mo ago
  There are ways to slim it down, but WebRTC and video playback would probably be one of the first things I'd remove if I were looking to do that! The other obvious target is the JS engine. IIRC V8 is 90mb just by itself. I don't think SpiderMonkey is quite so large but definitely still in the 10s of megabytes. A slower simpler JS engine (QuickJS, hermes, etc) could be quite a bit smaller.
  - cardanome 11mo ago
    Meanwhile Lua is under 200kb. Imagine if you could use it as a browser language, no more bloat and churn.
    - ricardobeat 11mo ago
      QuickJS is about 200kb as well and has similar performance to Lua, it's not about the language itself. V8 performance is closer to C in some areas.
  - johannes1234321 11mo ago
    That however would limit the browser to small audiences. Many users won't accept movies not playing and many sites require a JavaScript engine with all those optimisations, even SpiderMonkey loses too much in that space. Binary size however is less of an issue for most users.
    - nicoburns 11mo ago
      Yeah, I think these kind of setups don't make much sense for the main "browser application that end-users use" use case. They can make a lot of sense in the Electron "I'm wrapping a browser to use as an app framework" use case though.
- niutech 11mo ago
  It's not minimum. Custom WebKit builds could weight less, depending on features. Also Sciter is more lightweight.
Y_Y 11mo ago
> binary is 100MB+ on Mac If you're worrying about that size then Mac OS is not the platform for you.
- ricardobeat 11mo ago
  Not sure what your point is? Chrome for example is much smaller on Mac than other platforms. And it's not about absolute size, but compared to Chrome/Electron you'd expect a fresh modern codebase to be somewhat slimmer and faster.
  - deleted 11mo ago
    [deleted]
  - niutech 11mo ago
    Chrome is still bigger than Servo. For a really small size, go for Sciter, Netsurf or Dillo.
evolve2k 11mo ago
“Servo is more than a browser engine—it’s a collection of crates used widely across the Rust ecosystem. Maintaining these libraries benefits not just Servo, but the broader web platform.“ Per: https://www.igalia.com/2025/10/09/Igalia,-Servo,-and-the-Sovereign-Tech-Fund.html https://www.igalia.com/2025/10/09/Igalia,-Servo,-and-the-Sov...
Hemospectrum 11mo ago
> Servo has been in development for a decade I was curious how you arrived at that figure so I checked the dates. Servo began in 2012 as a Mozilla skunkworks project, died off in 2020, and was revived in late 2023. If you simply subtract the "dead" period, sure, it doesn't look like it was going anywhere fast, but that's ignoring the multiple major changes in direction and the 5+ years during which Servo development was fully subordinate to Firefox development. It only became a fully independent browser development effort after the project was revived by Igalia.

nicoburns 11mo ago

> originating at Mozilla, I imagine more web browser experience and expertise went into its architecture Andreas Kling who created Ladybird had prior experience working on KHTML/WebKit so there is expertise there too.

ionelaipatioaei 11mo ago

I think Ladybird will beat Servo at making an usable and good product, Mozilla might have more resources but that's not the only thing that you need if you want to build great software.

tracker1 11mo ago
Agreed. Servo is emphatically not anything resembling a priority at Mozilla and hasn't been for a long while.
- lawn 11mo ago
  Mozilla gave up on it a while ago. It somehow survived after years with little progress and has relatively recently gathered speed again under new stewardship.
- zargon 11mo ago
  Servo is not part of Mozilla any more.
echelon 11mo ago
Servo's value is that it's written in Rust. Ladybird is C++ and that still has the same issues as every other engine. I suspect Ladybird will/has already leapfrogged Servo in performance and usage due to the Ladybird team and its momentum. Mozilla isn't doing anything with Servo anymore. But I also don't really see a compelling reason for Ladybird's existence - we already have Chromium, Blink, Gecko, etc. It's hard for me to imagine a world where Ladybird is a healthy contender for marketshare. The only real novel thing to do in this space is "rewrite it in Rust".
- nicoburns 11mo ago
  > The only real novel thing to do in this space is "rewrite it in Rust". Ironically Chromium is now starting to include quite a bit of Rust. And of course Firefox has for some time.
- deleted 11mo ago
  [deleted]

F3nd0 11mo ago

I’m more hopeful about Servo because it’s released under a copyleft licence, whereas Ladybird chose a pushover one.

Imustaskforhelp 11mo ago
Can you elaborate what you mean by pushover license? Ladybird uses bsd-2 license which is OSI, I mean its not fsf/copyleft but permissive which should be better sometimes for things like embedding etc. no? It looks like servo uses mozilla public license 2, can you please explain me the difference and why you think one is pushover and other is not?
- F3nd0 11mo ago
  ‘Pushover’ is another term for ‘permissive’. It emphasises the fact that, unlike copyleft licences, pushover licences don’t make an attempt to protect the freedoms they grant their users. In other words, they allow anyone to make and distribute derivative works without preserving any of the freedoms which came with the original work. As far as I can see, for an author of derivative work, permissive licences are only really preferable when you either can’t or don’t want to grant or preserve the freedoms which a copyleft licence would require you to grant and preserve. (Which, to be fair, may often be the case.) From a different point of view, copyleft can be seen as better for embedding, since it means that Free Software in question will only be used to make more Free Software. The MPL is a copyleft licence, but it’s known as a ‘weak copyleft’ licence. That means it preserves only the freedom of the program it initially covers; any changes made directly to that program can only be distributed as Free Software, but the program itself may be used and distributed as part of a larger work, which as a whole does not have to be Free. (This is in contrast to ‘strong copyleft’ licences like the GPL, which require the entire larger work to be Free.) Weak copyleft is a kind of compromise which lets you e.g. embed a piece of software without having to grant all your users freedom to use, share and modify your entire work, but you're still required to grant them those freedoms in regard to the piece you’re embedding.