JAKE ARCHIBALD: Yeah, so
you've been submitting
your tough questions
to these folks,
and I get to hide behind
those kind of spiky words
and demand some clean answers.
So, yeah, let's
get straight to it.
So this first question, which
has been submitted anonymously,
which is always a good start--
[LAUGHTER]
Add to Home Screen
is pretty good,
but it's not in
the App Launcher.
It doesn't show up in battery
usage or data usage stats
as a separate item.
You know, can we get that?
Grace, do you want to
start us off with that?
It should be on already.
GRACE KLOBA: Is this working?
JAKE ARCHIBALD: Yeah.
GRACE KLOBA: Yeah.
So, we're definitely
aware of this,
and we're working hard to try to
make the Add Home Screen behave
more like a native app.
There are some
complications, like, I
think you mentioned the
battery usage, that we
can try to do a better job,
but for like a data usage,
is Add Home Screen is still
run inside a browser process,
and then onto a platform
that's just a single process,
we have some
challenge to work out.
JAKE ARCHIBALD: But you
think the ultimate goal
is to make these--
GRACE KLOBA: Yeah,
definitely more like,
I mean-- in the
coming year, what
we will try to do is make
it more like a native app
from the user perspective.
Yeah.
JAKE ARCHIBALD: So this next
question is also anonymous.
Is service worker ready?
[LAUGHTER]
DARIN FISHER: What does
the audience think?
JAKE ARCHIBALD: I'm
going to-- yeah,
what does the audience think?
I don't know.
Do you think it's ready?
AUDIENCE: Yeah!
JAKE ARCHIBALD: OK.
Well, moving on.
Well, no.
OK, so we've had like 2.2
billion page loads a day
through Service Worker and 350
million Push messages a day
as well in 2,300
sites using Push.
And yeah, OK, it's at
the moment Chrome-only,
well we have Opera
support as well.
And Firefox support,
they're hoping
to land that early next year.
So it's on their
standards track now.
So yeah, I'd say
it's pretty ready.
But the important thing here is
it's progressive enhancement.
Like, you know,
pages aren't going
to break in browsers that
don't have Service Worker.
And I think-- I really
think that developers
are in a position of power here
that if you start using Service
Worker and you can make your
sites have more features
and run quicker with Service
Worker than without it
then for other browsers,
that's going to show them,
look, you know, if they
want to compete on the web,
they need to have
Service Worker as well.
I reckon.
Just what I think.
If you want to ask
questions during this event,
we also have a microphone
in the middle there.
So if you want to
ask a question live,
then please do come
down the aisle.
It's sort of a weird kind
of wedding venue isn't it?
Especially with all
the white chairs,
but if you want to ask
a question, you can.
Oh, go on then.
Since you've got up.
It's sometimes difficult
to find someone
who's brave enough to
get to the microphone
and that person is you.
What is your question?
AUDIENCE: Hi, I'm Paul.
First of all--
JAKE ARCHIBALD: Would you
like a job in dev rail?
Plat Force, thank you, yes.
AUDIENCE: Really great,
great conference.
It's really nice to be here.
I have a question because
I heard a lot of web APIs
and how the web works, but
I haven't heard nothing
about the Chrome apps,
the Chrome extensions,
and this APIs, is it something
that's going happen over there?
Is it going to be
available and so on?
JAKE ARCHIBALD: Well we
had one question as well.
This actually ties in very
nicely to the next question
we were going to ask, so
we can sort of roll that
into one, which is when is
Chrome OS and Android going
to merge, and how soon can
we develop apps for that.
So, Darin, do you
want to take that one?
DARIN FISHER: I can talk
about all these things,
but so first off to your
question, Chrome extensions,
Chrome apps, these are
parts of the platform.
These are parts of Chrome.
They are things
we are invested--
when it comes to
Chrome extensions,
we're invested in enabling
customization of the browser.
You're going to see us
continue to evolve that.
What we are here today and
yesterday to talk about
was really the
things we're doing
to enhance the web platform.
It was a big focus of Chrome
and focus on the web itself,
the web ecosystem.
Historically, at
this summit, we've
talked about the whole spectrum
of things that Chrome is doing.
But we really wanted to
focus in on progressive web
apps, the mobile web,
and all the things
that you guys can do to create
great experiences there.
When it comes to, you know,
Chrome OS and Android,
there was certainly some
interesting press recently.
I just want to reemphasize that
this idea of Chrome OS being
folded into Android, it
doesn't really compute.
It doesn't make a
lot of sense in fact,
Chrome OS is an extremely
successful operating system.
If you think about
in particular where
it's been so successful
because of the simplicity
of the system, because
of the web really,
it's been a fabulous computing
platform for education,
businesses, and many homes.
It's really something
we started six years ago
with this idea of bringing the
simplicity of computing, speed
and simplicity, security, and
these core values, the things
that make computing just
less painful, right?
To try to create a simpler
computing experience
that people really
love, and I think we've
been pretty successful here.
And Chrome OS is something that
we're really behind and trying
to grow, and in particular.
Now you can totally imagine
that as the teams work together,
they're going to look
for opportunities
to leverage across
Android and Chrome OS,
especially under the hood
and so on, but as far
as how that evolves,
I think the number one
thing to keep in mind is that
that vision, the core user
experience of Chrome OS is
a thing that's here to stay
and we're fully behind.
JAKE ARCHIBALD: So-- oh.
Yeah, go for it.
GREG SIMON: Just really
fast, so you know,
if you look at all the
things we're working on
on Chromestatus.com on
the open web platform,
you'll see a lot of the
APIs or-- sorry-- a lot
of the functionality
from the Chrome OS APIs
that we're working into
the open web, right?
I was just in the office
earlier this week,
and I saw one of the Chrome apps
engineers with Web USB running,
like, you know, blinking
lights and everything else.
Now there are some
security things
that we need to get past
on that one, but you know,
we're very focused on bringing
all of this functionality
to the open web.
JAKE ARCHIBALD: So Chrome
works great on new devices,
like beyond the Nexus
range and things,
but in some parts of the
world, brand new devices
have small screens, half a gig
of ram, and limited storage.
How important is it to Chrome
to ensure that Chrome works well
on these resources and devices?
And what are we
doing in this area?
Grace, do you want
to take that one?
GRACE KLOBA: Sure.
I would take it again.
So, we call the low-end devices
is very important for us.
Right?
So this year, we
spent a lot of time
trying to especially working
on the memory footprint,
and we achieved a 30%
memory footprint reduction
for our browser process.
And for-- thank you.
For the render process, we're
working on the-- so that 30%
especially for the
low-end devices.
We're really
targeting the market
to try to make sure our
512 devices works well.
And the for render
process we are actually
having across the board effort.
I think yesterday mentioned
for the [INAUDIBLE]
to reduce the memory
usage, there's
like a 10% in the render
process that would benefit
the low-end devices too.
And we'll continue
looking into what else
we can reduce in
the coming years.
JAKE ARCHIBALD: Well one of
the questions I had via e-mail
recently is a lot
of the devices don't
have a lot of on-device storage,
and a lot of the storage
is deferred to SD cards.
Are we looking at anything to
be able to move Chrome storage
or even for particular origins
move the storage on to the SD
card?
GRACE KLOBA: So we are
looking into that for this
because a SD card-- every app,
if they have the permission
to access the external
storage, they can access.
So we have to ensure user aware
the particular local storage
data for the origin can be
accessed by the other app,
and then we need to build
like a permission model
before we can move the
storage to the SD card.
JAKE ARCHIBALD: So this
next question is for Parisa,
I think.
And it's quite a
pointy question.
Where are you?
Oh you're hiding over there.
So I'll read it directly
to you because I
think that's how it's
supposed to be written.
PARISA TABRIZ: OK.
JAKE ARCHIBALD: The deprecation
of APIs and features on HTTP
is causing developers pain.
Why are you forcing
this upon developers?
What are you doing to help make
HTTPS easier for developers,
especially on intranets?
PARISA TABRIZ: Yeah.
Well obviously whenever there's
an opportunity for pain,
I take it.
Uh, no.
[LAUGHTER]
So HTTPS is really important.
Did anyone see Emily's
talk yesterday?
Awesome.
If you didn't-- yeah.
It is deserving of applause.
So she went over, I think,
the motivation for this
better than I'll be able to,
but HTTPS is really important.
Without it, you know, as a user
and as a developer, site owner,
you can have no
expectation for security.
Right?
So for really powerful APIs,
one of the APIs we deprecated
recently was getUserMedia.
So, you know, having access
to a camera or device camera
we consider very
powerful and something
that really should only be
done in a secure context
so that, you know, user
can have some expectation
that the bits they're
sending to a site
have not been tampered by some
third party and the developer
also can have some expectation
that no bits that you're
sending to the user have
been tampered or snooped.
So we think HTTPS
is really important.
We're doing a lot of things
to try to ease the path.
Emily's talk went over
things in the web platform
in terms of features
that we're supporting
as well as a new panel that
we just added to Dev Tools
to try to help the developers
who want to support HTTPS
to get to green.
But really it's-- we think
it's the responsibility of us
to make sure that really
powerful features are only
accessed in a secure context.
JAKE ARCHIBALD: So we've had
a question in from Slack.
You can answer-- you can ask
questions on Slack as well,
and they get forwarded into
this Google doc I'm looking at.
This question comes
from Oliver J. Ash,
who's from the Guardian, a
developer who did the fall
back off-line crossword page,
which I think is brilliant.
We've seen a lot of stuff
around Service Worker,
these new features,
push messages,
but we're not seeing many Google
products using these things.
When are we going to start
seeing Google products,
such as Gmail Inbox, Google+,
when are they going to start
using this stuff?
I'll direct that one
at Alex, I reckon.
ALEX KOMOROSKE: So I
can't speak on behalf
of any of the other
Google products, I guess,
but just like a lot of
you all are experiencing
these technologies and seeing
how they can make your things
load much quicker or be much
more robust to flaky networks,
I think that these are
things that would also
make a lot of sense for a number
of the Google web properties
as well.
So although I can't
announce anything,
I think that would make sense.
JAKE ARCHIBALD: So we're
kind of seeing on the web
a resurgence of SVG Because
SVG has been around for ages.
And kind of when it started,
spec people or browser
developers were going to
web developers saying,
hey do you like Flash?
And we're like, not really.
Do you like XML?
No way.
Well, you're going to love
SVG because it's basically
both of those things.
But we're looking at
deprecating Smile,
which is the animation system.
So we had a question
in about that.
Are we going to break all the
existing Smile content out
there on the web by removing
this from the platform?
Dimitri, do you want
to take that one?
DIMITRI GLAZKOV: Thank
you for not making
that question too pointy.
JAKE ARCHIBALD: Why, oh why, oh
why are you breaking the web?
[LAUGHTER]
DIMITRI GLAZKOV: There you go.
That's more appropriate.
And the context here is that
we did recently-- well not
recently, but this
spring-- started
talking about removing
a Smile SVG feature that
enables your animation.
One of the weird things
there is that the reason why
we're doing this is
because we actually
don't see the path to
interoperability which is
this working in every browser.
And so at this point, it's
just a two browser feature,
and no other browsers
want to do this.
And so we're sort of like in
this really hard situation
where we're like, do
we carry this along?
Or do we remove it and make, you
know, our burden a little less?
And obviously this
involves developer pain,
and we felt it very hard, very
much on the Blink-dev, which
is the mailing list where all
these things are announced.
It's now a center thread
with people chiming in
very regularly.
Yes.
And the interesting
thing there is
I want to say that first
of all, some of the things
that Smile does
today are simply not
easily possible with the
web platform features.
I think I want us to first
get to the point where
we can say with full honesty
that we can compliment
the features of Smile with
the corresponding web platform
features that are on
interoperable path and then
maybe talk about deprecation
or removing at this point.
At this point, this Smile thing
thread is mostly a heads up.
Look, we know this is
not going anywhere, so,
you know, take a look.
JAKE ARCHIBALD: I
guess part of plan
as well as is for the
animation API in JavaScript
to start taking on kind
of a lot of this stuff.
DIMITRI GLAZKOV:
Yeah, web animations
is actually one of the kind
of interesting parts of that.
And I'm going to do the,
it's happening, thing.
So it's actually being
implemented across the board.
That's really cool.
Very excited about that.
But there are still
some pieces missing.
JAKE ARCHIBALD: I
mean, we're seeing
SVG was so unloved for
so long, but with devices
of different density,
especially people
are starting to
pick it up again.
But I mean, the implementation
we have still inherits a lot
from Web Kit, the
initial implementation,
and same for Safari's.
Firefox implantation
is old as well.
It kind of feels like it's
only Internet Explorer
and therefore, Edge, that have
kind of shown the way with you
can make SVG
perform really well.
Are we going to step
up our game there?
Is that something--
DIMITRI GLAZKOV: Totally.
We're totally
stepping up our game,
and this is-- we want to
make SVG as performant as it
can possibly be.
I have to say that as
a platform developer,
I'm amazed that people can
use this thing because it's
one of the most terrible
specced APIs ever,
and there are some places
where you don't want
to go in there because
bad, bad things will happen
to you, type of alley situation,
and still, yet it is a success.
And it's kind of the
story of the web.
The thing that wins is not
necessarily the best designed
one.
Right?
And so, yeah, we
want to work on this.
But we also kind of want to
look forward ahead to SVG 2
and prod that SVG working group
along a little bit and say, OK.
Come on.
Come on.
It's been two years.
Give something.
And so, get something
going there.
JAKE ARCHIBALD: So we've
got another standards-based
question.
I'll just read it out
as it's been sent in.
Pointer events, seriously,
when is it happening?
You've been promising
it for ages now.
Grace, do you have that one?
GRACE KLOBA: If you
check the check-in log,
it is happening right
now as we speak.
Right?
So it is behind the flag.
And I think I see
Rick over there.
Yeah.
So he's leading the [INAUDIBLE]
and there is a CR bug.
I do not recall
exactly bug number.
If you want to know, we
can find Rick after this.
And you can--
DARIN FISHER: He's right there.
GRACE KLOBA: Yeah, I see
him like waving his hand.
So, you can follow
the bug, and he also
has a Twitter feed
updating the status,
so you can follow
him on the Twitter.
And today I believe it's soon.
I think soon behind the
flag you can try it out.
And there are some
technical hard things
we need to figure out, so we
don't have exactly a date.
We're going to turn
it on by default.
I hope sometime soon
when Rick figured it out.
Next year.
DIMITRI GLAZKOV: And please,
please be nice to him.
You know, he's a really cool
fella, so just take it easy.
By the way, love the way
you ask the questions
and read them out.
Just you have to
do this everywhere.
JAKE ARCHIBALD: Well
we've had a question
in from Twitter that's being
pasted into this document.
And I'd like to thank
Paul Kinlan who's been
managing this at the moment.
Especially thank you for
posting every question
and using a different font.
That's not messing
with my OCD at all.
[LAUGHTER]
This question comes in
from Henry Helvetica.
Could be real
name, I don't know.
The way Chrome
pushes forwards, how
did the panel feel about
PPK's call to slow down.
I'm specifically not allowed
to answer this question,
and I think that's
because I've already
written blog posts about it.
So just a bit of background,
PPK wrote this blog post saying,
you know, the web platform
is progressing too fast,
and we should stop doing
it for like a year.
For some reason.
I'm sitting on the
fence about this one.
DARIN FISHER: You seem
pretty on the fence.
JAKE ARCHIBALD:
But you know, are
we moving too fast on the web?
Are we making--
are there mistakes
we're making by trying to
push the web forward so fast?
Or should we be
moving even faster?
Who wants to take that on?
GREG SIMON: So the
way that I would
measure this is what
is the developer
adoption of the new
things that we're
doing if there's
a big gap there,
then maybe we are
moving too fast.
But there are certain things
like we got Service Worker out
there really fast because, you
know, which was really fast.
But you know, this
one really fit
our model of how we
want to move forward,
which is an extensible platform,
and explainable platform.
So I don't want to just
throw in tons of APIs
that no one will use, so always
looking for that feedback,
and that's why we have on Chrome
Status all of the histograms
and what people are using.
ALEX KOMOROSKE: I
think too if there--
for things like Service
Worker and a bunch
of these other things, we worked
very closely with other browser
vendors and standards
committees and standards bodies.
For example, for
Service Worker, we
worked incredibly closely
and co-developed that
with Mozilla and other members
of the standards community.
And if other browser vendors
are coming to the table
and have meaningful discussion
other people are implementing,
developers are using, I
think to me that says,
no, we aren't moving too
fast, and we're actually
moving at a pretty good pace.
JAKE ARCHIBALD: And
don't forget that if you
want to ask a question live
here, the microphone is just
there.
Someone's already done it,
so it's not as scary anymore.
Right?
So if anyone is feeling brave,
you can come to the front.
GRACE KLOBA: I think
Darin wanted too--
JAKE ARCHIBALD: Oh, sorry.
Go on, go on.
DARIN FISHER: At this point now.
JAKE ARCHIBALD: Carry on.
Sing a song.
Don't let me stop you.
DARIN FISHER: No,
I was just going
to say that this
whole past year, we've
had a real focus on
just the core engine
and just optimizing
existing code paths
and you know,
prioritizing, you know,
scheduling work much better
all to bring a lot of wins
to the platform.
A lot of the V8
improvements came from just
being smarter about scheduling.
And with the focus
on emerging markets,
there's been such
an emphasis placed
on being smarter
about resource loading
and scheduling,
all of this stuff.
You have pages with
lots of iframes,
cross storage on
iframes, making sure
that the main document
content is given
the right priority, et cetera.
There's just so much we
can do when we really
focus on the core engine.
So I think part of the
answer to that question
is it's not always
just about new APIs.
Sometimes there's real holes
that need to be filled,
and that's where something
like Service Worker
comes in, push
notifications, et cetera.
But a big part of this
is just like making sure
the engine works well and
that you as developers have
a lot of control.
The engine shouldn't feel like
a big mysterious black box,
right?
You should feel like you have
a lot of control of Dev Tools
to help you understand
it, et cetera.
So there's just a lot of work
going into the core platform.
And I think that
stuff really pays off.
DIMITRI GLAZKOV: I want
to reframe that a little,
and actually PPK's post I had
a little milder response to it
than maybe Jake.
And basically my
question, my thing
was that if I were
to summarize it,
I would say the question
he's asking is to what end?
Why are you doing this?
Right?
And I think this
is what Greg said,
is that you have
to be-- in order
to deliver things
that are valuable,
you have to get really good
to listen to developers,
at listening to developers,
understanding what they want,
and building something that--
the question is are you
moving too fast has
such an obvious answer
because it's like, yes.
Because the developers need it.
And this is really obvious
to me that this is necessary,
and that's the next step.
And I think that's
what we've been doing,
and I think Darin underlined
the quality and excellence
of the product focus that we're
trying to do in balancing that.
I'm really optimistic
about 2016.
We are not moving too fast.
We are more focused
and better than ever.
Yay web.
JAKE ARCHIBALD: I had an angry
response to it, like you say,
but I tried to
channel that anger.
So if anyone's interested in
hearing that on the latest
episode of the HTTP
to a free podcast,
I wrote a five minute
poem about how disgusted
I was about this idea that
we should stop on the web.
So, that's something you
might want to check out.
Yeah, exactly.
May as well.
I've got a room full of
people on live stream,
I've got to plug my podcast.
You.
Do you want to ask a question?
AUDIENCE: Yeah, hi.
I'm not Paul.
So when there's so many
visions and directions
for the future of the platform,
how do you unify and prioritize
all these ideas?
RAHUL ROY-CHOWDHURY: So
that's a good question.
Let me take a stab at it.
I think it's very
important for us
as a team to have to pick
the battles we want to fight,
to pick the problems you want
to solve, and so for example,
for this year, you've
heard some of the themes
in this conference.
Performance is a big
issue on the mobile web.
We want to really invest and
make appreciable progress
on it.
Emerging markets and serving
the next billion users
who come online is a big focus.
And so, really
what we look at is
we sort of look at what's
happening out there,
look at what users are
doing, look at future trends,
and then make a very
deliberate choice about where
to focus our efforts, and
then align behind that.
And then, you know,
there's definitely
a lot of ideas that
come up midstream,
and you try and
incorporate those in,
but the idea is not
to be spread too thin.
So you don't want
to make 10% progress
on a variety of fronts.
You want to just nail a
few things really well.
ALEX KOMOROSKE: I would
emphasize too that this web
platform, it's an ecosystem.
It's a community.
That's why all the work we do
on Blink is fully in the open.
That's why Blink-dev encourages
folks to come in and share
their perspectives, their
feedback on proposals people
float there.
We had our Blink on computer
conference last week.
We had a whole bunch of folks
there from other browser
vendors as well.
And so it's ultimately
by talking to developers,
it's by observing places where
there's obvious gaps that we're
hearing again and again
from folks that they need.
But it's ultimately a
collaborative process
because we're kind of all
in this together in a way.
PARISA TABRIZ: I'll
just add one extra thing
to that because I
think it's challenging
having to prioritize all
of these different things
you want to do.
And one thing that's
really helpful
is Chrome has sort
of these guiding
principles of
simplicity and security,
and any time we find
ourselves maybe like excited
about one idea and getting away
from those core principles,
it's very helpful
to kind of refocus
and sometimes prioritize.
JAKE ARCHIBALD: So
moving on to Polymer.
Does Polymer support
progressive web apps?
There seems to be a big emphasis
on server side templating
and rendering when it
comes to this stuff.
Is that something
that Polymer supports?
Matt, do you want to take that?
MATT MCNULTY: Yes.
So it does.
I mean, if you watched Rob's
talk yesterday about that,
it was building a
progressive app in Polymer.
So you should probably
pay attention next time.
[LAUGHTER]
JAKE ARCHIBALD:
Good, quick answer.
Fair enough.
MATT MCNULTY: But no actually, I
can elaborate a little bit more
on that.
So I think if you look at
Paul Lewis's recent blog
post about performance
on frameworks
and how they impact
things like rail,
Polymer came out really
well in that comparison.
It's relatively small.
It's relatively fast.
I think there are
some things we can
do to make that faster and
get first paint quicker,
and we're working
on that right now.
But we're already in
pretty good shape,
and I think when you start to
see things like server side
rendering, a lot of
the reason for that
is because in certain
circumstances,
other frameworks have much
bigger payloads and much more
JavaScript that
they're passing down,
and you have to do something
different on first paint
as opposed to later paints.
And our goal is, you know, for
Polymer to be really, really
fast, have a really
fast first paint,
and still with idiomatic
usage without having
to resort to tricks like that.
JAKE ARCHIBALD: But you mean
we've got the paper elements
doing a lot of the DUI work.
Are they going to support acing?
Because that seems to
be one of the things
that you really need to get
this kind of first render down.
MATT MCNULTY: Yep, absolutely.
That's some of the stuff
we're working on right now.
JAKE ARCHIBALD: So we've
got a question from Slack
from Simeon.
So one of the big what's of
the current progressive web app
story is that we don't
have a good way of handling
mixed content or
cause, and I think
what you mean by
handling here is
a native app can
download podcasts,
RSS feeds from
anywhere on the web.
It doesn't have to
cause compatible.
And if you want to build
something like a podcast app,
you can't really do that
on the web at the moment
without building your own proxy
to send everything through
to not lose the
padlock, or you know
to get add cause
headers on, and some
of these-- you know, in
the case of a podcast app,
some of the files are going
to be huge in doing that.
Do we have anything, any ideas
on how to address this gap?
Parisa?
This is mixed content.
Do you want to take
a stab at this one?
PARISA TABRIZ: I don't
have any great ideas,
but it's a real problem.
And it's something we
should think about more.
I don't have any
great ideas for it.
I think it's a
legitimate situation.
JAKE ARCHIBALD:
One of the requests
we get quite a lot is to
say, well, why can't we just
make a request to
anywhere in the web
and get the content, because
if we don't put cookies on it,
then it's not leaking any data.
But the situation
we have there is we
don't want the web to
be able to access things
like your local service.
I mean, if you're an
evil page could just
do a port scan on local
hosts and look for sites that
are there, I mean,
that's basically
where you'll be running
prototype servers, new stuff,
stuff that you don't
want leaked onto the web.
And same goes for
internets as well,
so I guess with that
question, I mean,
I don't have any good ideas.
Anyone have a good idea?
ALEX KOMOROSKE: I have a larger
thought about the importance
of the security for the web.
We talked a lot yesterday
about the importance
of the low friction
on the web that
makes it so easy for
users to tap on a link
and experience something new.
That's so important for
that really healthy reach
that the web has.
And one of the reasons that is
true is because of security.
Because users don't have
to be afraid of what's
going to happen when
they tap a link.
And so sometimes that means
we get things where it's like,
we could've done this better if
we shipped a whole native app.
Well, yeah, of course.
The security model is different.
But that's one of the reasons,
the things that enables
the super power of the web.
So that's one of the
ways I think of it.
JAKE ARCHIBALD: So we see
it is a bug that native
allows this stuff to happens.
ALEX KOMOROSKE: I
wouldn't call it a bug.
I'm just saying it's a different
trade off in terms of reach.
JAKE ARCHIBALD: Do you want
to ask a question on the mic?
AUDIENCE: Yeah, hi.
My name is Adam.
I have a question about
push notifications.
So right now when
the user decides
to accept push
notifications, the token
is bound to a single
device, and do
you have some plans
to synchronize it
across all of the browsers or
when the user buys a new phone
that they don't have to sign
up for the same notifications
as before?
ALEX KOMOROSKE: So
we definitely talked
about those kinds of
use cases and tried
to reason how to do that in a
way that makes sense to users
and that helps them accomplish
the things they want to do.
One thing to remember
too is that when
choosing-- when a user chooses
to enable notifications,
it's often very tied to a
specific device or context.
So I might turn on breaking news
alerts on my desktop computer
because I'm always looking
for something to distract me
during the workday, but like I
don't want to do it on my phone
necessarily.
And so you have to
think very carefully
about the different
user contexts
that you'd want-- to say nothing
of the security implications
and privacy
implications of that.
We definitely talked
about it in our open,
trying to figure out
the best way to do that.
DARIN FISHER: You could
imagine a variety of approaches
with Chrome synchronizing
data already
between different Chrome
instances and so on.
Like Alex said, I
think this is something
we've talked about it,
but in the initial cut,
we wanted to keep it simple
and focus on the single device
case.
AUDIENCE: OK.
Thank you very much.
JAKE ARCHIBALD: So we had
one question in from slack.
Why does Jake not wear shoes?
Answer is simple.
You shoes, you lose.
Is VA actually paying
attention to the use asm flag?
Or because it used
to be it was saying
we're going to make
just all patterns fast,
so have we changed
our stance on that?
Greg, do you want to take that?
GREG SIMON: So sure,
I can take that.
So VA over the past year,
actually more than a year,
has been working on a
brand new compiler that's
called Turbo Fan.
This is to replace
the old one, which
is called Crankshaft
Anyway, so Turbo Fan
is a type ware compiler,
fully type aware,
which means that
in the limit, it
won't need to look at
the use asm key at all.
It will just be able
to infer the types
and map it, map it internally.
However, they are using
use asm as a trigger
to test Turbo Fan
as it rolls out.
And then once they have
deprecated Crankshaft then
they won't look at it anymore.
JAKE ARCHIBALD: So
push notifications
for apps that have been
added to Home screen,
when you launch a window
from a push event,
they don't launch in
the full screen window.
Why is that?
And is it something
that we can change?
Because it means you go
from this nice native-like
experience to something
which all of a sudden
looks very browser based.
Is there something we
can do to fix that?
Grace, do you want
to take this one?
GRACE KLOBA: I think
that's a good suggestion.
So like currently, you can
target-- like basically,
targeting the existing
already open the windows.
So if the At Home
screen currently
is one of the window is
open in the background,
you can still target it.
So I think we should try
to make sure even the--
because At Home screen,
we wanted to work more
like a native app, so I think
it's making sense for us to be
able to target it by
the push notification,
even when it's not running.
So.
Yeah.
JAKE ARCHIBALD: I mean, from
a standards point of view,
this is something we've
been looking at as well.
I mean, it's just
kind ideas that
are being thrown
around the room so far,
but we've been thinking
about something
like a launch event
in a Service Worker
that will be fired
if there's been
a kind of launch of a website
done in an ambiguous way.
And that will include things
like clicking a Home screen
icon, clicking a link, clicking
a link in the native app,
and that will let you
decide how to handle that.
Should it be launched
from the Home screen?
Should it create a new
full screen window?
And the hope is to let you
create single window apps
or multi-window apps using
this, and by ambiguous I
mean, if someone long presses
and says Open a New Tab,
that's not ambiguous.
We don't want you to
have to disrupt that,
but we want you to have control
when the launch is ambiguous.
Right.
OK.
We've got another
question from Slack.
Asking for clarification
on the asm bit.
Does Chrome do ahead of time
compilation like Firefox
and Edge for use asm.
GREG SIMON: I'm not
sure about for use asm,
but there is snapshotting
going on now,
but I'm not familiar with the
latest on what triggers it.
JAKE ARCHIBALD: I
think it's a sync
or defer on the script tag.
Will Google do that?
I think so.
I think we do it
for workers as well.
So I think we're all very
excited about Let's Encrypt,
but Google isn't on the
sponsorship list for it.
Is it something we endorse?
Is it something we'll be
telling developers to use?
Do we give it the thumbs up?
Is it something we
plan to sponsor?
PARISA TABRIZ: I cannot say
anything specific about that
today, but it's a project that
we're really excited about
and interested in.
And that's all I can
say today right now.
JAKE ARCHIBALD: News
to come on that.
PARISA TABRIZ: We're
pretty excited.
I said I'm excited, but
we're really excited.
We're pretty excited.
We're pretty excited.
And I think it's--
GREG SIMON: How excited are you?
PARISA TABRIZ:
Pretty damn excited.
JAKE ARCHIBALD: You see, if
you put a big number to that,
you'd have got a
round of applause.
PARISA TABRIZ: Lots
of zeros at the end.
Stay tuned.
JAKE ARCHIBALD: So
we've had a message come
in from Seth Thompson who was
speaking earlier, PM of V8,
saying yes, we do have real
ahead of time compilation
is coming for asm.js.
We didn't there previously,
but you can check it out
on Chromestatus.com
for news of that.
This one's written in
another different font.
Guys, you're winding me up.
The name of, what?
GREG SIMON: The
font, Ariel Arial?
JAKE ARCHIBALD:
Let's check it out.
This is Alpha Slab.
So this question is
written in Alpha Slab.
How will ES 2015 modules affect
how we look at Web Components?
So that's one for Dimitri.
DIMITRI GLAZKOV: So
the web components
is a loose congregation
of specs, right?
And it's been
evolving over time.
It's evolved quite
a bit this year.
As modules get ready to
be shipped on the web,
I think there's a lot of
interesting possibilities
that open up for custom
elements, and imports,
and I'm really excited
about trying to figure out
how this stuff fits together.
And especially with imports,
I sort of want to like,
I've been trying to pitch
the idea that we should
try to look at the loading
mechanism that hasn't yet
been fully specced out for
ES6 modules, for browsers,
and then maybe see
if we can rebuild
the imports on top of that
and make something amazing
happen there.
Because the features
that modules offer
are quite tantalizing for-- the
whole scoping thing is amazing.
And the whole export
stuff sounds really good.
So let's go figure it out.
Follow public web apps.
No, don't go there.
But you know, there is a
GitHub for W3C web components.
It's a pretty active
discussion, so lots
of interesting
conversations here.
JAKE ARCHIBALD: Would you
look at the state of that?
This is horrible.
It's like reading
a kind of, it's
like a ransom note it's
starting to look like.
OK, so we have--
MATT MCNULTY: I watched you
changing that around, though.
JAKE ARCHIBALD: There's
a kind of fight going on,
I'm trying to change it.
We've got Comic
Sans going on now.
Thank you very much.
Excellent.
Yes, this question is
written in Comic Sans.
TC39 has discussed the
possibility of adding types
in future versions
of the language,
is Turbo Fan's tech
support ready to support
this possible feature?
GREG SIMON: Yeah, there's
definite interest from us
in working on this.
I mean, we are working on it.
Was there anything
else beyond that?
JAKE ARCHIBALD: It
was just, is Total Fan
got some kind of type
support in there?
GREG SIMON: Yeah,
it's fully type-aware.
So it's actually
perfect fir for it.
JAKE ARCHIBALD: So,
it's another one from,
this is from Unfunk on Slack.
AUDIENCE: Hey, Jake.
Can I?
JAKE ARCHIBALD: Oh sorry.
I'm staring too much at trying
to decode the fonts that
are going on here.
AUDIENCE: Yeah, I got you.
MATT MCNULTY: What font is
your question going to be in?
AUDIENCE: I think I'll
pick the Hevetica for this.
OK, my question is-- I'm Johann.
So I am building
games using SML5,
and the problem
for me is actually
how we can hide if I
want to post the score.
For example, I build
a temp [INAUDIBLE]
and I got the score
of the player.
I want to post it to the server,
but the problem that I always
face is the people can
just open the dev tools
and then just throw in the
same request to the server
from the Java Script
console, and then
they can manipulate the score.
So.
JAKE ARCHIBALD: Well,
I mean surely this
must be something, the same
problem that native games face,
right?
Because I mean, you
can always just put
a listener on the wire,
something like Wire Shark,
and see the request
being sent and find out
where the score of this is.
Is that the answer?
GREG SIMON: [INAUDIBLE]
is much longer, right?
I mean, sure.
You can also decompile Java.
AUDIENCE: Yeah.
GREG SIMON: You know.
Sorry.
AUDIENCE: I mean, using the
native, you need another tools,
right?
PARISA TABRIZ: Can you add a
digital signature to the score
and then check that on
the server too before?
And if it's errors,
you're like, well
you know someone's causing
some kind of-- doing some kind
of manipulation on it?
AUDIENCE: One idea also
coming to my mind--
PARISA TABRIZ: Like a mac.
Like adding a mac to it?
AUDIENCE: One idea
also come to my mind
is, is it possible using a
web socket like a-- using web
socket to like a connect
between so it's not
like using the post request.
PARISA TABRIZ: I think you
probably if you're-- I think
you probably still want to
add some way to authenticate
the actual score.
So adding a signature for it
would I think help with that.
Because they could still
tamper with it in your client,
in your game.
AUDIENCE: OK, cool.
Thank you.
JAKE ARCHIBALD: So we've got a
question from Unfunk on Slack.
What's the best
way for developers
to provide feedback and make
feature requests, not just
to Chrome, but also other
browser vendors and standards
bodies as well.
Anyone want to be
brave on that one?
Standards bodies?
DIMITRI GLAZKOV: So I think
this is a good question.
I don't know if there
is like an easy way
to go and say like, I would
like to propose a feature.
Because there is
definitely W3C, which
is not the easiest
working group or group
of people to work with.
But I think something--
[LAUGHTER]
Did somebody make a face?
But I think there definitely
more and more opportunities
for developers.
I am going to tout ours, which
seems to have worked real well,
and this is just Blink-dev.
I think there's a lot of
developers listening there,
and sometimes just putting
an idea out is a good start.
And I think as a
community of browsers,
we do need to get better
at engaging developers
collectively, rather
than separately.
So I'm going to make a point to
look at Darin and Rahul there,
and because, you know, this
is a Chrome dev summit,
but there is people from
Microsoft here, from Mozilla,
and it's a great opportunity.
And you're all here, right?
So it's a great opportunity, and
we need to get better at this.
JAKE ARCHIBALD: There's also
the YCG, the web platform
incubation group.
That's a great place
to propose new things
or sort of take problems to.
And that's something we
at Google use ourselves.
The background
sync specification
is part of that movement.
So what I would always
advise, if you're
thinking about a new
platform feature,
try not to think about
solving just the one problem
you have but what are the
parts of that problem?
And can we create
them all and so those
can be used in different ways
to solve other problems as well.
ALEX KOMOROSKE: Because
designing a new web platform
API is really,
really challenging.
There's all kinds of
security considerations,
other APIs in the platform
that you have to fit within,
other semantics that
aren't immediately obvious.
It does require a fair bit
of effort to drive into it.
However, you'd be surprised a
number of times that browser
developers and on
standards lists,
people are making arguments
in complete vacuum.
And there's developers who
actually have very concrete use
cases, they've got numbers
or examples in the wild.
That would really help
for those conversations.
So I think looking for places
to give that concrete feedback
really helps the process.
JAKE ARCHIBALD: So,
this is actually
an issue that's been
bugging me recently.
When pages are launched from
the Home screen in full screen,
you lose-- or the
user loses access
to the URL bar, which
obviously impacts
being able to share
that page or that app.
It feels like we're
kind of losing
one of the core
features of the web.
Do we have any ideas,
any solutions for this?
Alex, do you want
to take this again?
ALEX KOMOROSKE: Yeah, let's see.
So Flipkart just
had a session where
they talked about how they
put different navigation
controls inside the
experience once it's
added to the Home screen.
And that is something important
that you have to reason about.
For example, I remember
when we had this past IO,
we had this awesome
IO web app that when
it was on full
screen, we're looking
at details on a session, you'd
be like, how do I share this?
Because I know it's got
a URL that makes sense.
I can share it with people.
But I don't know how to do it.
And we were all like, oh
that's a really good point.
How do you do that?
And so it's
important when you're
reasoning through this to
think about those kinds
of for instance.
We're also trying to look
into how best to support that.
So actually, Paul
Kinlan got a great post
on his site that explains a
way of doing this triggering
a native share intent.
But it's something that
you do have to reason about
if you're hiding this
browser UI that we've just
taken for granted.
JAKE ARCHIBALD: Do you
want to ask a question?
AUDIENCE: This one's a little
silly, so I'll make it quick.
I was wondering if you guys
knew of any benchmark that
would work really
well on my Nexus 6p
where I could beat an iPhone 6s.
I mean, just
anything, any place I
could go where I can compete
with my friend not Paul.
JAKE ARCHIBALD: You can already
use your 6p to beat an iPhone,
just actually physically
beat it on the screen.
AUDIENCE: That's
about all I can do.
JAKE ARCHIBALD: Then
your friend's iPhone
will run a lot slower.
GREG SIMON: How about
LoadFlipKart.com
AUDIENCE: What was that?
GREG SIMON: LoadFlipKart.com.
The best benchmark
is something that
affects users, not in a vacuum.
AUDIENCE: Will I win though?
Have you tried that one out?
Because if I-- he's
going to see this.
And if I lose at
this one too, it's
really going to be embarrassing.
JAKE ARCHIBALD: So
an app that I built--
see I can plug loads of things.
Its great.
SVGOMG, which is a kind
SVG optimization thing,
once the Service Worker's
there, you revisit that.
And that loads in 100
milliseconds flat.
And that's using
Service Worker, so
on devices that don't have
Service Worker, especially
if you're on something
like 3G, which
has like 1.7 seconds worth
of connection set up,
that's what it's
going to be on iPhone.
So find somewhere with 3G or
4G, and set like especially
the second load or
from a Home screen
launch of SVGOMG
on both, and you
will win by almost two seconds.
AUDIENCE: So I really
got to game it to win?
ALEX KOMOROSKE: So I
think what Greg was saying
is benchmarks are
really finicky depending
on the precise characteristics
of the device and what
kinds of-- just lots
of different things.
AUDIENCE: Well that's why
I want one where I can win.
ALEX KOMOROSKE:
But so, that's why
I think that Rail is an
interesting way of looking
at it.
What ultimately matters is the
user experience of performance,
and that allows things
like Service Workers
and other things that have
a really important impact
on them.
JAKE ARCHIBALD:
Yeah, and I wouldn't
say loading using caches and
things and Service Worker,
I don't like that's gaming it.
I think that is what we want
the future of the web to do.
We want when users
go back to something
they used to that it
appears instantly,
and they see content or
maybe even future content
that they haven't
even seen yet using
background sync and things.
And yeah, this is stuff
that Chrome is way down.
AUDIENCE: So Google is giving
us slower devices so that we
can be better developers.
Is that the gist?
JAKE ARCHIBALD: Is it?
Is it slower?
It's definitely slower?
AUDIENCE: It's
definitely slower.
I mean, just raw JavaScript
performance, it's a lot slower.
JAKE ARCHIBALD: Well
it's Android dev summit.
Isn't it soon?
Is that next week?
You can take that one to them.
We've got a question from
Slack from me Tim Kadlec.
Data saver is awesome
and necessary,
but it's understandably
bypassed on HTTPS,
making it conflict with the
security everywhere goal.
Both are super
important, but what's
being done to balance
security with the fact
that many people need to
use these proxy services
for speedy access?
Parisa, do you want
to take this one on?
PARISA TABRIZ: You did
say that word security.
This is about Data Saver?
JAKE ARCHIBALD:
This is Data Saver.
It doesn't work over
HTTPS understandably.
Should it?
Or is it something that's
going to die out as we
push HTTPS across the web?
PARISA TABRIZ: It's
a hard question.
So, we have a long ways
to go for all of the web
to have full HTTPS adoption.
So it would be nice if
I could blink and say
that that's going to be
a problem we immediately
need to fix today.
And my kind of hope
is that actually
the needs for Data Saver are
going to at the same time
go away.
And you look like you have
something on your tongue.
RAHUL ROY-CHOWDHURY:
No, go for it.
Finish.
Finish.
PARISA TABRIZ: And
I'm hoping that HTTPS
is going to get faster, networks
are going to get better,
our performance on bad networks
is going to get better,
and the need for Data
Saver will at some point
not be there anymore.
So, we're thoughtful to this.
I think we are really--
I care about HTTPS.
I also care about people being
able to use the web in networks
where I recognize that
it's not a experience,
and it actually impacts things.
So I think we're exploring
how to make this better.
DARIN FISHER: The
real promise of HTTPS
is the endpoint security,
and so we really
are being thoughtful about that.
RAHUL ROY-CHOWDHURY: Also,
note that Data Saver currently
is implemented as a
proxy service right?
Which is why all these
thorny questions come up.
You could imagine that the
same transforms could be
applied at the origin server.
Darin mentioned
briefly page speed,
which does some of this work.
So you can imagine other ways
to solve this data compression
problem without running
into a proxy service dealing
with HTTPS traffic.
DARIN FISHER: In addition, just
designing the web application
to be smarter about how
it uses the network,
you know Flipkart's the
great example here, right?
Leveraging Service
Worker, being smart
about the initial
payloads, being smart
about bringing down
content only when needed
and in the background,
caching it and so on.
All of those things
really can pay off here
to the point where,
as Parisa said,
feature like Data Saver
isn't really needed.
And so Data Saver
is really there
as a tool to help
users access the web.
The web as it exists today,
but as developers, we
can all change the web.
We can evolve it.
We can make it better.
We can make it so that
things like HTTPS work great.
PARISA TABRIZ: Yeah, and
I think to maybe one--
I don't know if this was
implied by the question,
but why not just have
Data Saver support HTTPS?
And that's a challenge as
well because, as Rahul said,
it's a proxy.
And SSL offers that end to end
connection, and we as Google
don't want to
interfere with that.
JAKE ARCHIBALD: Train, house,
river, skull and crossbones.
That question was
written in Wingdings.
Thank you very much to the
people operating that document.
We have a question on the mic.
AUDIENCE: Can you speak
to us specifically
about Service
Worker and security,
for say like a banking
application or retail as well,
is it just tell the
security folks it's HTTPS,
and we can just be OK with that?
Or--
JAKE ARCHIBALD: Well if your
bank website is not HTTPS,
then leave that bank.
Would be my first advice.
AUDIENCE: I don't
work for a bank.
JAKE ARCHIBALD: What security
issues are you concerned
about with this?
AUDIENCE: I work for Target,
and they had security issues.
I think everybody
knows about that.
But so in order to utilize
this, which we're planning on,
what do we give to
the security folks?
Because they've never
heard of it before.
So they're going to
have questions about it,
and in large
corporations like that,
it can take months and
months for those people
to catch up to these things.
Could there be like a white
paper that says, here's what
you need to know right now?
ALEX KOMOROSKE:
It's a great idea.
JAKE ARCHIBALD: Yeah,
we should do that.
PARISA TABRIZ: I'm
looking at Alex Russell.
He's like writing the
white paper up as we type.
But he's the Service
Worker security person.
Yes.
It will be done
probably by the end.
And we've got nine minutes, so.
AUDIENCE: I'll meet
you at the front door.
PARISA TABRIZ: Yeah.
JAKE ARCHIBALD: We have another
Service Worker question here.
Exciting possibilities
with Service Worker,
but is an empty app shell
a sensible starting point
to progressively enhance from?
Is there a strategy
to better avoid
serving a page without content
until JavaScript successfully
intervenes?
That's from Phil Hawkes.
Well, thank you .
You used to be my boss.
You could have asked
a kinder question.
Does anyone want to take that?
I mean, I could take that.
I'll take that.
Serving the app shell, currently
using the app shell approach,
you're going to get a result
much quicker than you would
by going to the network,
even with server rendering.
And we've proved that out.
One website you can
look at is if you
search for offline Wikipedia
as a demo I built. And you can
sort of set different
flags to server render,
or not server render,
or use a Service Worker,
and you can put those results
through web page tests yourself
and see what the effects are.
But one thing that
I'm excited about
and this will start
landing early next year
is streams arriving
within the Service Worker.
These are streams that you
can construct yourself,
and the technique I'm really
looking forward to using
is where you would serve
the header of the page,
including like a kind of first
render toolbar and things,
serve that from the cache, and
then start streaming content
from the network.
And if that stream
takes a while,
you can start serving
a different stream.
So in that model, your Service
Worker becomes the server,
and you are serving one
response with HTML in it.
And I think that's a
really interesting pattern.
That's something that Wikipedia
have expressed interest
in because it matches
much closer what they
do on the server,
and they can start
sharing code between the
server and the Service Worker.
You have a question?
Do you want to?
AUDIENCE: So, most web
technologies that we've worked
with have the ability to do
some degree of progressive
enhancement, but Service Worker
is very much a, your browser
does it or it doesn't.
How would you suggest
building an application that
needs to support
browsers that don't
have Service Worker without just
writing the application twice?
JAKE ARCHIBALD: Yeah, do
you want me to do it again?
Oh, I'm going to just be--
DARIN FISHER: I'll
just add a bit here.
Actually, I think I feel like
Service Worker was designed
to be very complimentary, like
you can take an existing web
application and add on
a Service Worker that's
going to be able to
intercept the network
requests that your page makes.
You're not having to rejigger
your page dramatically
to start benefiting
from Service Worker.
Of course you can
go even further,
but like compare that to
sort of old other techniques
like using App Cache,
where you really
did have to be redesigning
the way your page worked.
Or if you were trying
to use local storage
to serve your resources and
XML HP requests to fetch them.
There you're very much
redesigning your page
for that technology, that sort
of observing architecture,
but here you can take an
ordinary page with URLs
and start to capture them
into caches and so on.
AUDIENCE: I guess I'm
talking less about the case
where you're just using
Service Worker as a caching
acceleration mechanism
for resource requests
and more the additional features
or additional logic that may
get pushed into Service Worker.
I mean push notifications
already use that.
Other things will
start using that.
DARIN FISHER: I think
that's a good point.
And you can imagine
that you might
need to-- you might want to
build a framework that allows
you to take some of the
code that would demodularize
so the code that you want to
have in the Service Worker
could also run in
the main document
when you don't have the
Service Worker's context.
You know, but some
of that's probably
things-- I mean, these
patterns are things
for us to figure out, I think,
and for us as a community
to figure out.
JAKE ARCHIBALD: Yeah,
all of the examples
that we saw over the last two
days using Service Worker,
they work on browsers that
don't have Service Worker.
They just work better
on browsers that do.
GREG SIMON: One of the best
examples that I've seen of this
is the Google I/O 2014, the
talk that you and Alex gave
with the "Game of
Thrones," I think?
JAKE ARCHIBALD: Yes.
GREG SIMON: No.
Was it "Harry Potter"?
I don't remember.
It was one of those things.
Anyway, you guys started out--
DARIN FISHER: Big
difference there, Greg.
GREG SIMON: Sorry, I don't
know either of them, but--
JAKE ARCHIBALD: Fool of a tuc.
GREG SIMON: Yeah, that's true.
Anyway.
PARISA TABRIZ: I'm so
embarrassed for you.
GREG SIMON: What?
So, where you guys started out
with a non-Service Worker site,
and then in the course of
like over like 20 minutes,
you converted it into offline,
cacheable, and everything,
and it was really, really
magical to see actually.
So you can go back and
stream that off of YouTube.
JAKE ARCHIBALD:
And I mean, it is
possible to create a site that
depends on Service Worker,
but we made it so you would have
to jump through hoops in order
to do it.
Like you would
load the thing you
served from your server
would be a loading page,
and then you set up the
caches in the Service Worker.
And then once they are
ready, you refresh the page,
and then it can intercept it
and serve something different.
But we've made that
deliberately difficult,
and you can do that
if you want to,
but I will hunt
you down because I
don't think that's the
right way to build websites.
We have another question
on the microphone.
AUDIENCE: Yeah, this time
about Service Workers.
So, how's Service Worker
cacheing the app shell
and serving the content of
the API have to do with ICO?
How is it going
to work with ICO?
Is the search engine where we'll
see the content in this case?
I asked about the
app visibility.
JAKE ARCHIBALD: I think it's a
very similar answer to before.
If you're using Service Worker
as enhancement, the user
lands on the page and
you're serving content,
and then on the next load
of the Service Worker,
you can do things
with the caches,
there in terms of how Google's
web search sees your site,
it's exactly the same.
And there's no SEO
impact, yet if you
start making things depend on
Service Worker, at the moment,
you will impact SEO.
If we see a lot of
people doing that,
then we'll look at
ways of fixing that.
But there's nothing in
there at the moment.
AUDIENCE: OK, so
basically it's all
about progressive enhancement?
JAKE ARCHIBALD: Absolutely.
Yep.
Service Worker was built with
progressive enhancement in mind
from the start.
GREG SIMON: Remember,
the first load
of the site that
supports Service Worker
doesn't support
Service Worker right?
JAKE ARCHIBALD: Right.
So there's going to be a
breakout session on Service
Worker after the event, so.
And I still have a little
bit of energy left,
so I could probably
do a Q&A on that.
So I'll kind of--
DARIN FISHER: Why don't we
take another Service Worker
question?
JAKE ARCHIBALD: Yeah, you
guys are getting off lightly
with this.
So, when will Add to
Home Screen be on desktop
is a question we've
had because it's
really annoying that mobile
is pushing forward here,
and the desktop is
being left behind.
Rahul, do you want
to take that one on?
RAHUL ROY-CHOWDHURY: Sure,
I can take a stab at it.
We are looking at it.
We are experimenting.
On desktop, I think, which
is different from mobile
in the sense that on mobile, a
common usage pattern is going
to the Home screen,
launching an icon,
and so bringing that to the
web was a reasonable thing
to do because you're
in the user flow.
On desktop, it's a bit
more of a mixed bag.
There's much more sort
of established patterns
of behavior.
We need to be thoughtful
about how we want
users to change that behavior.
And so we're looking at it,
and we will figure out--
we'll try some things out,
and we'll see how they work
and then make progress.
DARIN FISHER: I mean, since
the beginning of time,
Chrome's had-- since
the beginning of Chrome,
Chrome has had a Create
Application shortcut
feature, which is essentially
Add to Home Screen.
It's just not something that we
are promoting in the same way
that we are promoting on
mobile-ware that you see
the banner show up and so on.
But as Rahul said, it's
something we're looking into.
JAKE ARCHIBALD: So
I am aware that I
keep saying guys when I'm
referring to groups of people,
so I apologize for that.
I'm going to blame
being in America
because I don't do
that back home, right?
I always say folks.
I say folks, so.
Something's gone very
wrong in my brain.
So I apologize for that.
Another question.
Angular is the largest
front-end framework currently.
Why does the Chrome dev team
not include them more in demos.
You would increase your
target reach audience
by several orders of magnitude.
MATT MCNULTY: Matt should
probably take that, right?
ALEX KOMOROSKE: Yeah.
MATT MCNULTY:
Yeah, exactly, I've
got a minute and 18
seconds to do this one.
So, yeah.
So I've been doing this
for a really long time.
I've been in the web UI
world for a really long time,
so you see a lot
of patterns emerge.
So there's always about
every two or three years, one
or two years, there's
a new hot thing
that everyone sort of
gets excited about.
So you know, right now,
it's actually probably
React more than Angular.
I'd say Angular was probably
the last one a couple years ago.
And you know, honestly, from
the web developer's perspective,
this is great.
These are all great choices.
The fact that you actually have
a choice on the web as opposed
to native is a really,
really good thing.
And you can find a framework
that actually really suits you,
and that's really awesome.
And I'd much, much rather have
someone build an app in Angular
than build a native
app, frankly.
You know, I really
want the web to win.
And you know, from the
perspective of framework
developers, you know,
because I was one previously,
you know, the web platform is
this thing that doesn't really
do what you want and that
you can never change.
So they build all
these big abstractions
and you know, bring
their own platform,
and bring their own
programming model to the table,
and it ends up being kind
of an interesting thing,
and it ends up being
really successful, right?
And part of our job in Chrome
is to make those things run
really, really fast.
But Polymer is pretty
different than that,
and when we first showed
up to work on Polymer,
before it was known
as Polymer, you know,
Darin and Dimitri
sat us down and said,
OK you know, here is these new
primitives, web components.
You have to make
something out of this.
It has to be idiomatic.
You have to use the platform
in the most idiomatic way,
and it has to be
really, really thin,
and if something's
broken, you have
to tell us so we can fix it.
So you know, that sort
of framework assumption
was incorrect for us.
We were actually allowed
to change the platform.
We were part of the platform.
And so what happened is Polymer
ended up being very different,
right?
We used Dom as the framework.
We don't build a
whole big framework.
You know, apps built in Polymer
don't have a really big JS
payload, and they're really,
really fast as a result,
and we can innovate on
them on a native level.
So in the end, Polymer
was ending up just
as kind of an extension
of the native platform.
OK?
And it was part of and we're
physically part of the team
as well.
So I think it ends up that
that's why Polymer's different.
That's why we're part
of the web platform.
That's why you see us here.
That's why you see us at IO.
And that's why
we're focused on it.
JAKE ARCHIBALD: And that
is all we have time for.
So thank you very much to
the panel, Greg Simon, Darin
Fisher, Grace Kloba, Rahul
Roy-Chowdhury, oh god.
I'm so sorry.
RAHUL ROY CHOWDHURY:
It's all right.
JAKE ARCHIBALD: And
some other people.
Dimitri Glazkov, Alex
Komoroske, Matt McNulty,
and Parisa Tabriz.
A big hand for these folks.
Thank you very much.
[APPLAUSE]
[MUSIC PLAYING]
