[MUSIC PLAYING]
TAYLOR SAVAGE: My
name is Taylor Savage.
And I'm a product manager on
Chrome's Developer Experience
team, which encompasses the
many different open source web
developer products that
we build here on Chrome.
So I'll be talking
today primarily
about one product in particular,
which is the Polymer Project,
and about how the
Developer Experience
team has been thinking
about leveraging
all the different features
you're hearing about
on the modern web
platform, in order to build
fully end-to-end applications.
But like a typical
product manager,
I want to start today
by taking a step back,
taking a 10,000-foot view, about
why we build developer-facing
tools and products and libraries
in the first place on Chrome
and the role that we see our
products playing in the broader
web development ecosystem.
So our biggest product that
we build on the Chrome team
is, as you might guess,
Chrome, the browser.
And our focus, when
building Chrome the browser,
is to provide the absolute
best user experience possible.
And so we've built
many, many features
within Chrome to
make this happen,
things like Chrome
Sync and Autofill,
tons of security work,
countless optimizations
to make page loading
faster and more efficient
that you've heard about
in the last two days,
things that we're talking
about at Chrome Dev Summit.
But at the end of
the day, a browser
is really only as useful as what
exists on the web to browse.
So we don't really
make Chrome great.
You really make Chrome great,
as web developers, with all
the things that you build.
So Chrome is just a window onto
the applications and websites
that you create.
So the quality of
the user experience
on Chrome the browser
product is very fundamentally
tied to the quality of the
sites that get put on the web.
So on the Chrome
team, in addition
to building Chrome
the browser, we're
looking for opportunities
to also build
products that help you
web developers create
and distribute really
high-quality sites.
And the trick,
though, for our team
is to figure out where
our effort is best applied
for maximal leverage.
Because as everybody
here is very well aware,
the open source web developer
ecosystem, on its own,
is an amazing massive place.
You don't really need us.
New products for web
developers are coming out
every single day, are being
built and being open sourced.
There is certainly no
lack of innovation.
And of innovation, there's
certainly no lack of diversity,
in terms of the tools that
are available for us to use.
Today's open source web
development world, though,
is subject to a dominating
force, which I affectionately
like to call the JavaScript
Industrial Complex.
And this is the
positive feedback loop
between all the different types
of players in our ecosystem,
the open source
projects themselves,
tooling that's adjacent to these
projects, content creators who
write blog posts, who tweet on
social networks, conferences,
trainings that people pay for
to learn more about these tools.
All these different
aspects are all
really critical to generate all
the projects and documentation
and education and support
that we rely on every day
to do our job.
But the dynamics of this
JavaScript Industrial Complex
will sometimes reward
shorter-term optimal solutions
at the expense of what might
be optimal in the slightly
longer term.
Now, we all want to
build tools and we all
want to use tools
that solve problems
that were hitting right this
instant on the web platform.
And so its these sorts of
tools that solve our problems
today that tend to benefit
the most from this system,
as you'd expect.
Now, fortunately,
the web has been
designed to be an incredibly
flexible platform.
And so many of the problems
in web development that we hit
can totally be papered over,
in the short-term, with tools.
But unfortunately, with
the continual application
of these tools, we
risk, one, adding
a ton of extra complexity
to our workflows and, two,
ultimately ossifying ourselves
at, sort of, a local maximum.
And we all know that getting
stuck micro-optimizing
at a local maximum is a
sure path to obsolescence.
So on the Developer
Experience team on Chrome,
we try to focus
specifically on solving
the problems that we have a
unique opportunity to solve.
So one big unique
angle that we have
is our proximity to
Chrome, the product.
So we have particular
expertise, when
it comes to how the
browser works, for example.
We have an ability to try
to influence the overall web
platform.
And so we look for
gaps in the ecosystem
where our particular
context and skill set
will be particularly valuable.
So we work on products like
Chrome Dev Tools, which
we can bundle
directly with Chrome
itself, which would communicate
with Chrome at a very low level
to help you inspect
and debug your website.
We built things like Lighthouse,
which can seamlessly and deeply
integrate with the
Dev Tools protocol
to express our
particular vision of what
makes a good, fast,
high-quality site
and help you measure your
own site against that bar.
But another unique position that
we have on the Chrome team that
helps inform what
developer products
we want to focus our time on is
our inherently long-term view.
So the web has a very
long-time horizon.
And we, here on the Chrome
team, are fundamentally
tied to that long-time horizon.
We're in a very
fortunate position
in that sense in that we're very
deeply committed to the very
long-term health of the web.
So Chrome is going to
be here a long time.
And we can't really
afford to get caught up
in short-term hot trends,
because we're playing
a very, very, very long game.
And often, what this means
is that the best investment
that we can make on the
Developer Experience
team on Chrome is an
investment in improving
the underlying platform itself.
So now, here's the rub
with that strategy.
Which is, the web platform
moves extremely deliberately.
It takes years for a new
feature in the web platform
to get designed, agreed
to, shipped across browser.
And there is a huge cost,
also, to taking features out
of the web platform, if
it's even possible to do.
So we have to be
extremely careful
and thoughtful and
deliberate when
considering what new features
we can add to this platform.
The road to changing the web
platform is a very long one.
You've got to get a
spec written and then
get it generally agreed to
across the different browser
vendors.
And then you've got to
implement it in a browser.
And then you got to
ship it in that browser.
And then you've got
to, inevitably, fix
the bugs that come up
after you've shipped it,
because you've broken it
and it's not useful yet.
And then you've got
to wait until it's
in enough browsers, shipped
and available for developers
to use, that the developer
ecosystem will actually
start taking advantage of it.
So for a fundamentally new
feature, a fundamental change
to the web platform
itself, to get baked in,
it requires a dedicated
group of people fighting
for that feature, in it for
the very, very long haul,
for years, maybe even a decade.
And so we dedicate a part of our
Chrome platform team to fight,
specifically, this fight,
to analyze the ecosystem
and then work with
other browser vendors
to come up with
new features that
plugs holes in the
platform, and then
fight in the trenches for
years, to actually see
these new features come to life.
So this is where web components
and the Polymer Project
come in.
So we noticed, a few years
back, that web development was
getting more and more complex
and that the ecosystem was
getting increasingly siloed
and locked into frameworks,
many of which, at their core,
were solving fundamentally
the same problem, which was
providing a sane component
model on top of
the web platform.
And again, the lack of a sane
web-native component model
is exactly the kind
of problem that
can totally be solved in
the short-term with tools.
But in the long term,
we'll only really
be able to drive
toward simplicity
with a fundamental
change to the platform.
And so we set out to
create web components.
Now, a long story short--
a long story short--
after many years, the
web component standards
have finally crossed
a major finish line.
Web components
have been natively
supported in Safari and
Chrome for a while now,
meaning that there are over
1 billion mobile devices
out there right now,
in users' pockets, that
have native support
for web components.
So web components are a reality
of today's web platform.
And we're starting to
see the ecosystem adapt
to these new, powerful,
web platform features.
We're starting to get to that
last phase of the component
flowchart.
New development frameworks,
like Ionic Stencil JS,
have really exploded onto
the scene, based entirely
around web components.
Other frameworks, like
Glimmer and Svelte,
allow you to output
components as web components.
And existing frameworks, like
Angular and Vue and Preact,
now provide first-class
support for web components.
So you can check out
custom elements everywhere
to see the latest progress
on first-class framework
support for web components.
And web components
usage in the wild
is actually really taking
off, kind of under the radar.
But it's really taking off.
So we just had a fun realization
on the team the other day,
after seeing another team
at another massive company
tweet about one of their web
components-based launches.
Which is, if you go
and if you look up
the top 16 global
brands in the world,
so the 16 most recognizable
companies in the world, nine
of those companies-- over
half of those companies--
have a product that is using
web components in production
and many of which
are using Polymer.
So web components might
not be instant hacker news
the top gold yet.
But the adoption
is very, very real.
In fact, if I were
starting a company that
was trying to make money
on web development,
I would absolutely pick web
components as my technology.
So on the Polymer
Project, we're continually
trying to evolve the Polymer
library, as these web component
standards evolve and reach
different phases of maturity,
to make it as easy as
possible for the standards
to cross the finish
line and, also,
for developers to take advantage
of components and production.
Earlier this year, we held our
third annual Polymer Summit
in Copenhagen, where we heard
from 25 different speakers
about the state of Polymer and
also innovations more generally
in the web component ecosystem.
So we heard from
major companies,
like USA Today and
Electronic Arts,
who are using Polymer to
be able to quickly spin up
new pages and web sites with
a consistent design language
and with minimal extra
engineering effort.
And we also gave
a sneak preview of
the forthcoming next major
version of the Polymer library,
which is Polymer 3.0.
So Polymer has always been
about making it easier
to build web components
and, specifically,
making it easier to
build web components
being as close to the
platform as possible.
And so Polymer 3.0 is
a very small evolution
of the library to come
even closer to realizing
this ultimate goal.
There are two major changes
to Polymer with Polymer 3.0.
The first is we'll be moving
from Bower to NPM, in order
to distribute Polymer
and the elements built
using the Polymer library.
[APPLAUSE]
And the second is
we'll be switching
from HTML imports to
ES Modules in order
to load Polymer and
Polymer-based elements.
So the reasoning behind
these two changes
is fairly straightforward,
as everyone
seems to intuitively get.
Although, major other
browser vendors have agreed
to and shipped custom
elements in Shadow DOM--
we're already seeing those
supported in the wild--
we haven't been able to reach
consensus around HTML imports.
And today's
close-to-the-platform way
to load code is via ES Modules.
So on the Polymer Project, we're
going to follow our own motto.
We're going to use
the platform and move
to using ES Modules in
order to load Polymer.
And there are some really,
really big exciting advantages
with this switch.
For one, Polymer will
become much more compatible
with the workflow and
tools and other libraries
that JavaScript developers
are already familiar with.
And Polymer elements
and applications
will also be able to run
without any polyfills
at all on Chrome,
Opera, and Safari.
And when Edge and Firefox ship
custom elements in Shadow DOM,
Polymer will run completely
polyfill-free on those browsers
as well.
And on the Polymer
Project, we also really,
really care about making these
transitions between versions
of the library as
easy as possible.
As you've seen, we have some
really, really big users
inside Google and
outside Google who
have thousands of
elements that can't
do a major one-off transition.
And so we're working on building
an auto upgrader tool that
will mechanically and
automatically upgrade
your 2.0 elements--
and even back
to 1.0 hybrid mode, if
you're familiar with that--
to Polymer 3.0.
So it will be an
automatic transition.
It even upgrades
your tests for you.
So you can learn much more about
Polymer 3.0 by checking out
polymer-project.org and
the blog for updates.
We're still working on a bunch
of tooling and support for 3.0.
And we expect to have a
stable release sometime early
next year.
So keep an eye out for that.
So 3.0 Polymer is
really the culmination
of what we've been trying to
do on the Polymer Project--
make it possible to
build platform native
components as close to
the web platform itself.
And we really think that the
web component technologies
are a transformative change
to the way that the web
platform works.
But components are really
only half the ballgame.
It should also be trivially
easy to take these components
and assemble full-fledged
end-to-end applications.
And when it comes to
today's ergonomics
of assembling web
components into apps,
we tend to agree with Sam here.
We think there is
a lot left to do,
in terms of improving
the developer
experience of building
end-to-end applications,
taking advantage
of web components.
And we also think they're
some really interesting
opportunities to take some other
cutting-edge changes to the web
platform, along
with web components,
marry them together, and
be able to build really
blazing fast end-to-end
apps that you
can deliver to users on
mobile seamlessly and quickly.
So I don't have a product,
per se, to announce today.
But I do want to take the
second half of this talk
to throw out some
of the key ideas
that we've been kicking around
on the Developer Experience
team for the shape of what an
app-building solution might
look like.
So Kevin Schaaf, an engineer
on the Polymer team,
went into detail of many
of these ideas in his talk
at the recent Polymer Summit.
So I encourage you
to check that out
if you're looking to
dive an a little more.
So really, there are
four main problems
that we are thinking
about when it
comes to going
from web components
to entire applications.
The first is how to
structure your application
for maximum performance, how to
factor your UI appropriately,
how to manage state
within your app,
and then how to actually serve
your application in production.
So we'll dive into
each of these and see
how we're thinking about
marrying a bunch of the web
platform features
into doing each
of these steps of building an
application really effectively.
So first, structuring
for performance--
the number one way to make sure
that your application misses
its performance
targets is to start
thinking about performance
after you've already
finished building your app.
And I think we've hammered
this concept home quite a bit
at this Chrome Dev Summit.
So there's one
overarching principle
when it comes to structuring
your performance, which we
find consistently invaluable.
Which is to minimize overhead.
Every single byte
of your web app,
as you've heard
again and again, has
to go through this epic journey
before it finally gets rendered
on a user's mobile device.
Every byte runs into
so many opportunities
for bottlenecks-- flaky
networks, slow devices.
The only guaranteed way to
achieve good performance
on mobile is to do less.
And unfortunately,
what we see again
and again is an attempt
to improve performance
by doing more.
So a lot of the
front-end world today
is enamored by the concept
of server-side rendering,
as a means specifically to good
performance, where we send down
server-rendered static HTML
to get the UI on screen,
while the user is waiting for
the rest of the app bundle
to download.
But unless your application
is mostly just static,
kind of passive content, what
the user actually wants to do
is interact with your app.
They want to select
a departure date
or sign up for a newsletter
or bookmark a house.
And server-side
rendering doesn't really
help with any of
this interactivity.
It just gives them
something to look
at while the rest
of their code loads,
so they can actually
do what they
came to your app or
your website to do.
So if you still have to send
this large bundle of JavaScript
down to transform that initial
rendering into something
that's interactive, the user is
still going to be frustrated.
And if you don't
believe me, here
are a couple of real-life
examples of how popular
server-side rendered
applications perform
on relatively slow 3G networks.
And as you can see, server-side
render the initial view really,
really quickly.
But the problem is,
on a slow network,
it can take a really long time
for the JavaScript to load.
And that leaves the user
looking at a screen that
looks like they can
interact with it,
but this can be an incredibly
frustrating experience.
So I want to make the
point that this is not
to say that server-side
rendering is wrong.
Absolutely not, it can certainly
improve the user experience
by getting pixels
on screen quickly.
Definitely a good thing to do.
Rather, it just says that there
are no shortcuts to delivering
a good user experience.
We need to focus on the right
metrics from the beginning.
And so we think, on the
Developer Experience team
here, that for a lot of apps
the right metrics should not
be first paint but, rather,
time-to-interactive.
And the best way to ensure
a good time-to-interactive
is this-- don't make the
user wait on anything
that they haven't asked for.
So what this means is,
only send exactly the code
that a particular
route requires in
as few round trips
as possible, sending
as little duplicate
information as possible.
And this sounds easy enough.
It sounds fairly intuitive.
But in practice,
this has historically
been very difficult,
given the bias
of existing front-end tooling.
So this is why we've developed
and have spent so much time
evangelizing the
PRPL pattern, which
gives a straightforward pattern
for factoring an application
for optimal delivery.
So with PRPL, start
by factoring code
around de-coupled
routes that fit together
into an interactive experience.
Use server logic to push down
only the components or the data
that a given route needs,
and eliminate round trips.
We render and make that
initial route interactive
as quickly as possible.
We use Service Worker to
pre-cache the next parts
of the app in the background.
And then we lazily import
this pre-cached code
that's needed for
subsequent routes
from the Service Worker cache.
So we summarize this
pattern as PRPL--
Push, Render,
Pre-cache, Lazy import.
So PRPL gives us a
really nice pattern
to ensure we're giving
the user exactly what they
need for a particular
route and no more.
But to ensure we're delivering
the ultimate best user
experience we can, we want
to measure iteratively
as we develop.
And so we recommend using
Web Page Test for this.
And Web Page Test recently
introduced a new Easy mode
that you can go to
that's preconfigured
for testing on mobile
devices and on 3G networks.
So make sure that you've
enabled Lighthouse
on webpagetest.org/easy.
And then just enter the
URL that you want to test.
And click Start Test.
And once testing
is finished, you
can click this Lighthouse
Score button here.
And then under
Performance, you can see
this timed interactive number.
And this is the number
that we want to optimize.
So there is a lot
of different advice
out there for what to target
for time-to-interactive.
And what we like to
say on the Chrome team,
and I think you've heard in a
few talks at this conference,
we talk about
aiming for 5 seconds
for time-to-interactive.
We think this is generally
a really strong target
for a good solid
user experience.
We think, though, that the
absolute highest quality sites
can do even better, down to
3.5 seconds to interactive.
And this is the target that
we'd shoot for on the products
that we're building on the
Developer Experience team,
specifically so we can leave
as much headroom as possible
for you, the developer,
to build more complex apps
and still get a really, really
fast time-to-interactive.
So in these settings,
a first byte
from a good edge-caching
server, after SSL negotiation,
will be around 2 seconds.
So this leaves us with
about a second and a half
to get the routes payload
downloaded, rendered, and ready
for the user to interact with.
And we found that
this translates
to roughly 50 kilobytes
of code and data
that you can send for the
initial critical section
of your route.
So now, Polymer 2.0 starts
at around 12 KG zips,
leaving you with
roughly 40K of budget
for the critical components
that you need for each route.
And we found that the best way
to get these recommendations
across and the best way for us
to internalize them as a team
is to give them a name.
And so we're calling
this one PRPL-50.
So for building fast
apps on the modern web,
you get a really
big head start when
relying on web components
for your component model.
Because you don't have to
download any extra code
to provide that component model.
It's already baked in
there with the browser.
We also think that any
modern app-building framework
should do everything possible
to help developers stay
underneath this PRPL-50 rule
for any particular route
in their application.
So that's how we are
thinking about structuring
for performance by minimizing
the amount of code that has
to run for any particular view.
The next step in building an
app will be to factor your UI
and actually assemble
these different views
into a full-fledged application.
So again, web components
really, really help us here.
So we'll want to leverage
reusable components
wherever possible.
Because the best line
of code is the one
that you didn't have to write.
So just like NPM is the
go-to source for JavaScript
libraries, web components
is your go-to source
for reusable web components.
So for a lot of
our app UI, we can
stand on the shoulders of
giants in the community
and stop reinventing
the wheel, and just
use web components that others
have already created for us.
Now, we talk a lot, when we're
talking about web components,
about leaf node
elements, in terms
of the sorts of UI widgets,
like buttons and drop-downs
and sliders, that the
user directly interacts
with and are, sort of, the
lowest nodes on your tree.
But we also think
that web components
can be hugely valuable
for app-level structure
and organization as well.
Using the standard web component
model for app components
in your app can have a
lot of different benefits.
So we can achieve
a smaller payload
and get to that PRPL-50 number
by using built-in browser
features, rather than
having to download
our own extra code on top.
We can get strong
encapsulation for free,
which is hugely useful when
scaling up to a large team,
all working on the
same code base.
We get great built-in
developer tool
support for web components,
via Chrome's dev tools.
And most importantly, we
get the full flexibility,
in terms of being able to reuse
our structural components.
So as long as you're using
custom elements and properties
and events as your
component interface,
and as long as you're using
Shadow DOM to encapsulate
the rendering of the
component, how a component does
it's rendering is totally
just an implementation detail.
So with a web component, you
can extend from whatever web
component-based class
you like, without losing
interoperability.
How the component actually works
is an implementation detail.
Its dependencies are an
implementation detail.
So this inverts the
traditional model
that we're used to when
building web applications.
We can build, for example,
an entire application out
of Polymer elements.
But that's just one choice.
Down the line, you could
switch some of your components
over to using a much
simpler element base
class, for example, than
what Polymer provides.
And those can work side-by-side
in your application
with Polymer elements,
one at a time.
We can try out using
SkateJS in our application,
without changing any
other part of our app.
And someone is
bound, in the future,
to make an even better
web component base class.
And we can introduce
improvements
to our app incrementally,
without throwing
the whole thing away each time.
So think about that.
If you wanted to change an app
from one framework to another,
there's no incremental path
to make a change like that.
Yet, this is entirely
possible when
we're using a standard
component model.
So this is one of the very real
benefits of web components,
even for app-level views.
We can dramatically lower
switching costs for us
without sacrificing our
ability to innovate and change
incrementally over time.
We don't lock ourselves
in at all when we're
assembling our application.
So now that we've
built our UI, we
need to bring our application
to life by loading it with data
and dealing with user
interactions that
will change that data.
So application state
management is, perhaps,
an area of web development
where the platform has the least
to say.
And so we get a lot of questions
about how we do managing
state on the Polymer Project.
So two years ago, at our
first Polymer Summit,
Kevin gave a talk called
"Thinking in Polymer"
that put forth the concept
of the mediator pattern
for how we think about
coordinating state
changes between web components.
So in short, a mediator
in the mediator pattern
owns a scope of other
components and is
responsible for propagating
data to those components,
listening to events
from those components,
mutating state and
propagating changes
to that state back down to
components in its scope,
but also up, via
events, to any owner
of this particular component.
And the mediator
pattern is really
useful for creating reusable
standalone elements that
can handle their own complex
state changes internally
but also communicate those
state changes externally
to anyone that
might be interested.
And this standalone
state management
ensures that reusable
web components
are easily portable between
any application context
and work just like
any other domino
that you might be used to.
So we often will build
full applications
by composing this
simple pattern together
over and over and over and over.
And eventually, you have
a top-level mediator,
which is controlling the whole
nested tree of components.
And you have an application.
However, the community
has also shown
that there can be
lots of benefits
to having less granular and
even global mediators of state.
So particularly, as
components become
more app-specific and as
generic components come together
to hold application
logic, having
one mediator for
all application data
can make your app much
easier to reason about.
And it also opens
up a whole suite
of nice developer workflows
that we'll get to in a minute.
So there are lots of these
global mediator patterns.
And those mediator
patterns, like Flux,
formalize this concept
of one central place
to put application state that's
passed down to components
and one place to dispatch
events that cause application
data to be mutated
and passed back down.
So we can really just think
about this global mediator
of state as a generalized
global mediator pattern,
like I described before,
for your entire application.
So now, there are
lots of choices
out there to implement
this global mediator
pattern that work just
fine with custom elements,
too many to go into.
But we purposefully made
Polymer very low-level and very
flexible, precisely
so that you could
have many different options for
how you want to manage state
in your application.
But a lot of times, developers
will say, just show me one way
to manage state that works.
And if you're that person,
we do think that Redux
is a really good choice.
And a lot of people have had
a lot of success with it.
So the Redux library
is very simple,
with very little magic and a
relatively small footprint.
It follows a very
easy-to-understand mediator
pattern.
And as complexity of
your application grows,
there's a large ecosystem
of add-ons to Redux
that can help your application
scale and complexity.
So these usually come
in the form of ways
to abstract and streamline
async flows in your application
patterns.
It is also, fortunately,
very, very simple
to integrate Redux
with web components.
So let's go back to our
global mediator diagram
and make it specific to Redux.
So the Redux term for the global
mediator that manages state
is called the Store.
Elements then
subscribe to state that
is passed down into an
element's properties
via a subscribed callback.
And in place of
events, the elements
dispatch what are called
Actions to the Store.
And we write functions
called Reducers
that then return a new
state object with changes
to the data that
have happened based
on actions that have occurred.
So there's a bit of
a trade-off involved,
going from localized state
management to global state
management.
But one of the key benefits
is that it opens up
a really nice set of
developer workflows,
like the dev tools
that ship with Redux.
Since actions that change
state are centralized,
it's trivial to log every action
that happens in an application
and to see the entirety of
application state all at once.
So there are lots
of ways to connect
custom elements to Redux.
And it's fairly simple to do.
But one approach
that we really like
is to build your views
as generic elements that
accept the properties
and fire changes
based on user interactions,
just like any other reusable web
component that you might
create, and then subclass
that generic element
to create a more
application-specific
version of the element that
is connected to the Store.
By subscribing to the Store
and setting properties
into elements and then listening
for DOM events and dispatching
Redux actions as a result.
So a key pro tip, also,
to point out-- if you're looking
into a global state management
technique, most of them don't
come out-of-the-box with a way
to separate all your different
state management code.
They lead you towards one big
blob of global state management
logic.
And this is in opposition
to our PRPL concept,
only loading the code that you
need for a particular route.
Now, this is totally possible
to achieve with Redux.
But it definitely is something
that we want to pay attention
to in our implementation.
So I'll give a quick
example for code
for how we'd make a
Redux-connected custom element.
So let's say we're building
a browsing-style explore view
in our application.
And we've built our Explore
page component, which
takes properties and events.
And then we're going to make a
subclass of this Explore page
that will be specific to
our application and hook
into our global Redux store.
So in the Constructor,
we can call
Redux' subscribe method
and dereferent state out
of the Store and then set it
into our elements property
interface.
And here, we are using Polymer
2.0's set properties API,
which provides a
really efficient way
to do a batch of multiple
properties into an element.
And next, we can
add event listeners
for any custom DOM
events that will
be fired from that element.
And then we can call
Redux' dispatch method
to notify the Store of
actions that have taken place.
And we'll do this
by using functions
that create an action objects.
So Redux calls these
Action Creators.
And we'll do that
for any of the events
that our component
will admit that need
to update global state.
And remember, this
Explore page JS
is lazy-loaded, only with
the slash Explore route,
for example.
So rather than loading all
of the state management code
with the app, we want to
load it and install it
alongside only the
components that need it.
So you can add a little
code to enhance Redux
with the ability to
incrementally build up
global logic in the Store.
So that logic that manages
the part of the state
that a component depends on,
can be lazily loaded along
with the component and
then added into the store.
Likewise, any
non-trivial logic needed
should also be separated
out and loaded along
with only the components that
need them to ensure that you're
achieving optimal delivery.
So we're going to continue
experimenting with patterns
for state management and how we
think they can fit into a web
component-based application.
And I also want to give a
shout-out to the Polymer Redux
Library which is a community
library that approaches
binding Polymer components
to Redux in a much more
declarative fashion.
So like I said before,
there's a lot of innovation
happening in this space.
And Redux is really
just one choice.
And virtually any of
these global patterns
can work totally well with web
components really seamlessly.
So finally, once development
of our app is complete
and we're ready to
deliver it to our users,
we need to host it and
serve it to clients.
And although a lot can be
accomplished by statically
serving our client
application, there
are a few minimal
features that we
feel are required to be
implemented on the server
to really achieve this
optimal user experience.
So we want to be
all to serve our app
shell for all rich
URLs, in order
to enable client-side routing.
We want to serve either
route-based dependencies using
HTTP Push or route-based bundles
for non-Push capable browsers.
We want to serve different
builds, optimized to target
different user agents.
And we want to serve
static content also,
for search engine crawlers that
might not execute JavaScript.
So we've been
doing a lot of work
on a reference server that does
all of these things, called
PRPL Server Node,
which is designed
to work hand-in-hand with build
output from the Polymer CLI.
So a lot of the things you heard
Sam talk about a little earlier
today, we're trying to
make much easier to achieve
with PRPL Server Node.
So this is a node-based
server that's
set up for client-side routing.
And it also has
built-in presets,
in order to serve
optimal code, depending
on the browser capabilities
of a particular client.
So it has presets that know
which browsers have ES6 support
and can take advantage of
custom element subclassing
and which need
ES5-compiled code.
It can also differentiate
between those
that take advantage
of HTTP/2 Push support
to serve granular components
for better efficiency
and caching and those that
will need bundled code.
And it will also serve
the optimal set of code
for a client, given what the
client can actually execute.
So last, it will also
leverage a new project
that we're working on called
Rendertron, for those bots
and crawlers that don't execute
JavaScript and social network
crawlers, like
Facebook and Twitter,
in order to serve a
fully-rendered HTML for optimal
SEO and social
snippet generation.
So stay tuned for more on that.
And you can check out more about
the PRPL Server Node beta here
on GitHub.
So that's it.
Those are the key
aspects that we
see in taking advantage
of the modern web platform
to ship fast and
high-quality apps
and also reduce your pain
during web development.
So you can really
start to see how
the interplay of these
different web platform
features-- web components and
Service Worker and HTTP/2--
that you achieve a
result that's greater
than just the sum of the parts.
So we're going to keep
exploring, on the Developer
Experience team, ways to
package up these concepts
and make them easier
for you and your teams
to take direct advantage of.
But in the meantime,
I encourage you
to take a look at some of the
latest with web components
and start applying some of
these concepts and ideas
to your current
web applications.
So thank you so much.
And stay tuned for more
coming from Polymer.
[MUSIC PLAYING]
