My name's Taylor Savage.
I'm the product manager of the
Polymer team here at Google,
and I'm going to talk a
little bit about Polymer.
So it's become a
bit of a tradition
now at Chrome Dev Summit to give
a Polymer state of the union.
So this is that talk.
So Polymer is, for
those who don't know,
the web developer library that
we build on the Chrome open web
platform team here at Google.
It's a lightweight wrapper
on top of the web component's
APIs-- the library
is-- and we also
build a whole
bunch of components
on top of that library.
So I'll talk a little
bit about where
Polymer has come since
one year ago a Chrome Dev
Summit last year, the general
state of Web Components,
which are these really
fundamental APIs that Polymer
leverages heavily, and
then where we're headed.
Where the Polymer library,
where the broader Polymer
project overall is headed
in the near future.
So let's roll back the
clock a little bit.
One year ago, this very
conference-- Chrome Dev
Summit-- Matt McNulty, who is
the Polymer engineering lead,
got up and announced kind
of a major, new evolution
in the Polymer library.
So up until that point,
Polymer was very much kind
of an experimental library.
It was all about experimenting
with these new Web Components
APIs, seeing what worked,
seeing what didn't work,
trying to build a developer
wrapper around Web Components
to make sure that it was
something that both worked
in the browser, and
also was something
that developers could use,
and that were actually
useful for building
applications.
And so what Matt announced a
year ago at Chrome Dev Summit
was Polymer 0.8.
And Polymer 0.8 was a shift away
from this experimental mode,
because we had realized
that we were actually
on to something here.
Web Components were pretty
stable and solid and great.
And this library was something
that could actually be useful.
So we shifted away
from experimenting
and towards building something
that you could actually
use in production.
So the goal was to kind
of balance and make
trade offs in keeping some
of the great ergonomics,
and the great
productivity gains that we
had achieved with
the experimental 0.5
version of Polymer,
but also make
it fast enough and
radically less complex,
to be something that you could
actually ship in production.
So 0.8 released around
this time a year ago,
a major step forward.
It still needed
some time to bake.
And at Google I/O this past
May, we announced Polymer 1.0.
And this was the big
production-ready release
of the Polymer library.
So Polymer 1.0 was essentially
a ground-up rewrite of Polymer.
Again, trying to
maintain the same great
ergonomics that Polymer
had evolved over time but,
under the hood,
kind of radically
redesigning and simplifying
everything to make it fast.
So we redesigned the data
binding system, rebuilt it
from the ground up to
be much more direct,
introduced a whole
new styling system
to be able to pierce
through shadow roots
when you're building
these components based
on Web Components that
was much more idiomatic
and the right trade-off in
terms of developer handles,
but also encapsulation.
And we also included a
lightweight shadow DOM
shim called shady DOM,
rather than relying
on the full heavyweight-- but
a little over heavyweight--
shadow DOM poly film.
So all of these things together
made for a much faster,
production-ready library.
And at that time, a number
of products at Google
launched with
using Polymer using
this library in production.
So how much faster was
Polymer 1.0 from 0.5?
Quite a bit.
It was three times
faster on Chrome,
four times faster on Safari.
It was also smaller.
So it was also 36%
smaller than 0.5.
So this was a major step
forward for the Polymer library.
It was also a major step
forward for everything
that we build on top
of the Polymer library.
So the Polymer team, in addition
to working on this library,
builds sets of components.
And traditionally, we had just
had two kind of component sets.
With Polymer 1.0,
we dramatically
expanded the scope of that to
include five element product
lines, as we call them.
The Iron Elements--
and these are
elements that are built on
top of the Polymer library
to make it easier for
developers to build applications
on the web leveraging
Web Components.
So Iron Elements were
kind of the basic building
blocks for what you might
need to build an application.
The Paper Elements were the
reference implementation
for material design.
So these are all the
components-- the buttons,
and the ripples,
and the drop downs,
and the menus-- that you use
to implement Google's material
design language on
a web application.
And I want to take
the opportunity
to make totally clear, Polymer
is a Web Components library.
But building with Polymer we've
created these Paper Elements,
which in these represent
material design.
So Polymer is not
material design.
Polymer is a web
developer library.
But we do ship these Paper
Elements to help developers
as one of many of
our element product
lines for material design.
We also ship the Gold Elements.
So these were a
small set of elements
for building good e-commerce
check out flows on the web.
So things like auto
completing credit card fields
with the right mark
up under the hood,
auto validating zip
codes, and locations,
and phone number fields
to make it really easy
to build a great checkout form,
or a great e-commerce type
form.
We also ship the
Google Web Components.
So these are wrappers
around some of the APIs
that various Google
projects provide,
things like Google Maps, and
Google Drive, and YouTube.
And yeah, we take the
imperative JavaScript APIs
that these products provide
and wrap them in a component
so that you can use these
declaratively on your page,
just like any other element.
So this includes the
Google Maps element,
for example, which you
can just put on your page,
and it renders a Google map.
And finally, we announced
the Platinum Elements.
So these were wrappers
around Service Worker.
And you've heard a lot about
Service Worker today and all
the amazing things
that it can do.
So the Platinum
Elements are wrappers
around a lot of
these service worker
features to make it
easier to leverage
those in your application.
Again, declaratively,
using the typical element
syntax you're used to.
These let you develop
a progressive web app
using declarative components.
So really exciting stuff with
the Polymer 1.0 announcement.
Huge step forward
for the library.
Huge step forward for the
element product lines.
But what about Web Components?
So Polymer 1.0 was
production ready.
A number of Google
products and products
that other companies
are building
are using it in production.
But it could be even awesomer.
It could be faster.
And with that true
encapsulation,
to really get true
encapsulation and true usability
of these components, you need
Web Components shipped broadly
across browsers to really
realize the potential
that Web Components have.
So where are we
with Web Components?
And I'm very happy to say--
if you take nothing away
from this talk, please
take this away--
web components are happening.
Incredibly exciting.
They've been in the
works for a long time.
But in just the last
six months, we've
seen incredible movement across
all the different browser
vendors towards
shipping web components.
So a little bit of a highlight
reel here of what we've seen.
This was a blog post
from the Edge team.
"We are happy to announce that
we are starting development
to add HTML Template element
support to Microsoft Edge
today!
This is just the beginning of
our Web Components journey.
Following template support,
and after completing
the DOM rewrite, the next goal
is to implement Shadow DOM."
And I'm very happy to say that
Edge actually shipped Template
just a week ago.
So they are already
shipping Web Components.
Super exciting, great progress
being made on the Edge team.
They're doing some great work.
Firefox Mozilla
had this blog post
not that long ago. "Web
Components have been planning
for over three years, but we're
optimistic the end is near.
All major browser vendors
are on board, enthusiastic,
and investing significant time
to help resolve the remaining
issues.
Let's get ready to
componentize the web."
And then finally, WebKit.
So WebKit just
recently announced
they are shipping the new
shadow DOM slot-based V1
API in WebKit Nightly.
So you can actually play
with this today in Safari.
It's out there in the
Nightly build of this.
Incredibly exciting work
that the WebKit team has done
with the shadow DOM V1 API.
On the Polymer
team, we will soon
be shipping an
experimental version
of this V1 slot-based API
in our shady DOM polyfill.
So you can start playing
with it and getting
the feel of the ergonomics
before the shadow DOM V1
slot-based rolls out broadly.
So we want to give lots
of time to prepare.
But incredibly
exciting work being
done across all these
different browser vendors.
Web Components
are actually here.
It's going to be not
too long, and we'll
be able to have polyfills be
the exception and not the norm.
So incredibly excited
by all this progress.
So Web Components
have come a long way.
Polymer has come a long way.
We've seen really great
adoption of the Polymer library
just since the 1.0 release
three or four months ago.
So Polymer in the wild--
over a million web pages
are now using Polymer
on the current web.
We had Polytechnics
all around the world
run by our incredible
Polytechnic organizers.
These are events to
learn all about Polymer
and build with Polymer.
Literally, every single
continent except Antarctica
that we had a Polytechnic event
on, so incredibly exciting.
And we've also seen
some major companies
really adopting and leveraging
Polymer Web Components
in super interesting ways.
So I want to talk a little
about a few specific limitations
that I think reflect the
diversity of application
that you can have with
Polymer Web Components.
So the first I want
talk about is GE.
So GE's Predix platform,
it's a Cloud platform
that you can kind of
think of as the operating
system for the Industrial
Internet of Things.
So imagine that you have a
wind farm of wind turbines,
and they're all generating data.
And all that data is
getting piped back
in to the Predix
engine on the Cloud,
and you need a way
to visualize all
of this data that's coming in.
And so what GE
has built is a set
of components using Polymer to
be able to easily put together
dashboards to be able to
understand and visualize
the data that's coming in.
So, awesome application,
so a whole bunch
of different components
that can be pieced together
to create a variety of different
interfaces on these dashboards.
And you get all this information
about your Industrial Internet
of Things just at a glance.
So a really perfect use
case for these components
and a great application of
it, an industrial level scale
that's deploying Polymer
The second company that I
talk about is Net-A-Porter.
They are a major
e-commerce company.
And they've done some
awesome work using
Polymer on their product pages.
So a company like
Net-A-Porter, where
you have a whole bunch
of different products
and a whole bunch of
different product pages,
and all the product pages are
going to be slightly different.
Some are going to
have color swatches.
Some are going to have
to have size drop downs.
So are going to have
additional information.
Some are going to have
Also Goes With sections.
And they built each of
these as a component,
as a Polymer component.
And so they can just put
together these product pages
out of these components.
And all of these components
are also naturally responsive.
So this same site
works great on desktop.
It works great on mobile.
And it's a really great
deployment of Polymer
at scale, and to really leverage
building and sharing and using
these components across
all the different product
pages on the site.
And then finally, Suumo.
So Suumo we've talked
about a little bit,
a Japanese real
estate company that's
really on the cutting edge
in terms of the web platform.
They build some awesome stuff.
They are just releasing today
a mortgage interest simulator
that's built in Polymer.
So this is just a great example
of a really immersive app
that feels great,
that works on the web.
You can put in all the different
variables around your mortgage
and get what your
payments would look like.
So it's just a great
material design
app that uses all the
Polymer components
and has a great interface,
and it works great on mobile.
So really awesome work there.
So kind of the broad spectrum,
from shared components,
to build dashboards,
to actually deployments
on an e-commerce site, to
just building a really great
end-to-end app with Polymer.
We're excited to see all
of this uptake externally
in the ecosystem.
We're also really excited to
see uptake internally here
at Google.
So here Google,
over 320 projects
are using Polymer internally.
And that number is just
growing every single day.
We've seen some major
Google products launch
with Polymer 1.0 just
in the last four months
that it's been out,
that are leveraging it
at scale in production.
These include products
like YouTube Gaming.
So this was a major
launch not that long ago.
This is built
Polymer end-to-end.
Every single component that
you can see on that screen
is a Polymer
component, just about.
And they use this to
structure their application
and get these really
nice effects and really
nice transitions.
Similarly, Google Play Music.
So this uses a lot
of the Paper Elements
to get that nice material
design application feel.
You can see the ripples
and the drawer panels.
And this uses Polymer to
structure the application
as well.
Google Patents-- a really
snappy application of Polymer--
just to be able to search
patents and read information
about each patent.
Of course, the
Google I/O website,
which was kind of
a progressive web
app before that term came about.
It was at the Google I/O
conference this last year,
built in Polymer.
And this Chrome Dev Summit
website for the coverage you're
at right now-- also
built in Polymer.
And there are so many
major Google products
that are also using Polymer that
haven't launched just quite yet
that I can't talk about today.
But we're incredibly excited
for those to launch as well.
We had the first ever Polymer
developer summit in Amsterdam.
That video of the building
with the big Polymer
logo on the front
was not Photoshopped.
That was real.
It's a major building on
the river in Amsterdam.
Just an incredible
venue, an awesome event.
We had 800 engineers
there from all
over the world who were
interested in Polymer
and learning about Polymer.
Day to day, a whole full day
of talks, a night of code labs.
All of those talks we recorded,
and they're all up on YouTube.
It's a great resource.
We kind of go end-to-end
from start to finish,
how you might build a component,
how you might assemble
components into an application.
So if you're interested to
learn more about Polymer
and how you can use Polymer
and build applications
with Polymer, the videos
from the Polymer Summit
are a really great resource.
So of course, the
core Polymer team
did not just give up and
declare victory at 1.0
and leave and quit.
No, very far from that.
So we've been working
really, really
hard to continually
improve the library
and all the elements
that we're building.
And kind of the two
pillars, or two core values
that we think about when
we're building Polymer
and we're building components--
everything that we're
building on the team-- are
ergonomics and performance.
So ergonomics, how
easy is it to build
a component using Polymer?
How easy is it to
build a good component
that you can compose
with other components,
that you can compose into an
application using Polymer?
And then performance,
how fast can you
build something with Polymer?
How fast is your
and resulting app
when you've built it in an
idiomatic way with Polymer?
And so these things seem like
they're a little bit of a trade
off, and they certainly are.
We're always balancing.
We want to improve both
ergonomics and performance.
We're thinking about new
things we want to build,
and ways to improve the
library and components.
On the ergonomic side,
since Polymer 1.0,
we've shipped a
number of new features
with the library, some of these
very major features, things
like compound binding, things
like distributed children
changes for an
element, ways to share
style sheets between components,
a whole set of features
to make it easier to build
components using Polymer.
But we have this
mantra on the team,
which is that "every
feature has a cost."
Whenever you add
a feature, you're
adding some level of abstraction
away from the platform,
just naturally.
And so there's
always going to be
a cost to adding that feature.
So whenever we're thinking about
implementing a new feature,
adding it to the library,
we're thinking, what cost
are we transferring
on to our developers
when we add this feature?
So this is the
constant trade off.
So I'm really proud to say,
even with all those features
that we added since 1.0, 1.2--
the most recent release-- is
actually 20% faster
than 1.0 was.
So this is great.
And this is actually a
conservative estimate.
Depending on your use case,
it can be even faster.
We've also worked hard to
improve all the elements
that we build with Polymer.
We've made all of our elements
faster and slimmer and more
robust.
We've also worked hard to
improve the accessibility
across all the elements.
That's really, really
important to us.
So we want to be leading
from the front in terms
of both Web Component
performance and Web Component
accessibility.
And so the entire
engineering team
is scaled up in terms of making
accessible Web Components.
So we've kind of
achieved, at least
at this release, a nice having
our cake and eating it too.
We've improved performance by
adding features to the library.
We've improved ergonomics.
And we've also
improved performance.
And I think that the way we've
been able to achieve that
is because we're
building the Polymer
library up from the platform.
We're relying on native platform
features with Web Components
and building up from
there, just as sugaring.
So we're able to make really
informed trade offs in terms
of just small sugaring layers
away from the platform,
and very targeted improve and
add features while maintaining
really good performance.
I think that's a
powerful direction.
So I want to take a little
time to think about that,
about the web platform.
Polymer's come really far.
Web Components have
come really far.
The web platform
has come really far.
I think that's the
theme that you're
hearing again and again today.
And the platform
has come so far,
we now have this concept
of progressive web apps.
With Service Worker, you're
able to build applications
that are resilient to
flaky networks, that
can send you push notifications,
that can launch from the home
screen without Chrome around it.
It's just an immersive
application that you've built.
This is an amazing
platform that we have.
And features like Service Worker
and WebApp Manifest really,
truly make the web finally
a first class application
platform-- really, truly.
For 90%, 99% of use
cases out there,
you can get everything
you need building
on the web with Service
Worker, an WebApp
Manifest and similar new
features in the web platform.
And these are largely
developer facing features.
I mean, sorry, these are largely
consumer facing features,
features your users will see.
Your user will see an
app working offline.
That's new.
Your user will see a web
application sending you
a push notification.
These are very, truly
user facing features,
and that makes it this first
class application platform.
And it's changing
the way that we
can think about building
applications on the web.
Things we've never been able
to do before as web developers,
could only dream of,
we're now finally
able to actually do in
our web applications.
That's really powerful.
But the web has not only
become in just recent years,
and months, even, a first
class application platform.
I think with Web
Components being
a developer facing
feature-- a feature that
makes our lives easier
as developers in terms
of structuring our apps, giving
us fundamentally new primitives
in the web platform
for building components
that are isolated and
reusable-- the web
has really become a first
class developer platform.
And this is huge.
For so long, the history
of web development
kind of follows this arc of
doing lots of crazy things
to try to avoid
the web platform,
to try to smooth
over its rough cases.
But I think we're at a really
significant turning point now.
I think the web can be a
really elegant platform.
With features like
Web Components
and features like
Service Worker,
we're now able to
build applications
on the web platform in
ways that the platform
intended us to build them.
And that's really powerful.
And by sticking to the platform
now, we can build applications,
and the platform
can help us out.
The platform can
improve these features
and improve performance.
And we can gain from those
features and performance
improvements in the
platform, as long
as we're building to the way
that the platform intended.
And so I think Web
Components are just
the seed that's going to really
spread across all of our norms
that we've taken for
granted as web developers
in terms of how we
structure applications,
how we build applications
on the web platform,
just in the same way that
Service Worker is going
to change the way we think
about what our applications
can do for our users.
So what's next?
Polymer has come
a really long way,
but it's constantly growing.
There are over 20 people working
directly on the Polymer project
currently, and that number
seems to be growing every week.
So where do we see
this library going?
Right now, the Polymer library,
it very much is a scalpel.
So it's a very powerful tool
when used in the right hands.
But it's certainly still
easy to make mistakes.
And we want it to be easy
just to build applications
generally.
So Polymer is great for
building web components,
but we think it should be
easy to use components.
It should be easy
to build components.
It should be easy
to share components.
It should be easy to
optimize components.
And it should be easy to
assemble entire applications
out of these components.
So there are a few
products that we're
working on right now to
make this all easier,
to make this a reality.
The Polymer library is
just kind of the first seed
to be able to make it
easier to build and share
these components.
So I'll talk about
a few of the things
that we have in
progress right now.
The first is, it can be easy
to make a mistake when you're
building a Polymer element.
So very purposefully, we want
to keep Polymer lean and light.
And so we don't include
a bunch of error checking
code, just to make sure you're
not slipping up as a developer.
We keep that out of the library.
So make sure that you're
shipping only what
you need down to your users.
And so we still want to make
it easy to find these mistakes
before you have to refresh your
page and come across your bug
yourself.
And so we're really happy
to announce Polylint, which
is a project we've been
working on for a little while
now to be able to lint
your Polymer code in line,
in your text editor.
So it is a node module.
It has plugins to common text
editors like Adam and Sublime.
It will find common
mistakes that you
might make when developing
a Polymer component,
things like missing
an HTML import.
It will notify you when
you're missing this,
and it will show you what
component you're using
that you haven't imported.
Things like, if you're
binding to a property
that you haven't declared,
it will notify you of that
as well.
Even more subtle things when
you're building Polymer,
things like binding
the incorrect way
to a native
attribute, like class.
So a whole slew of
different linting errors,
it will find as you develop.
So we think it'll be a
really powerful tool.
We're curious to see
what developers like
and what more things we
can find with this linter.
So please do check it out.
It's in our Polymer
Labs organization.
Everything we keep
in the Polymer Labs--
we like to develop
everything out in the open.
So this has been out in
the open for a while now
inside of Polymer Labs.
That's our kind of breeding
ground for new products
that we want to get feedback on
and learn more about before we
graduate them into the
Polymer organization.
The second new thing I want
to talk about is Polydev.
So Web Components are a really,
really powerful primitive.
But you have to be cautious
about where you apply
that really powerful feature.
With great power comes
great responsibility.
And so Polydev, we want
to give you better insight
into how you're using web
components effectively
in your application to build
a performance application.
So what Polydev is, is
a Chrome plugin that
goes into your Dev Tools pane.
And it shows you
the amount of time
spent in various custom elements
that you're using in your page.
So in this example, this
is the Polymer Summit site.
And it spends a lot
of time, if you're
reloading between
Schedule and Speakers,
in the Schedule
grid and Speakers
grid, as you would expect.
But it's really
great for picking out
particular examples
where you might
be spending more time
than you think creating
certain types of elements.
And so it gives you
a nice visibility
into what you might spend time
optimizing in your application.
So this is in kind
of a vein of products
that we want to help
ship, to help better
measure the performance
of individual components
and better see how the
performance of those components
contributes to the
overall performance
of your application.
And so this is also available
up on the Polymer Labs
organization slash Polydev.
So finally, a lot
of the questions
that we get about building
applications with Polymer
revolve around
these kind of ideas.
How do I structure
my application?
How do I lazy-load
sections of my app?
How do I handle routing?
How do I handle
internationalization?
And for so long in
web development,
the answer to all
these questions
has been user framework.
This is what frameworks
were built for,
to provide this entire
suite of solutions
for this kind of class of
problems around application
structure.
And you really needed
to use a web framework
to be able to easily get
these things spelled out
for you in terms of
building an application.
So for so long, we'd been
building these very towering
constructs in JavaScript
above the platform, really
to give us any sense of coherent
organization of an application.
But this can be kind of brittle.
It can be like building a
Jenga tower on top of Legos.
It requires you to buy in
to an overarching framework,
with all of the things that
cost that might come with that.
You're adding layers
of abstraction
between you and the platform.
In fact, you're not really
building a web application
anymore.
You're building an
application on the platform
that is this other framework.
And then that framework
has to communicate
with the web platform.
So there's this huge layer of
indirection, source of bugs,
source of performance overhead.
And also, if a new
platform comes along--
as they tend to do-- or a
new framework comes along--
as they tend to do--
you tend to have
to throw out all the components
you built for this framework.
The framework components
don't inter-operate
the way Web Components do.
And so Web Components, as a new
kind of fundamental primitive
that is in the web platform,
give us an opportunity
to rethink a lot of
the best practices
that we've taken for
granted for so long,
in terms of building
applications,
in terms of structuring
applications.
So on the Polymer project, we've
been thinking about this a lot.
We've been thinking about
how do Web Components change
the way we can think about how
to structure an application
top to bottom?
They give us these really
powerful new primitives.
How can we apply them to
problems that you usually
solve with a framework?
So how might you solve
a lot of these problems?
How might you solve routing?
How might you solve
internationalization?
How might you solve application
structure using components
that you can swap in and swap
out when a new one comes along,
that you can only pay as you
go, only pay for the features
that you're actually
using in your application?
So we talked about the Carbon
Elements project a little bit
at the Polymer Summit.
It's still a work in
progress, but this
is our solution--
it's what we're
naming our solution--
for structuring top
to bottom applications
using components
and leveraging components.
And we want these to be our
goal with the Carbon Elements.
They should be as close to
the platform as possible.
They should be,
again, a thin sugaring
layer to be able to give
you this coherent structure
without making you buy
in to entire framework,
without making you buy in to
all this overhead in JavaScript.
And we want them to leverage
the best of the platform.
We want them to be the
best, most elegant pieces
that the web platform has.
We want them to really
use those to their fullest
so that it's easy to build these
things with Carbon Elements.
But we also want you to be able
to swap out a different element
to solve a different problem.
If you want to use
a different router,
we want that to be easy.
And we don't want
to lock you in.
We want these components
to really be plug and play.
And so these are still very
much a work in progress.
Obviously, building a
whole set of components,
these are a big, wide
swath of problems to solve,
which are very challenging
problems to solve.
But I'm really happy to
announce our first piece of this
that we're opening
up today, which
are the App Layout Elements.
So the App Layout Elements
try to solve the problem of,
how do I structure the
layout of my application?
How do I get this
responsive layout?
And so we've had a
few of these types
of components in previous
element sets that we've had.
Paper Elements had paper
header panel, drawer panel.
Those were very much targeted
toward material design type
layouts.
The App Layout
Elements are meant
to be much more
general solutions
for structuring application.
So these are things
like responsive drawer
panel, a scrolling header panel
that you can compose together.
But we want them to
be way more flexible.
We want you to be able
to not just use them
for material design
language, but to be
able to extend them and compose
them together to create just
about any kind of
app layout design
that you could possibly want.
And so one example of a pattern
that the App Layout Elements
allow.
If you wanted a
responsive layout,
but you wanted tabs
across the top on desktop,
and you wanted those same menu
items to go into a side nav
on mobile-- and
this is something
that you couldn't do with
the Paper Layout Elements--
with the App Layout
Elements you can do this.
It's specifically meant
for flexible types
of adaptive UI in this sense.
So I really, really would love
to get feedback from everybody
on the App Layout Elements.
They are also
under Polymer Labs.
There's a nice splash page with
some documentation about how
you can get started using them.
And Rob, who's talking next,
will give a little bit more
about these App Layout Elements.
So the other features
I talked about
are very much a
work in progress.
We will open these
up as soon as there
is something to
play with, in terms
of routing,
internationalization,
and lazy loading.
And last, but finally
not least, I definitely
want to give a big thank you
to our incredible community.
These were some of the
most active contributors
to the Polymer library,
and the Polymer project
overall, in terms
of poll requests,
in terms of great issues
with great repros,
in terms of just support
in our community,
on our mailing lists,
on our slack channel.
So thank you so much.
The project would not be
anywhere near where it is
without this group of people.
And this is by no means
a comprehensive list.
There are many more
that have dedicated
a huge amount of time,
and really, really
helped the project grow.
We also hope that this
list continues to grow
as more people get involved.
So thank you, again,
so much, everyone.
And yeah, thank you.
Yeah, so I'm excited to see
where the Polymer project goes.
Please keep up with
us on the Polymer blog
and follow us on
Twitter, @Polymer.
And thank you so much.
[MUSIC PLAYING]
