MALE SPEAKER: Let's do it.
MALE SPEAKER: I've been at
Google for almost a year now,
and one of my favorite
things about working here
is the availability of people
who have the real in depth
knowledge of how
the browser works.
And a lot of the assumptions
I had as a developer just
didn't hold true, and they
were able to show me why.
So it's great to bring
that to a wider audience.
So for the first talk today,
please give a warm welcome
to Greg Simon and Eric Seidel.
MALE SPEAKER: Yes
GREG SIMON: Thank you.
Is this on?
Perfect.
All right, terrific.
I'm Greg Simon.
I work on the Blink
team here at Chrome.
ERIC SEIDEL: And
I'm Eric Seidel,
also work on the Blink team.
GREG SIMON: So when Eric
and I were coming up
with a plan of what we were
going to talk about today,
we tried to put
ourselves in your shoes
and said, what would we like
to hear from the people working
on the actual browser engine?
What do you have-- what's coming
new in the next six months
that I can use?
And what have you been doing
sense you forked WebKit?
And so that's basically the
structure of our talk today.
We have three sections.
You need to push this one here.
And it doesn't work.
How did we get there?
How did we get
here, meaning what
happened since we forked WebKit?
And what we're going
to be doing-- you know,
this isn't working that great.
And how can I best influence?
Because at the end
of the day, the folks
that work on Blink
at Chromium really
work for you guys, right?
We publish a new
developer API basically
every six weeks because
that's what Chrome's shipping
schedule is.
So we're going to
start by having Eric--
he's going to talk
a bit about what
we've done since we forked.
And we're actually really
fortunate to have Eric here
today.
He's worked on the source code
base for about eight years,
right?
ERIC SEIDEL:
Something like that.
GREG SIMON: The longest of
anyone on the Chrome team.
ERIC SEIDEL: So yeah.
So Blink.
Blink, very exciting.
Or at least, very
exciting for us.
As Greg mentioned, we've
been here about eight months.
April 4 was our big D-day.
We were WebKit or part
of the web community,
and we forked to have Blink a
separate open source project.
First thing we did is we deleted
half our source, half of which
we didn't necessarily need.
And then we've
spent a lot of time
taking our tangled
integration with Chrome
and trying to make it look
a little bit more like this.
We're still maybe not done.
But what I want to
talk about first
is non-code changes to Blink,
but rather process changes.
Because I think this
is the part that most
affects the people in
this room, in this room
and on the live stream.
This is the part that's maybe
most observable to those
who don't hack on
the Blink code base.
So one big change that we made
is we added an intents system.
We wanted to make sure that
our decision making process
for what we change
about the web platform
is an open process and one
that you can participate in.
So every time before we're going
to change the web platform,
we send a public announcement to
Blink dev announcing our intent
to add a feature or
to remove a feature.
Then we go off, and we code it.
And then the very next
day after it's checked in,
it's already there shipping
in our canary builds.
It's off by default, but you
can turn it on using about:flags
experimental feature.
We get feedback from
you during that process.
We get feedback from
our own internal testing
or testing in the
open source project.
And then the second
email that's sent, again,
to our public mailing
list is an intent to ship.
And this is where we evaluate,
is this feature far enough down
the standards process?
Do web devs like it?
Because again, the feature that
we implemented behind that flag
is the exact feature
that is specified
by the spec, no
prefixes, no nothing.
And then once it's approved
by the community to say,
we can commit to
this indefinitely,
then it appears in Chrome.
So even if you're not
following on our mailing list,
we try to make it
very easy for you
to be informed as to our
feature development process.
If you go to
chromestatus.com, you
can see the features
that we've worked
on, the features that
we've shipped, the features
that we're planning
to deprecate.
And even if you're not
paying attention to that,
we announce all feature changes
on the Chromium Releases blog
with links to bugs, which
you can get to the tracker
dashboard, which you can get
to the original discussions
on the mailing list.
I actually forgot to mention,
on the tracker dashboard,
you can edit this.
We try to track not just
Chrome changes, but also
the status of these
features in other browsers.
And if you have
information about that,
you can request edit access
and change it yourself.
So another big
policy change which
affects, again,
particular web developers
is that this webkit prefix that
we had in the WebKit world,
we're trying to
remove from Blink.
And additionally,
we have no plans
to add a blink vendor prefix.
We think this is a good thing.
Instead, we implement
features exactly
as they're specified behind
a runtime flag, which
means that you can access
them way sooner than you used
to be able to before,
when we implemented
behind a compile time flag.
So to talk about other code
changes that we've made--
or so that was
some process bits.
Let's talk about some code.
We've removed lots
of code, as we
mentioned in the very
first slide, including
a bunch of broken WebKit
features or features of the web
platform that were added 20
years ago but never worked.
We have not done
this in the dark.
We have done this using
data, anonymously reported
aggregate statistics by Chrome
users who opt in with the,
I want to report my
anonymous usage data.
And this is, again, all public.
You can go to
chromestatus.com, and you
can see here we're tracking
the usage of CSS features
across the web.
So if you scroll down
this list, you'll
see ones that are used
in 0.0001% of websites.
And those are the ones that
are on the chopping block.
So yes.
So other code changes.
One of the major
focuses that you
heard Linus talk about, which
you've heard other talks talk
about, is that we live
in a multi-platform web
or a multi-device web.
And it's important
for consistency
across those devices,
something we've not
done super well at up until now.
And so one of the focuses
of the last six months
has been to try and improve that
story across versions of Chrome
and across now
versions of Blink.
A big part of that was
shipping Android WebView.
But you can see we still have
a lot of work ahead of us.
This is a benchmark
on the web, HTML5Test,
which shows that, yeah,
things are getting way better.
We're much closer
to desktop in terms
of having one set of web
platform APIs everywhere.
But we're still not quite there.
So to demo the, at least,
getting better part,
Greg is going to give us a demo
of one of the new features that
shipped in the latest Android.
GREG SIMON: Yeah.
This is the-- so one
of the most requested
features in Chrome and
Android was the Web Audio API.
And we finally have it working.
What it is-- it's
a JavaScript API
that lets you assemble audio
graphs with different sort
of audio processing
nodes, things
that you wouldn't normally write
JavaScript to actually run,
because they're fairly
performance sensitive.
And so you can do
very, very cool things.
[TECHNO MUSIC PLAYS]
ERIC SEIDEL: [INAUDIBLE]
GREG SIMON: Yeah.
ERIC SEIDEL: Which is the--
GREG SIMON: It's the camera.
There it is.
ERIC SEIDEL: There you go.
GREG SIMON: OK.
Cool.
And we're live.
So here, I've got-- I'm
just playing a loop.
And as I drag my finger,
I'm changing parameters
on a biquad filter that is
part of the audio processing
[INAUDIBLE].
[TECHNO MUSIC PLAYING]
GREG SIMON: So I
can be my own DJ.
And again, this is a very
small amount of code.
But these are things that people
like to do, so here it is.
ERIC SEIDEL: And you
couldn't do before Web Audio.
GREG SIMON: It's also really,
really useful for games
because you can
actually place sounds
in different parts of space.
ERIC SEIDEL: So we're
making lots of changes.
And as you saw, we're
removing lots of code.
But one of the things we
were asked to talk about
in this talk was a
little bit about how
the sausage gets made.
What happens behind the scenes?
And to, I guess,
reassure that we're
working very hard to make sure
that we aren't breaking things
as we go.
So one of the things we do to
keep the wheels on the wagon
is a lot of testing.
Every single change
we make to Blink
is tested immediately
by over 30,000 tests.
And that's just the Blink tests,
not to mention all the Chromium
tests that run
additionally later.
And you can see, again,
all these are public.
You can see all our
thousands of bots.
You can see some of
the tools that we
use to diagnose failures.
You don't need that
necessarily for your worlds,
but it's public in
case you want it.
Also, we focus a
lot on security.
There's a link at the bottom
you can click to learn more.
But we have systems that
throw millions and millions
of broken web
pages at our engine
to make sure it
doesn't fall over.
And sometimes when
I make a change
to one part of the web
platform that interacts badly
with another part
of the web platform
that you didn't necessarily
expect, this sort of system
catches it an hour later.
It's kind of amazing.
We do the same kind
of things with speed.
We have thousands and
thousands of benchmarks
that we run on every change.
And we have 24 hour sheriffing
of these bots and these graphs
that alert us when
we've regressed speed.
And then they have
a little button here
we can click to bisect and
find out exactly which change
caused that speed regression,
very powerful technology.
GREG SIMON: Yeah.
This was something that
we realized last year.
We had way too many
graphs, that we
couldn't have humans
track them anymore.
So we used some
signal processing that
was available from
inside Google to actually
not only detect when
things get slower,
but when things get faster too.
So we have a perf
increase of the week
email that gets
sent out, et cetera.
It's very, very cool.
ERIC SEIDEL: Very
much a focus of ours.
We're also not just
trying to not get slower.
We're also focused
on getting faster.
One of the things that this
same team produced for us
in the last couple months is--
they ran a million websites
on Desktop through the browser
and took aggregate statistics.
And they also did the
top 25K on mobile.
Mobile's significantly slower.
So it takes a lot
of hours in mobile.
And what you can see
on this is-- this graph
is actually really
very depressing to me
because the blue and
the orange is you,
and the rest is us
getting in your way.
And that's a problem.
It's something we're very
aware of and actively working
on fixing.
And the graphs have actually
gotten a little bit better
since then.
We've started to tick away
at the low hanging fruit.
But we have a long way to go.
So Greg's going to talk about
what else is coming down
the pipeline.
GREG SIMON: Cool.
Thanks, Eric.
So what new APIs, what
new performance parts
are you going to see
in the next six months?
Well, first of all, a
biggie is Web Components.
Now this is something that Eric
Bidelman covered pretty well
in his talk about Polymer.
We've been working on this
for almost three years.
Of course, nearly every
JavaScript UI framework
has its own component
model because that's
sort of boilerplate
for doing UIs.
And it means that you have
to buy in totally to one
framework.
And it's very tricky
to mix and match them.
So we decided three
years ago to work
on building this functionality
into the platform
to make UI frameworks
much more lightweight
and also fix some of the name
spacing problems that you have.
So there are three parts.
There's the Shadow DOM, where
you can encapsulate DOM,
so it can't be walked
through or seen, et cetera.
We've actually been shipping
this for-- the video player
works with this.
This is even prior to
us forking on Blink.
We have custom elements
where you can actually
create your own tags so that
your code looks much more
readable.
And we also have
HTML imports, which
aids with pulling
in blocks of content
or pulling in actual components.
So this is coming soon.
We have a last call on custom
elements for this month.
The other two,
we're working hard
to get the specs
in a shape where
we feel that we can ship it.
But you don't have
to wait for that.
You can start using it today
because we've written polyfills
for every evergreen browser
that implements all three
of these things.
So when Chrome
actually turns it on,
things will just get
faster if you ship today.
Web animations.
So for UI these days,
having silky smooth,
complex movement is
now table stakes.
And so you can't--
so we realize this.
And so we've been working
for the past six months
on a new animation
back end that's
going to replace the one
that drives SVG and also
the one that drives CSS.
And we're also
going to be exposing
a new API called the
web animations API.
Now what's cool about this
API is it is timeline based.
So here we have a new
animation object here.
But you can also
group them together.
So you can actually create
fairly complex animations
that are all synchronized.
So let me show you
an example of how
that works after I turn on the
tablet here, after I unlock it.
OK, cool.
So here is a simple
animation here
because you can see I'm
running out of tablet here.
So I've got-- this is actually
much smoother than that.
The problem is it doesn't
seem to capture well here.
I have a few curves here.
And ease in and ease out.
Now of course, we don't have
the native implementation
of web animations shipped yet.
I think it sort of runs, but
it certainly isn't shipping.
This is all done with the
web animations polyfill.
The same team in
Blink that is working
on shipping web animations
and writing the new back
end-- they started
by doing a polyfill.
And that's what
Polymer uses as well.
Another example
of web animations
here-- so here I've got
two separate animations.
And they're going to run
on the same time line.
So they're perfectly in sync.
When you use this
API, you will always
be getting the GPU as well.
So very, very cool stuff.
So that's going to ship
sometime next year.
But as I said before, you
don't have to wait to use it.
You can grab the polyfill and
start using it immediately.
Partial layout.
One of the wonderful
things about the web
is that it does layout for you.
You just throw text at it.
It's the only platform where
Hello World is actually
just the text, Hello World.
Of course, this is also one
of the problems with the web,
that it's doing layout when
you don't really want it to,
like you just want
to reach into the DOM
and measure where
one div is placed.
And what happens is--
the clicker doesn't work.
What happens is we lay
out the entire page.
And so what should
have been a sub
millisecond call ended up
taking 25 milliseconds,
and I just missed a frame.
So we have changed Blink so
it now does partial layout,
meaning it will only lay
out enough of the page
to return the value that
you're asking for from.
And then it will
carefully unwind itself.
Now even though we've
done this already,
we haven't shipped
it yet, because we
have two other problems
that we're dealing with.
One is on Chrome on Android,
we do double layouts
because we have to
do text auto-sizing.
And then on desktop,
we're working
on getting overflow
scroll bars turned on
because the presence
of a scroll bar
causes you to do
extra layouts anyway.
Speaking of text
auto-sizing, anyone
who's loaded a page, a
desktop page in our browser,
and the page author
hasn't set meta viewport,
will see this sort of
behavior where we basically
lay out the whole page.
We try to identify what the
main body of content is.
We set a minimum
on the font size.
And then we lay it out again.
Now the algorithm
could certainly
be improved, as you
can see by this.
We've got-- this is Hacker
News talking about the MotoG,
I believe.
And all this text should be
the same size, but it's not.
So we are working on that
as I speak here today.
But we're also going to
do it in a single pass.
As I mentioned, when talking
about partial layout,
we can't quite
ship partial layout
until we're able to
do just one pass.
So this is coming
very, very, very soon.
CSS Grid.
20 years ago, I worked on
the web browser for the Apple
Newton, actually 21 years ago.
And one of our
features was tables.
And it took a lot of code
to write tables because--
and I'm still
talking about tables,
and it's 20 years later.
Like, what?
It's time for some
improvement in this area.
So CSS Grid was a
feature that was first
shipped by Internet Explorer.
We have it pretty much
fully implemented.
I say pretty much because
the spec is in last call,
but it's still kind of
being pushed around a bit.
You can turn it
on and try it out,
but we expect to ship
this very, very soon.
What's cool about
CSS Grid, of course,
is you can separate the
content from how it appears.
So if you combine this
with media queries,
you can do really great,
responsive design.
Speaking of responsive, images.
This is something that you guys
want, something that we want.
But we don't have it yet.
And that's because
there hasn't been
agreement on what
the API looks like.
There's been many patches landed
inside Blink for-- of course,
they haven't shipped yet.
But there's some
disagreement about whether it
should be picture, srcset, srcN.
I think it's not
going to be srcN now.
I think it's now
srcset or picture.
ERIC SEIDEL: It changes daily.
GREG SIMON: But honestly,
it changes almost daily.
I mean, I did these
slides last week.
And I had to add the
picture tag in yesterday
because that was
the latest news.
I know you may think
it would be great
if we just put our foot down
and just shipped something.
But then we're forking
the web platform, right?
I mean, we really need
to have-- the success
of the web is that
it's consistent.
And so it's important
that we take our time
and get at least one other
browser to agree and ship.
Ideally, we get every
browser to do it as well.
This is also-- sub-pixel fonts.
The fonts on Windows
don't look that great.
They can certainly be improved.
A year ago, we shipped the
change at WebKit-- actually,
a year and a half
ago-- which was we
changed the rendering
precision of the entire tree
to be fixed point.
Prior to that, it was a
mixture of int and float.
If you put a break
point in there
or just paused the program
and looked at the call stack,
it was like float,
float, int, int, float.
And of course, things were
off by one pixel constantly.
We got that fixed.
The last thing to fix,
though, is fonts.,
Of course, looking at
the column on the left,
this looks like a
web page from 1998
when the only font
that you were drawing
was Arial because it was
in C, Windows folder.
And I didn't do
anti-aliasing, because my CPU
wasn't that powerful, et cetera.
The column on the
right is what's
going to be coming very
soon, I think this quarter.
And so you're going to have
not only sub-pixel sizing,
but sub-pixel
positioning as well.
Most web content these days
is consumed on LCD screens.
So you can use ClearType
or, even increasingly,
Retina displays.
So this is important.
Now it's kind of hard on this
overhead to see the difference.
It's very subtle.
Look-- whoa, what did I just do?
I guess I'm printing it.
Who puts a print button
on a presentation remote?
That doesn't seem that good.
That seems like a fail.
Oh yeah, there it is.
OK, cool.
All right.
That's-- oh, well.
Look at this E here.
See, on the left,
it's much more janky.
Very, very subtle, right?
So this is DirectWrite.
This was actually a big change.
Skia, which is the graphic
system inside Blink--
or, I guess, that Blink
uses, to be correct.
It used GDI, which is a
really, really old graphics
API on Win32.
And you have to use GDI in
order to ship on Windows XP.
But starting with
Vista, I believe,
they turned on DirectWrite.
So this is coming very, very,
very soon in a canary near you.
This is a slide provided
by our friends at V8.
V8's not part of Blink, but it's
an extremely important piece
of Chrome and a really important
piece of your life as well.
The speed team-- they
are maniacs about speed,
which is great.
And they'll always be
maniacs about speed
because that's why
it's called V8 and not
V6 or I4 or something, right?
But coming in the
next six months,
we're going to be improving
some of the ES6 support, things
like symbols and
iterators, et cetera,
and also something
called Object.observe.
I'm not sure if Eric Bidelman
covered this yesterday.
But a couple years ago in
Blink, we shipped DOM mutations
where you can set
up a callback so you
know when part of
the DOM has changed.
So Object.observe is a
new ECMASciprt feature
that is the same thing but
for JavaScript objects.
So given any
arbitrary object, you
can watch when
properties on it change.
So if you put two
and two together,
you now have got data binding
natively in the platform.
And it's fast.
Because it's really tricky
to polyfill Object.observe.
We do do it in
Polymer, but it's not
the nicest piece of
code I've ever seen.
OK, cool.
So how can you influence
these features and things
that we work on?
You actually can.
ERIC SEIDEL: Yeah.
As Greg said, you guys are king.
As history has
proven many times,
a platform is nothing
without its apps.
And you guys write the apps.
So we want to know
what you have to say.
If you feel C++ in your blood
and want to write C++ with us,
all of our code is open.
You don't even have
to tell anybody.
You can just simply change it.
Rather, you don't have
to evangelize to us.
You can just simply
post a batch.
All of our code is open.
Our bug tracker's open.
One of the steps on the critical
path to anything getting
changed in Blink-- at least,
anything web facing-- is a bug.
So whether you file that
bug or we file that bug,
again, you guys
know what it should
look like probably
better than we do.
And you have access
to our bug tracker.
You can see what
we're working on.
You can influence
what we're working on.
Another way that internal
web devs, to Google at least,
help us to improve is
through reducing test cases.
Often, a bug will come in,
and we don't necessarily
understand your
complicated web app.
And so helping us to
understand, explaining it to us
like we're five, as
it says on the slide,
is an important step.
Because every change that
we make needs a test.
And so whether you write that
test, or we write that test,
it has to be written.
Longer term is the question of
standards, as Greg mentioned.
Part of the beauty of the
web is that it's ubiquitous,
that it works more or less
the same everywhere you try.
And the way we accomplish
that is through standards.
So they're always looking
for folks like yourself
who understand the web
platform to help the standards
bodies to determine what
the next web platform should
look like.
If we're moving too slow, or
standards are moving too slow,
you can always fix it yourself
in JavaScript to some extent.
And one of the techniques
that has become bigger,
as we mentioned
earlier in this slide,
for us to sort of
test out new features,
for you to test
out new features,
is to simply write it in JS.
And finally, if you
guys do nothing else,
we simply want to hear from you.
That's why we're here today.
That's why we're talking
to the live stream,
that you guys, again, are
in charge of the apps.
And we want to know
what you have to think.
So you can listen in, join in to
our conversations on Blink Dev.
You can talk to us on Plus.
You can talk to us on Twitter.
But we want to hear from you.
GREG SIMON: Yeah.
And we will be around, I
guess, an hour from now.
And we would really
like to hear,
are we working on
the right stuff?
Should we be prioritizing
something different, et cetera?
It really matters to us.
So OK.
ERIC SEIDEL: Thank you.
