
Mozilla's Servo Engine Now Capable of Rendering GitHub - kungfudoi
https://www.phoronix.com/scan.php?page=news_item&px=Mozilla-Servo-GitHub
======
pcwalton
Also see Ars Technica rendered in Servo:
[https://twitter.com/pcwalton/status/631961638304804864](https://twitter.com/pcwalton/status/631961638304804864)

I've been working on knocking down layout bugs that affect the most popular
sites lately. Please feel free to try it out and file GitHub issues,
especially if you can minimize test cases! You're definitely likely to see
various degrees of brokenness on most sites, but the core CSS 2.1/CSS3 layout
is pretty solid at this point; there's just a long tail of bugs and corner
cases we've got to nail down. This is where finding and isolating the bugs
that break the major Web sites is important!

~~~
andy_ppp
Interesting, as a web developer I really really want Servo to become a big
success. I wonder at what point do Mozilla think I should start having a once
over in Servo before putting my sites on the web?

Why not, I'll start doing this as it can't do any harm and create some test
cases should I find some weirdness.

It's really easy to build a copy of servo after all:

    
    
        https://github.com/servo/servo
    

The instructions there generally just work.

~~~
pcwalton
Don't contort your Web sites to work around brokenness in Servo; just file
bugs. Rendering bugs are our bugs, not yours :)

~~~
Stormcaller
I wonder if there was an idea of a "strict mode" at any point? When making
sure every site works surely you guys will have to render invalid code
"correctly", I assume.

For example I am willing to develop in your browser if it meant I wouldn't
broke some rules and the browser would care about that. Of course html
validators exist and browsers display invalid css in their inspectors but I am
asking for something like that would expect valid code. throw an error in my
face if I didn't close a html tag or used an invalid css value, at any point.

Like if a javascript code resulted in my page getting invalid layout then
browser could yell at me that causes an invalid layout. Maybe even a small
performance improvement if my code conformed to every layout rule.

~~~
Tobu
xhtml worked like that, html5 has moved towards specifying the quirks that are
used to deal with poor conformance. That said, if you look at a webdev
console, things that cause poor performance (à la document.write) tend to be
noted.

------
seertaak
I have to say, as a C++ developer, I'm really impressed with Rust's progress
in the last year. Creating a browser rendering engine is a complicated task --
it's a very strong proof that the language is practical. Rust also seems to
have a friendly, engaging community, and leaders (e.g. pcwalton) that are
fair-minded and that invite and inform rather than scare away. The docs are
nicely presented and informative. The language feels fresh and modern. The
build and library discovery story is 10x better than what C++ offers.

In short, there's a lot to make you want to move over. Still, I a) have a ~90K
LOC code base in C++/Obj-C that I'm not going to abandon any time soon, and b)
after having gotten burned (in Haskell) by the "more purity or strictness (in
the conventional, not evaluation, sense) is always better" argument, I'm
waiting to be convinced that having a more picky compiler actually helps
rather than getting in the way. As mentioned above, projects like this
certainly make one more confident that it does help.

~~~
cjcole
I've gone all-in for Rust for any side projects. I still get paid to write
C++, but I choose to use Rust. I'd say that I'm up to around 20K LOC at this
point and the sheer peace of mind that I get is worth almost any amount of
extra arguing with the compiler when it just works the first time I run it --
which happens a surprising proportion of the time.

Improvements which would make me really happy:

* Faster builds. This is still a pain point.

* "Non-lexical borrows" [1]

* Trapped under ICE [2]

I know that all of the above are being actively worked on, so I'm waiting
patiently. [3]

[1] Borrows are currently tied to scopes (blocks, etc). This makes certain
safe borrowing patterns illegal, requiring slightly-to-highly awkward
workarounds.

[2] The compiler crashes too often (ICE). I was recently stuck with a non-
compiling code base and facing the prospect of systematically commenting out
code to find the offending piece. Fortunately, this one was fixed quickly.
There are many others remaining, though. (It is getting better as Rust gets
more use.)

[3] This is a lie. Patience is rarely one of my virtues.

~~~
gamegoblin
The ICE issue is what turned me off Rust.

I went all-in for side projects like you (this is how I typically learn a
language), but after two months or so, I was spending 30-60 minutes a day
trying to figure out the cause of compiler crashes, and then tweak my code so
it didn't trigger them.

I've heard the ICEs have gotten _much_ better in 1.2 (I was working in 1.0),
but I haven't picked it up again.

~~~
steveklabnik
To you or anyone else who reads this, if you find an ICE, please report it or
:+1: a previous report. It can be hard to tell which ones hit a lot of people,
and which ones don't.

~~~
tmzt
Would it be possible to add an optional crashpad-like script, one that allows
you to review the data sibmitted in hex/ascii before sending it off?

~~~
steveklabnik
We've been discussing it, not just for crashes, but even compiler errors. But
it's all in the 'wild dreaming' kind of phase, there's privacy concerns, and
you'd want such a thing to be VERY opt-in. But it's a cool idea.

