
Steam store rendered in Servo - jontro
https://twitter.com/jruderman/status/580888265642770433
======
davvid
I'm a C++ developer, and Rust looks very exciting to me. Maybe I'm optimistic,
but Rust really looks like it can be a serious C++ contender in the long run.

Talking with other C++11/C++14 users here, the general feeling is that, yes,
C++ is a good language because of the performance you can get out of it and
some of the nice features that have been added, but the language carries
around a lot of cruft that is unavoidable due to its age and maturity.

C++ has always been an expert's language. These days it's the expert's expert
language++. There are no shortages of landmines and gotchas in the C++
landscape.

Modern C++ is a new language, and it really does help, but for the first time
there's another language that can actually fill those same shoes.

A really big deal that isn't really addressed by golang is the fact that you
can produce shared libraries with rust, and call them from existing C/C++
programs through a C interface. That's a really big deal in places with a lot
of legacy code.

Another big deal (from the scientific computing POV) is the lack of garbage
collection. Yes, GC is helpful, but replacing C++ means squeezing every last
bit of performance out of your hardware. Rust does not sacrifice in this
regard.

I really hope that Rust has a bright future. It's almost like "C++ done
right", but I would stray away from such a label since someone might Linus you
and say, "there's no way to do C++ right".

I also view golang as the successor to Python. It's faster, modern, addresses
concurrency, and makes things easier for developers. It takes a strongly
opinionated stance, and that's exactly the right choice for many problem
domains.

Python, unfortunately, is dead to me. The GIL is a deal-breaker, and even
though we have _lots_ of Python code in production, I can definitely see a
future where Python is phased out in favor of something like golang.

Basically, I'm bullish on Rust + Golang, neutral on C++, and slightly bearish
on Python/Ruby-like languages that do not address the concurrency problem.

~~~
odiroot
Whoa, how is Go a successor to Python, with completely different philosophy?
Especially considering static typing.

It's light years closer to C++.

~~~
cwyers
From a blog post by Rob Pike, one of the designers of Go:

"I was asked a few weeks ago, "What was the biggest surprise you encountered
rolling out Go?" I knew the answer instantly: Although we expected C++
programmers to see Go as an alternative, instead most Go programmers come from
languages like Python and Ruby. Very few come from C++.

We—Ken, Robert and myself—were C++ programmers when we designed a new language
to solve the problems that we thought needed to be solved for the kind of
software we wrote. It seems almost paradoxical that other C++ programmers
don't seem to care."

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

~~~
bsdetector
I don't think that's an accurate portrayal that they were "C++ programmers" as
if to imply they were experts or even proficient at it. Plan 9 doesn't even
have a C++ compiler. From his wikipedia bio, Ken Thompson "later refused to
work in C++".

I think they were surprised that C++ programmers didn't like Go because Pike
and Thompson weren't actually C++ programmers. Griesemer however appears to
know C++ well.

