
Mozilla and Samsung Collaborate on Next Generation Web Browser Engine - dave1010uk
https://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung-collaborate-on-next-generation-web-browser-engine/
======
mtgx
To people wondering why Samsung would join this, I think Samsung is a big
believer in the HSA Foundation [1] for heterogeneous computing, and they were
one of the first partners in this along with AMD and ARM.

Samsung seems to believe in having the best performing devices and components,
so it's not that surprising that they want to be at the forefront of the
heterogeneous computing movement.

They also probably see themselves as a competitor against Intel, with both the
ARM ISA that they support and the foundry that they own. In the next few years
there will be a battle between HSA and Intel's Phi co-processor idea, and I
think Samsung is one of the many who wants HSA to succeed (using computing
power from all sorts of processors vs using only CPU's for everything).

<http://hsafoundation.com>

~~~
sanxiyn
This is a great story, but probably not the case. I would be surprised if the
part of Samsung responsible for HSA is even aware of Rust, let alone Samsung
is working on Rust. The semiconductor division is pretty independent of other
divisions.

~~~
hkmurakami
In particular the System LSI group.

[http://www.samsung.com/global/business/semiconductor/aboutus...](http://www.samsung.com/global/business/semiconductor/aboutus/business/overview)

------
ChuckMcM
This is a great announcement and adds some much needed support to Servo/Rust.
I've been pretty impressed with Samsung too. Clearly they want to have their
own seat at the table and they are executing quite well on that desire.

~~~
fudged71
I'm not confident that Samsung is interested in developing the Android
platform, though. They seem to be working on a proprietary ecosystem to
separate themselves from the rest of the Android ecosystem. In fact, this is
probably one of their motivations: to have control over a leading browser that
isn't Chrome so that they can integrate it into their phones as default
instead of Google's solution.

~~~
ChuckMcM
Actually if Samsung wants to be a player I really think they can't afford to
be tied to Android long term. Too much control at Google and Google is another
player and nominally an 'opponent' at some point. Of course their is "Android"
and there is the stuff that Google puts around it. Watching the Chinese
companies add value to the OS install has been instructive as well.

What Android has done has shown the component manufacturers some ways to
expand their markets outside "known" players. Part of the challenge of making
a phone is getting the chip vendors willing to sign off on giving you software
to run their chips (weird I know).

~~~
kragen
That sounds interesting — what kind of value are the Chinese companies adding?

~~~
meric
Check it out: <http://en.miui.com>

~~~
sdoering
Didn't know this. Looks really really interesting. One feature I found
especially nice was the text-message/phone-call spam-protection.

Looked for me to be something like an ignore-list. Something I wish I had here
in Germany, when using feature-phones 16 years ago.

Why nobody ever invented a feature inside their phones, I do not know.

~~~
kragen
My guess is that carriers want to be able to advertise to a captive audience,
and in the US and EU, they can largely choose which phones their users buy; so
killfiles as a feature are verboten.

------
surrealize
Servo is a "high-risk research project"[1], so I've been wondering what would
happen if it doesn't pan out. Rust would still be interesting even without
Servo, but would mozilla still invest in Rust if they stopped working on
Servo?

So it's nice to see some non-mozilla involvement and momentum in Rust/Servo.
Maybe that means that an investment in learning/using Rust is that much less
risky :)

[1] [http://www.mail-archive.com/dev-
servo@lists.mozilla.org/msg0...](http://www.mail-archive.com/dev-
servo@lists.mozilla.org/msg00111.html)

~~~
paulirish
"I think it's premature to start making a roadmap that makes Servo a
competitive product in N years; apart from anything else, such a roadmap is
going to be pure fantasy" -- also from that post, from just 6 weeks ago.
Curious.

That said, having an ARM backend to Rust on Android phones means big things
for the potential of mobile web performance. I'm hopeful!

~~~
bzbarsky
A few things:

1) There is no uniform agreement about the state of Servo. Some are more
optimistic than others.

2) There is a number of unknown unknowns here; that's what makes it a research
project and makes it hard to roadmap. For example doing parallel layout of CSS
involving floats is an actual research topic people are currently publishing
papers on...

~~~
qznc
Does it even make sense to parallelize the layouting? When does it take longer
than a few milliseconds?

I'd rather see DOM-updating (e.g. via Javascript) in parallel to the
rendering. Although, that already leads to problems since rendering changes to
DOM as well.

------
paddy_m
This is really exciting. I'm glad to see rust being used for serious apps.
This is actually the first new browser engine that I know of being written in
the past 10 years.

Good for Mozilla for attempting hard problems in innovative ways.

