- The docs.rs docs are still building, but the docs from the recent RC are available [0]
- The Slint project have an example of embedding Servo into Slint [1] which is good example of how to use the embedding API, and should be relatively easy to adapt to any other GUI framework which renders using wgpu.
- Stylo [2] and WebRender [3] have both also been published to crates.io, and can be useful standalone (Stylo has actually been getting monthly releases for ~year but we never really publicised that).
- Ongoing releases on a monthly cadance are planned
Tangent, but Slint is a really cool project. Not being able to dynamically insert widgets from code was the only thing that turned me off of it for my use case.
> As you can see from the version number, this release is not a 1.0 release. In fact, we still haven’t finished discussing what 1.0 means for Servo
Wait, crate versions go up to 1.0?
EDIT: Sorry, while crate stability may be an interesting conversation, this isn't the place for it. But I can't delete this comment. Please downvote it. Mods feel free to delete or demote it.
The fundamental problem with Rust versioning is that 0.3.5 is compatible with 0.3.6, but not 0.4.0 or 1.0.0; when major version is 0, the minor takes the role of major and patch takes the role of minor. So packages iterate through 0.x versions, and eventually, they reach a version that's "stable".
If version 0.7 turned out to hit the right API and not require backward incompatible changes, releasing a version 1.0 would be as disruptive as a major version change to your users and communicate through version semantics that it is a breaking change.
Semver declares that version 0.x is for initial development where there is no stability guarantee at all. This is the right semantics for a versioning system, but Cargo doesn't follow this part of semver. Providing stability guarantees throughout the 0.x cycle inevitably results in projects getting stuck in 0.x.
This is one of my biggest gripes with Cargo. But Rust people seem to universally consider it a non-issue so I don't think it'll ever be fixed.
> The fundamental problem with Rust versioning is that 0.3.5 is compatible with 0.3.6, but not 0.4.0 or 1.0.0
That’s a feature of semver, not a bug :)
You are right to notice that minor versions within a major release can introduce new APIs and changes but generally, not expected to break functionality until the next major release. However, this rule only applies to libraries after they reach 1.0.0. Before 1.0.0, one shouldn’t expect any APIs to be frozen really.
Personally, I think the 0 major version is a bad idea. I hear the desire to not want to have to make guarantees about stability in the early stages of development and you don't want people depending on it. But hiding that behind "v0.x" doesn't change the fact that you are releasing versions and people are depending on it.
If you didn't want people to depend on your package (hence the word "dependency") then why release it? If your public interface changes, bump that major version number. What are you afraid of? People taking your project seriously?
Is there a table of implemented RFCs? Something similar to http://caniuse.com where we can see what HTML/JS/CSS standards and features are implemented? If it exists, I can't seem to find it. Closest thing seems to be "experimental features" page but its not quite detailed enough.
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.
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.
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.
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++.
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.
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).
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.
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
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?
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.
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.
> 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?
Linux (GNU/Linux or whatever) doesn’t even have the concept of a system web view. In some environments you have some comparatively popular choice, like WebKitGTK, but it’s nothing like WebKit on macOS or WebView2 (or MSHTML in the past) on Windows.
On my system (Arch, Sway), I do have webkitgtk-6.0 installed, but only because I manually installed epiphany (now called “GNOME Web”) because I wanted a decent proxy for testing Apple’s expensive browser (I have found webcompat-style Safari issues to be consistently reproducible in Epiphany).
Some notes:
- The docs.rs docs are still building, but the docs from the recent RC are available [0]
- The Slint project have an example of embedding Servo into Slint [1] which is good example of how to use the embedding API, and should be relatively easy to adapt to any other GUI framework which renders using wgpu.
- Stylo [2] and WebRender [3] have both also been published to crates.io, and can be useful standalone (Stylo has actually been getting monthly releases for ~year but we never really publicised that).
- Ongoing releases on a monthly cadance are planned
[0]: https://docs.rs/servo/0.1.0-rc2/servo
[1]: https://github.com/slint-ui/slint/tree/master/examples/servo
[2]: https://docs.rs/stylo
[3]: https://docs.rs/webrender
Tangent, but Slint is a really cool project. Not being able to dynamically insert widgets from code was the only thing that turned me off of it for my use case.
> As you can see from the version number, this release is not a 1.0 release. In fact, we still haven’t finished discussing what 1.0 means for Servo
Wait, crate versions go up to 1.0?
EDIT: Sorry, while crate stability may be an interesting conversation, this isn't the place for it. But I can't delete this comment. Please downvote it. Mods feel free to delete or demote it.
The fundamental problem with Rust versioning is that 0.3.5 is compatible with 0.3.6, but not 0.4.0 or 1.0.0; when major version is 0, the minor takes the role of major and patch takes the role of minor. So packages iterate through 0.x versions, and eventually, they reach a version that's "stable".
If version 0.7 turned out to hit the right API and not require backward incompatible changes, releasing a version 1.0 would be as disruptive as a major version change to your users and communicate through version semantics that it is a breaking change.
Semver declares that version 0.x is for initial development where there is no stability guarantee at all. This is the right semantics for a versioning system, but Cargo doesn't follow this part of semver. Providing stability guarantees throughout the 0.x cycle inevitably results in projects getting stuck in 0.x.
This is one of my biggest gripes with Cargo. But Rust people seem to universally consider it a non-issue so I don't think it'll ever be fixed.
> The fundamental problem with Rust versioning is that 0.3.5 is compatible with 0.3.6, but not 0.4.0 or 1.0.0
That’s a feature of semver, not a bug :)
You are right to notice that minor versions within a major release can introduce new APIs and changes but generally, not expected to break functionality until the next major release. However, this rule only applies to libraries after they reach 1.0.0. Before 1.0.0, one shouldn’t expect any APIs to be frozen really.
No, it's explicitly not. Semver says:
> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
Cargo is explicitly breaking with Semver by considering 0.3.5 compatible with 0.3.6.
Personally, I think the 0 major version is a bad idea. I hear the desire to not want to have to make guarantees about stability in the early stages of development and you don't want people depending on it. But hiding that behind "v0.x" doesn't change the fact that you are releasing versions and people are depending on it.
If you didn't want people to depend on your package (hence the word "dependency") then why release it? If your public interface changes, bump that major version number. What are you afraid of? People taking your project seriously?
If you want to lure Microslop to migrate all their "great" apps to Servo.
Easy, just add bloat code so it will use 5GB of RAM by default, that's instant adoption by MS.
Is there a table of implemented RFCs? Something similar to http://caniuse.com where we can see what HTML/JS/CSS standards and features are implemented? If it exists, I can't seem to find it. Closest thing seems to be "experimental features" page but its not quite detailed enough.
Oh, I forgot that https://arewebrowseryet.com/ exists for this too!
Closest is perhaps the web platform tests
https://servo.org/wpt/
https://doc.servo.org/apis.html is auto-generated from WebUDL interfaces that exist in Servo. It's not great but better than nothing.
Their bloghas monthly posts on changes https://servo.org/blog/
What this crate could be used for?
Is Servo production-ready enough to replace or embed alongside engines like WebKit or Blink?
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.
when servo is ready i have plans to swap it into qutebrowser which ive been growing fonder of
Did firefox drop servo? I recalled they where in the progress of "rewrite in rust"?
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.
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
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.
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
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++.
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.
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).
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.
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
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?
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
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.
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.
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.
> 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?
Tauri/Dioxus aren't necessarily the end state of Rust GUI
No particular reason Servo couldn't one day become the system web view on Linux distros...
Linux (GNU/Linux or whatever) doesn’t even have the concept of a system web view. In some environments you have some comparatively popular choice, like WebKitGTK, but it’s nothing like WebKit on macOS or WebView2 (or MSHTML in the past) on Windows.
On my system (Arch, Sway), I do have webkitgtk-6.0 installed, but only because I manually installed epiphany (now called “GNOME Web”) because I wanted a decent proxy for testing Apple’s expensive browser (I have found webcompat-style Safari issues to be consistently reproducible in Epiphany).
Yeah the closest thing you come today is arguably WebKitGTK, which is known for being not exactly great.