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.

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,

Oh, I forgot that https://arewebrowseryet.com/ exists for this too!

Closest is perhaps the web platform tests

https://servo.org/wpt/

Agreed. Which other software does society need badly?

> show us servo contrib log or something like that

Servo may not be the best project for this experiment, as it has a strict no-AI contributions allowed policy.

https://doc.servo.org/apis.html is auto-generated from WebUDL interfaces that exist in Servo. It's not great but better than nothing.

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

We do not need vibe-coded critical infrastructure.

It's an alternative browser engine, vis a vis Ladybird

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.

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://crates.io/crates/chromiumoxide

Unfortunately we're going to get it whether or not we need it.

Specifically, it's the browser engine that spun out of Mozilla's early efforts towards a rust-based browser, and is one of the motivating projects for the entire Rust ecosystem

Their bloghas monthly posts on changes https://servo.org/blog/

Hey - Many rust libraries adopt [0-based versioning](https://0ver.org/). That link can describe it more elegantly than I.

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.

Servo has been on-the-go for a while though. It hasn't been a lightning speed development, it's just getting a bit more visible.

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.

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.

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.

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.

That is not the meta. The meta is to ship blink so you only have to support a single version of a single web engine in stead of many versions of many different web engines.

It's extremely tempting to write stuff and not bother to understand it similar to the way most of us don't decompile our binaries and look at the assembler when we write C/C++.

So, should I trust an LLM as much as a C compiler?

I trust people to understand the code they write. I don't trust them to understand code they didn't write.

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

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.

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

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

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.

I disagree. Thorough testing provides some level of confidence that the code is correct, but there's immense value in having infrastructure which some people understand because they wrote it. No amount of process around your vibe slop can provide that.

They may be production-ready in some sense but they're not ready to be put in Firefox, and/or they are v8 bindings.

They're all more than 10x slower than SpiderMonkey.

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.

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

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.

Well, yes, agreed - that is the essential domain complexity.

But my argument is that we can work to minimize the time we spend on verifying the code-level accidental complexity.

That's just status quo, which isn't really holding up in the modern era IMO.

I'm sure we'll have vibed infrastructure and slow infrastructure, and one of them will burn down more frequently. Only time will tell who survives the onslaught and who gets dropped, but I personally won't be making any bets on slow infrastructure.

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?

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

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.

To go further, semver provides semantics and an ordering but it says nothing about version requirement syntax. The caret operator to describe a range of versions is not part of the spec. It was introduced by initial semver-aware package managers such as npm or gem. Cargo decided to default to the caret operator, but it's still the caret operator.

In practice, there's no real issue with using the first non-zero component to define the group of API-compatible releases and most package managers agree on the semantics.

Tauri/Dioxus aren't necessarily the end state of Rust GUI

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 prompting that didn't explain well enough perhaps but how was I to know I failed without reading the code?

I disagree. The code itself matters too.

But people will complain, so ex falso quodlibet

Thank you.

Eventually this will get cleared up. I’m close than I’ve ever been to actually handling this, but it’s been 9 years already, so what’s another few months…

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.

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

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.

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.

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.

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

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.

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.

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