As someone who had their first internet connection through NLnet in the 90s (later UUnet I think?), I’m so pleasantly surprised the impact that the organization has for open source projects globally.
The more I actually look at projects I care about the more and more I'm noticing just how extensive their support is. I wish more governments and philanthropists would do like them.
Yes, it's absolutely true. We used to provide internet connectivity and fund open source projects with the profits. Now we fund open source projects as a service and from donations.
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.
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.
I was not aware of this, and now I suddenly understand the weird hate that the project gets from drive-by commenters. (I don’t agree with it, but I can see a plausible motivation.)
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?
> 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.
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.
Their performance is not great comoared to the competition and their market share is at 3.7% and falling. The only thing that keeps me there, is ublock origin. The moment ladybird or a a servo base browser becomes an option I switch.
And if FF also starts to restrict UO, I just go to chrome then. I assume many think like me.
> 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.
Being dependent on a direct competitor is not a comfortable position to be in. It's ameliorated significantly by Chromium being open source, but not completely.
Some non-profits have their HQ in the valley and pay SF salaries when they could just as well have paid a fraction of that to a very competent developer elsewhere.
European safety nets, and government grants have helped open source projects a lot, and this is a big reason almost all of these projects end up being developed/maintained by folks from EU. Even if the sponsorships could hire 2-3x as much man power elsewhere in the world.
Another big thing is govt aligned sponsorships are not for software but for generating jobs/work within their borders.
yeah but the us folks aren't working out of SF and generally these projects have mostly flat pay structures (unsure if that exactly fits but a few comments make it seem like it checks out)
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.
This sounds very cool! If you'd like to talk about your experience with the project on the Servo zulip (servo.zulipchat.com), we love hearing feedback from embedders.
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.
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.
> 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.
That can only happen if we don’t all focus resources on Blink, which is the point. By definition, we can only have other engines if diversity is a thing.
The problem isn’t specifically Google (though they are a problem), but any one individual company having all the power.
>That can only happen if we don’t all focus resources on Blink
Why? What's fundamentally stopping Edge market share from going to 90% that would go away if they switched back to their own browser engine?
>but any one individual company having all the power.
Open source means that anyone can make any change at any time. Google doesn't have all the power over what a fork does. A fork is still in full control.
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
It's easier maintaining a fork of Blink than an entirely different engine. Google being the primary maintainer doesn't mean that browsers can't make large forks.
>work on other browser engines is not duplicated or wasted.
How is having N engine developers implement some new addition to the EMCAScript or CSS standard for each of their engines not duplicated work?
> It's easier maintaining a fork of Blink than an entirely different engine. Google being the primary maintainer doesn't mean that browsers can't make large forks.
Maintaining a fork is not fun as taking patches from the origin repo becomes more complicated the longer the fork exists and the bigger the divergence becomes.
> How is having N engine developers implement some new addition to the EMCAScript or CSS standard for each of their engines not duplicated work?
It would be duplicated only if they all maintained, say, a Blink fork.
It’s not really a finished product yet (in terms of being production-ready), but it would already be usable as an embedded kiosk for applications where you own the pages being accessed.
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.
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.
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.
When the original Phoenix browser was released, Explorer was in the middle of its slumber with the dreadful v6. Phoenix might not have been as feature-full as IE6, but it was very much the superior experience. It made browsers fun again.
not sure what you’re quoting but the last sentence of the post I replied to is:
> 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.
> 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.
IE5 and then IE6 were head-and-shoulders better than Mozilla around the 1999-2002 era. They were significantly faster and lighter, and not just because of the deep OS integration but because Mozilla's browser was actually a full Web suite, with a built-in page editor and a mail client.
Then Microsoft stopped developing IE, and it became essentially frozen.
Mozilla moved ahead with refactoring the browser parts into a lightweight Phoenix (Firebird, Firefox - anyone remembers the FireSomething extension?). But it took _years_ for it to get into a usable state.
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).
At least originally, servo was just an experimental browser with the intention to carve up useful parts and send them back into Firefox. I believe firefox's current css parser came from servo.
Setting aside the fact that using Rust for a JIT won't help that much - a new JS engine is a huge undertaking, especially if the goal is to compete with V8. They could eventually switch to Boa[1] if they wanted more safety, but it's still ways off and doesn't seem necessary enough just yet
Also, isn't the goal of Servo to effectively compete with CEF first and foremost? Because you don't need memory safety for that really
One thing at a time, it looks like implementing a rendering engine from scratch is already enough work for 20 years. First make it work, then make it better.
Yeah I remember Ladybird, and Serenity OS starting as a learning project to teach engineers that a Browser can be made from scratch by a relatively small team. I even remember the author claiming he did it to occupy himself as he was trying to stay sober off drugs. This was all very admirable.
Then somewhere along the way, they decided they wanted to be a real browser for some reason even though we have Chrome, Safari and Mozilla which is open source. This is IMO the worst use of your time as talented engineers, your product is completely undifferentiated and can never be differentiated since it’s a browser. You’re competing against very well funded adversaries, who are giving away everything for free.
Inevitably to compete, you will lean heavily into AI coding, at which point the “learning” goal is completely left at the wayside.
I’d analogize, there are sometimes good reasons to build a game engine, maybe it’s for learning, keeping the skill alive, something unique you want to demonstrate or you just want to reinvent the wheel for your game but using AI, a bajillion tokens to build an Unreal clone is a waste of your time, which is exactly what Ladybirds doing.
> your product is completely undifferentiated and can never be differentiated since it’s a browser.
I disagree with this. Yes, we have Chrome, Safari, and Firefox. And a few spin-offs of those. However, functionally, they are all pretty much the same. They all offer largely the same set of features, have substantially identical UX, and in general try to be everything for everyone.
What's missing is a browser for those of use who aren't "everyone." There is an (admittedly small) market for a browser for the privacy-conscious, the ad- and DRM-averse, the hackers, the power users, and those who are delighted rather than scared to see every possibly tweakable knob and button in their settings menu. Let me change the theme, let me rearrange the UI to my workflow, let me block any damn element/site I choose at the network level. Give me an API to extend and modify the _whole_ browser however I want without needing your corporate permission.
What's missing is the "Linux" of browsers.
(To be clear, I am not suggesting that Ladybird or Servo will fill this gap. It's too early to say one way or the other.)
The browser as an implementation of the standard is not differentiable. But a universal app engine with sandboxing untrusted apps, high performance, and platform neutrality that may or may not retain a DOM or render HTML is very browser-like and under explored.
On the other hand, I don't know if a slightly more customizable browser is something that's really worth building from scratch.
It's not as extensive as what you describe, but in case you happened to be unaware, you can customize the Firefox (and Thunderbird for that matter) UI fairly significantly with userChrome.css: https://support.mozilla.org/en-US/kb/contributors-guide-fire...
> starting as a learning project to teach engineers that a Browser can be made from scratch by a relatively small team. I even remember the author claiming he did it to occupy himself
I'm not even disagreeing with your position (mostly by not having my own), but I find it hilarious how close this reads to Torvald's "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)"
> Then somewhere along the way, they decided they wanted to be a real browser for some reason
I had the impression all along this was the goal. The initial message was "You CAN build a modern browser" which includes JavaScript, modern CSS, WebGL, WASM, WebGPU, etc. The initial article that Ladybird very loudly proclaimed to be antithesis to asserted these are why you can't make a web browser.
Would also be interested to hear why. Personally I used to watch serenityOS and only recently relooked into it to see the main guy was no longer leading it but working on ladybird full time
Myself, my annoyance with Ladybird is that restarted everything from scratch. There are components of servo that are really good and basically complete. Why not use those components and concentrate on the components where you have design conflicts with Servo?
Their origins are in C++, which is what SerenityOS has used. They've never done zig. They explored using Swift as a C++ successor language for the project[1], but seeing the platform support out of Apple was lacking, they gave up and made the bet on Rust[2].
The motivation to use a memory safe language as the alpha approaches sounds more of a longer term bet [3].
They did start with C++. They experimented with Swift, then experimented with Rust, ultimately choosing Rust. I don't see how experimenting with things makes anything "not serious". If you don't question your primitives and just accept them "because that's how it has always been", you're not a very good engineer in my book. In any case, the tech stack is not in constant flux as you claim, it's still C++, with more and more parts moving / being started in Rust, with the eventual probability of Rust replacing C++ organically, I suppose. Seems like pretty sound strategy to me to slowly, but surely, adopt a memory-safe language.
An AI-assisted rewrite can make sense, if you take the time to uphold semantics and code quality, as they suggested. In practice, the first file I looked in had unsound unsafe – in the Rust sense, that a safe caller could cause UB, not that any callers do so – in fact there are no callers, the functionality was removed from the C++ bindings in a 1400-file changeset but left in the associated Rust module.
I'm curious why you care about whether or not they spent time and effort to write those components themselves. Isn't that their choice as the authors? How does it materially affect you or the product experience? From my vantage point, I love the idea of having even more options as it will create competition, making all sides better for it. Having a singular dominant player in any space (whether it's a browser, kernel, or library) is something we should try to avoid whenever possible.
They can obviously do whatever they want, but realistically, having five different engines that are all 70% complete is not helpful. That's not providing more options. Instead, having one that's 99% complete would be providing more options.
If you look at some of the other comments replying to my original comment, you'll get the context that the project started out as a hobby project, purely for fun.
Call me chronically online or whatever, but I've looked at his twitter, and I really don't like his attitude. What specifically grinds my gears is one of tweets where he looks down on programmers who rewrite and program just for the fun of programming.
It's so hypocritical of him, when his entire project started off as just for the fun of programming.
The cherry on top is this was all a part of the whole "agentic shift". I'm fine with someone using AI, and he seemed to use it semi responsibly (at least last I checked), but his hubris and hypocrisy make me not care about the project anymore.
Yeah it's an interesting turn. I remember seeing him talk about how programming for fun was part of essentially his rehab. Seems like it's turned into something different now if he's looking down on others for doing the same.
It's a decision they've made. Perfectly reasonable. If they did accept AI code, that's perfectly reasonable too. They just made their policy clear here..
I would personally whitelist people with good enough reputation/contribution history. Might get the best from both worlds. Avoiding AI spam while saving time for the core contributors. If they just have capability to use it responsibly.
Judging by how many once-respectable expert developers I've seen start churning out high-velocity utter crud¹, I'm not sure that anyone has the capability to use it responsibility. (Except you, of course, dear reader.)
¹: Often correlating with a marked decline in the quality of their technical writing. I don't know which direction the arrow of causality goes, but I have observed LLM use inducing madness under reasonably-controlled circumstances – different phenomenon, similar principle. I suspect the use of AI codegen systems is causing the reduction in discernment ability, rather than a sudden drop in discernment ability causing increased use of AI codegen systems.
It is unfortunate. I guess we also can blame the social pressure. Most want features and don't value quality or durability unless something breaks and is unusable. Competence is often measured with shipping speed, rather than service had zero bugs over its lifetime.
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.
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.
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.
Servo also had some other novel architectural ideas IIRC, not directly related to paralelism, but it's been a while since I was looking into that, I don't remember much.
Will you though? I like the adage: "We used to write software like hardware will get twice as fast every 2 years. Now we should write software like hardware will get twice as expensive every 2 years."
NLnet has been sponsoring large blocks of Servo development as well. Filter with 'servo' in the list here: https://nlnet.nl/project/
As someone who had their first internet connection through NLnet in the 90s (later UUnet I think?), I’m so pleasantly surprised the impact that the organization has for open source projects globally.
The more I actually look at projects I care about the more and more I'm noticing just how extensive their support is. I wish more governments and philanthropists would do like them.
I didn't know about this but of NLnet history. I assumed you had been mistaken so I looked it up. That's really cool!
Yes, it's absolutely true. We used to provide internet connectivity and fund open source projects with the profits. Now we fund open source projects as a service and from donations.
https://nlnet.nl/foundation/history/
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.
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.
I was not aware of this, and now I suddenly understand the weird hate that the project gets from drive-by commenters. (I don’t agree with it, but I can see a plausible motivation.)
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?
> 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.
Samsung has put Enlightenment 17 in front of every Tizen user. I am not seeing the flood of apps implemented on EFL coming out
I think it is actually Mozilla people look at when they ask "why" :-P
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.
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 never had. But yes, mozilla management let FF go down the drain.
Down the drain? Firefox is still a great browser.
Their performance is not great comoared to the competition and their market share is at 3.7% and falling. The only thing that keeps me there, is ublock origin. The moment ladybird or a a servo base browser becomes an option I switch.
And if FF also starts to restrict UO, I just go to chrome then. I assume many think like me.
Firefox is acceptable, but it's definitely not what it used to be. I've long stopped expecting any positive user- visible change in Firefox updates.
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.
sorry, what? servo existing as a mozilla side project did not give it broad adoption
> 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.
I don't really see why they would do that?
Being dependent on a direct competitor is not a comfortable position to be in. It's ameliorated significantly by Chromium being open source, but not completely.
Samsung web browser uses chromium, I doubt they care
Sanctions
Any idea how much this has cost them?
Some non-profits have their HQ in the valley and pay SF salaries when they could just as well have paid a fraction of that to a very competent developer elsewhere.
The hyperlink to the maintainer's name says they are out of rural Ontario. According to the total in https://opencollective.com/servo/expenses?limit=20&searchTer... it comes out to $52,883.97 (USD) in these payments over the last 12 months.
European safety nets, and government grants have helped open source projects a lot, and this is a big reason almost all of these projects end up being developed/maintained by folks from EU. Even if the sponsorships could hire 2-3x as much man power elsewhere in the world.
Another big thing is govt aligned sponsorships are not for software but for generating jobs/work within their borders.
Yes, but SF salaries are still twice German salaries and probaby 4x Eastern Europe salaries.
I think if someone is maintaining open source software, they're already not worrying about making that much money.
yeah but the us folks aren't working out of SF and generally these projects have mostly flat pay structures (unsure if that exactly fits but a few comments make it seem like it checks out)
This is public https://github.com/servo/project/issues/181 and https://github.com/servo/project/issues/187. TL;DR: up to $4800/month (at a rate of $150/h depending on hours actually worked)
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?
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.
This sounds very cool! If you'd like to talk about your experience with the project on the Servo zulip (servo.zulipchat.com), we love hearing feedback from embedders.
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.
Naive question then: Where does Servo stand, relative to Electron?
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/
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...
>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.
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.
Churn makes it impossible to keep up a fork, Google weaponizes its manpower, making the "open source" argument moot.
There are many active forks that are an existence proof that it's possible. It's also a ton of man power to maintain your own browser engine.
Monocultures are bad full stop. Blink is corporate controlled open source, which has been clearly less than.
At this point Microsoft should just open source it for science.
> The best thing for long term browser compatibility is focusing resources into Blink.
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?
> 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.
Whether a new browser uses a brand new engine or not that doesn't stop Chrome being integrated with Android.
The argument was not about stopping Chrome from becoming integrated into Android.
> If a different fork took 90%
That can only happen if we don’t all focus resources on Blink, which is the point. By definition, we can only have other engines if diversity is a thing.
The problem isn’t specifically Google (though they are a problem), but any one individual company having all the power.
>That can only happen if we don’t all focus resources on Blink
Why? What's fundamentally stopping Edge market share from going to 90% that would go away if they switched back to their own browser engine?
>but any one individual company having all the power.
Open source means that anyone can make any change at any time. Google doesn't have all the power over what a fork does. A fork is still in full control.
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.
And you can't do what Google doesn't want you to do. That's a nice ad blocker you have there, shame if we removed support for it.
“The benefit of open source is that anyone can fork and modify the code!”
Yet somehow this argument seems to evaporate since people’s brains short circuit the moment they see the name Google.
The community can always fork and maintain a separate version of Chromium if necessary. Or does this concept only not apply to Chromium?
Brave literally ads an ad blocker into the browser itself. When you fork software you can do whatever you want to it.
Except one does since Google is the primary maintainer. Anyway, work on other browser engines is not duplicated or wasted.
It's easier maintaining a fork of Blink than an entirely different engine. Google being the primary maintainer doesn't mean that browsers can't make large forks.
>work on other browser engines is not duplicated or wasted.
How is having N engine developers implement some new addition to the EMCAScript or CSS standard for each of their engines not duplicated work?
> It's easier maintaining a fork of Blink than an entirely different engine. Google being the primary maintainer doesn't mean that browsers can't make large forks.
Maintaining a fork is not fun as taking patches from the origin repo becomes more complicated the longer the fork exists and the bigger the divergence becomes.
> How is having N engine developers implement some new addition to the EMCAScript or CSS standard for each of their engines not duplicated work?
It would be duplicated only if they all maintained, say, a Blink fork.
servo is incredibly cool. super easy API to embed, and to build browsers around it.
>> What can one actually do with Servo today?
You can run CAD in it: https://solvespace.com/webver.pl
It’s not really a finished product yet (in terms of being production-ready), but it would already be usable as an embedded kiosk for applications where you own the pages being accessed.
The Hurd of browser engines
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 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.
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.
> it was the best open source browser.
Yes that was implied because IE was not mentioned either!
When the original Phoenix browser was released, Explorer was in the middle of its slumber with the dreadful v6. Phoenix might not have been as feature-full as IE6, but it was very much the superior experience. It made browsers fun again.
That’s a quote you seem to have materialized from thin air - op didn’t make this claim.
It’s literally the last sentence?
not sure what you’re quoting but the last sentence of the post I replied to is:
> 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.
Your quote doesn’t appear.
Or you're quoting me which then I don't understand what point you're trying to make.
> 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.
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.
IE5 and then IE6 were head-and-shoulders better than Mozilla around the 1999-2002 era. They were significantly faster and lighter, and not just because of the deep OS integration but because Mozilla's browser was actually a full Web suite, with a built-in page editor and a mail client.
Then Microsoft stopped developing IE, and it became essentially frozen.
Mozilla moved ahead with refactoring the browser parts into a lightweight Phoenix (Firebird, Firefox - anyone remembers the FireSomething extension?). But it took _years_ for it to get into a usable state.
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.
At least originally, servo was just an experimental browser with the intention to carve up useful parts and send them back into Firefox. I believe firefox's current css parser came from servo.
Feels like ladybird is going to Linux Servo
Fashware.
https://git.sr.ht/~rabbits/fashware
That's news! Would be really cool.
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.
Setting aside the fact that using Rust for a JIT won't help that much - a new JS engine is a huge undertaking, especially if the goal is to compete with V8. They could eventually switch to Boa[1] if they wanted more safety, but it's still ways off and doesn't seem necessary enough just yet
Also, isn't the goal of Servo to effectively compete with CEF first and foremost? Because you don't need memory safety for that really
I referenced Boa without linking, so: https://github.com/boa-dev/boa
Why would it help? Rust doesn’t do anything to make generated assembly code safer.
You don't have to have a JIT to have a JS VM ?
But you would want one to get competitive performance.
One thing at a time, it looks like implementing a rendering engine from scratch is already enough work for 20 years. First make it work, then make it better.
there is active work to make the js engine more pluggable https://github.com/servo/servo/issues/40600 (and safety work)
https://servo.org/blog/2024/04/15/spidermonkey/
https://github.com/servo/servo/wiki/Servo-and-SpiderMonkey-R...
the monthly updates always mention their refactoring work on the script crate
They can always reimplement it later.
Focus on core right now, you can change js engines further down the line if need be.
Congrats on the successful year!
I'm glad we have an alternative to ladybird, since I haven't been a fan of the direction of the project for a bit.
Yeah I remember Ladybird, and Serenity OS starting as a learning project to teach engineers that a Browser can be made from scratch by a relatively small team. I even remember the author claiming he did it to occupy himself as he was trying to stay sober off drugs. This was all very admirable.
Then somewhere along the way, they decided they wanted to be a real browser for some reason even though we have Chrome, Safari and Mozilla which is open source. This is IMO the worst use of your time as talented engineers, your product is completely undifferentiated and can never be differentiated since it’s a browser. You’re competing against very well funded adversaries, who are giving away everything for free.
Inevitably to compete, you will lean heavily into AI coding, at which point the “learning” goal is completely left at the wayside.
I’d analogize, there are sometimes good reasons to build a game engine, maybe it’s for learning, keeping the skill alive, something unique you want to demonstrate or you just want to reinvent the wheel for your game but using AI, a bajillion tokens to build an Unreal clone is a waste of your time, which is exactly what Ladybirds doing.
> your product is completely undifferentiated and can never be differentiated since it’s a browser.
I disagree with this. Yes, we have Chrome, Safari, and Firefox. And a few spin-offs of those. However, functionally, they are all pretty much the same. They all offer largely the same set of features, have substantially identical UX, and in general try to be everything for everyone.
What's missing is a browser for those of use who aren't "everyone." There is an (admittedly small) market for a browser for the privacy-conscious, the ad- and DRM-averse, the hackers, the power users, and those who are delighted rather than scared to see every possibly tweakable knob and button in their settings menu. Let me change the theme, let me rearrange the UI to my workflow, let me block any damn element/site I choose at the network level. Give me an API to extend and modify the _whole_ browser however I want without needing your corporate permission.
What's missing is the "Linux" of browsers.
(To be clear, I am not suggesting that Ladybird or Servo will fill this gap. It's too early to say one way or the other.)
The browser as an implementation of the standard is not differentiable. But a universal app engine with sandboxing untrusted apps, high performance, and platform neutrality that may or may not retain a DOM or render HTML is very browser-like and under explored.
On the other hand, I don't know if a slightly more customizable browser is something that's really worth building from scratch.
So a greatly more customizable browser is worth it?
It's not as extensive as what you describe, but in case you happened to be unaware, you can customize the Firefox (and Thunderbird for that matter) UI fairly significantly with userChrome.css: https://support.mozilla.org/en-US/kb/contributors-guide-fire...
> starting as a learning project to teach engineers that a Browser can be made from scratch by a relatively small team. I even remember the author claiming he did it to occupy himself
I'm not even disagreeing with your position (mostly by not having my own), but I find it hilarious how close this reads to Torvald's "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)"
> Then somewhere along the way, they decided they wanted to be a real browser for some reason
I had the impression all along this was the goal. The initial message was "You CAN build a modern browser" which includes JavaScript, modern CSS, WebGL, WASM, WebGPU, etc. The initial article that Ladybird very loudly proclaimed to be antithesis to asserted these are why you can't make a web browser.
Would also be interested to hear why. Personally I used to watch serenityOS and only recently relooked into it to see the main guy was no longer leading it but working on ladybird full time
They announced they are doing an AI assisted rewrite of parts of their code into Rust. That would alienate some.
https://ladybird.org/posts/adopting-rust/
Myself, my annoyance with Ladybird is that restarted everything from scratch. There are components of servo that are really good and basically complete. Why not use those components and concentrate on the components where you have design conflicts with Servo?
Didn't they start with like C++, then zig, and now rust.
To me it's just not serious. They also had articles of "why we are doing zig and not rust".
It's an ambitious project, but I can't take it seriously when the tech stack is in constant flux.
Their origins are in C++, which is what SerenityOS has used. They've never done zig. They explored using Swift as a C++ successor language for the project[1], but seeing the platform support out of Apple was lacking, they gave up and made the bet on Rust[2].
The motivation to use a memory safe language as the alpha approaches sounds more of a longer term bet [3].
[1] https://ladybird.org/newsletter/2024-11-30/#swift-language-a...
[2] https://ladybird.org/posts/adopting-rust/
[3] https://ladybird.org/posts/changing-how-we-develop-ladybird/
They did start with C++. They experimented with Swift, then experimented with Rust, ultimately choosing Rust. I don't see how experimenting with things makes anything "not serious". If you don't question your primitives and just accept them "because that's how it has always been", you're not a very good engineer in my book. In any case, the tech stack is not in constant flux as you claim, it's still C++, with more and more parts moving / being started in Rust, with the eventual probability of Rust replacing C++ organically, I suppose. Seems like pretty sound strategy to me to slowly, but surely, adopt a memory-safe language.
I think they used swift instead of zig because Kling was using mac for development
An AI-assisted rewrite can make sense, if you take the time to uphold semantics and code quality, as they suggested. In practice, the first file I looked in had unsound unsafe – in the Rust sense, that a safe caller could cause UB, not that any callers do so – in fact there are no callers, the functionality was removed from the C++ bindings in a 1400-file changeset but left in the associated Rust module.
I'm curious why you care about whether or not they spent time and effort to write those components themselves. Isn't that their choice as the authors? How does it materially affect you or the product experience? From my vantage point, I love the idea of having even more options as it will create competition, making all sides better for it. Having a singular dominant player in any space (whether it's a browser, kernel, or library) is something we should try to avoid whenever possible.
They can obviously do whatever they want, but realistically, having five different engines that are all 70% complete is not helpful. That's not providing more options. Instead, having one that's 99% complete would be providing more options.
Spreading oneself too thin makes you much less likely to succeed.
What in particular? I've enjoyed watching some of the community update videos and dev videos, but haven't followed the project closely.
If you look at some of the other comments replying to my original comment, you'll get the context that the project started out as a hobby project, purely for fun.
Call me chronically online or whatever, but I've looked at his twitter, and I really don't like his attitude. What specifically grinds my gears is one of tweets where he looks down on programmers who rewrite and program just for the fun of programming.
It's so hypocritical of him, when his entire project started off as just for the fun of programming.
The cherry on top is this was all a part of the whole "agentic shift". I'm fine with someone using AI, and he seemed to use it semi responsibly (at least last I checked), but his hubris and hypocrisy make me not care about the project anymore.
Yeah it's an interesting turn. I remember seeing him talk about how programming for fun was part of essentially his rehab. Seems like it's turned into something different now if he's looking down on others for doing the same.
[flagged]
Can you explain more about that?
[flagged]
Thanks!
[flagged]
[flagged]
There's nothing sad about that. He's entitled to his opinions, as are you.
[flagged]
[flagged]
Non ai post as top post. We did it guys! But seriously, it’s nice to see other news on here. Important we keep covering broader tech things.
[dead]
[flagged]
[flagged]
It's a decision they've made. Perfectly reasonable. If they did accept AI code, that's perfectly reasonable too. They just made their policy clear here..
I would personally whitelist people with good enough reputation/contribution history. Might get the best from both worlds. Avoiding AI spam while saving time for the core contributors. If they just have capability to use it responsibly.
This seems like the direction Zed has taken. Which they even enforce actively: https://github.com/zed-industries/zed/issues?q=label%3A%22no....
Judging by how many once-respectable expert developers I've seen start churning out high-velocity utter crud¹, I'm not sure that anyone has the capability to use it responsibility. (Except you, of course, dear reader.)
¹: Often correlating with a marked decline in the quality of their technical writing. I don't know which direction the arrow of causality goes, but I have observed LLM use inducing madness under reasonably-controlled circumstances – different phenomenon, similar principle. I suspect the use of AI codegen systems is causing the reduction in discernment ability, rather than a sudden drop in discernment ability causing increased use of AI codegen systems.
It is unfortunate. I guess we also can blame the social pressure. Most want features and don't value quality or durability unless something breaks and is unusable. Competence is often measured with shipping speed, rather than service had zero bugs over its lifetime.
In this time and age I don't think it is a reasonable decision, but sure, their right to make that decision.
Exactly. Once lots of vulnerabilities are discovered they would then have to think twice about this policy.
on their what?
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++.
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.
You're underestimating web developers.
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.
Servo also had some other novel architectural ideas IIRC, not directly related to paralelism, but it's been a while since I was looking into that, I don't remember much.
Thanks to the scheduler, you can do both!
I want all my software to use all my cores, because I'll have twice as many within 5 years.
Will you though? I like the adage: "We used to write software like hardware will get twice as fast every 2 years. Now we should write software like hardware will get twice as expensive every 2 years."
that's something you, the user, are free to enforce with priorities, pinning, etc.