Servo is now available on crates.io • Hacker News Board

Re: Servo is now available on crates.io

#101

Post by simonw » Mon, Apr 13, 2026, 6:28 PM UTC

scrame wrote: post #67

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

That's pretty cool. I'm guessing it would need some tweaking to handle things like cookies, or does it just need a pointer to the cookiejar? I'm not too familiar with servo,

It's a VERY simple initial demo, I expect things like cookies would require quite a lot more work.

Re: Servo is now available on crates.io

#102

Post by bastawhiz » Mon, Apr 13, 2026, 6:31 PM UTC

diath wrote: post #19

bastawhiz wrote: post #15

Earlier quoted context omitted.

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

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

Re: Servo is now available on crates.io

#103

Post by steveklabnik » Mon, Apr 13, 2026, 6:34 PM UTC

mort96 wrote: post #52

moron4hire wrote: post #47

Earlier quoted context omitted.

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 "he…

By releasing a library with version 1.0, I communicate: "I consider this project to be in a state where it is reasonable to depend on it". By releasing a library with version 0.x, I communicate: "I consider this project to be under initial development and would advice people not to depend on in unless you want to participate in its initial development". I don't understand why people find this difficult or controversi…

There is additional subtlety here.

For example, sometimes projects that have a 0.y version get depended on a lot, and so moving to 1.0.0 can be super painful. This is the case with the libc crate in Rust, which the 0.1.0 -> 0.2.0 transition was super painful for the ecosystem. Even though it should be a 1.0.0 crate, it is not, because the pain of causing an ecosystem split isn't considered to be worth the version number change.

Re: Servo is now available on crates.io

#104

Post by jddj » Mon, Apr 13, 2026, 6:41 PM UTC

rafaelmn wrote: post #61

mort96 wrote: post #54

Earlier quoted context omitted.

We do not need vibe-coded critical infrastructure.

If you're trusting core contributors without AI I don't see why you wouldn't trust them with it. Hiring a few core devs to work on it should be a rounding error to Anthropic and a huge flex if they are actually able to deliver.

What if it impairs judgement?

Re: Servo is now available on crates.io

#105

Post by nmvk » Mon, Apr 13, 2026, 6:44 PM UTC

Really excited to see this. I contributed to Servo open source 10 years ago, and it was a very cool experience.

Re: Servo is now available on crates.io

#106

Post by zokier » Mon, Apr 13, 2026, 6:47 PM UTC

the__alchemist wrote: post #65

moron4hire wrote: post #50

Earlier quoted context omitted.

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

I think we can come up with a reason why bumping the version number each breaking change isn't an elegant solution either: You would end up with version numbers in the hundreds or thousands.

Browser version numbers are in the hundreds and it doesn't seem to be a problem.

Re: Servo is now available on crates.io

#107

Post by Night_Thastus » Mon, Apr 13, 2026, 6:54 PM UTC

rafaelmn wrote: post #48

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

The problem with such infrastructure is not the initial development overhead.

It's the maintenance. The long term, slow burn, uninteresting work that must be done continually. Someone needs to be behind it for the long haul or it will never get adopted and used widely.

Right now, at least, LLMs are not great at that. They're great for quickly creating smaller projects. They get less good the older and larger those projects get.

Re: Servo is now available on crates.io

#108

Post by the__alchemist » Mon, Apr 13, 2026, 6:55 PM UTC

zokier wrote: post #106

the__alchemist wrote: post #65

Earlier quoted context omitted.

I think we can come up with a reason why bumping the version number each breaking change isn't an elegant solution either: You would end up with version numbers in the hundreds or thousands.

Browser version numbers are in the hundreds and it doesn't seem to be a problem.

Indeed! I think both 0-based versioning, and this (maybe?) downside I bring up addresses the tension between wanting to limit the damage caused by breaking changes with retaining the ability to make them.

Re: Servo is now available on crates.io

#109

Post by epcoa » Mon, Apr 13, 2026, 6:59 PM UTC

px43 wrote: post #76

8NNTt8z3QvLT8tp wrote: post #53

Earlier quoted context omitted.

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.

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.

lol

Re: Servo is now available on crates.io

#110

Post by thephyber » Mon, Apr 13, 2026, 7:03 PM UTC

skrtskrt wrote: post #91

bawolff wrote: post #63

Earlier quoted context omitted.

I dont think that will ever be possible. At some point security becomes - the program does the thing the human wanted it to do but didn't realize they didn't actually want. No amount of testing can fix logic bugs due to bad specification.

AI as advanced fuzz-testing is ridiculously helpful though - hardly any bug you can in this sort of advanced system is a specification logic bug. It's low-level security-based stuff, finding ways to DDOS a local process, or work around OS-level security restrictions, etc.

Re-read the thread you are replying to.

Each of the last 4 comments in your thread (including yours) are conflating what they mean by AI.