Can't believe Mozilla wasn't interested in it
The fact that mozilla wasn’t interested in that really tells a lot about their priorities
Can't believe Mozilla wasn't interested in it
The fact that mozilla wasn’t interested in that really tells a lot about their priorities
They fired everyone working on it and completely abandoned it while giving the CEO a million dollar pay raise the same year.
When are we going to talk about how openly corrupt Mozilla has become? They clearly have issues at the top that need to be fixed for the betterment of web.
When are we going to talk about how openly corrupt Mozilla has become?
It's routinely discussed on HN, whenever a topic about Mozilla/browsers comes up. The real question in my opinion is what can we do about it? Start an awareness campaign? Stop using Firefox? Stop donating to Mozilla?
Stop using Firefox?
And use what? A Chromium reskin and give up the web to Google?
Mozilla has (many) problems, but it remains the main organisation fighting for the open web.
I'd argue that the EFF is the main organization fighting for the open web.
The EFF is great and important too, but I feel like developing a competitive browser has more direct impact.
I agree, but that's a very generous description of what Mozilla is doing. I'd say they're less "developing a competitive browser" and more "keeping an uncompetitive browser on life support to continue to profit off it".
Mozilla has (many) problems, but it remains the main organisation fighting for the open web.
Well, it’s adifferentorganisation from MS and Google anyway. I’m not sure how much I’d say they’re fighting for an open web, so much as I’d say they’re fighting for their slice of it. But the end result is more or less the same.
There is not much we can do ourselves, they are hurting themselves more than we can hurt them.
We don't want to punish the corrupt, we want to save Firefox from them. If would be great if some organization could fork Firefox and work with Servo to make a usable browser, but that's going to be really expensive, and the new browser will have to make a name for itself. Also the organization will have to do better than Mozilla in terms of corruption, which, again, is not a given when a lot of money is involved.
While very frustrating, it's just not reasonable at all to call that fraud or corruption. To make that case, you'll need to also make the argument that the CEO's remuneration is unreasonable to the given market rate; and more specifically, that you might be able to hire somebody else and achieve similar results for meaningfully less cash,andthe CEO and board know this,andthey're overcompensating intentionally.
Now: I agree that the pay is absurd! I'm quite willing to believe she's not worth it, too. But she's hardly the first CEO to have ridiculous pay; nor am I convinced the board is overcompensating her for corrupt reasons - it may simply be a difference of perspective. And - perhaps I'm wrong, and this pay is a going market rate and a hypothetical cheaper replacement would do worse - I really don't believe that, but to call something corruption I'd need to be rather sure of that and of their knowledge of it.
Or they (Firefox folks) learned what happens when you (Netscape) try a major greenfield rewrite (Netscape v5) so ambitious that it becomes the example of why one should never rewrite.
And instead just back ported the lessons learned to make Firefox/Gecko better years earlier than a rewrite could.
That's why Servo exists in the first place. That's exactly the reason why always has been intended as a research engine, with an explicit focus on high modularity, and easy portability of single components, several of which were then incorporated into Firefox.
Especially the latter wasn't some kind of salvage, trying to squeeze value out of some theoretical project.It was an explicit goal from the beginning.
Facts don't matter, this is one of those QAnon things were people collectively fan-fiction an apocalyptic battle for them to be on the right side of based on nothing more than a vague dislike of women and minorities.
That they got a ton of valuable code and lessons which improved Firefox a lot? Seems like the investment into Servo paid off really well.
Except Mozilla did it twice IIRC.
And it really doesn’t matter whst conventional wisdom holds, when the architecture of a project is based on flawed assumptions, or things just changed since it was architected.
It has to be majorly refactored, period.
I was really disappointed to see Mozilla drop Servo and I think it was the wrong decision for them to make, but seeing this take mere hours after seeing people in a thread about Android Firefox bashing Mozilla for prioritizing a rewrite of their mobile browser is certainly some whiplash.
And to a certain extent, I get it, I also think Servo was a more valuable project than Fenec. But let's not pretend that there's an obvious correct answer to "should Mozilla rewrite its browsers from scratch?"
Again, I say this as someone who wanted Mozilla to stick with Servo. It was a bad decision for them to drop it, I think there was a lot more value that could have been extracted from the project. But if Mozilla had stuck with Servo, I guarantee there would be people on HN right now saying, "why are they rewriting their browser engine, the current one works fine, why aren't they doing X? Shows a lot about their priorities. This is the problem with Mozilla, they're too focused on theory and engineering projects instead of just shipping a good browser." There's no winning.
I think there was a lot more value that could have been extracted from the project
What exactly? They extracted the 2 pieces that worked better than the existing gecko stack (Stylo and WebRender). I'm a big fan (and small contributor) to Servo, but it's far behind on anything else (layout, networking, security, web api support...).
On a small level, I think that some of the areas it's behind on (security, layout) might have eventually turned out to be improvements. Stylo and WebRender were behind Firefox when they first began development as well, they were experiments to see if Rust could enable differing patterns. I personally think those experiments would have been useful to try and replicate for layout at the very least, although I don't know for sure if they would have yielded fruit.
On a bigger level, I think having a more easily embeddedable Firefox could change the dynamics around V8 and Chromium could end up being pretty important for the health of the web overall, including the health of Firefox.
There's an argument to be made here that none of that potential is gone because, hey, Servo is still being developed. But I think it could have gone faster with Mozilla's support behind it for longer, I think they would have served as an effective advertising/hype engine behind the technology. I think the dominance of Chromium for embedded applications does influence how developers approach the web in some minor ways.
On a really out-there level, I would like to see HTML-like interfaces proliferate in more apps, and Servo in particular has a very modular approach that could make it more feasible to bring in the DOM without bringing in languages like Javascript (yes, manipulation and events and all that stuff would need to be accessible without JS, but... it's certainly easier than it would be with Chromium, Stylo already makes some interesting applications possible). If I had to pick a company to push that effort that I didn't thing would horribly mess it up, Mozilla would be high on my list. And I vaguely maybe suspect that pulling more browser technologies out of the web could open up more technical fields and niches for Mozilla to get its hands into. Right now what that area mostly looks like is Electron or embedded Chromium. At most you have embedded JS engines like V8.
I'm hoping that there's some potential to do more interesting things, and I think it could have been valuable to Mozilla and it could have increased developer investment/mindshare if Mozilla was a bigger player in those areas.
But that's just my instinct, maybe I'm wrong.
Possibly memory safe (possibly. Helix, for example, recently had a build that was crashing due to memory safety problems) doesn’t explicitly mean “great security”.
Not even memory safe.
It has many "unsafe" and "transmut", and this is without the bazillion external dependencies it also depends on.
I mean they currently have 12 unsafes and 4 transmutes (who knows how many in dependencies). I wouldn't say it'smanywhen the code base is clocking at around 53k of Rust. Compared to languages such as C/C++/Zig, which provide no safety at all, it's still an improvement to at least know where to look when address sanitizer is screaming at you (see the bug I linked to in the sibling comment).
Both zig and modern C++ have safety that is generally good and catches swathes of issues.
I’ve been writing zig for a couple months now and have only once accidentally leaked in a test, and haven’t once accidentally messed up a buffer.
Not saying you can’t, because zig definitely has escape hatches, but idiomatic zig has proven quite easy to stay safe without even thinking about it.
No. Neither is as pedantic as rust, but zig has been a joy to work in compared to either C++ or Rust in my opinion.
I agree that there's a lot to like about Zig (the module system and error management are the two I mainly consider superior to Rust's approach for example) but I wouldn't say it's easy to stay safe without thinking about it. Quite the contrary actually.
Rust sometimes forces you to add annotations which certainly can get unwieldy at times (I think this in particular trips a lot people because sometimes they knowwhatthey want to tell the compiler but don't knowhowto express it in Rust speak and thus anger ensues). Zig, on the other hand, doesn't require any of that and makes code look simple and arguably more pleasant in comparison, but it doesn't mean the "contract" between objects goes away. It's just not expressed in code and checked by the compiler but rather by the person writing the code.
Take [0] for example. The compiler (at least in the current stage, it's at 0.11 after all) is perfectly happy with code which returns a pointer to a stack allocated memory from a function. The fix is torememberthat you need to pass the argument via pointer and not let the compiler decide for you. But what if the programmer forgets or somebody else is working on the code?
Are you talking about this? Interesting read and caused by one of the unsafe+transmute the sibling comment is talking about.
It was recent. I just updated to Sonoma and then after recompiling everything, helix was crashing whenever I switched modes due to reading past the buffer.
Sorry I can’t be any more help on specifics than that. I am WAY beyond fiddling with my tools when they give me trouble. I just moved back to neovim.
if you don't have time to look into it then you shouldn't just blindly spout incorrect information, just saying.
I'm very excited about Servo. Can't believe Mozilla wasn't interested in it.
This doesn’t feel like an accurate statement. It’s probably better described that Mozilla funded it as a research project, realized that it was going to cost a lot more money and time to bring it fully to the market and decided to save the money (and distributed that money to execs and others in ways that were not inline with their projected morals).
Based on what I’ve read from their blog posts, Mozilla then took what they could from Servo and incorporated it into Firefox, which means they were able to get some value from the project.
My guess is that if someone were to have offered Mozilla a lot of money and an unlimited timeline to complete Servo, they would have done it.
If you offered me a lot of money and unlimited timeline I'd have done it as well, and I don't know what Servo is.
Servo is an experimental web engine written in Rust, originally by Mozilla.
I'm pretty sure this was a sarcasm.
I think the joke is that he'd do pretty much anything if given a lot of money and infinite time.
My guess is that if someone were to have offered Mozilla a lot of money and an unlimited timeline to complete Servo, they would have done it.
My understanding is that they tried to do that with VR (turn Servo into the first VR-capable browser and work on browser-technology-based AR overlays) and even had a partnership with Magic Leap at one point, it just never really went anywhere.
Ah, yeah, I forgot about that. Seemed like a good tactic to get it onto some production use case more quickly.
Can't believe Mozilla wasn't interested in it.
It is because it doesn't make money. An expensive research project (Servo) that was not worth the effort for Mozilla.
Mozilla needs to find better ways of making money and not depending on Googles' money.
Now thanks to the US v Google anti-trust trial, Mozilla doesn't know if they should support Google for keeping them alive for their hundreds of millions of dollars or being going against them for Google to be broken up for more competition.
Either way Google's search AND browser monopoly is held together by paying its competitors such as Apple (for Safari) and Mozilla (for Firefox).
That sounds like an amazing failure of imagination to me. I see at least 3 excellent angles.
1. Chrome beat Firefox in the stability/security area. Its usage of multiple processes, sandboxing, etc is excellent, while Firefox failed to adapt. Servo seems to have an excellent potential for coming up on top there, being both more secure, and having higher performance.
2. There are actually markets interested in security. Think say, banking, military, industry, IOT. There are various laws coming requiring companies to take security seriously. Servo has a lot of potential there too. There's potential for both projects that have security as a selling point, and regulatory compliance.
3. Embedding. Like I said, using a web engine as a component seems to have been forgotten in modern times. Surely that can be sold to somebody, because there are plenty use cases for embedding web engines in stuff.
3. Embedding. Like I said, using a web engine as a component seems to have been forgotten in modern times. Surely that can be sold to somebody, because there are plenty use cases for embedding web engines in stuff.
It's not forgotten. Microsoft has WebView2 which uses the same engine as MS Edge and it can be included in your .net applications.
If OTOH you want an ActiveX then you can buy AntView, which wraps WebView2 in an ActiveX control.
Disclaimer: AntView is a control sold by my company.
While this is great brainstorming, that doesn't mean it's a viable business plan. Having a large highly qualified dev-team working on experimental stuff for now over a decade and no likelihood of completion anytime soon and without a business plan is pretty tricky, even for a non-profit.
In general, for research of that type (of scale) it doesn't strike me as generally very viable to rely on commercial support, and such a niche technicality is surely not going to collect enough donations to run on that alone. If we want to fund this because it's an interesting option for the future in the long term, governments are going to need to chip in - and it looks like that's at least partly at play here (or even primarily), i.e.: system working as designed.
1. Chrome beat Firefox in the stability/security area. Its usage of multiple processes, sandboxing, etc is excellent, while Firefox failed to adapt. Servo seems to have an excellent potential for coming up on top there, being both more secure, and having higher performance.
Theydidadapt, and the HN types got mad at them for breaking the old-style extensions, which were effectively incompatible with multiple processes, sandboxing, performance, etc. And were totally incompatible with Servo at a fundamental level.
2. There are actually markets interested in security. Think say, banking, military, industry, IOT.
Those industries areinfamousfor doing things like having applications that only support IE9 in Windows XP. Security may matter to them in theory but in practice it is clearly far lower on the priority list than stability and supporting one golden path. Getting them to adopt something novel and experimental for use cases they want to be thoroughly boring and unchanging for 15 years is never ever going to happen.
As someone that compiled and ran Servo and submitted a couple of patches, it had a long way to go (years of development) before it would have been production ready in its entirety.
Now thanks to the US v Google anti-trust trial, Mozilla doesn't know if they should support Google for keeping them alive for their hundreds of millions of dollars or being going against them for Google to be broken up for more competition.
Why would they not publicly support Google when Google are the ones keeping Mozilla alive? I'm all for journalistic integrity, but I don't think Mozilla could pullthatone off.
It seems I'm utterly and entirely misled to believe that Servo is the engine behind Mozilla since... FF52 (it was, right)? Can some please explain what is it that Mozilla uses then to render pages, and which parts did Mozilla rewrite in FF? Did some parts of Servo made it into FF, and is FF contributing back to Servo?
sorry, too many questions perhaps.
Firefox uses and has always used Gecko as its engine. Some parts that originated from Servo got transplanted into Firefox over the last few years, but overall it's still Gecko.
thank for clarification.
I kinda feel betrayed using FF, always thought its a predominantly Rust-based project with improved security etc. it'd be great to have the Servo engine taken in its entirety and plugged into FF, but I guess this is not on the roadmap, reading all these comments here.
Even if it was on the roadmap, it would still be many years until that would be possible.
They transplanted some components, most namely Stylo. But Servo in its entirety is far from complete.
WebKit is still very embedding-friendly, though building it on Windows is messy. Works great under macOS and Linux though.
We absolutely need more embeddable web engines though. Gecko is nice but it being permanently joined at the hip with XULRunner is killing it.
I get your point but xul specifically is gonehttps://docs.google.com/document/u/0/d/1ORqed8SW_7fPnPdjfz42...
Gecko is nice but it being permanently joined at the hip with XULRunner is killing it.
XULRunner's last release was off of the 41 branch, 8 years ago. It's dead.
Mozilla was interested in Servo. What do you mean? They extracted multiple components into Gecko including WebRender and Stylo.
Don't you know the rule? The top comment of any Mozilla-adjacent discussion needs to contains at least 70% of misinformed garbage dunking on Mozilla. /s
I also love the idea of a web engine as a component. This for some reason seems to have disappeared in modern times.
I have used CEF, WebKit, and WebView2. Only the former is easily embeddable cross platform, and as soon as it became popular, Google put a lot of resources into disallowing Google login from it or any other embedded browser[0]. I had to abandon my own CEF-based browser because of this. While I abhor the business practice, there's nothing I can do. If my browser can't login to Google products, it can't see much adoption and I don't have the time to try and win a cat-and-mouse game against their detection methods.
If we want embedded browser components to be more mainstream where anyone can develop a browser, we're going to first have to address that large companies block them if they get too popular but the embedding company is not popular. Ideally an embeddable non-Android Gecko would come about because FF is too big to block (lots of talk in the past, and I even PoC'd stealing the window handle[1]). But there's no money in it.
0 -https://developers.googleblog.com/2016/08/modernizing-oauth-...
There's a difference between a browser and an embedded webview. The latter shouldn't be logging into anything important at it's ripe for abuse - and basically training people to be phished by any app they install.
I admit the two categories are hazy, but it's an important distinction.
Oh, that ACtiveX comment brought so many memories! I remember that when the desktop background failed, an ActiveX error page was shown (on the desktop) with clickable links. That was so consufing...
See also Ladybird for another from-scratch browser being built by a more ragtag indie group.https://ladybird.dev/
The chaddest of the chad projects honestly.
Why do we need another browser engine written in C++?
Can you explain why people shouldn't pursue passion projects because they are written in a language you don't like?
Not the parent, but my own opinion is that if a C/C++ passion project becomes successful, it burdens other people with yet another source of security vulnerabilities.
This is even more so for small projects that didn't have the decades of security hardening of Firefox/Chrome behind them, and now people go to these projects assuming their security is on par with Firefox/Chrome.
Why is your imaginary burden more important than someone's passion?
I find Rust people to be really annoying these days if you can't even write software in the language you want to write without being a burden to society.
Building an browser engine from scratch is a great exercise for validating both the specifications and the web platform tests.
For example, here's some bugs raised by Andreas Kling in the HTML spec that were found while building Ladybird:
https://github.com/whatwg/html/issues?q=is%3Aissue+author%3A...
I have more hope in Ladybird than Servo, TBH. Considering how young it is, Ladybird is already very impressive.
Even just to take screenshots, Servo's renderer is very basic, slow and buggy.
I don't see Ladybird ever being seriously useful. Already serious browser projects like Brave, Arc, and Orion struggle to keep me off of Firefox.
Servo is honestly doing the correct thing by focusing on embed-ability into other projects, something that has been basically dominated by Chrome alone
Hm... is Ladybird more feature complete than Servo at this point?
I have more optimism for Ladybird as well. For me, That’s not a knock on Servo and mostly because it was started as a research project, which suggests you’re focusing more on experimentation than producing a product.
Is ladybird actually usable outside of serenity os?
There are many ports. GTK, Qt, and Cocoa are the 3 that I am aware of.
Ladybird is amazing.
They move so fast and are building all of it in the open. I'm very impressed by what the Ladybird team is doing.
It's cool to see the work on Servo since Igalia picked it up. There was a lot of tech debt to work through due to years of minimal maintenance, but they seem to have been making real progress.
My personal hope is they push hard on the modularity angle. Seems to me that:
1) there's probably a niche to be filled by an OSS browser engine focussed on embedability
and
2) That it could be a huge boon for the long-term health of the web platform if there are build-your-own-browser "lego building block" libraries that people can mix and match to create new engines.
1) there's probably a niche to be filled by an OSS browser engine focussed on embedability
Absolutely. Electron or something Electron-like with Servo embedded could be a nice outcome. Tauri already fills that niche a bit, but uses whatever the OS provides, rather than embedding anything. Would be nice with something in-between that.
Tauri is actually adding experimental Servo support.
Oh wow, I wasn't aware of this! So proper embedded cross-platform engine into the final binary? That'd be awesome.
Yep, embedding the Servo engine into the final binary. This work is sponsored by another (separate) NLnet grant:
An embedded engine is also a much faster path to viable use cases. For example Sciter [1] has some degree of success despite implementing only a sane subset of the DOM API. It doesn't work well for general internet surfing, but when used as an UI library you just avoid the parts that don't work.
My personal hope is they push hard on the modularity angle
It is strongly designed that way (the component model and the embed layer).
Wild speculation: With iphones being forced to open their web engine there might be some apps interested in embedding their own engines across mobile devices.
Somehow I thought that Servo was already incorporated into Firefox.
Is there a way to render some HTML in Rust into an image, without loading a whole browser? It doesn't have to support a lot of HTML or CSS.
The closest thing currently is probablyhttps://github.com/trimental/inlynewhich differs in two ways: it only support markdown not arbitrary HTML, and it renders to screen rather to an image. But it's a good start.
IMO the main blocker for web rendering in Rust right now is better text layout, and in particular support for embedding non-text content within text ala `display: inline-block`. If/when that is implemented I think we'll be able to do a decent job of rendering basic web pages.
The CSS style system (stylo) started out in Servo and is now in Firefox but as I understand it they've diverged quite a bit.
https://blog.nightly.mozilla.org/2017/07/25/stylo-is-ready-f...
WebRender and Stylo come from Servo and have been integrated as Quantum Render and Quantum CSS. An maybe some other things as well?
Not the entire engine but WebRender (GPU-based compositor) and Stylo (CSS engine) are in Firefox for a few years now.
What's this "Legacy Layout" they're using as a comparison? The previous iteration of Servo? Looks like some of the code is still used by both, as the curves sometimes (but not always) go up and down at the same time...
Legacy Layout refers to the original system, Layout 2013. There was a second system started, Layout 2020, to address challenges with implementing parts of the CSS spec which didn't cleanly map to Layout 2013's architecture.
There's a good report in the Servo wiki from this year (authored by a group of Igalians) summarizing the differences between the two and why the decision was made to move forward with Layout 2020.
https://github.com/servo/servo/wiki/Servo-Layout-Engines-Rep...
That is great news for Servo! NLNet Foundation has been funding a lot of great projects lately. I see their name pop up a lot.
Yes, my projecthttps://www.oilshell.org/has been funded by NLnet since 2022, and it's helped a lot. I needed some help to push through a few problems, and that happened :)
It is very forward thinking since we happen to be mostly in North America, but the funding comes from the EU.
The money for this grant actually comes, in part, from the European Commission (via the NGI programme).
Servo is a web rendering engine written in Rust, with WebGL and WebGPU support, and adaptable to desktop, mobile, and embedded applications.
It is embeddable, independent, memory-safe, modularand parallel web rendering engine.
I'm very excited about Servo. Can't believe Mozilla wasn't interested in it.
Not only the idea of an engine with great security and performance is an excellent one, but I also love the idea of a web engine as a component. This for some reason seems to have disappeared in modern times.
IE used to have an ActiveX control back in the Windows 9x days. You could embed a web engine anywhere you wanted. KHTML also worked like that. And in modern times... nothing. Neither Firefox nor Chrome seem to have interest in that kind of usage. Qt WebEngine thankfully exists, but in my understanding has a bit of an antagonistic relationship with Chrome, because Chrome doesn't care for that kind of use.
Plus Chrome is a Google thing, and Google things in my experience are their own world, making them annoying to build and integrate.
So I'm very much looking forward to having a viable alternative to integrate into our code. Both solving security concerns and hopefully making the integration less painful.