~~~
hobbyist
I am not well-versed in the browser designs, could you highlight what hard
problems are you referring to?

~~~
kibwen
Check out the high-level overview of Servo's design:

<https://github.com/mozilla/servo/wiki/Design>

The goal is extremely pervasive concurrency in aspects that no modern engine
has yet begun to approach (and likely could not approach without enormous
effort and/or a full-on rewrite).

~~~
shawn-butler
>> Because C++ is poorly suited to preventing these problems,

It is really hard to take seriously any project that has this kind of nonsense
in its introduction.

~~~
steveklabnik
I think you're being downvoted because if anyone knows about the pain of using
C++ to develop a browser engine, it's Mozilla. They have some pretty strong
empirical evidence to back up their statement.

~~~
shawn-butler
No, you don't bash a language for failures of the people using it. It is
hyperbole unsupported by any evidence and it is precisely this mentality that
keeps our profession on the Greatest New Thing(TM) every x years treadmill for
better or worse.

Language bashing/trolling serves no purpose.

I am rather most likely being downvoted because HN in the past few months has
taken an extreme downturn towards a slashdot/herd mentality, but that is just
another pendulum swinging.

~~~
acdha
> I am rather most likely being downvoted because HN in the past few months
> has taken an extreme downturn towards a slashdot/herd mentality

You're being downvoted because you clearly have no idea what you're talking
about. It's entirely appropriate to criticize a language for being too hard to
use correctly - your argument would apply equally well to saying that C++
should never have been created because it was simply the fault of people using
earlier languages not using them sufficiently well.

This approaches dark comedy because you're also criticizing a company which
maintains one of the largest and most important codebases in existence and has
a huge list of bugs and security issues demonstrating that even in the hands
of very experienced developers it's too easy to use C++ incorrectly.

~~~
shawn-butler
Oh, so you think the statement that was quoted was that c++ was too hard to
use? Because when you read what was actually quoted it says c++ is poorly
suited to solve issues related to data races and parallelism which is a pretty
false statement.

Are you able to see how that is different now with a little help? Or is it so
insufficient to make up straw arguments and put words into my mouth that now
you want to do the same for Mozilla foundation?

------
ksec
I am actually surprise this pieces was written by Brendan, given the way
Mozilla has been moving lately with asm.js, PDF.js and Shumway which is like
Flash.js; It wouldn't be surprise if their Next Goal were to built the Entire
( or Most of ) Browser with Javascript.

I am surprised that Samsung decide to help. Which basically reads to me as
relationship with Google is going pretty bad or they are simply hedging their
bet.

It was only earlier today I posted that Yahoo should also have a few engineers
helping Mozilla to develop Servo.

And i really really hope Servo is licensed like Rust, Dual MIT + Apache 2.0

~~~
ConstantineXVI
Google pays Mozilla to push Google Search, not to develop a browser (which
Google can do just fine on their own). It doesn't really mean much that
they're teaming with Samsung for Servo, other than Samsung's taken an interest
in using Servo for their own products.

Note it's not mentioned exactly which division of Samsung they're working
with; they may want Servo for Tizen, their Smart TVs, to ensure it plays nice
with Exynos, or none of the above.

[EDIT: the post explicitly mentions porting Rust and Servo to Android and ARM;
which rather strongly suggests the mobile group. Interesting, as FirefoxOS and
Tizen are more or less aimed at the same markets]

~~~
sanxiyn
I think it is "none of the above". Servo, right now, is cloudcuckooland stuff;
this suggests it is a long bet research, not tied to any particular product
division. Samsung probably has Tizen, Smart TV, Exynos in mind, so you could
equall say "all of the above", but I think "none of the above" is more
accurate description.

------
dave1010uk
While this mentions Android, I think the biggest winners in this could be
Mozilla and Samsung's own mobile OS's: Firefox OS and Tizen respectively. I'm
hoping that if they're collaborating on Servo then the 2 platforms will
hopefully become fairly interoperable (in terms of app portability).

Some further details about Servo and Rust can be found here:
<http://www.mozilla.org/en-US/research/projects/>

~~~
ajross
A browser engine is an awfully portable thing. For a consumer, switching
between them (e.g. from Firefox to Safari, whatever) is just a question of
minor UI skinning. I don't see that it "benefits" any OS in particular.
Assuming it's universally better, Android and Tizen would need to port from
WebKit and Firefox from Gecko. If it confers a true competitive advantage,
they'll all do it. If not, some probably won't.

