6 ms·
Of all projects for Mozilla, the supposed champions of the web, to abandon, it still blows my mind that they chose Servo to be the one to lay off the entire tea
by WD-42 2y ago
Of all projects for Mozilla, the supposed champions of the web, to abandon, it still blows my mind that they chose Servo to be the one to lay off the entire team for.
- torginus 2y agoThis. Especially since it's pretty much supposed to be Rust's flagship project.
- IshKebab 2y agoTo be fair, it wasn't really by the time they abandoned it.
- torginus 2y agoStill, I think Rust was designed for the style and scale of application that a Web Browser is. Foundational, but not kernel level, highly complex, with a wide feature set, performance is important (but not the most important) and high reliability/maintainability and quality is expected. Building these kinds of apps was commonplace in the 90s/early 2000s: photo editing apps, word processors, IDEs, 3D modeling software etc. Maybe RDBMS count as well. In practice Rust is mostly used by web people to gain clout - rewriting microservices, which are usually <10k, but very rarely above 100k LOC, and were originally written in a very slow language, such as Python or Ruby. Had these projects started out in an uncool, but performant language, like Java, there'd have been very little reasonable justification for these Rust rewrites.
- jokethrowaway 2y agoThe main advantage is having a reliable type system and a codebase you can reason about and refactor fearlessly. On the performance side, raw processing power is not that important as you are waiting for io all the time: the main difference is not having GC and GC spikes (if you are working at significant scale) and lower memory usage all around.
- IshKebab 2y ago> In practice Rust is mostly used by web people to gain clout Complete hogwash.
- IshKebab 2y agoI agree. Pretty much the main distinguishing feature of Firefox is that it doesn't use WebKit/Blink. Crazy of them to discontinue working on their own engine's future, especially when it was already yielding results. I'm trying Firefox on Android at the moment and it's noticeably less snappy than Chrome. I wonder if Servo would have changed that.
- soganess 2y agoI am always in bizarro world when I read comments like this. I swear I perceive firefox for android to feel snappier and smoother than chrome. To be clear, I am not trying to claim you are wrong! It is the common wisdom that chrome is faster on android. But I swear, scrolling and page loading just feels faster on firefox. My only guess is the adblocker, but I think firefox is faster than brave, so who knows. I wonder if other have a similar experience and can shed some light on the situation?
- Zardoz84 2y agoUsing uBlock Origin makes wonders. Chrome could be faster, but isn't fast enough to render all the ads shit stuff that are on many webs.
- IshKebab 2y agoI just double checked by closing all tabs, killing the browser and then loading Hacker News. It's about 0.5s on Chrome and 1s on Firefox (roughly). That's a big difference. Firefox is probably faster for ad-heavy sites, but it definitely isn't for sites without obtrusive ads.
- soganess 2y agoThat is the kind of results I would expect! Plus V8 (if that is still the JS engine in chrome) has always been faster. And android is probably the priority target for chrome at this point. But on the occasional times I launch it (chrome), it just feels like it bogus down more often doing basic things. Someone once suggested that, paradoxically, it is slower because I don't use it very often. Something to do with ART and how the AOT compilation work on android
- usrnm 2y agoWhy? They already have their own browser engine, what would they gain by creating another one? It's a browser company, not a Rust promotion company, from this point of view the decision was completely logical.
- bpye 2y agoMany components from Servo (like WebRender) ended up being useful in Firefox. That alone seems like a pretty reasonable motivation to continue?
- usrnm 2y agoNo, it doesn't? It shows that Gecko can be updated and modernised without the need for a complete rewrite.
- ptman 2y agoBut a rewrite may allow for an overall better architecture.
- usrnm 2y agoIs there anything wrong with Gecko architecture? So wrong that it's a major obstacle and cannot be changed? I don't know anything about its internals or browser engines in general, so I can't really comment on that, but what I do know from practice is that a complete rewrite is a very expensive and a very risky project, that will fail more often than not. There should be very serious arguments behind it, something a lot more serious than the age of the codebase or a new and shiny programming language.
- cassepipe 2y agoIt is a very big project and has a big potential for the classic double-free, use-after-free, null-dereferencing, one-off index errors etc. which they designed Rust to get rid of in the first place. I believe they had such a bug some months ago and that it was quite serious.
- Certhas 2y agoHonestly though: Why? Large chunks of the most important servo work is in Firefox now. Nobody else maintains even one web engine. What is the importance for the open web of Moz developing two?
- cabirum 2y agoMozilla could run out of money in the middle of engine rewrite, see also: Netscape[1]. I think they just decided to play safe. [1]: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- peterfirefly 2y ago[flagged]
- LeFantome 2y agoYes, since Firefox IS Netscape, they have some experience with this.
- deleted 2y ago[deleted]
- dralley 2y agoHN: "Mozilla has too many side projects that don't make the browser better" Also HN: "Mozilla should spend more than a decade and tens of millions of dollars on a brand new browser engine that has no hope of replacing Gecko before it reaches 100% compatibility with a spec thousands (tens of thousands?) of lines long, not to mention the kind of "quirks" you see with websites in the wild, while they already lag behind Google with the browser engine they already have." People like cool R&D projects, and that's understandable - I like Servo too. But the fact that it was really cool doesn't compensate for the fact that it was not going to be production-ready any time soon and in that light it's understandable why it was cancelled. While some parts of Servo ended up being so successful that they were merged into Firefox, a lot of what remained only in Servo (and not in Firefox) was nowhere close. The layout component was by far the least mature of any part of Servo at the time (unlike Stylo and WebRender, I mean) and in fact it was going through the early stages of a brand-new rewrite of that component at the time the project was cancelled, partly because the experimental architecture ended up not being very suitable. https://servo.org/blog/2023/04/13/layout-2013-vs-2020/ https://servo.org/blog/2023/04/13/layout-2013-vs-2020/
- demurgos 2y ago> that has no hope of replacing Gecko before it reaches 100% compatibility with a spec thousands (tens of thousands?) of lines long When Servo was still managed by Mozilla, they were able to merge some components incrementally into the Firefox. Most famously, Stylo and WebRender were first developed in Servo. They could have kept Servo for experimentation and merge parts incrementally. It may also have enabled better embedding supporting which is a weak point of Firefox compared to Chrome; which is a long-term solution to remain relevant.
- dralley 2y agoI covered that. Sure, Stylo and WebRender were successful enough that they made it into Firefox, but the Layout component was very much not. Servo was in the middle of a clean-slate rewrite of the layout component because the initial architecture chosen in 2013 wasn't very good. The CSS engine and rendering engine are a lot easier to swap out than the remaining parts. Again, I get why people like Servo, but "in 10 years, maybe we'll be able to take on Electron" isn't that great of a value proposition for a huge R&D project by a company already struggling to remain relevant with their core projects.