[nobodysfool]

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.

[kllrnohj]

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

[vertex-four]

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.

[pcwalton]

Ada isn't memory-safe with dynamic allocation (unless you use GC). Dynamic allocation is essential for a Web browser.

[cygx]

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

Sure it's hard and always will be. But the point is that C++ makes it harder than it needs to be. That's where Rust comes in.

[octo_t]

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

[1] - see this comment here: https://news.ycombinator.com/item?id=7484536

[wtetzner]

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