Top
Best
New

Posted by ffin 9 hours ago

Servo is now available on crates.io(servo.org)
338 points | 115 commentspage 2
grimgrin 6 hours ago|
when servo is ready i have plans to swap it into qutebrowser which ive been growing fonder of
Talderigi 7 hours ago||
Is Servo production-ready enough to replace or embed alongside engines like WebKit or Blink?
bastawhiz 7 hours ago||
It depends on your use case. I wouldn't use it for a JS-heavy site. But if you have simple static content, it's probably enough. It's worth testing it out as a standalone app before integrating it as a library.
mayama 5 hours ago||
It doesn't crash as often as it used to few years ago. JS heavy sites might not work, and layout issues too. And internet gatekeepers cloudflare turnstile doesn't work.
andriy_koval 3 hours ago||
why did it crash? Rust is supposed to be memory safe?..
nablaxcroissant 2 hours ago||
crashes happen for reasons besides memory safety. web-engines are crazy complicated pieces of software and crashes could happen for any number of reasons. also I would be shocked if this was written using purely safe rust
z3ratul163071 5 hours ago||
we've come full circle. they've invented rust to do servo with it.
hybirdss 5 hours ago||
feels like we're actually getting new browser engines this decade and it's kind of strange
t43562 4 hours ago|
Servo has been on-the-go for a while though. It hasn't been a lightning speed development, it's just getting a bit more visible.
tusharkhatri369 5 hours ago||
Sounds great, would use the crate from now on. its more convenient that way
phplovesong 7 hours ago||
Did firefox drop servo? I recalled they where in the progress of "rewrite in rust"?
dralley 7 hours ago||
Firefox incorporated parts of the Servo effort which were able to reach maturity. Stylo (Firefox's current CSS engine) and Webrender (the rendering engine) and a few other small components came from the Servo project.

Most other parts of Servo were not mature enough to integrate at the time Mozilla decided to end support for the project and didn't look like they would be mature enough any time soon. The DOM engine for example was in the early stages of being completely rewritten at the time because the original version had an architecture that made supporting the entire breadth of web standards challenging.

Keep in mind that you can continue adding Rust to Firefox without replacing whole components. It's not like Mozilla abandoned the idea of using more Rust in Firefox just because they stopped trying to rewrite whole components from the ground up.

andruby 7 hours ago|||
Yes, during the layoff of August 2020

Mozilla laid off the full Servo team, but never publicly announced this afaik. Wikipedia includes it here: https://en.wikipedia.org/wiki/Firefox#cite_ref-120

Sammi 6 hours ago||
Mozilla can't help it but be their own worst enemy. Ladybird may well never have happened if Mozilla just had kept working on Servo, and Ladybird is most definitely going to out compete Firefox when it reaches maturity, as Mozilla keeps on burning bridges with open source enthusiasts.
zarzavat 6 hours ago||
The problem with Mozilla is not just technical but cultural. The organization has been infected with managers. The managers want to keep their jobs more than they want Firefox to succeed. Clearly the solution is for the managers to fire themselves and allow the developers to run the show, but that was not going to happen.

Ladybird, by contrast, is a developer-lead open source project that has no such constraints. They also don't have a product yet but I'm sure the picture will be radically different in a few years.

Conway's law in action.

estebank 5 hours ago|||
To add to the other replies, Firefox was explicitly never going to consume all of Servo. It was always meant to be a test bed project where sub-projects could be migrated to Firefox. I suspect that the long term intent might have been for Servo to get to a point where it could become Firefox, but that wasn't the stated plan.
alarmingfox 7 hours ago||
I think they implemented parts of it into their Gecko engine. But they laid of all the Servo development team in like 2020 I believe.

Only recently when it moved over to the Linux Foundation has Servo started being worked on again

9fwfj9r 7 hours ago||
It's a great move. The early development of Rust aimed to support Servo. However, it's still disappointing that the script engine uses SpiderMonkey, which is purely C++.
drzaiusx11 7 hours ago||
It's best not to try and eat the elephant in one bite, which is perhaps where this project went wrong initially. Maybe this is a symptom of learning from past mistakes rather than a flaw.
saghm 7 hours ago||
My understanding is that the original intent of Servo was to be a way to develop features and port them over to Firefox itself (which did happen with at least a few features), and the relatively slower pace of developer is more due to Mozilla laying off everyone who was working on it. (Yes, presumably many of the same people are involved, but I would expect that being able to work on something full time without needing another source of income will end up making progress faster than needing to find time outside of work and balance between other things in life, ideally in a way that avoids burnout).
drzaiusx11 6 hours ago||
My understanding was that from day one the desire was to make a complete "web rendering & layout engine" and only pivoted to shipping smaller sub-components like Stylo (stylesheets) when it appeared to be "taking too long." I followed the project from the early days through the layoffs, but I may be misremembering things.
saghm 4 hours ago||
Interesting, it's certainly possible I was never aware of the super early days.
swiftcoder 7 hours ago|||
There are what, 5+ rust javascript engines that claim to be production-ready? Bolting one of those on in place of spider monkey seems like a reasonable future direction
mort96 6 hours ago|||
What do you mean by "production ready" here exactly? In a web browser context, the JS engine is expected to have a high performance optimising JIT compiler. Do the existing Rust JS engines have that?
8NNTt8z3QvLT8tp 6 hours ago|||
There's something to be said for the security benefits of not having a JIT though. Especially if you've used Rust for the engine you should have pretty solid security.
px43 5 hours ago||
Yeah, having a code section that is writable and executable is a huge no-no from a security standpoint. JIT is a fundamentally insecure concept, just in general. By definition it's trading security for speed.
epcoa 2 hours ago||
lol
swiftcoder 6 hours ago|||
I honestly don't know, but they do say "production ready" on their marketing pages, so...

For an example of what I mean, see JetCrab: https://jetcrab.com

CryZe 6 hours ago|||
This doesn't implement a JS engine, it's just a wrapper around boa.
mort96 6 hours ago|||
That page says:

> Complete JavaScript execution pipeline from source code parsing to bytecode execution.

So it's a bytecode interpreter, not a JIT.

It might still be production ready for a bunch of use cases. I may use it as a scripting layer for some pluggable piece of software or a game. I wouldn't consider it appropriate for a "production ready web browser" which intends to compete with Firefox and Chrome.

EDIT: Also for some reason all its components are called v8_something? That's pretty off putting, you can't just take another project's name like that.. and from the author's Reddit comments it seems to be mostly AI slop anyway. I'm guessing Claude wrote the "production ready" part on the website, I wouldn't trust it.

nicoburns 5 hours ago||||
They're all more than 10x slower than SpiderMonkey.
depr 6 hours ago|||
They may be production-ready in some sense but they're not ready to be put in Firefox, and/or they are v8 bindings.
tialaramex 7 hours ago||
I mean SpiderMonkey works, and presumably is fairly self-contained, so I can see why replacing that isn't attractive unless you believe you can make it significantly better in some way.
diath 7 hours ago|
Too little too late now that the new meta is to use system provided webviews so you don't have to ship a big ass web renderer per app.
bastawhiz 7 hours ago||
System web views were available as drag and drop components in VB6 two and a half decades ago. There's nothing "new" about that as a concept, and plenty of reasons to not want to use Blink/WebKit.
diath 7 hours ago||
> System web views were available as drag and drop components in VB6 two and a half decades ago. There's nothing "new" about that as a concept

We are in a thread discussing a Rust library, logically, I was referring to the current approach in GUI rendering in the Rust space (such as Tauri and Dioxus).

> and plenty of reasons to not want to use Blink/WebKit.

Such as? Can you name a few objective reasons against Blink/WebKit (the technology) that does not involve just not liking Google/Apple?

bastawhiz 3 hours ago|||
> the current approach in GUI rendering in the Rust space (such as Tauri and Dioxus).

Tauri itself doesn't render web views. It uses wry under the hood. Dioxus isn't a web view at all and deserves a fundamentally different purpose.

> Can you name a few objective reasons against Blink/WebKit (the technology) that does not involve just not liking Google/Apple?

If you have a cross platform application, it sucks having to worry about which features work or don't work based on which engine is available and how old it is. You also don't know if there are user scripts being injected that are affecting the experience. It's impossible to debug and many users don't even know what browser engine is being used, they just know your app doesn't work.

If you build for Servo, it works exactly the same on every platform. You could use wry and test that Edge is good on Windows, WebKit works on the past few versions of Macos, gtk WebKit works, etc etc, or you can just use Servo.

Not to mention, Servo is probably much lighter than whatever flavor of chromium the user has installed under the hood.

airstrike 7 hours ago|||
Tauri/Dioxus aren't necessarily the end state of Rust GUI
swiftcoder 7 hours ago|||
No particular reason Servo couldn't one day become the system web view on Linux distros...
chrismorgan 6 hours ago|||
Linux (GNU/Linux or whatever) doesn’t even have the concept of a system web view. The closest you might get to the notion is probably WebKitGTK which is perhaps the GNOME idea of a system web view, but it’s nothing like WebKit on macOS or WebView2 (or MSHTML in the past) on Windows for popularity or availability.

As a user of a desktop environment other than gnome-shell, I only have webkitgtk-6.0 installed because I chose to install Epiphany—it’s a good proxy for testing on Safari, which Apple makes ridiculously expensive.

mort96 6 hours ago|||
Yeah the closest thing you come today is arguably WebKitGTK, which is known for being not exactly great.
charcircuit 5 hours ago||
That is not the meta. The meta is to ship blink so you only have to support a single version of a single web engine in stead of many versions of many different web engines.