
Servo: Inside Mozilla's mission to reinvent the web browser - brson
http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
======
TheZenPsycho
Why are so many people here on HN so eager to throw away html/css/js, just
because they're a little icky and you don't like to use them?

Do you not realise that means throwing away the _entire web_ , and its history
going back to the early 1990's? Backwards compatibility and platform stability
are GOOD THINGS that we need more, not less of. Lest we perpetually build
content for doomed platforms, and leave no mark, no history on the world.

the better course is evolution, not revolution.

Mozilla has been through every revolution, first hand. They know what they're
doing.

edit: I'm flattered but please vote up the comments relevant to the actual
post.

~~~
protonfish
In my opinion HTML/CSS/JavaScript is the best interface design technology ever
invented. I believe it gets a lot of hate because:

1) Amateurs can use it easily and poorly 2) It is not taught in computer
science class 3) HTML/CSS is not programming 4) HTML docs attempt to be
responsive/liquid as opposed to traditional screen painters.

These are actually good things (and #2 can be fixed) but they represent a
significant philosophical shift that most traditional developers don't want to
accept.

~~~
rimantas
I am an expert in web technology (approaching 15 years of experience) and I
absolutely disagree that that's is the best we have.

Edit: damn, it is more than 15 years already. I've brought home the first HTML
spec printout in 1996 and got first money for the website I've built in 1998.
Still remember fixing <center> bug in IE3 when it came out…

~~~
chris_mahan
I used the web in 1993, in the fall, with mosaic, and grey backgrounds. On a
286. With windows 3.1, and 16 colors.

So that makes it 20 years. (dangit!)

Anyway, I think javascript made a mess of it. The point of the web was to link
documents. JS makes links obsolete, as they now are relegated to JS-app entry
points.

before I get too much in the weeds, I'm gonna go read the article.

~~~
zachrose
Shouldn't calling something "obsolete" mean it's no longer compatible or
practical? Links work! They will always work!

------
haberman
This is so cool, and I love that Rust is being so heavily driven by the
pragmatic needs of an ambitious project like this. As a systems guy, Rust is
the most excited I've been about a new language in years.

~~~
shmerl
Yes, Rust is very promising especially if you look for better alternatives for
C++. I wish it would stabilize and someone could write an in depth and well
structured book on it. I have easier time learning languages that way, when
ideas are explained and well presented, rather than deducing it all from very
lacking documentation. In case of Rust it's even more difficult since it's
packed with new ideas.

~~~
rdtsc
> Yes, Rust is very promising especially if you look for better alternatives
> for C++.

Go kind of wanted that prize. It didn't quite get it.

Many will say how they care about cool features, built-in concurrency, nice
stuff and in the end, when comes to releasing product if performance isn't
there, it won't replace C++.

Some program in C++ because they love the language. They really do. There are
people like that, I've met one, once. Quite often others do it because the
rest of their world does (libraries, coworkers) and performance.

The niche were performance matters (and I understand that is a loaded word so
to speak) is going to be hard to get into.

~~~
Sammi
Go was never supposed to replace C++, it was supposed to replace Java in
server applications. Happily it seems Python and Ruby developers are finding
good use in Go too.

How was a garbage collection language ever supposed to take the place of a
manual memory management language? The area that C++ shines in is systems
programming, and you can't do that with Go, because of garbage collection.
Rust on the other hand, is precisely made for systems programming.

~~~
scribu
> Go was never supposed to replace C++, it was supposed to replace Java in
> server applications.

That is simply not the case. Rob Pike himself describes how we was working on
a large C++ application when he thought of creating Go:

[http://commandcenter.blogspot.com/2012/06/less-is-
exponentia...](http://commandcenter.blogspot.com/2012/06/less-is-
exponentially-more.html)

------
kendalk
I am hoping Servo is going to increase the use of Rust. There aren't many
resources for it at the moment even though it is at version 0.9. I would think
that a language nearing "1.0" would have a wider community by now. Here's
hoping!

~~~
masklinn
> There aren't many resources for it at the moment even though it is at
> version 0.9. I would think that a language nearing "1.0"

FWIW the language is only nearning 1.0 in that 0.9 > 0.8. 0.9 is by no means
the final pre-1.0 release.

~~~
smnrchrds
This conversation resurfaces every time a project gets to x.10 version number,
e.g. KDE SC 4.10. Considering even HN audience which are mostly programmers
find this versioning scheme confusing, I wish we have had settled on another
identifier to separate minor and major version numbers. Something that didn't
have a mathematical meaning. I personally like : and ::

~~~
chrismorgan
One could use the pretty standard tuple notation: Rust (0, 9), KDE SC (4, 10).
It's pretty common to represent version numbers in ways not dissimilar from
that internally…

------
whyme
I would have thought ditching HTML, the box model, CSS and JavaScript to be a
more important objective that should come sooner than this. Or another way to
put this would be: Wouldn't development efficiency/simplicity be more
important than running the current junk in parallel?

~~~
azakai
What's the superior alternative? (serious question)

~~~
TheZenPsycho
In spite of the firmly stated opinion I left elsewhere in this thread, I do
indulge in imagining how all this tech stack could be better.

First things first, I found out the other day that someone actually built the
major part of my vision: Constraints Oriented stylesheets (using cassowary).

[http://gridstylesheets.org/](http://gridstylesheets.org/)

This is how iOS now handles layout. It makes easy things easy, and hard things
achievable. Exactly what you'd want.

Beyond this, I think that html has too many tags. To put another way, the
browser should not generally permit <script> and <style> to exist in the same
context that <em> can exist. onblah= attributes were a terrible mistake that
we'll never be able to undo. It would be cool if there was something like a
<content> tag which, within it, only permits content oriented mark up, while
disabling scripting and styling tags. Likewise, forms, scripting, meta tags
and linkages should be in isolated contexts.

And finally, what idiot decided that & ampersands should have a prominent
position in many URLS and then use & for entity encoding in html, a completely
different purpose. URLS now have to be
[http://entity&amp;encoded](http://entity&amp;encoded)

uhg. so stupid. what would be wrong with <amp> or <amp/> instead? or since
we've freed up & for normal expected use, <gt> <lt> and <quot>

ah well.

~~~
groks
> ...what idiot decided that ampersands...
    
    
        example.com/?a=1&b=2
        vs.
        example.com/?a=1;b=2
    

The second example doesn't need to be encoded in HTML.

[https://stackoverflow.com/questions/3481664/semicolon-as-
url...](https://stackoverflow.com/questions/3481664/semicolon-as-url-query-
separator)

~~~
TheZenPsycho
And that would be great if it didn't inadvertently break certain browsers,
proxies, web servers and parameter parsers. Back in the day the advice was you
could use & or ;. TBL had subtly different semantics in mind for them though:
apparently ; was meant to represent some coordinates in some spacial system
while & was the normal query parameter separator.

Somewhere along the line, for some reason, everyone settled on & and the web
ossified around the assumption that was the only character that ever gets
used.

------
pdknsk
Reads like the original Chromium manifesto (comic), plus goals for Blink.

[https://chromium.googlecode.com/files/chromecomicJPGS.zip](https://chromium.googlecode.com/files/chromecomicJPGS.zip)
[http://www.chromium.org/blink](http://www.chromium.org/blink)

~~~
azakai
The goals are shared, which is not surprising - everyone wants faster, safer,
more parallel, etc.

But the means are extremely different between those projects.

------
piyush_soni
I hope when they are rewriting the browser with modern architecture, they keep
in mind the problems which kept this bug alive for more than 12 years now
(while all other major browsers fixed it one by one), citing 'foundation' or
architectural problems:

[https://bugzilla.mozilla.org/show_bug.cgi?id=78414](https://bugzilla.mozilla.org/show_bug.cgi?id=78414)

~~~
pcwalton
There are currently no plans to support plugins, so that bug is not relevant
to Servo.

~~~
piyush_soni
You mean that will again be an 'after thought'?

~~~
fabrice_d
No, we won't support plugins at all.

~~~
pcwalton
Nit: I wouldn't say we _won 't_, but there are currently no plans to.

~~~
mercurial
In the hypothesis Servo becomes Firefox's engine, this will be a blocker for
Danish users. The government-mandated Nem-ID scheme uses a Java applet, and is
used everywhere (taxes, banks, school system...).

~~~
mbudde
A javascript version of Nem-ID is planned for release in 2014 [1].

[1]: [http://www.nets.eu/dk-da/Produkter/Sikkerhed/NemID-
tjenesteu...](http://www.nets.eu/dk-da/Produkter/Sikkerhed/NemID-
tjenesteudbyder/NemID-JavaScript/Pages/default.aspx)

~~~
mercurial
Thank you. Then apt-get purge icedtea-7-plugin icedtea-6-plugin is planned for
execution in 2014 as well.

------
higherpurpose
> Mozilla on how its Servo engine will throw away the 20th-century baggage
> that holds back current browsers and harness the power of modern multi-core
> smartphones and tablets.

Then I hope they don't intend on supporting any 32-bit platform. Make a clean
start on 64-bit platforms. By the time Servo is out, there should be 64-bit
ARM processors cheap enough even for their low-end phones, and on a desktop it
should be a nobrainer.

~~~
sanxiyn
As a matter of fact, Servo was broken in 32-bit for quite some time, although
it isn't at the moment.

~~~
lastontheboat
No, it's definitely still broken on 32bit platforms. It does not even finish
building right now.

~~~
sanxiyn
Doesn't it build on Android, which is 32-bit?

~~~
rat87
Maybe he meant x86 as opposed to ARM(32 bit)?

~~~
lastontheboat
Correct.

------
friendzis
> "It usually only had one core, clock speeds were lower and you had much less
> memory available to you,"

Yeah, right. Modern browsers already eat up several GIGS of memory, while
super-advenced-zomg tablets boast of 2G. Most have 1G 80% of which is eaten by
the system (and widgets, and other persistent stuff). But not caring about
memory is hype. Because its future, technology, and, you know, Moore's law

~~~
fulafel
It doesn't mean that Servo would use more memory. Current browsers are doing
things like multi-process to trade off memory for security and getting less
safety in return than a memory-safe language would provide.

------
rebelidealist
Another day and another ambitious project by Mozilla. However, when will
Mozilla see these projects thru and give them the proper marketing so they
have a chance to thrive?

~~~
kbrosnan
It is open source. We don't get to have it both ways. Reporters see a slide
deck from FOSDEM [1] and decide to report on it.

[1]
[http://video.fosdem.org/2014/UD2218A/Saturday/Servo_building...](http://video.fosdem.org/2014/UD2218A/Saturday/Servo_building_a_parallel_web_browser.webm)

------
batmansbelt
I wonder if mozilla plans to merge this back into b2g eventually, and how easy
that will be. They have several very exciting projects on the go, but some
seem to be heading in different directions.

~~~
fabrice_d
Yep, I started to hack around b2g and servo build systems to make that happen.
Stay tuned.

~~~
lastontheboat
You're the best.

------
taeric
I can't help but question whether this will actually realize any improvements.
What pages will actually be faster? By how much?

~~~
pcwalton
We have significant signs that this will improve performance on many pages. It
would be too early to quote numbers, but you can run tests yourself if you're
interested.

See "Fast and Parallel Webpage Layout" for some early work by Leo Meyerovich
at UC Berkeley:
[http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/pub...](http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/pubfiles/playout.pdf)

~~~
taeric
Thanks for the link! For running the tests, are you just saying to do this on
servo? Is there a preferred "getting started" page out there?

~~~
taeric
So, the preferred "getting started" of just reading the README on the repo
seems to be working out quite well, actually. Looking forward to having fun
with this.

------
owenversteeg
I love how they capitalize iframe as iFrame :)

------
jessedhillon
I cannot help but think of Joel Spolsky's article about reasons not to do a
complete rewrite of your project -- a lesson he learned after finally shipping
the long delayed rewrite of Netscape Navigator (progenitor to Mozilla)

[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

~~~
coldtea
Well, on the other hand if they haven't done the rewrite, Mozilla wouldn't be
here now, and Netscape would have been an insignificant player like Opera at
best.

So, it might have not worked out for Netscape the company, but then nothing
would have, and at least if worked well for Mozilla the organisation.

~~~
pjmlp
I imagine one has to thank Google for the funding as well.

------
gdiocarez
Very nostalgic!

------
revelation
Mozilla seems like a post-capitalist non-profit for the benefit of bored
programmers everywhere, sponsoring such useful work as "lets rewrite the
browser".

It's not yet another HTTP, HTML, CSS .. implementation that is needed, it's
_making these standards sane_ and fit for 2014.

~~~
checker659
As far as I know (and people don't seem to talk about it all that much), the
core of the browser is borrowed from a browser project called NetSurf (yes,
there are others besides webkit / blink). So, technically, they're not really
reimplementing HTML/CSS/HTTP/What-have-you.

~~~
lastontheboat
Nope. I mean, the parser's from there, but we're replacing it. We wrote a CSS
parser to replace the NetSurf one we used for a bit, and all the layout code
is from scratch. There's a Rust library called rust-http providing us with
networking.

~~~
checker659
I see. Thanks!

