Regardless of actual use as an (embedded) browser, it is useful in the sense that it can be used to provide (another) source of validation about whether specs and WPT [1] tests are properly and clearly defined. That helps for long term browser compatibility.
Making a new browser engine hurts browser compatibility more than it helps it. It now becomes one more target that needs to be tested against, limitations need to be kept tracked of, etc. The best thing for long term browser compatibility is focusing resources into Blink. In regards to the standard we can use LLMs to cross reference the spec, with tests, and with the implementation to make sure all match.
One could argue that effectively Blink is also not open source. At any rate users don't have power over it, as witnessed by the manifest v3 stuff jammed down our throats.
yeah in a perfect world google dictates how the standard will evolve, we kill all competition so we're sure that you have only one target to build your software against, I'm sure a monopoly will greatly improves innovation and not be used to stiffen competition. /s
The best thing for long term browser compatibility is focusing resources into Blink.
That’s what makes Google more dominant, and if you think that’s a good idea you should really put down your LLM and go read up on a bit of history. Do you want to live in a world where a single company controls your access to the web? Are you eager to navigate through ad pages with a little bit of web? To have even more of your data mined?
Browser diversity may be a bit annoying for developers, but it is good for users, and developers are users too. When there’s a lack of diversity, everyone but the dominant player is squeezed.
Google's dominance comes from market share not from owning upstream. If a different fork took 90% market share that fork would have the dominance and power.
And that market share is maintained by integration with Android and low-key sabotage of others browsers, especially Firefox. Similar to how Microsoft maintained its monopoly decades ago.
Servo doesn't implement the whole web platform, but your own desktop app isn't the whole web. You can generally work around any limitations or missing features. And it might be lighter than CEF or whatever.
Couldn't agree more. Looking at [1], it seems to me like Servo has a much better adoption story than Ladybird. The latter seems to be just building a browser that's going to be crashy and not really work on the web. The former is addressing problem spaces where, even with the limitations of the half-finished state it's in, it can be usefully applied: WebView/Electron-replacement and headless browsers. Things not currently on this list that could/should be: HTML rendering for desktop E-Mail clients. Also, I wonder to what extent they're implementing paged media and capable of targetting PDF output or similar (like weasyprint). That could be another domain, where you don't need full web-scale abilities.
And yet, somehow, Ladybird seems to be the darling of the masses (in certain circles at least). Doing vibe-ports to Rust, while going closed-contribution also, in my mind, sits in a marked contrast to the origin story that initially generated so much goodwill.
I use servo to render e-ink UIs and screenshot them to push to the displays. About 10% of the memory usage and 5% of the render time as doing the same thing with headless chrome. It doesn’t handle every possible feature, but it handles enough that it’s never been an issue when it’s my only target rendering environment. I love it.
Was this recent? Because Firefox were the browser that worked better than all the rest, for quite many years, maybe 2005-2010, and Firefox had no competition basically until Chrome arrived on the scene.
Just the fact that Firefox got browser tabs before anyone else, and Firebug, just took it to another level compared to all the other browsers available at the time.
Firefox was bad on linux for a long time. Even running the windows ff build via wine/proton got you better performance than the "native" build (I think that was around 10 years ago).
Hardware accelerated video decoding (for video playback or for WebRTC) is available via VA-API for both X11 and Wayland. Since firefox-101.0.1-4 package it's enabled by default for Intel/AMD users.
Google still tries to sabotage Firefox experience on Google Apps, especially Meet but also YouTube and sometimes Google Sheets/Docs as well.
They want to degrade the experience just enough to get you fed up with FF and go (back) to Chrome, without making it absolutely obvious that's what they're doing.
They often label these things as "regressions" because they don't test on Firefox and take forever to fix them. But I can't help but believe it's intentional.
Yes, exactly. Google products working worse on Firefox is a problem with Google, not Firefox. I'm not sure why the conflict of interest isn't more obvious.
Your history is off. Opera was the first mainstream browser to implement tabs and boy was Opera also much faster than Firefox at its peak (both UI, resource usage, and rendering) which overlaps that “peak” Firefox period by a lot.
Firefox was great because it was open source but it wasn’t ever really the “best” browser - it was the best open source browser.
They are clearly progressing now as a project and the world definitely needs what they are building - it's literally something you can download and run right now.
Rust was started in 2006 (20 years ago) and is now one of the most powerful programming languages, while the Servo project was started in 2012. If they reach parity and beyond of current browsers this could clearly become one of the most important browser engines in the future. Effort very well spent in my opinion.
I really wish a patron would step up and sponsor this project. Not just by money, but also by plugging it in their browser-carrying products. Maybe Hauwei of Samgsung; they now sling a browser derived of another for-profit --usually competitor-- company's browser.
So right now Servo is funded by the community, and this is no good because why? Instead you propose that this project should be funded by a for-profit company with it's own objectives in this world (that often starts with "more money"), again leading me to ask why?
The setup right now seems to give enough people enough time to work on it to move forward, why on earth would you want to involve companies infamous for their shit software quality, like Samsung?
Probably because broad adoption would help making it a real option to use in the near future?
So sure, Samsung would bundle it with their usual crap, but if it helps making the engine more mature, great, but I also don't see why they would in the first place.
In fairness, while there was definitely Mozilla mismanagement, there was also a massive monopolistic marketing/bundling campaign by Chrome. Google search and other properties pushed Chrome, Google paid application publishers to bundle Chrome the way they bundled adware, and so on.
So right now Servo is funded by the community, and this is no good because why?
Because look at Mozilla... You need to get the browser in front of people. A browser that works on the real web, is such a huge project, you cannot do it as a hobby community-funded project for ever. You need user-share-%.
Samsung can put it in front of Samsung appliance users.
Instead you propose that this project should be funded by a for-profit company with it's own objectives in this world (that often starts with "more money"), again leading me to ask why?
You understand that Mozilla Firefox is not funded by the "community" and is completely funded by Google's money. Even donating does not fund the browser.
Mozilla knows that the open source "community" has no money, and cannot replace the amount of money Google is paying them and the employees who work on the browser.
The question is are you ready to fill the $600M a year black hole for Google to NOT pay Mozilla to fund Firefox?
It only makes sense for Servo to get funding from for-profit companies at this point, which is one of the only ways open source can work.
It came about because US sanctions on Huawei mean that they are unable to make contributions to any of the major browser engines which are all controlled by US entities.
Hot take... There is something about programming projects spending 10x (or 1000x) the effort to parallelize execution when everything is still restricted by von Neumann architecture.
Just that - even if you distribute work to a number of cores (that itself limited), you still need to sync the execution. So unless you have some bigger chunks of computation, the performance increase will be very small.
And yes, there are bigger chunks of work when rendering a web page, but that is typically already outside the css engine and can be distributed without having to rewrite the core engine.
But my comments are a bit generic here, so I am open to comments regarding this particular project.
It's more efficient to use all the cores briefly and go back to whatever background task than have long running mixed load. This also matches performance expectations, you generally want the web page displayed _now_ and the compile to finish ASAP while accepting it will take _some_ time.
What can one actually do with Servo today?
It’s apparently still not ready to be used as a browser engine (and may never be), so what exactly is it for?
Regardless of actual use as an (embedded) browser, it is useful in the sense that it can be used to provide (another) source of validation about whether specs and WPT [1] tests are properly and clearly defined. That helps for long term browser compatibility.
[1] https://wpt.fyi/results/?label=experimental&label=master&pro...
Making a new browser engine hurts browser compatibility more than it helps it. It now becomes one more target that needs to be tested against, limitations need to be kept tracked of, etc. The best thing for long term browser compatibility is focusing resources into Blink. In regards to the standard we can use LLMs to cross reference the spec, with tests, and with the implementation to make sure all match.
Ah, you must be too young to have experienced early Internet Explorer, which attempted just this.
Internet Explorer was not open source acting as engine everyone's browser could use and it got abandoned by Microsoft. It is not the same situation.
One could argue that effectively Blink is also not open source. At any rate users don't have power over it, as witnessed by the manifest v3 stuff jammed down our throats.
Monocultures are bad full stop. Blink is corporate controlled open source, which has been clearly less than.
yeah in a perfect world google dictates how the standard will evolve, we kill all competition so we're sure that you have only one target to build your software against, I'm sure a monopoly will greatly improves innovation and not be used to stiffen competition. /s
Using Blink doesn't mean you have to defer all decisions to Google. You just benefit from not having to duplicate work.
Except one does since Google is the primary maintainer. Anyway, work on other browser engines is not duplicated or wasted.
That’s what makes Google more dominant, and if you think that’s a good idea you should really put down your LLM and go read up on a bit of history. Do you want to live in a world where a single company controls your access to the web? Are you eager to navigate through ad pages with a little bit of web? To have even more of your data mined?
Browser diversity may be a bit annoying for developers, but it is good for users, and developers are users too. When there’s a lack of diversity, everyone but the dominant player is squeezed.
Google's dominance comes from market share not from owning upstream. If a different fork took 90% market share that fork would have the dominance and power.
And that market share is maintained by integration with Android and low-key sabotage of others browsers, especially Firefox. Similar to how Microsoft maintained its monopoly decades ago.
Lol, for Blink perhaps, what about the rest of the ecosystem, the web and the users, like the ones who don't even use Blink?
Very idealistic point-of-view with no basis in reality, sadly, because wouldn't it be nice if we could care about just one engine?
https://v2.tauri.app/blog/tauri-verso-integration/
https://github.com/versotile-org/tauri-runtime-verso
Servo doesn't implement the whole web platform, but your own desktop app isn't the whole web. You can generally work around any limitations or missing features. And it might be lighter than CEF or whatever.
Couldn't agree more. Looking at [1], it seems to me like Servo has a much better adoption story than Ladybird. The latter seems to be just building a browser that's going to be crashy and not really work on the web. The former is addressing problem spaces where, even with the limitations of the half-finished state it's in, it can be usefully applied: WebView/Electron-replacement and headless browsers. Things not currently on this list that could/should be: HTML rendering for desktop E-Mail clients. Also, I wonder to what extent they're implementing paged media and capable of targetting PDF output or similar (like weasyprint). That could be another domain, where you don't need full web-scale abilities.
And yet, somehow, Ladybird seems to be the darling of the masses (in certain circles at least). Doing vibe-ports to Rust, while going closed-contribution also, in my mind, sits in a marked contrast to the origin story that initially generated so much goodwill.
[1] https://servo.org/made-with/
servo is incredibly cool. super easy API to embed, and to build browsers around it.
I use servo to render e-ink UIs and screenshot them to push to the displays. About 10% of the memory usage and 5% of the render time as doing the same thing with headless chrome. It doesn’t handle every possible feature, but it handles enough that it’s never been an issue when it’s my only target rendering environment. I love it.
The Hurd of browser engines
Feels like ladybird is going to Linux Servo
That's news! Would be really cool.
I remember waiting on the Mozilla project to deliver something that could browse as well on linux as closed source browsers on windows/mac did.
It... took... long...
But there it was. And it still works.
Was this recent? Because Firefox were the browser that worked better than all the rest, for quite many years, maybe 2005-2010, and Firefox had no competition basically until Chrome arrived on the scene.
Just the fact that Firefox got browser tabs before anyone else, and Firebug, just took it to another level compared to all the other browsers available at the time.
Firefox was bad on linux for a long time. Even running the windows ff build via wine/proton got you better performance than the "native" build (I think that was around 10 years ago).
Much longer than 10 years! I’ve been on Linux since 2008 an it was never a problem.
From https://fedoraproject.org/wiki/Firefox_Hardware_acceleration
I think that was around 2022-23.
I remember this affecting my laptop video watching a lot. Google meet feeling sluggish on Firefox is also something I remember until very recently..
Google still tries to sabotage Firefox experience on Google Apps, especially Meet but also YouTube and sometimes Google Sheets/Docs as well.
They want to degrade the experience just enough to get you fed up with FF and go (back) to Chrome, without making it absolutely obvious that's what they're doing.
They often label these things as "regressions" because they don't test on Firefox and take forever to fix them. But I can't help but believe it's intentional.
Yes, exactly. Google products working worse on Firefox is a problem with Google, not Firefox. I'm not sure why the conflict of interest isn't more obvious.
Your history is off. Opera was the first mainstream browser to implement tabs and boy was Opera also much faster than Firefox at its peak (both UI, resource usage, and rendering) which overlaps that “peak” Firefox period by a lot.
Firefox was great because it was open source but it wasn’t ever really the “best” browser - it was the best open source browser.
Yes that was implied because IE was not mentioned either!
They are clearly progressing now as a project and the world definitely needs what they are building - it's literally something you can download and run right now.
Rust was started in 2006 (20 years ago) and is now one of the most powerful programming languages, while the Servo project was started in 2012. If they reach parity and beyond of current browsers this could clearly become one of the most important browser engines in the future. Effort very well spent in my opinion.
I really wish a patron would step up and sponsor this project. Not just by money, but also by plugging it in their browser-carrying products. Maybe Hauwei of Samgsung; they now sling a browser derived of another for-profit --usually competitor-- company's browser.
I don't really see why they would do that?
Sanctions
So right now Servo is funded by the community, and this is no good because why? Instead you propose that this project should be funded by a for-profit company with it's own objectives in this world (that often starts with "more money"), again leading me to ask why?
The setup right now seems to give enough people enough time to work on it to move forward, why on earth would you want to involve companies infamous for their shit software quality, like Samsung?
Probably because broad adoption would help making it a real option to use in the near future?
So sure, Samsung would bundle it with their usual crap, but if it helps making the engine more mature, great, but I also don't see why they would in the first place.
It had broad adoption, Mozilla threw it away.
The same would occur again.
Servo never had. But yes, mozilla management let FF go down the drain.
In fairness, while there was definitely Mozilla mismanagement, there was also a massive monopolistic marketing/bundling campaign by Chrome. Google search and other properties pushed Chrome, Google paid application publishers to bundle Chrome the way they bundled adware, and so on.
Servo was not intended to replace Gecko. By all reports it was an experimental component, many of whose findings were used in Gecko.
That folks want to take it further is admirable. But doubtful Mozilla could have afforded to with their existing commitments.
Because look at Mozilla... You need to get the browser in front of people. A browser that works on the real web, is such a huge project, you cannot do it as a hobby community-funded project for ever. You need user-share-%.
Samsung can put it in front of Samsung appliance users.
Samsung has put Enlightenment 17 in front of every Tizen user. I am not seeing the flood of apps implemented on EFL coming out
You understand that Mozilla Firefox is not funded by the "community" and is completely funded by Google's money. Even donating does not fund the browser.
Mozilla knows that the open source "community" has no money, and cannot replace the amount of money Google is paying them and the employees who work on the browser.
The question is are you ready to fill the $600M a year black hole for Google to NOT pay Mozilla to fund Firefox?
It only makes sense for Servo to get funding from for-profit companies at this point, which is one of the only ways open source can work.
Huawei are funding Servo. They have a small full time team on it and are the main reason the project got revived in 2022.
That’s interesting, anyone have more info on how why this came about? The why is pretty clear at least.
It came about because US sanctions on Huawei mean that they are unable to make contributions to any of the major browser engines which are all controlled by US entities.
Hot take... There is something about programming projects spending 10x (or 1000x) the effort to parallelize execution when everything is still restricted by von Neumann architecture.
This. I don't want your browser engine to use all my cores. I want the rest of my cores to be compiling C++.
Thanks to the scheduler, you can do both!
that's something you, the user, are free to enforce with priorities, pinning, etc.
It is not really about reserving cores.
Just that - even if you distribute work to a number of cores (that itself limited), you still need to sync the execution. So unless you have some bigger chunks of computation, the performance increase will be very small.
And yes, there are bigger chunks of work when rendering a web page, but that is typically already outside the css engine and can be distributed without having to rewrite the core engine.
But my comments are a bit generic here, so I am open to comments regarding this particular project.
I want all my software to use all my cores, because I'll have twice as many within 5 years.
It's more efficient to use all the cores briefly and go back to whatever background task than have long running mixed load. This also matches performance expectations, you generally want the web page displayed _now_ and the compile to finish ASAP while accepting it will take _some_ time.
Assuming it is "briefly" and not indefinitely. See: cloudflare, excessive js, etc.
Congrats on the successful year!
NLnet has been sponsoring large blocks of Servo development as well. Filter with 'servo' in the list here: https://nlnet.nl/project/
Servo uses mozjs which is just rust bindings for SpiderMonkey which is still C++.
All this effort to use rust and yet they would not rewrite the JS engine which is the biggest attack surface for memory vulns.
Why would it help? Rust doesn’t do anything to make generated assembly code safer.