[MUSIC PLAYING]
NICOLE SULLIVAN: Hi, and
welcome to the day two keynote.
My name is Nicole.
I'm a PM on the Chrome
Web Platform team.
MALTE UBL: Hi, my name is Malte.
I work on AMP and JavaScript
infrastructure at Google.
So actually, this is a little
bit awkward today because,
for the second keynote--
and Ben and [? Dion ?] already
talked about, effectively,
everything yesterday--
so we thought we'd do
something slightly different.
So normally, at a Chrome
Dev Summit keynote,
we'd walk through all
the new, exciting APIs
that the [INAUDIBLE] platform
makes available for you.
And so we actually
are going to do that.
But first, we want to talk about
something slightly different.
We want to talk
about web frameworks.
NICOLE SULLIVAN: Developers
who build for the web often
choose to use a framework.
In the past, changes
to the web platform,
didn't necessarily take the
frameworks into account,
and changes to frameworks
didn't necessarily
take the web platform
into account.
We think both the web platform
and frameworks benefit
from a close
collaboration, and so we're
out to make that happen.
Obviously, if you're
building something simple,
it makes sense to choose
simple technologies.
But as soon as an app
is sufficiently complex,
in most cases, developers
choose to use a framework.
A few months ago, I put out
a very, very methodologically
correct Twitter
poll, asking people
why they choose
to use frameworks,
and got back a whole
bunch of answers.
And this one, in
particular, sort of
resonated with a lot of people.
"You can't not use a framework.
Your only real choice
is to either use
one that's open source,
documented, tested, supported,
maintained, mature and proven"--
and I think we'd all throw,
you can stack overflow stuff
about it into that one.
Or the option B is you
cobble together some garbage,
unmaintainable stuff yourself.
MALTE UBL: I've made a
few of those, actually.
NICOLE SULLIVAN:
Yeah, I might have
made one or to have
those in my day before.
MALTE UBL: And
given that, we just
want to start by
recognizing that frameworks
are part of the web.
And if you're using
a framework, you
are in fact using the platform.
So let's go from there
and kind of extrapolate
to the further web stack that
is based on that insight.
So on the bottom, obviously,
you have the web primitives.
So that would be the Dom, the
Fetch API, service workers,
stuff like that.
NICOLE SULLIVAN: Then above
that, we have built-in modules.
Built-in modules
are pretty exciting.
They're a new thing.
It's the idea that we can build
in a layered way for the web.
They're high-level APIs
that solve something
like virtual scrolling
or carousels.
I think we all love
to hate the carousel.
But if we're truly
honest, they're
on almost every site
in the known universe.
So we can build something
like a high-level API,
like a virtual
scroller, and then that
drives out the
low-level APIs that we
need to make those experiences
accessible, searchable, truly
fast.
Those low-level APIs can then
be used by the entire ecosystem
of virtual scrollers.
That makes a big difference
because it allows everyone
to level up together.
MALTE UBL: Right.
Then one level up, we've
got the frameworks.
So that would be like
React, Angular, Polymer,
or higher-level stuff, like
Next.js and Sapper that kind of
treat you to everything that you
need to build an application.
So obviously, these
aren't standardized.
They're not web standards,
but most applications
use one of these.
And so we think of them
as part of the platform.
NICOLE SULLIVAN: The next
part is web components.
And you're probably
thinking, wait,
that doesn't make any sense.
Web components are a web
primitive or a web standard.
I'm not talking about the web
components, the standards,
I'm talking about your web
components-- your date picker
or, I don't know, tabs.
MALTE UBL: Maybe the carousel.
NICOLE SULLIVAN:
Maybe your carousel.
Sorry.
Yeah.
These are the web
components that
layer on top of your stack.
Why it's important
to put them there
is because they're an important
measure of interoperability
between different
parts of your system.
MALTE UBL: Right.
To kind of make a point,
let's do a quick poll here.
NICOLE SULLIVAN: Ooh, yeah.
MALTE UBL: Who here in this room
has built a React application?
All right.
That's most hands.
So if you--
NICOLE SULLIVAN:
Oh, keep them up.
MALTE UBL: No, no.
Keep it up.
NICOLE SULLIVAN: Keep them up.
MALTE UBL: Keep it up.
Keep it up.
If anywhere in your company
you also have an Angular,
jQuery, Backbone, Polymer,
anything like it, both hands.
NICOLE SULLIVAN: Yeah.
MALTE UBL: All right.
So if that's the case--
NICOLE SULLIVAN: I
love your honesty.
MALTE UBL: Wouldn't it be
nice if you could use the date
picker in both of those?
If you could have a
design system that
spans your entire
applications suite,
no other framework
gets built in.
So that's where we think
the leaf components, web
components, are really the
right technology to build that.
NICOLE SULLIVAN: There's,
however, a real problem
with web development today.
We're struggling to
make stuff that's
really fast and responsive and
has buttery-smooth animations.
And I think we're struggling
because, in a bunch of ways,
it's actually really hard.
Not everybody struggles.
There are examples of
sites that achieve this.
But at scale, what we observe
is that our performance goals
aren't being met.
MALTE UBL: Right.
And so what we're observing
is that, in web dev today,
we often have to make that
choice between developer
experience--
how we feel as
developers-- and user
experience-- how users feel.
And that shouldn't
really be how things are.
In the vast majority of
cases, developer experience
combined to accumulate a
great user experience-- that's
just not how it works today.
But if we can achieve those
things coming together,
the web will be
better for everyone.
NICOLE SULLIVAN:
This is why we're
so excited about frameworks.
Yes, frameworks sometimes
make web apps slower.
That's a reality.
But they're also our best
hope to make them faster.
MALTE UBL: Right.
That's a bold statement.
NICOLE SULLIVAN: It
is a bold statement.
MALTE UBL: Right?
To prove that this is
actually happening,
we thought, wouldn't it
be nice if we celebrated
all the great improvements
that framework
has made through this year?
Let's start with React.
They have done a bunch
of foundational work.
For example, they're working
towards making code splitting
something that's
first class supported
in the framework,
which is really nice.
And then they've
done a lot of work
to break up the rendering
of huge dump trees
into tiny chunks.
So that if you
have a big update,
it doesn't lock down your
browser for many seconds.
Everything's kind of
done in small bricks.
NICOLE SULLIVAN: This
is a theme you're
going to hear us talking
about a few times.
MALTE UBL: Yeah.
NICOLE SULLIVAN: Angular
made improvements, too.
The Angular CLI enabled
performance budgets.
This is great.
Because how often do you not
realize that you actually
alienated a bunch of users by
adding that one more library,
or NPM installing
something, then it
installed a whole
bunch of other things?
Angular also did a bunch of work
to remove unnecessary polyfils,
and that's fantastic.
We don't want polyfils for
the most modern browsers.
MALTE UBL: Right.
Speaking of which, Vue
basically did the same thing
with a thing called modern mode.
So you only ship the modern
code to modern browsers, right?
And that's effectively
the same idea.
And that's why we're so
excited about frameworks
bringing this best
practice to all the users.
Similarly, with another
one, just making--
preloading,
prefetching something
the framework does by default.
NICOLE SULLIVAN: Polymer did
some good work this year, too.
They're transitioning
to lit-element
for super small components.
And they also got faster
because, yay, Firefox shipped
native web component support.
MALTE UBL: Woo!
Cool.
Let's talk about Svelte.
They get a bullet point for
already being super fast.
NICOLE SULLIVAN: Yeah,
it's kind of hard--
with Svelte, it was like,
well, they're so fast,
what do we even say about this?
MALTE UBL: Right.
But I think this
was a great example.
So they built a Hacker
News app, and they did it
in an idiomatic
way, so not using--
NICOLE SULLIVAN: It wasn't
super highly optimized.
MALTE UBL: --super
ridiculous hacks, right?
So everything in that app--
HTML, CSS, JavaScript--
together is under 20 kilobytes,
which is just amazing.
NICOLE SULLIVAN:
AMP did some good--
Malte did some good stuff, too.
So this, apparently,
is the only feature
he shipped this year,
because now he's a manager.
MALTE UBL: Yeah, I'm sorry.
NICOLE SULLIVAN: So he
ships feature policies
against synchronous
XHR for all ads.
If you're going to
ship one feature,
this is a pretty darn good one.
MALTE UBL: Right.
If you're [INAUDIBLE],, you
get to put your own feature
on the slide.
NICOLE SULLIVAN: Nice.
He also reduced-- or
sorry, they also reduced--
MALTE UBL: No,
definitely not me.
NICOLE SULLIVAN: --reduced the
JS size on the wire by 20%,
by enabling Brotli
compression algorithm.
We love this kind
of thing, right?
Because how great is it
that all you have to do
is turn on a different
kind of compression,
and you get 20% reduction
in size on the wire?
MALTE UBL: Right.
Moving on to Ember, which
removed jQuery from the default
bundle, by the way--
I have a jQuery t-shirt.
Just leaving that out there--
making their bundle size 20%
smaller, which is great.
And they did it in a way
that's backward compatible
so that people can
slowly migrate to this.
NICOLE SULLIVAN: Yeah,
it's pretty neat.
They actually, as far
as I understand, made it
so that anyone can turn
on and off old code--
MALTE UBL: Right.
NICOLE SULLIVAN: --using
the same functionality.
So that's pretty great.
MALTE UBL: And then
another theme here,
implementing the incremental
progressive rendering
with batched rehydration,
which again, comes down
to that "chunking of work"
theme, which we're seeing here
all the time.
Great.
So to summarize this, we
really want to get to a state
where not only the super experts
can make great web experiences,
everyone should
be able to do it.
And frameworks are an integral
part of making that happen.
Today, we feel that we--
and by we, I mean browsers,
framework and tools--
have under-invested
in tools that
focus on combining
great developer
experience with a focus
on user experience.
Well, we can make this
happen as a community.
By integrating the best
practices for performance
into frameworks, all
users of those frameworks
automatically get
all the benefits.
And that's how we
think we can achieve
great outcomes for users
at the scale of the web.
All right.
NICOLE SULLIVAN: To
make this happen,
we're announcing
three things today.
The first one is,
we are including
frameworks in the Chrome
Intent to Implement process.
How many folks know about
our intent to implement,
intent to ship stuff?
A few.
Great.
That's awesome.
So we have, basically, two
important check points--
we have more than
that, but two very
important check
points-- when we're
going to ship a new feature.
One is our intent to
implement and the other
is our intent to ship.
At both points, when we are
about to build something
and when we're about
to ship something,
we want to get a
lot of feedback.
And so we go through
this intent process
in order to intentionally go
in and draw in that feedback.
Previously, we had listed
web developers as folks
that we wanted to
get feedback from.
But now, we're actually
explicitly adding
frameworks to that intent
to implement process.
MALTE UBL: Right.
And secondly, we want to put
real dollars behind this.
So we're starting with
a budget of $200,000
to kickstart developing of
performance-related features
in frameworks.
In particular, we make
available a list of performance
features that we'd love
all frameworks to provide
to the users by default. Folks
who are working on a framework
can ask for funding
to do the actual work.
We're still working
out the exact details.
But if you're interested,
check out this bit.ly link
for more information.
NICOLE SULLIVAN: The third
thing that we want to do
is increase collaboration
between frameworks
and the Chrome team.
It's funny to
announce this today,
because it's actually something
that we started in the summer.
And we've been working
with a bunch of frameworks
for the past several
months, but we
are excited today
to talk through some
of what we've started already.
MALTE UBL: Right.
That brings us to
our next section.
It's very much
under construction.
You heard that in
the intro today.
What you're hearing
about here-- these
aren't things that
are shipping tomorrow.
Some of them you can
try out a little bit.
Some of them are really just--
NICOLE SULLIVAN:
Some behind a flag.
MALTE UBL: Yeah.
We're really just
thinking about them.
So it's still very much time to
give us your feedback, your use
cases, your examples, to work
out how they really work.
NICOLE SULLIVAN: The first
one we want to talk about
is Display Locking.
We basically don't want to
update the DOM inadvertently,
and so this gives
us a way to lock it.
Before I joined Google,
there-- well, many times,
I think this is one of the
most requested features.
But before I joined Google, the
Polymer team and the Paint team
had a bunch of conversations
about a new primitive
called Display Locking.
The idea of Display Locking
is that you can basically
lock down a section
of your DOM, and we
won't trigger render and other
things on that bit of DOM
until you unlock it and
say, OK, it's ready to go.
It's super subtle.
And it may not be something
you interact with directly,
but it's definitely something
that frameworks need in order
to eliminate unnecessary
browser work.
Now, we're collaborating
with the React team
to nail down the API.
And we had an Intent
to Implement out
about a month ago.
So if you have comments,
we'd love to hear them.
MALTE UBL: I have
a question, though.
Is it related to that bocolor?
NICOLE SULLIVAN: [LAUGHS]
MALTE UBL: Because
I'm using every day.
NICOLE SULLIVAN:
Yeah, absolutely.
MALTE UBL: Nice.
NICOLE SULLIVAN: [LAUGHS]
Well, this is kind of awkward.
Is it working?
MALTE UBL: I don't know.
NICOLE SULLIVAN: It's
kind of strange to see
a blank white screen in the
middle of a presentation.
Why do we think that's OK
when web pages are loading?
It's sort of-- ah,
what's going on?
MALTE UBL: Right.
Every time-- every single
time you load a new web page,
the browser says, hm,
what's the good idea to do?
Oh, yeah, I'm going
to paint white.
And then it's going to
take a while, right?
Why is that the case?
So it shouldn't be the case.
NICOLE SULLIVAN:
We should tell you
that we totally scared
the tech check people
when we had a blank white
screen during our tech check.
MALTE UBL: All right.
We really need page
transitions on the web.
You're probably
familiar with stuff
like this from the material
design specification
where one page
morphs to the other.
And there's other
ideas how to do this.
Now, this is something you would
see in your application going
from one state to
another, but we also
want this for normal
navigations, right?
Here's a great example.
So this is something the
image search team at Google
is working on.
NICOLE SULLIVAN: It's kind
of subtle, so look closely.
MALTE UBL: Yeah, well,
we'll walk you through it.
So this is their image
search result page.
And when you click
one of the images,
you go into this box to see the
larger version of the image.
So their goal was that
more people click through
to the underlying web page.
And so they wanted
to make that really
easy by just literally
putting that web
page at the bottom
of the page, right?
So that, as a user, all you have
to do is put your finger on it
and draw it up.
We're hoping that
this greatly increases
the number of navigations
actually happening.
But this is something
that you really just
can't build on the web today.
NICOLE SULLIVAN: And
we'd love for you
to be thinking,
if you didn't have
to have that blank white
screen, what would you build?
What would you design?
Because I think it's actually
a pretty exciting space.
MALTE UBL: Right.
Today, you really
have to choose between
either a fancy transition
or doing a real navigation
where the browser
loads on your page.
And there isn't
really a solution
for the cross-origin
case where you navigate
to different domain at all.
And so that's why we're
so excited about portals.
What portals give you
are advanced transitions
between websites that
are real navigations.
SPAs, single-page apps,
that's the way to do it today.
But here, you can-- and this is
what this example GIF shows--
this is a navigation from
one web page to another.
And you can morph between
them any way you like,
which seems like something
we should have in 2018.
NICOLE SULLIVAN: It
does, doesn't it?
Yeah.
I think sometimes people
choose a single-page app
with all of its complexity,
when actually what they
wanted was fancy transitions.
So we hope that this [INAUDIBLE]
MALTE UBL: Right.
It can be really hard
to do a single-page app.
Cool.
NICOLE SULLIVAN: So I
got a sporty new car.
And within a month,
I got a ticket.
I was driving too fast.
MALTE UBL:
[INAUDIBLE],, hopefully.
NICOLE SULLIVAN: No.
On the San Mateo bridge.
Whoops.
I won't tell you how
fast I was going,
but I found out that my car
has this really cool feature.
I can turn something on
so that it beeps anytime
I go over 80 miles per hour.
That seems really good,
because there should be limits.
And this car does not feel
like it's going fast when it's
going actually pretty fast.
There's also something
you can turn on
for a motor or a car, which
is called a governor, which
actually will not allow the
car to go over a certain speed.
Feature policies are
sort of like that.
You have a couple of options.
You have Enforce mode and
you have Report-Only mode.
You can turn a feature
policy on for something
like synchronous XHR,
and you can say, no,
I don't want to allow that.
And it simply will not
allow that to happen
on your site at all anymore.
Or you can turn on Report-Only
mode, and you get that beep.
Hey, something's wrong.
You should check it out.
We're pretty excited
about feature policies
because they run in CI.
You can run them in development.
You can run a different
set of feature policies
on your third-party
content, your ad content,
than you do on
your regular page.
So you've got a
lot of flexibility
around how you use it,
and we're excited to see
what you want to do with it.
What you can use today is a
synchronous XHR feature policy.
We collaborated
with the AMP team,
and they've got it turned
on for all ads in AMP, which
is pretty exciting.
MALTE UBL: This is, basically,
by the way, the worst
feature of the web.
You want to turn this off
for your website, right?
There's no good reason
to have Sync XHR.
NICOLE SULLIVAN:
There's basically
no conversation in
which Malte does not
bring up that you should
turn off Synchronous XHR.
MALTE UBL: I'm so mad about it.
NICOLE SULLIVAN: [LAUGHS]
Even at your barbecues.
There are other policies
that are available, as well.
So there are some exciting
ones, but they're behind a flag.
So you have to go and turn it
on behind the flag in order
to check it out.
There are three I'd
love for you to look
at-- unoptimized images,
oversized images,
and unsized media.
Go see how they improve
your performance.
See whether you like it
with Enforce mode on,
or Report-Only mode.
We would love more feedback.
MALTE UBL: Right.
And don't upload pictures from
a DSLR directly to the web,
please.
NICOLE SULLIVAN: Yes.
And you'll hear Jason
talk more about this
a little later today.
MALTE UBL: Right.
All right.
Next, we want to talk
about instant loading,
so how we get from super
fast to 0 milliseconds.
To show you what exactly we
mean by that-- because instant
is an overloaded word, right?
There's instant apps, which
don't do instant stuff.
So let's talk about this.
Here's a film strip you might
be familiar with from how
a web page loads.
This one loads in
eight seconds, right?
And obviously, you
could make that faster.
But--
NICOLE SULLIVAN: I mean,
we've spent years trying
to eek out every little second
that we can out of the film
strip, right?
MALTE UBL: Right.
But we want this.
We want, basically,
everything to go away,
and only that last frame
to render right away.
So we have a solution
for that, which
is actually relatively obvious.
You have to load that web
page before the user clicks.
But now you might wonder
why I put a bathroom
stall on the screen, right?
It's a US bathroom stall.
It has this little
gap, which, like this--
[LAUGHTER]
--introduces a privacy
problem, right?
[LAUGHTER]
Does anyone know why
this is the case?
Anyway--
[LAUGHTER]
So when you load some other
web page before the user said
they wanted to go
there, that web page
might be able to
read your cookies,
set cookies, stuff like that.
And that's not something
the user expects, right?
So we need a solution for that.
And the solution that has been
under development for a while
is called web packaging.
What it provides, as
one of its features,
is privacy-preserving
instant loading for the web.
I want to explain really
quick how that works,
but we'll have a
talk, later today,
that goes into actual detail.
NICOLE SULLIVAN: Yeah.
MALTE UBL: From people who are
working on it, which is great.
So the way web
packaging works is
that you're a document author,
and you have a TLS certificate
that we're using for
HTTPS, something like that.
And you sign that content
to be created by you.
And then anyone can
deliver it on your behalf,
but the browser says,
OK, this was originally
signed with that
TLS key, so I can
say it came from
example.com, because that
was the original party.
And I want to
drill down on this.
Anyone can deliver it.
So you could have
a different CDN,
but you can deliver it
over BitTorrent or IPFS.
It doesn't really matter.
You can do basically HTTP over
anything, which is really cool.
Oh, my god, look at this.
NICOLE SULLIVAN: So we
collaborated with the AMP team
on this, because they're
one of the frameworks
that we're working with.
And we're pretty excited
about the instant loading
and how fast we're going to be
able to bring content to users.
But Malte, what about the URLs?
MALTE UBL: Yeah, AMP
doesn't have very good URLs.
So there's [INAUDIBLE] AMP.
And with web
packaging, that problem
goes away, which is really cool.
So that's why we're
excited about it.
But-- and this is
the important part--
it's a web standard, right?
And so with web packaging,
we can bring Instant Loading
to all these frameworks.
And this is not an
exhaustive list, right?
It doesn't really matter.
This technology is
completely technology--
it doesn't care
about technology.
So really, really cool.
We can't wait for this
to land on browsers.
Web packaging also
addresses one more problem
that I think is really subtle.
Eric Meyer tweeted this and
wrote this blog post, which
is really cool, a while ago.
Traveling to Africa and
noticing that HTTPS,
which is the greatest thing that
happened to the web in a while,
among many other
greatest things--
actually introduced
a few problems.
So let's imagine
you're a cell tower.
And you're not actually
connected well to the internet,
but you have LTE to
everyone connected to you.
Right?
It's great if you have an
edge cache at that cell tower.
Now, with HTTP, that's
something you can build.
With HTTPS, it's
something you can't build.
So you always have to go to
the origin, to someone actually
able to serve on
that TLS certificate.
Right?
And the great thing
about web packaging
is that it can bring
back that feature.
Because it's untangling
delivery from TLS security,
you can get all great benefit
of having edge caching for HTTP,
but have it together with
the security benefits of TLS.
I also want to just
really quickly say
that web packaging is
not related to Webpack.
However--
[LAUGHTER]
--however, there's a
bundling spec coming up.
And so web packaging
is actually going
to bring bundling as a
first-class feature to the web
platform, which I think
is also way overdue.
And so bundlers, like
Webpack, can eventually
use Web Packaging as
the output format.
You can actually try this today.
There's a subspec,
called Signed Exchange,
which is available
in Origin Trial.
You can go to this
URL and try it out.
NICOLE SULLIVAN: Let
us know what you think.
MALTE UBL: Yeah.
NICOLE SULLIVAN: Later today,
you'll hear [INAUDIBLE] and--
who else is speaking about it?
MALTE UBL: [INAUDIBLE]
NICOLE SULLIVAN: Yes.
So the next bit that we'd
like to talk to you about
is scheduling.
So any time developers build
something sufficiently complex,
they end up needing to
manage a task queue,
prioritize work, and
be sure that everything
is getting done on time.
MALTE UBL: So we don't run
out of time on our talk.
NICOLE SULLIVAN: That, too.
A typical app has
competing deadlines,
so keeping the user
input responsive,
while rendering smoothly
at 60 frames per second,
and doing the actual work
of fetching, preparing,
and rendering the UI.
In talking to the React
team a few months ago,
we realized that a
framework-based scheduler
has serious downsides.
It can't schedule
third-party code.
It has a lot of
difficulty interleaving
tasks with browser functions,
like rendering and garbage
collection.
In short, it has to fight
other systems for resources.
With help from React, Google
Maps, AMP, Polymer, and Ember,
as well as the web
standards community,
[? Shuby ?] and Jason-- who
you're going to hear from later
today--
are designing a scheduler
that will run in the browser.
It's meant to have high and
low-level APIs, like Grand
Central Dispatch, so
borrowing some ideas there,
and be able to interleave code
from all different sources.
They're working on
things like, how do you
interleave garbage collection
or code that's in a promise?
What's exciting about
this, in particular,
is that when you break
things down into small tasks,
it's much more useful
if you have a great way
to schedule them.
When you can schedule
things, they're
much more valuable if
you've broken things down
into small tasks.
This is where frameworks
and the browser
can work well together to
provide a much better user
experience than we're
capable of providing today.
This is one of the things I'm
most excited to PM right now,
and I'm really excited
for you to hear
from [? Shuby ?]
and Jason later.
MALTE UBL: Right.
It's really a good example
for how frameworks help.
Because actually
taking your code
and breaking it down
into small chunks,
that's really, really difficult.
But as a framework layer,
this is something
that people can just
take a long time doing, but
then having it for everyone.
NICOLE SULLIVAN: I
mean, I think you saw,
in the framework
awards section earlier,
that three frameworks,
at least, are
working on breaking things
down into really tiny rendering
chunks.
So this is pretty exciting.
MALTE UBL: Right.
Next, we're talking about
Animation Worklet and Jank-Free
Parallax.
By the way, ironically, in
front of a janky animated GIF.
So Animation Worklet--
first, we need
to talk about other animation
APIs because there are a few.
There's the Web Animation
API, which is great.
And you should use it.
And also more importantly, it
just landed in Safari Preview.
So relatively soon, we should
have it in most browsers.
CSS animations are also
awesome, and they're basically
everywhere.
So you can use them.
And you should use these APIs.
And Animation Worklet doesn't
provide additional value,
except in some very
important circumstances.
Because these APIs are
inherently time-based,
which makes sense, animations
go from A to B over time.
That's kind of what they do.
However, there are
some animations
that aren't time-based.
For example, this one,
which animates Pac-Man
based on scrolling
left and right.
And this is something
that's really difficult
to do on the web today
in a jank-free fashion.
So the reason for this is
that, with Animation Worklet,
on the other hand,
where you don't get jank
is because that actual
worklet runs super close
to the actual software
that does the scrolling.
And so you can do it, even when
the main thread does anything
busy, which is really cool.
My team actually
has been working
on getting this into our-- what
we call-- scrollbot animations.
And it was just a
drop-in replacement.
And it makes everything
so much smoother.
[? Surma ?] is talking
about this later today
in the talk about Houdini.
NICOLE SULLIVAN: And he'll
have some really cool demos.
MALTE UBL: Yeah.
NICOLE SULLIVAN: Almost
every web app eventually
needs something like
an infinite list.
It just happens, right?
On other systems--
on Android, on iOS--
there are things
like UI table view.
On the web, you're left
to figure it out yourself.
Now, many frameworks have
really good implementations
of a virtual list in an infinite
scroller kind of situation.
But the web platform primitives
make certain behaviors
impossible.
For example, have you tried
to use findInPage if you're
using an infinite list?
I often find myself going
back to search for a tweet
that I made, or someone
else made some time ago.
You can't search for
things that aren't actually
in the DOM right then.
This is obviously going to have
accessibility implications,
as well.
With new low-level APIs that
we're putting into place,
like searchable and
visible DOM, all
of the sudden, these things
become solvable and get
addressed.
You'll hear more about
our collaborations
with React, Virtualized,
Angular, and Twitter
in Gray's talk a
little later today.
MALTE UBL: All right.
So that brings us to
the end of our talk.
Just summarizing--
we have been talking
about our vision for a
framework-inclusive web
platform future.
NICOLE SULLIVAN: Instant
loading and page transitions
are coming to the web.
Especially if you're
a designer, get
thinking about what you're
going to build with that
because it's going
to be kind of cool.
MALTE UBL: Right.
And then we talked about a
set of new low-level APIs
making it easier to build
reliably fast web apps.
And that's especially
true if frameworks
help web developers take
advantage of them by default.
Thank you, very much.
NICOLE SULLIVAN: Thank you.
[MUSIC PLAYING]
