Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Servo is now available on crates.io

servo.org

Post reply on HN
Print view View original

41–50 of 155 posts

Re: Servo is now available on crates.io

#41

Post by mort96 »

swiftcoder wrote: post #34
mort96 wrote: post #30

Earlier quoted context omitted.

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

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.

Re: Servo is now available on crates.io

#42

Post by zarzavat »

Sammi wrote: post #27
andruby wrote: post #22

Earlier quoted context omitted.

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.

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.

Re: Servo is now available on crates.io

#43

Post by CryZe »

swiftcoder wrote: post #34
mort96 wrote: post #30

Earlier quoted context omitted.

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

This doesn't implement a JS engine, it's just a wrapper around boa.

Re: Servo is now available on crates.io

#44

Post by Starlevel004 »

mort96 wrote: post #28
apitman wrote: 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 standard library has a whole bunch of tools to let them test and evolve APIs with a required-opt in, but every single ecosystem package has to get it right first try because Cargo will silently forcibly update packages and those evolution tools aren't available to third party packages.

Such a stupid state of affairs.

Re: Servo is now available on crates.io

#45

Post by jaapz »

moron4hire wrote: post #33
mort96 wrote: 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…

0.x is not that you don't want people depending on it, you just don't want them to come and complain when you quickly introduce some breaking changes. The project is still in development, it might be stable enough for use in "real projects(tm)", but it might also still significantly change. It is up to the user to decide whether they are OK with this.

1.x communicates (to me at least) you are pretty happy with the current state of the package and don't see any considerable breaking changes in the future. When 2.x comes around, this is often after 1.x has been in use for a long time and people have raised some pain points that can only be addressed by breaking the API.

Re: Servo is now available on crates.io

#46

Post by echelon »

simonw wrote: post #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...

This is super useful! I have immediate use for this.

Do you know if Servo is 100% Rust with no external system dependencies? (ie, can get away with rustls only?)

Can this do Javascript? (Edit: Rendering SPAs / Javascript-only UX would be useful.)

Edit 2: Can it do WebGL? Same rationale for ThreeJS-style apps and 3D renders. (This in particular is right up my use case's alley.)

Re: Servo is now available on crates.io

#47

Post by moron4hire »

mort96 wrote: post #40
moron4hire wrote: post #33

Earlier quoted context omitted.

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.

Any project may change at any time. That's why they bump from v1 to v2. But by not using the full precision of the version number, you're not able to communicate as clearly about releases. A minor release may not be 100% compatible with the previous version, but people still expect some degree of similarity such that migrating is not a difficult task. But going from v0.n to v0.(n+1) uses that field to communicate "hell, anything could happen, YOLO."

Nobody cares that Chrome's major version is 147.

Re: Servo is now available on crates.io

#48

Post by rafaelmn »

This should be the real benchmark of AI coding skills - how fast do we get safe/modern infrastructure/tooling that everyone agrees we need but nobody can fund the development.

If Anthropic wants marketing for Mythos without publishing it - show us servo contrib log or something like that. It aligns nicely with their fundamental infrastructure safety goals.

I'd trust that way more than x% increase on y bench.

Hire a core contributor on Servo or Rust, give him unlimited model access and let's see how far we get with each release.

Re: Servo is now available on crates.io

#49

Post by simonw »

echelon wrote: post #46
simonw wrote: post #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...

This is super useful! I have immediate use for this. Do you know if Servo is 100% Rust with no external system dependencies? (ie, can get away with rustls only?) Can this do Javascript? (Edit: Rendering SPAs / Javascript-only UX would be useful.) Edit 2: Can it do WebGL? Same rationale for ThreeJS-style apps and 3D renders. (This in particular is right up my use case's alley.)

It depends on stuff like SpiderMonkey so not pure Rust.

It should be able to render JavaScript but I've seen it throw bugs on simple pages, no doubt because my vibe-coded thing is crap not because Servo itself can't handle them.

Re: Servo is now available on crates.io

#50

Post by moron4hire »

jaapz wrote: post #45
moron4hire wrote: post #33

Earlier quoted context omitted.

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…

0.x is not that you don't want people depending on it, you just don't want them to come and complain when you quickly introduce some breaking changes. The project is still in development, it might be stable enough for use in "real projects(tm)", but it might also still significantly change. It is up to the user to decide whether they are OK with this. 1.x communicates (to me at least) you are pretty happy with the cu…

If you are at the point that other people can use your software, then you should use v1. If you are not ready for v1, then you shouldn't be releasing to other people.

Because this comment, "The project is still in development, it might be stable enough for use in "real projects(tm)", but it might also still significantly change." That describes every project. Every project is always in development. Every project is stable until it isn't. And when it isn't, you bump the major number.

Post reply on HN