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

121–130 of 155 posts

Re: Servo is now available on crates.io

#121

Post by mnutt »

minimaxir wrote: post #58
echelon wrote: post #46

Earlier quoted context omitted.

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

I have been building/vibecoding a similar tool and unfortunately came to the conclusion that in practice, there are just too many features dependent on the full Chrome stack that it's just more pragmatic to use a real Chromium installation despite the file size. Performance/image generation speed is still fine, though. In Rust, the chromiumoxide crate is a performant way to interface with it for screenshots: https://…

I think you could in theory have a similar webkit-based stripped down headless crate that might have a good tradeoff of features, performance, and size.

Re: Servo is now available on crates.io

#122

Post by globular-toast »

giovannibonetti wrote: post #80

For those of you using a browser to generate PDFs, the Rust crate you should look into is Typst [1]. Regardless of your application language, you can use their CLI. It takes some time to get used to their DSL to write PDFs, but nowadays with AI that shouldn't take too long. [1] https://crates.io/crates/typst

I recently deployed typst to generate PDF letters automatically. Being familiar with (La)TeX (I've typeset everything from letters to my PhD thesis), I was shocked at the speed. It's quick enough to use in an HTTP request cycle. The language was also super easy to learn.

Not sure if it's quite as good as TeX at typesetting, but it seems good enough. When I did my thesis, TikZ was even more valuable. I don't know if there's any replacement for that.

Re: Servo is now available on crates.io

#123

Post by Tmpod »

apitman wrote: post #25
nicoburns wrote: post #2

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…

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.

Agreed, I find Slint really interesting. To me, the biggest pain point is the very limited theming support. It's virtually impossible to make a custom theme without re-implementing most widget logic, which is a shame.

Re: Servo is now available on crates.io

#124

Post by mrbonner »

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

Cool! I checked the source and noticed that even LLM prefers simplified, high level Rust coding styles: use value types such as String, use smart pointers such as reference counting, clone liberally, etc… instead of fighting the borrow checker gatekeepers.

It is the style I prefer to use Rust for. Coming from Python, Typescript and even Java, even with this high level Rust, it yields incredible improvement already.

Re: Servo is now available on crates.io

#125

Post by jbvlkt »

falcor84 wrote: post #55
mort96 wrote: post #54

Earlier quoted context omitted.

We do not need vibe-coded critical infrastructure.

As I see it, the focus should not be about the coding, but about the testing, and particularly the security evaluation. Particularly for critical infrastructure, I would want us to have a testing approach that is so reliable that it wouldn't matter who/what wrote the code.

I have been thinking about that lately and isn't testing and security evaluation way harder problem than designing and carefully implementing new features? I think that vibecoding automates easiest step in SW development while making more challenging/expensive steps harder. How are we suppose to debug complex problems in critical infrastructure if no one understands code? It is possible that in future agents will be able to do that but it feels to me that we are not there yet.

Re: Servo is now available on crates.io

#126

Post by jbvlkt »

t43562 wrote: post #86
falcor84 wrote: post #77

Earlier quoted context omitted.

I somewhat agree, but even then would argue that the proper level at which this understanding should reside is at the architecture and data flow invariants levels, rather than the code itself. And these can actually be enforced quite well as tests against human-authored diagrammatical specs.

If you don't fully understand the code how do you know it implements your architecture exactly and without doing it in a way that has implications you hadn't thought of? As a trivial example I just found a piece of irrelevant crap in some code I generated a couple of weeks ago. It worked in the simple cases which is why I never spotted it but would have had some weird effects in more complicated ones. It was my promp…

Exactly. We do not have another artifact than code which can be deterministically converted to program. That is reason we have to still read the code. Prompt is not final product in development process.

Re: Servo is now available on crates.io

#127

Post by andrepd »

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

Cool! I checked the source and noticed that even LLM prefers simplified, high level Rust coding styles: use value types such as String, use smart pointers such as reference counting, clone liberally, etc… instead of fighting the borrow checker gatekeepers. It is the style I prefer to use Rust for. Coming from Python, Typescript and even Java, even with this high level Rust, it yields incredible improvement already.

> Cool! I checked the source and noticed that even LLM prefers simplified, high level Rust coding styles: use value types such as String, use smart pointers such as reference counting, clone liberally, etc… instead of fighting the borrow checker gatekeepers.

Yeah that tracks because the AI is dumb as a bag of bricks. It can apply patterns off stackoverflow, but can hardly understand the borrow checker.

Re: Servo is now available on crates.io

#128

Post by lastontheboat »

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

Servo does execute JS and does support webgl (and some but not all of webgl2 if you enable the feature: https://book.servo.org/design-documentation/experimental-fea...).

Re: Servo is now available on crates.io

#129

Post by mort96 »

steveklabnik wrote: post #103
mort96 wrote: post #52

Earlier quoted context omitted.

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

Oh hey I recently saw a comment which discussed this exact issue: https://news.ycombinator.com/item?id=47752915

Re: Servo is now available on crates.io

#130

Post by rl3 »

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

We do not need vibe-coded critical infrastructure.

>> ...give him unlimited model access

>We do not need vibe-coded critical infrastructure.

I think when you have virtually unlimited compute, it affords the ability to really lock down test writing and code review to a degree that isn't possible with normal vibe code setups and budgets.

That said for truly critical things, I could see a final human review step for a given piece of generated code, followed by a hard lock. That workflow is going to be popular if it already isn't.

Post reply on HN