
Another Big Milestone for Servo: Acid2 - dherman
https://blog.mozilla.org/research/2014/04/17/another-big-milestone-for-servo-acid2/
======
brson
Servo is the kind of project that launches a thousand research papers. Some of
the early results are staggering and the project is still just getting going.
It is a great example of doing serious research to practical ends.

Some examples:

\- firstly, the entire foundation, Rust, is itself an ambitious research
project that solves many long-standing problems in the domain.

\- Servo has, or has plans for, parallelism (combinations of task-, data-
parallelism, SIMD, GPU) at every level of the stack.

\- The entirety of CSS layout (one of the most difficult and important parts
of the stack) is _already_ parallelized, and it's fast.

\- It puts all DOM objects in the JS heap, eliminating the nightmarish cross-
heap reference counting that historically plagues browser architectures (this
is part of Blink's "oilpan" architecture).

~~~
gsnedders
> \- It puts all DOM objects in the JS heap, eliminating the nightmarish
> cross-heap reference counting that historically plagues browser
> architectures (this is part of Blink's "oilpan" architecture).

Does Gecko not already do this? Certainly Presto did, and (I believe) Trident
does.

But to add another bit of research into the mix, and what I think is arguably
the most important point:

\- Builds on all the work around HTML(5) and CSS 2.1, both of which are the
best part of a decade of work, both aiming to get browsers actually
implementing to specifications, and specifying behaviour in sufficient detail
(with minimal undefined behaviour) that a web page cannot easily distinguish
two user agents. By actually specifying the web platform as it actually
exists, it suddenly makes it far more practical for new browsers to enter the
market (compared with the previous hellish situation of the hardest part of
developing a browser being reverse-engineering existing browsers with
sufficient marketshare that web developers ensure their web pages work in
them). If this is shown to be viable, suddenly we have a truly open platform!

~~~
kibwen
Here's another really fantastic reason for the research Servo is doing: by
using concurrency and parallelism pervasively, Servo is discovering and
mapping out all the places where sequentialism is baked into the web standards
themselves. With any luck, their experiences will help to guide the next
generation of web standards and prevent them from being inadvertently hostile
to parallelism.

~~~
bascule
floats :(

~~~
dherman
The float taketh away and the clear: both giveth back again:

[http://pcwalton.github.io/blog/2014/02/25/revamped-
parallel-...](http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-
layout-in-servo/)

------
bithush
With the bad press Mozilla has had the past few weeks it is easy for people to
forget about some of the awesome things Mozilla are working on such as Rust
and Servo. I really like the look of Rust and feel it might be the future
native language for high performance applications. It is very exciting!

~~~
nnethercote
Indeed. Brendan's resignation was dismaying and distracting, but we haven't
stopped working on stuff.

Just after Brendan resigned, I read a comment somewhere to the effect of "I
guess that's the end of Firefox OS". Um, no. A major project run by a company
of 1,000 employees (and many volunteers) doesn't stop because one person left,
even if that person is at the top. Especially when it's progressing well.

------
ChuckMcM
This is awesome, I wonder if there is a more constrained web rendering engine
somewhere. Something where rather than 'render everything we've ever seen' is
'render the following html 'standards' correctly' (or at least predictably). I
was looking for something like this for a modern day sort of serial terminal
thing.

~~~
richdougherty
Out of interest, what are the reasons you don't want to be able to 'render
everything we've ever seen'?

~~~
danudey
I worked for a medical software company which had to deal with incoming
digital images (DICOM) from all kinds of manufacturers (Siemens, GE, Philips,
and tons of other smaller players).

I once heard one of our lead developers say that 80% of the code we wrote was
to work around problems in everyone else's implementations. The DICOM format
has a bunch of predefined fields and supports custom fields that manufacturers
can use, but a lot of manufacturers would, for no reason I could figure out,
use fields incorrectly a surprising amount of the time. They would store one
of the most basic pieces of information in the wrong field, and then store
that data nowhere, or put it in a custom field, or store it in the wrong
format, etc.

Enough manufacturers doing 95% of things right and 5% of things wrong, making
everyone else jump through hoops to handle their broken behaviour, and
suddenly your code grows massively. Sure enough, we had to write an entire
system for remapping fields from certain machines so that incoming data from
broken implementations would be somehow magically coerced into being correct
(either by simply copying data over to fields, or more advanced post-
processing).

The less time browsers spend wondering what to do with inherently,
irredeemably broken HTML, the faster they can render content which actually
does work properly.

Unfortunately, that only works in controlled environments, like store kiosks,
intranets, etc. Otherwise you end up choking on the 95% of the content which
is only 5% broken.

~~~
cpeterso
Your story is a perfect example of the dark side of Postel's law: "Be
conservative in what you send, be liberal in what you accept." The people who
care about writing software that Just Works™ end up maintaining software that
is crushed under its own gravity. :)

~~~
nnethercote
I think the wisdom of Postel's law is questionable at best.

~~~
hyperpape
Apparently what we think of as Postel's law is a bastardization.
[http://erlang.org/pipermail/erlang-
questions/2014-March/0781...](http://erlang.org/pipermail/erlang-
questions/2014-March/078195.html).

------
modeless
I want Rust scripting support in Servo.

    
    
      <script type="text/x-rust" src="foo.rs">
    

Since Rust is a safe language this should be possible without compromising
security, though I don't think anyone's yet attempted to write a JIT compiler
for Rust. Has the Servo team considered this as a possibility?

~~~
Touche
Why do you want to script with Rust?

~~~
pekk
Javascript is a terrible language, even though Rust is experimental it would
be a big improvement. And it does have attractive aspects as a language.

More broadly, breaking the iron grip Javascript has on client-side development
would be wonderful and Mozilla is the last stumbling block in front of this
goal.

~~~
malandrew
Insofar as scripting languages go, Racket/Scheme would also be a nice
addition. After all that is what Eich was going for when he created
JavaScript. He wanted a language with scheme-like semantics but other forces
wanted it to have a C-style syntax.

------
talklittle
Previous discussion:
[https://news.ycombinator.com/item?id=7483729](https://news.ycombinator.com/item?id=7483729)

~~~
kibwen
Note that the previous announcement was a bit premature: three weeks ago, on
the date of that discussion, Servo was passing Acid2 only on a feature branch.
As of two weeks ago the master branch should be passing as well.

------
camus2
When can I expect Servo to be in Firefox instead of the current engine?
2015/2016? do you have a rough idea?

~~~
kibwen
There are no plans yet to ever integrate Servo directly into Firefox. At the
very least Servo will certainly exist as a standalone browser engine (and
unlike Gecko, Servo is designed to be embeddable, so it will be an actual
alternative to Webkit in that space).

The biggest impetus for Servo at the moment is that it's researching the
biggest wins to be gained from concurrency and parallelism in browser engines,
thereby guiding efforts to tack such things onto Gecko.

~~~
Symmetry
Well, then I'll hope for a Servo equivalent of Luakit before too long.

------
schmrz
> Many kinds of browser security bugs, such as the recent Heartbleed
> vulnerability, are prevented automatically by the Rust compiler.

Does anyone care to explain how this would work? If you used OpenSSL from Rust
you would still be vulnerable to Heartbleed. Or am I missing something?

~~~
sanderjd
Of course it's true that Rust can't protect you from things done in libraries
called across its FFI. It's also true that at the moment most of, or at least
a lot of, real work done in Rust eventually ends up calling into some C
library. But I think that will be less and less true as time goes on.

~~~
metajack
Lots of bits of Servo use the FFI, but we've been replacing them as we go
along with Rust versions. We did this so we could stand up a whole browser as
fast as possible and then iterate on the important pieces first.

As an example, we used to use Netsurf's C library for CSS stuff, but now we
have our own parser and style system written in 100% Rust.

~~~
sanderjd
I think it's a great approach, and I plan to whole-heartedly enjoy watching
more and more of those chunks get whittled away as time goes on. I'd love to
see a pure-rust spidermonkey replacement at some point!

------
macinjosh
This is what I see when I run Acid2 in Servo. Perhaps they haven't merged the
changes in to the public repo yet.

[http://cl.ly/image/1b123r220P3u](http://cl.ly/image/1b123r220P3u)

~~~
pcwalton
Yes, the fix (a submodule update for rust-layers) is blocked on a Rust upgrade
which is currently in progress.

------
acqq
Is Servo using GC?

~~~
pcwalton
For the DOM thread only, yes. All layout data structures are not using the
garbage collector.

~~~
steveklabnik
And for those who don't follow Rust closely, it's important that it's "the DOM
thread only," as Rust's opt-in GC is on a per-task (thread) basis, so the
threads that don't use GC don't even know it's there or running.

~~~
dbaupp
(Note that Rust doesn't actually have its own GC yet, Servo is just using
spidermonkey's JS GC. pcwalton's comment implies it is being used single-
threadly though.)

~~~
metajack
There can be multiple script tasks even within a single page. For example,
cross-domain or sandboxed iframes will have each DOM and script in its own
task. Also, each of those will have their own layout and rendering tasks.

------
sgarlatm
I'm curious what Chrome's plans are for the future, in particular related to
parallelization. Has anyone seen any articles about that anywhere?

~~~
paulirish
Eric Seidel talks here about some of the ideas in parallelizing things:
[https://www.youtube.com/watch?v=4Sm-
DbIOqiU#t=818](https://www.youtube.com/watch?v=4Sm-DbIOqiU#t=818)

And a 2014 Brainstorm thread with similar ideas:
[https://groups.google.com/a/chromium.org/d/msg/blink-
dev/Z5O...](https://groups.google.com/a/chromium.org/d/msg/blink-
dev/Z5OzwYh3Wfk/IWooaY5FZowJ)