------
kibwen
Preexisting discussion on /r/rust:
[https://www.reddit.com/r/rust/comments/30blul/the_steam_stor...](https://www.reddit.com/r/rust/comments/30blul/the_steam_store_rendered_in_servo/)

Servo's been looking pretty exciting for a while now. I believe they just
passed a milestone where it now implements the CSS rules used by 50% of all
webpages (according to a survey performed by Google), and its performance is
still blowing other layout engines away if preliminary reports are to be
believed (as ever, we'll see if that holds up as they implement more of the
web). Definitely a project to watch.

In other neat news, just yesterday they managed to implement a rudimentary
tabbed browser GUI using only web technologies:
[https://github.com/glennw/servo-shell](https://github.com/glennw/servo-shell)
. Ideally this would be a stepping stone to the more full-featured
browser.html project:
[https://github.com/mozilla/browser.html](https://github.com/mozilla/browser.html)

~~~
pcwalton
Once my two layout PRs (border-collapse and transition) land, we will have at
least _some_ support for every _standard_ CSS property used by 50% or more of
Web pages, as measured by Chromium's usage counters. That does not mean that
the implementations are bug-free or that all features of those properties
work; for example, multiple backgrounds, elliptical radii, and many transition
properties are not yet supported. But it's an important milestone nonetheless,
IMHO.

~~~
weaksauce
What's your estimation on the future of servo? Will it eventually become the
new Firefox or will they just relegate it to a research offshoot?

~~~
bjwbell
Looking at the number of outside contributors shows a bright future for Servo
even if Mozilla doesn't fund it beyond research. It is much much more friendly
to newbies than trying to contribute to gecko or webkit/blink. And webkit
started out entirely unfunded as KHTML.

------
FreakyT
I am excited for Servo. I think it has the potential to act as a real
competitor to the current Webkit ubiquity, which, while not _necessarily_ bad,
probably isn't ideal.

~~~
mmastrac
Agreed. The web has always been healthiest where there are a handful of
independent browsers in the mix. We're sliding down the path of a
ChromeDesktop/SafariMobile duopoly which isn't good for the web.

I'd really like to see Servo start pressuring the big guys and possibly start
winning some of the embedding battles.

------
RobotCaleb
Okay. But what's a servo?

~~~
simcop2387
Mozilla's experimental rendering engine, written entirely from scratch to
avoid a lot of the problems that Gecko and other engines have because of their
age. Along with that they're experimenting with parallelized layout and other
things to get better efficiency and performance.

~~~
theandrewbailey
Mozilla is (planning on) using it for FirefoxOS. They have no plans to do so,
but I'd be happy seeing it in desktop Firefox.

edit: planning on

~~~
muizelaar
FirefoxOS uses Gecko like desktop.

~~~
theandrewbailey
I spoke too soon. They are planning and working on it.

[http://blog.servo.org/2015/02/24/twis-25/](http://blog.servo.org/2015/02/24/twis-25/)

[http://techcrunch.com/2013/04/03/mozilla-and-samsung-
collabo...](http://techcrunch.com/2013/04/03/mozilla-and-samsung-collaborate-
on-servo-mozillas-next-gen-browser-engine-for-tomorrows-multicore-processors/)

[https://github.com/servo/servo/wiki/Roadmap](https://github.com/servo/servo/wiki/Roadmap)

------
Animats
That's very nice. This is great progress for Servo and Rust. It's a screenshot
of a page rendered without any Javascript, though. Here's that page, run
through our service which removes all Javascript, Flash, and embedded code,
parses the HTML, and re-emits cleaned-up HTML.[1] (This tool is normally used
to check how our crawler sees a page.) It looks exactly like the screenshot on
Twitter, once you scroll down past the video they're not showing.

Now they have to interface Servo to all the ugly stuff - the Javascript JVM,
plug-ins, etc.

[1]
[http://www.sitetruth.com/fcgi/viewer.fcgi?url=http://store.s...](http://www.sitetruth.com/fcgi/viewer.fcgi?url=http://store.steampowered.com/app/105600/)

~~~
jruderman
Servo is already hooked up to a (very old) version of SpiderMonkey, but it's
missing enough DOM features that most pages hit errors. This Steam page hits
"ele.canPlayType is not a function", "document.write is not a function", and
"link.href is undefined".

Last I heard, Servo does not plan to support plugins such as Flash. I'm not
sure if the existence of Shumway changes this.

~~~
hsivonen
Fun times ahead if document.write isn't already supported. When I rewrote
Gecko's HTML parsing, accommodating document.write was a (or maybe the)
dominant design issue.

~~~
realusername
I'm quite curious, why document.write is so hard to implement compared to
other methods ? Is it not working a bit like innerHTML ?

~~~
hsivonen
It's quite different from innerHTML, since document.write inserts source
characters to the character stream going into the parser, and there's no
guarantee that all elements that get opened get closed. There's even no
guarantee that the characters inserted don't constitute a partial tag. So
document.write _potentially_ affects the parsing of everything that comes
after it.

For this to work, scripts have to appear to block the parser. However, it's
desirable to start fetching external resources (images, scripts, etc.) that
occur after the script that's blocking the parser. In Firefox, the scripts see
the state of the world as if the parser was blocked, but in reality the parser
continues in the background and keeps starting fetches for the external
resources it finds and keeps building a queue of operations that need to be
performed in order to build the DOM according to what was parsed. If the
script doesn't call document.write or calls it in a way that closes all the
elements that it opens, the operation queue that got built in the background
is used. If the document.write is of the bad kind, the work that was done in
the background is thrown away and the input stream is rewound. See
[https://developer.mozilla.org/en-
US/docs/Mozilla/Gecko/HTML_...](https://developer.mozilla.org/en-
US/docs/Mozilla/Gecko/HTML_parser_threading) for the details.

For added fun, document.write can write a script that calls document.write.

~~~
Animats
What a mess. To support a stupid HTML feature, the browser's parser has to be
set up like a superscalar CPU, retirement unit and all. Hopefully the discard
operation doesn't happen very often.

i86 CPUs have to do something like this if you store into code just ahead of
execution. That was an optimization technique marginally useful in the 1980s.
Today it's a performance hit. The CPU is happily looking ahead and decoding
instructions, when one of the superscalar pipelines has a store into the
instruction stream. The retirement unit catches the conflict between an
instruction fetch on one stream and a store into the same location in another.
The CPU stalls as instructions up to the changed instructions are committed.
Then the CPU is flushed and cleared as for a page fault or context switch, and
starts from the newly stored instruction.

Only x86 machines do this, for backwards compatibility with the DOS era. The
same thing seems to have happened in the browser area.

(Prospective fetching should be disabled on devices where you pay for data
traffic. Is it?)

------
sho_hn
This is significant because there's an ongoing effort to implement the
Chromium Embedded Framework (CEF) API on top of Servo, and Steam uses a
derivative of CEF in its official client application. I'm guessing this is how
the idea of using the Steam pages as a Servo testcase came to be, since Steam
is at least a hypothetical embedding testcase.

~~~
pcwalton
While we are interested in embedding (and there are at least three proof-of-
concept-phase browser shells for Servo as a result), there's no motive behind
using Steam other than that Jesse's a gamer. :)

------
greggman
As anyone here watched the Jonathan Blow videos on his language ideas?

[https://www.youtube.com/watch?v=TH9VCN6UkyQ](https://www.youtube.com/watch?v=TH9VCN6UkyQ)

I don't care about the specifics of his language but I think he brings up a
very valid point which my summary would be, we should design a language that
is both performant AND fun to program. Fun = type less boilerplate, make
refactoring easier.

C++ is not that language and from what I've read Rust is not that language
either. C++ is stuck with backward compatibility so it can arguably never
achieve those goals. Rust didn't seem to have those goals it mind, it had
other goals so it's not really a fun language either. Too verbose or so I've
read.

~~~
pcwalton
For a browser engine, "memory safe" as a design criterion massively outweighs
"fun to program in" (although I do think Rust is pretty fun). Most critical
browser engine vulnerabilities are memory safety issues, and we would be not
be doing our jobs if we wanted to have "fun" at the expense of security.

Jonathan Blow's language is not memory safe, and is not trying to be. That may
well be fine for his domain, but not for ours.

~~~
greggman
Like I said, my point is not about the specifics of his language. It's about
the ideas he discusses. I agree with him that anytime I'm typing 150 lines of
boilerplate on C++ or refactoring things from global function to member
function etc, all the busy work required to do that is depressing. I wish more
language devs would take stuff like that into account when designing their new
language.