------
grayrest
If you're interested in checking out the progress, the build process[0] is
really easy.

Here's the current page:
[http://i.imgur.com/NmRNaRz.png](http://i.imgur.com/NmRNaRz.png)

If you want to poke around more, servo shell[1] lets you switch starting pages
without having to re-run from the command line.

[0] [https://github.com/servo/servo](https://github.com/servo/servo) [1]
[https://github.com/glennw/servo-shell](https://github.com/glennw/servo-shell)

~~~
Manishearth
Not only is it pretty easy to build, it's also pretty easy to contribute to!

We have a bunch of easy issues
([https://github.com/servo/servo/labels/E-easy](https://github.com/servo/servo/labels/E-easy))
and are willing to mentor people on them.

~~~
frdmn
This is really a great idea. Thanks for mentioning this!

------
kbrosnan
Direct links to the tweets that prompted this article.

Github -
[https://twitter.com/pcwalton/status/633411771617832961](https://twitter.com/pcwalton/status/633411771617832961)

Ars -
[https://twitter.com/pcwalton/status/631961638304804864](https://twitter.com/pcwalton/status/631961638304804864)

~~~
haberman
Really curious to hear more explanation of this comment from Patrick:
"Printing is pretty incompatible with parallelism though." Is he saying that
Servo as a parallel engine won't be able to handle printing?

~~~
smt88
It's likely possible to work around that limitation. For example, Servo could
render to a binary image and then send _that_ to the printer.

~~~
pcwalton
That's not the problem. We could easily run our parallel screen layout and
then just use Skia (or the local system)'s PDF backend. The trouble is that
this doesn't implement the printing spec. As Simon mentioned above, the
problem is the various CSS rules that control pagination.

------
tbrock
Is multithreaded rendering really the next big browser breakthrough? If so,
are Google and Apple also working on similar projects?

~~~
qznc
I don't think it will feel like a breakthrough. On the desktop the network is
the bottleneck, not the rendering. However, it might save energy on mobile
multicore devices. That is nice, because on my smart phone the browser really
drains the battery.

~~~
_pmf_
> However, it might save energy on mobile multicore devices.

Multicore devices shut down cores to save energy. How would multithreaded
rendering save energy?

~~~
grayrest
Processor power use scales with frequency as well. See [0], specifically the
'Low Memory and Power Devices' section, which shows power savings running 4
cores at lower frequency versus 1 core at max frequency. I think they
eventually decided that running at max frequency on all processors and
sleeping wound up being most efficient but that's my memory and could be
completely incorrect.

[0] [http://blogs.s-osg.org/servo-adapting-c-to-work-on-the-
web/](http://blogs.s-osg.org/servo-adapting-c-to-work-on-the-web/)

------
leeoniya
nice. i wish the blog was updated more frequently -
[http://blog.servo.org/](http://blog.servo.org/)

~~~
Manishearth
This is entirely my fault. I was the one writing This Week In Servo blog
posts, and I had a rather busy internship over the summer which didn't leave
me much time to write the blog posts. And now I have a rather busy semester --
I probably could carve time out to start writing again, but right now I'm too
swamped to do it. I'm glad you enjoyed the posts, though!

Following [http://twitter.com/ServoDev](http://twitter.com/ServoDev) can keep
you up to date for now.

~~~
jxn
Thanks for the write-ups that you did. It's so much more tempting to
contribute to a project when there are active public summaries of work being
done. Sometimes, I admit, I don't even bother submitting my pull requests on
projects with 50 unmerged PRs and no activity. When I see evidence of a
progress and organization like those blog posts, it makes me want to
contribute even if I don't necessarily have a personal itch to scratch.

I'd love to see more posts soon, if you or someone else ever gets the time*!

------
Scarbutt
Mozilla really needs to step up its game and start innovating, a technically
"superior" browser won't make it gain market share against Google, Microsoft
and Apple, these three have powerful platforms to promote their browsers, what
does Mozilla have? Firefox's usage is declining every day at a fast pace.

I'm amazed to see how much average Joe users have Chrome installed with no
help from anyone.

Edit: Want to add that I wasn't taking a stab a Servo, which is a truly
awesome project on its own no matter what's going with Mozilla.

~~~
pcwalton
This is a truly bizarre comment. Can you elaborate as to how Servo is not
"innovating"?

~~~
Scarbutt
With the "innovating" part I was talking about Mozilla in general, not Servo.
Servo is innovating in the web browser space, no doubt about that, but will
that really be enough for Mozilla to compete with others browsers which have
big platforms supporting them? I'm talking from a business angle here.

~~~
pcwalton
The only charitable interpretations of this comment I can figure out are
either "Mozilla shouldn't bother improving its core technology because it's
doomed anyway" or "Mozilla should build a 'native' OS stack to push its
browser", which are gratuitous negativity and off-topic/silly, respectively.