For myself, I'm skeptical. There's really nothing "wrong enough" with Gecko or
WebKit that I can see another option really being that much better. Developers
_love_ to rewrite stuff (obviously both Gecko and WebKit are _already_
effectively rewrites of pre-existing technologies), but the market has a long
history of not being nearly as enthused. But I'm willing to be proven wrong.

~~~
coldtea
> _Developers love to rewrite stuff (obviously both Gecko and WebKit are
> already effectively rewrites of pre-existing technologies), but the market
> has a long history of not being nearly as enthused._

Actually your examples nullify your argument.

Mozilla would be dead today without Gecko, ie with the old Netscape code
piled.

KHTML would have gone nowhere much if it wasn't for the Webkit rewrite.

So in both cases, it was the rewrites that made those engines break out.

~~~
ZeroGravitas
And KHTML itself can be (and was, by many) regarded as a pointless rewrite of
Gecko, which seems crazy now we're aware of its impact.

~~~
Samuel_Michon
Surely the impact of Webkit has been greater than that of Gecko? Webkit made
decent mobile browsing possible, and until recently Gecko wasn't available in
mobile browsers.

Gecko did put a dent in desktop browser usage share early on (when Safari was
Mac-only, and Safari for Windows has never caught on – for good reasons), but
the desktop is quickly becoming the second screen. Nowadays, most sites are
built for Webkit first.

~~~
nnethercote
You seem to have overlooked the whole "Firefox basically saved the world from
an IE monoculture" thing that happened in the mid-2000s.

~~~
Samuel_Michon
Safari was released in January of 2003. Soon after, Microsoft ceased
developing Internet Explorer for Mac. Almost two years later, Firefox 1.0 was
released, and it took quite some time after that for it to become a good
browser. In the meanwhile, plenty of us had been using a Gecko based browser
for years: Netscape.

------
msutherl
It's awesome that language design is being promoted as a significant part of
this project. Good design from the ground up.

------
pjmlp
Nice to see Rust gaining traction.

We need to have more safe alternatives for systems programming.

------
leeoniya
Samsung is really making good use of the hacker community. They hired
Cyanogenmod lead dev last year to collab on Android, too.

~~~
smacktoward
It was back in 2011. And he's already moved on:
[http://www.theverge.com/2013/3/25/4144226/steve-cyanogen-
kon...](http://www.theverge.com/2013/3/25/4144226/steve-cyanogen-kondik-
departs-samsung)

~~~
leeoniya
wow, funny coincidence that news just broke a few days ago. good to know.

------
jusben1369
"X is an attempt to rebuild the Web browser from the ground up on modern
hardware, rethinking old assumptions along the way. This means addressing the
causes of security vulnerabilities while designing a platform that can fully
utilize the performance of tomorrow’s massively parallel hardware to enable
new and richer experiences on the Web."

Probably says more about how long I've been around but I think I've read a
mostly similar paragraph 5 to 6 times over the last decade.

~~~
raldi
Mozilla, Firefox, Chrome, Safari, and I think one of the IE's too. And now
this. So yeah, 5-6 is a good estimate.

Edit: Also the original Netscape.

~~~
fzzzy
None of those were from the ground up. Mozilla was based on the netscape
codebase, firefox was based on the mozilla codebase, safari was based on the
khtml codebase, and chrome was based on the webkit codebase. IE I'm not sure
about, but it seems unlikely that they started from the ground up, surely
newer ie uses code from older releases.

~~~
fpgeek
You're right. Internet Explorer was originally based on Spyglass Mosaic. [1]

[1] <http://en.wikipedia.org/wiki/History_of_Internet_Explorer>

------
MatthewPhillips
This will be a big win for faster web apps. DOM performance is the biggest
blocker to having a smooth experience in the browser nowadays, not JavaScript
speed.

~~~
neoeldex
IMO not the performance of DOM but the DOM itself is the biggest blocker to a
good experience (user and dev)

~~~
coldtea
In what sense? And what do you propose replaces it?

~~~
lenkite
The DOM should have been a cursor based or perhaps a pull-based API.
Everything being an in-memory tree was OK a decade ago but not today the node
count in the millions across browser tabs.

Dom funcions could have been generic ala C++ STL style for iteration
restrictions

~~~
tantalor
Your comment surprises me. Maybe I don't undertand the DOM as well as you?

I don't think a DOM tree is necessarily all in memory. For performance reasons
you might cache the tree in memory, but that's not a requirement.

You have to query it, right? Of course you can query for the same element
multiple times, so it's not cursor-based. But the engine can generate the tree
in response to user queries instead of storing the entire tree in memory.

What do you mean by pull-based API?

