Live data from Hacker News

Servo is now available on crates.io

servo.org

31–40 of 155 posts

Re: Servo is now available on crates.io

#31
post #24

> 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.

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.

Re: Servo is now available on crates.io

#32
post #10

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.

No particular reason Servo couldn't one day become the system web view on Linux distros...

Yeah the closest thing you come today is arguably WebKitGTK, which is known for being not exactly great.

Re: Servo is now available on crates.io

#33
post #28
post #24

> 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 wou…

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?

Re: Servo is now available on crates.io

#34
post #30

Earlier quoted context omitted.

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

Re: Servo is now available on crates.io

#35
post #28
post #24

> 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 wou…

> 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 :)

Long answer: You are right to notice that minor versions within a major release can introduce new APIs and changes but generally, should not break existing APIs 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.

Re: Servo is now available on crates.io

#36
post #10

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.

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. 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.

Re: Servo is now available on crates.io

#37
post #16

Earlier quoted context omitted.

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 needi…

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.

Re: Servo is now available on crates.io

#38
post #28

Earlier quoted context omitted.

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 wou…

> 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 :) Long answer: You are right to notice that minor versions within a major release can introduce new APIs and changes but generally, should not break existing APIs until the next major release. However, this rule only applies to libraries after they reach 1.0.0. Before 1.…

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.

Re: Servo is now available on crates.io

#39
Here's a vibe-coded "servo-shot" CLI tool which uses this crate to render an image of a web page: https://github.com/simonw/research/tree/main/servo-crate-exp...

  git clone https://github.com/simonw/research
  cd research/servo-crate-exploration/servo-shot
  cargo build
  ./target/debug/servo-shot https://news.ycombinator.com/
Here's the image it generated: https://gist.github.com/simonw/c2cb4fcb15b0837bbc4540c3d398c...

Re: Servo is now available on crates.io

#40
post #28

Earlier quoted context omitted.

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 wou…

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 relea…

Versioning is communication. I find it useful to communicate, through using version 0.x, "this is not a production ready library and it may change at any time, I provide no stability guarantees". Why might I release it in that state? Because it might still be useful to people, and people who find it useful may become contributors.
Post reply on HN