YHK - yet another hacker news clone

>long term browser compatibility

Making a new browser engine hurts browser compatibility more than it helps it. It now becomes one more target that needs to be tested against, limitations need to be kept tracked of, etc. The best thing for long term browser compatibility is focusing resources into Blink. In regards to the standard we can use LLMs to cross reference the spec, with tests, and with the implementation to make sure all match.

Couldn't agree more. Looking at [1], it seems to me like Servo has a much better adoption story than Ladybird. The latter seems to be just building a browser that's going to be crashy and not really work on the web. The former is addressing problem spaces where, even with the limitations of the half-finished state it's in, it can be usefully applied: WebView/Electron-replacement and headless browsers. Things not currently on this list that could/should be: HTML rendering for desktop E-Mail clients. Also, I wonder to what extent they're implementing paged media and capable of targetting PDF output or similar (like weasyprint). That could be another domain, where you don't need full web-scale abilities.

And yet, somehow, Ladybird seems to be the darling of the masses (in certain circles at least). Doing vibe-ports to Rust, while going closed-contribution also, in my mind, sits in a marked contrast to the origin story that initially generated so much goodwill.

[1] https://servo.org/made-with/

That's news! Would be really cool.

Was this recent? Because Firefox were the browser that worked better than all the rest, for quite many years, maybe 2005-2010, and Firefox had no competition basically until Chrome arrived on the scene.

Just the fact that Firefox got browser tabs before anyone else, and Firebug, just took it to another level compared to all the other browsers available at the time.

Sanctions

Being dependent on a direct competitor is not a comfortable position to be in. It's ameliorated significantly by Chromium being open source, but not completely.

Probably because broad adoption would help making it a real option to use in the near future?

So sure, Samsung would bundle it with their usual crap, but if it helps making the engine more mature, great, but I also don't see why they would in the first place.

> So right now Servo is funded by the community, and this is no good because why?

Because look at Mozilla... You need to get the browser in front of people. A browser that works on the real web, is such a huge project, you cannot do it as a hobby community-funded project for ever. You need user-share-%.

Samsung can put it in front of Samsung appliance users.

> Instead you propose that this project should be funded by a for-profit company with it's own objectives in this world (that often starts with "more money"), again leading me to ask why?

You understand that Mozilla Firefox is not funded by the "community" and is completely funded by Google's money. Even donating does not fund the browser.

Mozilla knows that the open source "community" has no money, and cannot replace the amount of money Google is paying them and the employees who work on the browser.

The question is are you ready to fill the $600M a year black hole for Google to NOT pay Mozilla to fund Firefox?

It only makes sense for Servo to get funding from for-profit companies at this point, which is one of the only ways open source can work.

That’s interesting, anyone have more info on how why this came about? The why is pretty clear at least.

I was not aware of this, and now I suddenly understand the weird hate that the project gets from drive-by commenters. (I don’t agree with it, but I can see a plausible motivation.)

Thanks to the scheduler, you can do both!

that's something you, the user, are free to enforce with priorities, pinning, etc.

It is not really about reserving cores.

Just that - even if you distribute work to a number of cores (that itself limited), you still need to sync the execution. So unless you have some bigger chunks of computation, the performance increase will be very small.

And yes, there are bigger chunks of work when rendering a web page, but that is typically already outside the css engine and can be distributed without having to rewrite the core engine.

But my comments are a bit generic here, so I am open to comments regarding this particular project.

I want all my software to use all my cores, because I'll have twice as many within 5 years.

It's more efficient to use all the cores briefly and go back to whatever background task than have long running mixed load. This also matches performance expectations, you generally want the web page displayed _now_ and the compile to finish ASAP while accepting it will take _some_ time.

I didn't know about this but of NLnet history. I assumed you had been mistaken so I looked it up. That's really cool!

You don't have to have a JIT to have a JS VM ?

They announced they are doing an AI assisted rewrite of parts of their code into Rust. That would alienate some.

https://ladybird.org/posts/adopting-rust/

Myself, my annoyance with Ladybird is that restarted everything from scratch. There are components of servo that are really good and basically complete. Why not use those components and concentrate on the components where you have design conflicts with Servo?