I wonder if Servo is advanced enough to get some performance numbers on large pages compared to other engines. In any case, I'm looking forward to see what becomes of it. Like Rust, it seems a well thought-out approach to solving difficult problems.
My intern, Laleh Beni, gave a talk last week where she compared the performance of Servo on a synthetic benchmark to that of Firefox on Android:
https://air.mozilla.org/servos-power-struggle/
We're not publishing comparisons with other engines for now because we don't support the full web platform yet in Servo and it doesn't make for a fair comparison against them. Certainly, we benchmark against other engines internally and try to ensure Servo's page load times are at least as fast as the other engines. That said, we don't have incremental layout yet, so Servo is _way_ behind on any measurement involving dynamic page updates.
Lots of good progress, but we also still have lots of work to do!
I just don't understand the justification for this.
> pre 2000
I'm pretty sure a lot of good technology is written pre-2000. Why you'd want to throw it away is beyond me. Just because something is old doesn't mean it's outdated.
> difficult to experiment or fundamentally change
Generally with mature products this is true, so the solution is to use an immature product? Why not just take the time to learn the existing products so that you can experiment or make your changes.
> security and performance are hard
It's always been that way, and it always will be. I doubt a new library/platform will change that. The only thing it will do is make the developer an expert on the system (since she designed it).
The diagrams don't make sense, and seem to miss the point. Not all scripts will cause the layout to change. Some may, but the renderer shouldn't be controlling the script, except in extreme or very specific cases.
> Just because something is old doesn't mean it's outdated.
Yes and no. The state of the world pre-2000 is very, very different than today. Pre-2000 engines were not built for HTML5/CSS3, they were not built for touch panels, they were not built for quad-core CPUs being standard (hell, dual-core wasn't really even a thing), GPUs were an unexpected surprise, not a cornerstone of the device.
You either refactor until you have nothing left from pre-2000 anyway, or you rewrite from scratch.
> It's always been that way, and it always will be.
No, it isn't, and no, it won't. Having security AND performance at the same time is hard, but Rust very much looks to be a compelling answer to that.
It's a research project. Maturity has nothing to do with it. There's literally no plans for Servo apart from research.
> It's always been that way, and it always will be. I doubt a new library/platform will change that.
Except that we have ridiculously few memory-safe systems programming languages. Rust is one, I believe Ada is another. Provably memory-safe code means no more stack/buffer overflows, no more writing to random bits of memory, and in Rust's case it can be for almost free.
because browsers in the 1990s were radically different to how they are today. Writing one from scratch lets you learn from past mistakes.
Its immature to start with, but if you have a reference engine (say gecko) and source test data (say the entire internet), you've got some pretty awesome tests already.
I am quite sure the people working on servo have got a lot more experience working with browser engines than most of us, and most of them are contributors to firefox/gecko. I would add that using servo, they manage to find several "bugs" in the new css specification that would have made parallelising CSS layouts much harder (due to servos inherently parallel nature)[1]
A new language that prevents some of the most common security issues via the typesystem will be more secure, whilst not sacrificing the low level performance of higher level language (like Java etc).
> Generally with mature products this is true, so the solution is to use an immature product? Why not just take the time to learn the existing products so that you can experiment or make your changes.
It's not hard to experiment or make changes because they don't know the software, it's because the structure of the software is hard to change.
Sometimes the best way to move forward is to start new, using everything you've learned from previous projects.