~~~
lenkite
All the DOM implementations I know store the DOM tree in memory. Because DOM
allows unrestricted, write access to any portion of the tree at any time, a
disk cache would work well for some access patterns and fail for others. Yes,
you can point out that browser implementations don't hold heavy weight DOM
node _content_ in memory. (Usually just a pointer), but that doesn't remove
the fundamental problem that the API has mostly restricted the choice of data-
structures and limited the set of performance optimizations.

I probably should have not used the term "pull based api", since that is just
a fancy word for a cursor based api.

Example could be SQL - we get a result set after a query exection and can
iterate over the elements of the result set. SQL databases can be implemented
in a wide variety of ways. (Though best practice has condensed this to a few).

A browser api that had a query language to get different types of node
cursors: read-only, appendable, live, etc and some well-defined, optimizable
operations on such cursors would have allowed implementors to choose a wide
variety of data-structures/algorithms for optimization.

------
adamisen
If Google is paying Apple $1B/yr to be the default search engine on iOS, it
stands to reason that Samsung could negotiate similar per device rates. That
seems like enough potential upside for this to be a no-brainer to me.

------
cromwellian
I'm no lover of C++, but I'm skeptical that it's really that much more
difficult to achieve this design in C++. The parallelism shown is still fairly
coarse grained and amenable to traditional techniques. It may be more
convenient or less bug prone with Rust, but I read as more substantial, the
redesign and rewrite from the ground up. If the redesign was using C/C++,
they'd likely get the same benefits, just with uglier code.

Isn't it more likely that lessons learned in Servo will simply be back-ported
to C++ in Firefox?

~~~
smosher
You can write equivalent programs in C++, but if you learned Rust well I am
not sure you'd want to.

 _The parallelism shown is still fairly coarse grained and amenable to
traditional techniques. [...] If the redesign was using C/C++, they'd likely
get the same benefits, just with uglier code._

I should hope so, Rust's parallelism is nothing new after all! (Okay, I know,
you probably mean by writing programs using explicit mutexes and all that.) I
really want to talk about the second part of the quote: what exactly are those
benefits? I think you've excluded safety for some reason.

If Servo offers competitive performance I think it's most likely the whole
engine will simply replace Gecko. I mean why would you spend the time and
money to go from the safer to the less-safe code when you can use what you've
got?

~~~
cromwellian
There's obviously benefits in using better languages for safety and error
checking, it's one of the reasons why I like Closure Annotations/GWT/Dart over
raw Javascript because of my experience on large projects and relatively
simplistic bugs silently propagating through.

The traditional response to these kind of language imperfections is "better
tests, better practices". Otherwise as, Unit Tests solve all problems. For
C++, someone would say to use some set of abstractions or static analysis
tools that confers additional safety that isn't available in the out-of-the-
box language.

Language level support tends to encourage more consistent usage of something
than just depending on vigilance.

My metapoint though, is that large code bases are hard to displace, especially
if the enduser benefits can be achieved through iteration. Rewriting Gecko
from scratch in Rust is a tall order, considering how long it took Gecko and
WebKit to get to where they are now. It seems much more likely that
WebKit/Gecko can be refactored to get most of the benefits in a much shorter
period of time than a rewrite.

~~~
pcwalton
"The traditional response to these kind of language imperfections is "better
tests, better practices". Otherwise as, Unit Tests solve all problems."

The security vulnerabilities found in all browser engines stemming from things
like use-after-free suggest otherwise.

"For C++, someone would say to use some set of abstractions or static analysis
tools that confers additional safety that isn't available in the out-of-the-
box language."

It's really, really hard. The language works against you at all levels. Type
systems are much easier ways to achieve the same result.

------
_pmf_
What's in this madness for Samsung?

~~~
dave1010uk
My guess is it may reduce their dependence on WebKit, which is mostly
"controlled" (for want of a better word) by Apple and Google, their main
competitors.

~~~
icambron
"Driven" would be my choice of words there.

~~~
leoc
'Controlled' is honestly pretty accurate. In principle anyone can fork WebKit;
in practise it would take major investments on the three fronts of engineering
effort, standards politics and mass user adoption to make a WebKit fork that
"matters" - one that web designers would worry, and have to worry, about being
compatible with. If you don't have both the resources and the desire to do
that, then you have to play nice with Apple and Google - or with one of their
two remaining competitors.

------
ancarda
Any idea when Servo might make it into Firefox desktop builds?

~~~
Ygg2
A rough guesstimate would be five to ten years. Don't hold your breath either
way. Right now Rust is not very optimized and still in flux, while Servo is
pretty much a black box for me.

