← Back to context

Comment by awesomekling

8 months ago

I can't speak for Servo, but my understanding is that they have very different goals than we do.

Servo wants to build an embeddable engine for controlled sets of HTML/CSS/JS content, with a focus on modularity and parallelism.

Ladybird wants to build a usable browser for the open web, warts and all, with a focus on compatibility and correctness.

I'm a big fan of Servo and I hope they become a huge success! Competition and new ideas in browser engines will benefit all of us! :)

> Servo wants to build an embeddable engine

That’s what they pivoted to after being expelled from Mozilla, but that wasn’t the original goal, was it? It’s the safer(?) one they turned to when the job security evaporated.

(Not sure if that changes anything, just feel obligated to point out the retcon here.)

  • It would be very cool if Servo were picked up as the engine for a new browser.

    • Agreed, I really hope that someday we'll get a full rust browser, because rust is a language where I could see myself contributing (e.g. fixing bugs that annoy me when using it all day) to it, compared to other languages like C/C++.

  • >that wasn’t the original goal

    They always aimed for a better embeddable story than Gecko. That and more parallelism in layout and processing.

    > It’s the safer(?) one they turned to when the job security evaporated.

    Not safer, more like saner multithreading story. Safe rust isn't so much for security as it is safety in a parallel context.

    • Re better embeddability, sure. As best as I can tell the Firefox devs have been feeling some amount of dismay due to the fact that everyone embeds Chromium/Blink, despite the whole Mozilla/XUL thing having been built more as an application platform rather than as a foundation for one specific web browser. And that’s entirely understandable, as is attempting to do better on the second go-round. But now it seems that Servo is explicitly targeting embedding and -adjacent use cases only, and that’s a post-Mozilla thing.

      Re “safe”, I meant that targeting the embedding usecase is safer in a social and project-planning way, as in smaller probability of other people calling them nuts and greater probability of getting something usable in a finite amount of time. Which is fair enough.

      1 reply →

The talk about correctness gets me thinking.

If there is a difference between how specs define something, and how browsers behave (and website expect them to behave), will you choose technical correctness or websites actually functioning?

Technically this has been the big problem of HTML5 vs XHTML, and "technical correctness" lost to actual usability.

  • Nowadays the spec mostly is "whatever Chrome does".

    Firefox has often been forced to just conform to Chrome behaviour, despite differing specs, or because the spec was rejected/not agreed upon.