SPEAKER 1: OK, so at the start
of the web, we just had tags,
and you would build your
pages out all of these tags.
And some tags looked
differently to others,
and there was no
real reason for that.
And since then, we've
had this process
of trying to explain the magic
behind how pages are built up,
and then give that
magic back to developers
so can use that magic to
build different things.
So an example of
that is that DOM
explained the
structure of pages.
CSS explained why
one heading was
a different size
or another, and you
could use that to style
things differently.
But until recently,
we couldn't really
explain why an
input element looked
the way it did and
behaved the way it did
and why a select element
was completely different,
had a different
set of behaviors.
Well, we have a new
explanation for that.
We've got Web Components.
And then the explanation
for how all that works,
and what you do with it,
and how Polymer works,
that is going to pull
forth from the face
hole of our next speaker.
It is Eric Bidelman.
Big round of applause.
[APPLAUSE]
ERIC BIDELMAN: So
I'm from the US,
so I'm going to
continue the trend.
Woohoo!
That's from my face hole.
So a little bit about myself.
My name is Eric Bidelman.
I work on Polymer.
I work on the Chrome team and
the Developer Relations team
here at Google.
You can follow me on Google+.
You can follow me on Twitter.
There's way too
much stuff to talk
about in 30 minutes with
Polymer web component,
so feel free to stop by
Office Hours, chat at me
on these different channels.
So for those that
have heard of Polymer,
you've probably come
into the project.
You've seen our website.
And there is this really
nice little explanation
of what the heck Polymer is.
And it says, "Polymer a new
type of library for the web.
It's built on top
of Web Components.
And it's designed to
leverage the evolving web
platform on modern browsers."
And so that's cool.
It's very inspirational.
It's a good little
intro to the project.
If you actually
look closer, you are
going to see this little
diagram all over the place.
We overload this in
a number of places
to describe the different
pieces of Polymer.
It's a nice Lego block
building of colors and stuff.
And so when people start to
investigate Polymer, they say,
well, is it polyfills?
And yeah, it's polyfills.
Is it a framework?
Yeah, it's a framework.
Is it UI widgets for the web?
Yeah, it's that , too.
We're working on that.
It's also a set of monomers
that combine together
to form a molecule if you're
a science geek like me
and go on Wikipedia last night.
But to really understand
what Polymer is,
you actually have to
take a step back in time
to the early days of the web.
In order to understand
where we're going,
you have to understand
where we've been.
So this is what the
web looks like today.
We'll transport
ourselves back in time
to an earlier day
when the web looked
like this, or at least
Google.com in '98.
And this is probably what your
first web page looked like.
You had a couple of
elements to play with.
You had things
like the form tag.
You had selects.
You had dropdowns.
You had list elements,
radio buttons.
And so the platform was pretty
limiting to what we could do,
but we didn't really need
anything more than that.
Of course, since
we're in the '90s,
we have Clippy's second
cousin, which is Selecty,
and he's telling us that we're
going to build a website today.
Oh, thank you.
So Active Select is a
really awesome element.
And it's worth
actually discussing
this for a few minutes.
With Select, you can put
some options in this thing,
and it just knows what
to do with those options.
It knows what to do with
these [? chore ?] elements.
And what you get out of
it is some default UI.
I don't have to touch
CSS or do anything crazy.
So that's really cool.
This works by itself.
Think of it as an early
component for the web,
and this is native
to the platform.
This is your classic
example of running out
of schwag at a conference.
Nothing is available except
for that XXL T-shirt.
But the point I make
here is that we're
configuring these elements,
not with a bunch of script,
but with just a
little bit of HTML.
Just plopping an
attribute on these options
and you get a
different behavior.
So these are grayed out,
and that XL, of course,
is the only one
that's available.
And you can move attributes
to the Select element itself.
So I can say size
equals 4, and I
can put the multiple
attribute on this element,
and it completely changes
the way this element behaves.
Now the users can select
multiple items, right?
And we no longer
have a dropdown.
We have this multiselect
widget, which is really cool.
Again, just by changing some
attributes on this element,
it knows what to do with that.
And you can put other
stuff in this tag.
It's smarter than
you actually think.
We can put the optgroup in.
We'd give it a label, have some
options in there, and instead
of your common dropdown, you
get a completely different UI
again, which is really cool.
So super versatile,
if you think about it.
And I haven't touched
any code here.
I'm just declaring the stuff.
Select doesn't take everything.
It actually is very picky.
It knows what it wants.
You can only put options.
You can only put
optgroups in there.
If you try to jam
an LI in there,
for instance, the parser's
just going to throw that out,
and it's not going to
render that in my dropdown.
If we're building components,
we want that ability, too,
to selectively choose what
markup we want to deal with.
Select is really
great by itself.
It has all this ability.
I can configure it
with attributes.
Now if you put it in a different
context, such as a form,
it takes on new
responsibilities.
It takes on new meaning.
So now when it's in
my form, somebody's
going to select this,
give it a couple values,
and that name attribute is
going to be submitted along
with the form.
So this is really cool.
We're composing, now, a
bigger and bigger application
based on these
smaller components.
And, of course, it's got a
slew of properties and methods
that it has on
its DOM interface.
And I apologize if
that's very small,
and you can't really see it.
Selected index, for instance,
is a property on this DOM
interface that doesn't
really make sense
as an HTML attribute,
but it totally
makes sense in JavaScript.
I want to be able to get at
the option that's selected.
And Clippy-- excuse me,
Selecty-- also fires events.
When something
interesting happens,
I get DOM events for this.
So Select is probably way more
useful than you ever thought.
Let's flash forward today
and see where we are.
Quick gut check--
a tab component
is sort of the quintessential
component for the web
these days.
So where are we with this?
What do we have to do
in order to build a tab
component on the web?
When we first started off, it
looked something like this.
There's a little bit of markup.
We're overloading ULs.
We're overloading LIs.
And just at the bottom there,
we call a little bit of script
to activate this thing
and get it going.
And over the years,
we've sort of
added on more and more
JavaScript, less and less
markup, and now we're at the
point where a lot of the frames
are just jamming in gobs
and gobs of JavaScript.
And that's really because the
platform itself has lacked
express that we needed
to it as we've evolved.
The platform hasn't evolved
with us, unfortunately.
So we're hoping to
try to change that.
So this is what people
ended up doing, right?
Let's pile on the JavaScript.
Let's pile on loads and
loads of JavaScript.
And ultimately,
there's something
wrong about this picture.
The story is no brighter on
the other side of the coin.
So the markup is
equally as atrocious
as where we've sort of moved
to in the script world.
This is Gmail source.
If you open up the dev tools,
at least the markup side,
I have no idea
what's going on here.
This is not maintainable at all.
I know they've done this on
purpose, but as a developer,
this is actually how
we build web apps.
It's a nightmare.
It's absolutely a nightmare from
the script side and the market
size.
What?
What?
Nobody likes this.
So we've moved really far
away from where we started,
from the Select, the
declarative nature of HTML,
what the web is good at.
And now we're a sad panda in
the corner with a small balloon
instead of the large balloons.
I don't know why I
chose balloons here.
I think it's just because
I feel very deflated when
I think about all this stuff.
But it makes me sad.
We can do much, much better.
So what if markup
was meaningful again?
If you take the Gmail chat
example, for instance--
let me bump this up
just a little bit.
If you take the
Gmail chat example,
and you can imagine a world
in the case of Web Components,
where you're
declaring everything,
and it's very descriptive.
You know exactly what's going
on in this web application.
So I have a Hangouts module
element that I've created.
Within that, there's components
such as a Hangout chat.
I know who it's from.
It's from Paul and Eddie,
just by an HTML attribute.
That's how you configure
this tag, their profile ID.
Inside of that there is
a discussion going on.
And inside of that,
there's Hangout messages,
each describing sort of each
individual chat message.
So I have a prototype with that.
I can talk to Paul Irish.
He's loving the Web
Components thing.
Hey, man.
Hey, man.
So everything is
completely self-contained
because it's all a Web
Components, all using shadow
DOM.
I can chat with Larry, too.
He's not going to
say much back to me.
'Suuuup.
And so that's really awesome,
because I know exactly--
I know exactly what's
going on in this picture.
I don't have to guess.
And that's because
we can get back
to a platform that
actually makes sense again.
So that's the universe,
at least, we conceptually
feel is relevant on
the Polymer team.
We want to get back to that
sort of declarative nature
of the web and
what it was good at
and reuse HTML and DOM like
it's first-class citizens again.
So let's jump into Polymer.
Quick spoiler alert.
Standards are the bottom
of all this stuff.
So everything I'm going
to talk about today--
and I won't take a deep
dive into the standards,
but it's all based on
four WC3 specifications.
So we have templates being
able to define a section of DOM
to be inert and able to
stamp that out for later use.
That's the template tag.
HTML imports-- so bundling
up CSS JavaScript and HTML
in a single unit
and delivering that
to another application,
that's great
if we want to have
a set of components
and deliver that
to some end user.
Custom elements, right?
The bread and butter.
Being able to define a new tag
in HTML is super important.
Teach the browser new tricks.
Hangout module, Hangout
message, et cetera.
And shadow DOM is sort of
the bedrock of all this.
And you don't have to use
it, but you can totally
use it if you want things
like encapsulation.
So for the first time
ever, we have the ability
to encapsulate markup,
encapsulate DOM,
and encapsulate styles.
So styles from your page
that's embedding you,
they don't bleed in.
And your styles don't bleed
out to the outside world,
and that's super important.
You can see by this
chart here that we
have a lot of
implementation going on
in Chrome, whether it's
in-stable or behind a flag.
Firefox is gung-ho
about all this.
There's open bugs for
all these specifications.
Opera gets some of these for
free with their move to Blink.
And I just added Safari,
who is going to enable,
as of today, the
template element.
So a lot of progress
on the native front.
Woo!
Yeah.
Yeah.
Seth likes it.
A lot of progress on the native
front with a lot of this stuff,
and that's super exciting.
But what is Polymer?
So I sort of alluded
to this diagram before.
Let's jump into it
just a little bit.
The first is it is
a set of polyfills.
So we want to enable
web developers
to use this stuff today.
It's really exciting stuff.
It's going to change the
way we do web development.
We want you guys to
play with it and give us
feedback on all the specs.
So the red part of this
diagram are those polyfills,
things like Pointer Events and
Shadow DOM the Custom Elements.
That part is really cool
because that actually
goes away over time as
the browsers implement
these native APIs.
So that part kind of
dwindles to nothing.
And the rest of Polymer sort
of lives on, gets faster,
gets better, because it's
using the native stuff.
The sugaring layer, the yellow
layer of Polymer, that middle
section is sort of
our opinionated way
to use all these API and
specifications together.
You can use Shadow
DOM by itself.
You can use HTML
imports by itself
and all these different
specs by themselves.
But we want to sort
of help developers
learn how to use them together
in a really coherent way.
And we also provide
things like data binding
and some other
conveniences in this layer.
Ultimately, we want to make your
life more productive as a web
developer.
And the last piece, and
probably the most work
in progress to this point,
is the UI components,
the green layer at the very top.
So again, everything
below this uses the core.
It uses the platform polyfills.
And we want to give you
ability to just drop
a component on your
page, a UI component that
does the right things.
It's responsive by default.
It's 60 FPS, and it's using
this underlying stack.
So philosophy and goals.
We keep it simple on the team.
The first and probably the
most core fundamental aspect
of the project
and Web Components
is everything is an element.
We think that's awesome.
We think HTML should be
a first-class citizen
again to the web.
We think it's cool, and DOM
feels actually really good
to work with again.
Unless you start to
play with this stuff,
it actually makes a
lot of sense again.
You have to write
tons and tons of code.
Eliminate boilerplate.
We want to, again, make your
life more productive as a web
developer.
And so we want to
remove-- even in 2013,
it's hard to be a web developer.
It's very tedious.
You have to remember things like
touch events, pointer events,
and all this other stuff.
We want to remove all that.
The last piece is to utilize
the modern web platform.
So if you have a
hand on the steering,
you have a hand on
the gear shifter.
But you always have your eye
sort of looking backwards.
You can never really
progress the platform forward
and really show developers
and the web what can be done.
So we're only supporting
the latest version
of modern browsers.
Turns out it's also very
hard to polyfill things
like Shadow DOM for old IE.
So let's talk about elements.
We're going to go up and
talk about that top layer
of the stack.
And the mantra here,
if you remember,
is that everything
is an element.
Everything is an element.
So what do we mean by
everything is an element?
Well, this is one example.
If Ajax was just part
of the browser today,
you would probably
use it as an element.
And you probably wouldn't
write a lot of JavaScript code.
And so that's
exactly the approach
we've taken with the
Polymer Ajax tag.
The way you configure
this tag is you
give it a URL, just
an HTML attribute,
very akin to the Select element.
You're configuring this
element using attributes.
It's all declarative.
And then you're passing
in a parameters attribute
as well with some additional
parameters for that URL.
And so instead of writing a
bunch of XHR code every time
I start an app, I'm
just basically dropping
this on my page, and it knows
exactly what to do with that.
And I'm configuring
it from the outside
via parameters, attributes.
And I wire up a little
bit of JavaScript.
Just like the Select element
fires a change event when
somebody selects something
new, this element
is going to fire a
Polymer response event.
And then I can
subscribe to that,
fetch this element from
the DOM, subscribe to that,
and just use the same
techniques I'm used to.
JSON.parse, parse the
response from this JSON feed.
This element has also an API.
Just like in the
case of Select, it
has API methods I can
call on its DOM interface.
So there's this go
method that I can call.
And so this feels
really good, because I
can reuse this
each and every time
I need Ajax in my application.
Everything is an element,
thinking about layout
using nothing but elements.
So I don't know how many people
have tried to use CSS Flexbox,
but it's pretty painful.
It's a great-- this one guy.
It's an awesome,
awesome CSS feature.
We've needed this
for a long time.
But it's still very
intricate, and you
have to know a lot
of things about it.
So if you remember for
the case of Select,
Select was able to
rearrange its children,
give me some default UI
without much work at all.
And the approach on
the Polymer team ,
what we've taken is let's make
a Polymer flex layout tag.
And inside of it, its children
just know to be flex children.
And so now I can configure
this tag with attributes.
So I can change vertical.
I can just remove
that attribute,
and the element just knows
what to do with its children,
and, of course, default back
to a row representation.
I can toggle the flex attribute
on its children elements.
And, of course, it'll
do the right thing.
So it takes a lot
of the burden out
of knowing some of these new
technologies under the hood.
I can literally
just have this thing
to do what it's
supposed to do, which
is arrange my page
in a certain way.
It's conceptually interesting
to think about elements
that actually don't
render anything.
So Ajax, it's not
rendering something.
It's a utility element.
It's doing something
on the page.
Same with the layout.
It's doing something
on the page.
It's not actually
showing me stuff.
And we've been playing around
with a lot of these non-- I
call them non-visual utility
elements, things like layout
for CSS grid and flexbox.
We have a media
query element that
just handles doing media queries
and firing events for that.
So you just drop this
in and reuse this,
and you don't have to
worry about stuff anymore.
Tags for dealing with a
single-page application
or shared state.
Polymer local storage
is actually pretty cool.
So if you tie this up
to another element,
you get some change
events, you pass
some data using
data binding to it,
and I'll show you
an example of that.
And you persist data
to local storage.
You don't have to worry about
hooking that up yourself.
And then other things,
like Polymer signals,
being able to broadcast
messages to different components
on the page or to
the broader page.
So conceptually it's
a little bit weird
to drop the stuff on your page,
and it doesn't render any UI.
It just, for instance,
reads a file.
What?
A tag that reads a file?
That's crazy.
But once you get into
the Polymer core,
it starts to really,
really make sense.
And on top of that, we
have a set of UI elements
that we're working on.
So this is what people
think about when
they think of components-- the
UI that you plop on your page.
And your usual
suspects apply here.
We have things like
a Polymer UI card.
And basically what you do is
you drop this on your page,
and you get things like
swiping functionality
for free with touch
events and pointer events.
It's pretty nice.
We have a sidebar menu item.
So you just drop this
markup on your page,
and you get the
usual site navigation
with a little thing that follows
you, and it's got animations.
It's all 60 FPS.
But the really cool
thing about this
is it's just a bunch
of markup, right?
So I'm not writing any code to
actually reuse this element.
I'm just declaring Polymer
UI side menu on my page.
It's got attributes,
like Selected,
that I configure it with.
Labels, so we're using parts
of the platform already.
Inside of it, it knows what
to do with its children.
And it expects a certain
type of children.
It expects Polymer
UI submenu item.
And so that's what's rendering
all this, just a bunch of tags.
So it's really
easy as a developer
to know what's going on here
and to maintain and to use.
It's important to note
that Web Components really
lend themselves very nicely to
composability and reusability.
So we're actually using--
for a lot of the UI elements
that we're creating, we're
using these utility elements
under the hood.
So, for instance,
Polymer selector
is this sort of selecting
widget that manages state
and selecting those menu items.
And so we're reusing stuff.
We don't have to reinvent the
wheel each and every time we
start a new app.
We can just compose an
app out of components.
So this is the world
we're creating.
We hope is really
exciting for developers.
The universe is, as I
see it-- this is actually
the video I played
at the beginning.
It is a Polymer application.
It's written by John
McCutcheon on the Dart team.
He used the Polymer Dart port.
And this is pretty cool,
because I absolutely
know zero about WebGL.
But I do know HTML very well.
And so he created a
bunch of custom elements
for working with 3-D Scene.
And so this is just
wrapping his WebGL library.
You can see I can
change the Earth just
by changing an attribute
on this element.
I can scroll up and change
the texture of the sun.
And just by changing a source
attribute to a new URL,
WebGL is updating that texture.
We'll make it the--
yep, Web Components
are the center of
our solar system.
So that's really cool.
Because again, I don't
know anything about WebGL.
But I know a ton
about HTML, and I
can read exactly
what's going on.
Each one of these
tags knows what
to do with its
children to render
that scene in a certain way.
So let's talk about
how you actually
build a Polymer element
or Web Component.
This is the yellow
layer in the center.
This is the sugaring
layer, convenience APIs.
The goal here is to
eliminate boilerplate.
We want to make it
really easy for you
to develop Web Components.
So Polymer has a
number of features.
The moral of the
story, here-- I'll
just play through
the first couple-- is
that we want to make
things super declarative.
If I haven't made
that clear right now,
we want things to
be declarative.
We think it's very
powerful to do that again.
So instead of writing
a bunch of code
to register an element
in the browser,
you basically declare
a Polymer element.
It's a declarative form.
To extend an element,
use the Extends attribute
on your element to
extend another component.
We have things
like data binding,
your typical double
mustache in text.
If I want to data bind
this inputs value,
I'll just set up a
property and data bind it.
We have declarative events.
So when this on-event name--
in this case, a click--
happens, when it's fired,
this property on your element
is going to be called.
And then we have a bunch
of other stuff, things
like property observation,
reacting to states.
When this property changes, do
this, give me this callback.
The last one, pointer
events and pointers,
is pretty cool, right?
This is a really evolving,
awesome specification
that unifies input on the web.
And you get this for free.
If you're building
a Polymer element,
you don't have to
worry about touches.
It's just built into the model.
Goal here, again, is to
be declarative and write
less code.
And what I mean
by write less code
is, actually, now we're in
the platform layer, sort
of the core or the
polyfill layer.
So if you wanted to just use
the specifications by themselves
to create an element,
you would actually
write this each and every time.
This is the template tag.
Let me see if can
zoom in just a tad.
So I have my markup using a
template tag, the inert section
of markup that I'm
going to stamp out
for each instance of the
element that's created.
Then what I do is I
write a little script.
I write a prototype.
God knows writing
prototypes are crazy.
I have a created call
back because This
is all part of the
Custom Elements API.
I'm creating Shadow
DOM out of the template
that I'm just creating, and
then I call document.register.
So there's a lot of
stuff going on just
to register a simple,
simple tag that
does nothing other
than render an input.
So that's pretty crazy.
We think we can do better.
And so that's where
Polymer Element comes in.
What's cool about
Polymer Element
is that we've created
a custom element that
allows you to create custom
elements, which is crazy.
But it's using, again,
the document.register
under the hood.
So you declare your
Polymer Element.
You give it the name of the tag
you're going to create, maybe
give it a constructor if
people want to call you using
the new operator in JavaScript.
And then inside of
the Polymer element,
you just drop your markup using
the template element, which
is one of the specifications.
So this one is pretty simple.
It just has a style
sheet in it that colors
all inputs red
within my Shadow DOM.
So it's Shadow DOM that Polymer
is going to create out of this.
So we're not going
to bleed styles out.
It's not going to color
all inputs orange.
But this is all you have to do.
And then as soon as the browser
and Polymer processes this,
people at the bottom here,
users of your element,
can declare it on their page,
just as a normal DOM element.
They can use DOM to create
it using Create Element,
or they can use the
new operator as well.
But at some point,
you're probably
going to want to define an API.
So just as in the case of
Select, it had properties,
it had methods, it had
events that had fires.
We'll take our example
that we had before,
which is that silly
input, and we'll just
kill this no-script attribute
that I have on top here.
So when we kill that, we
can in-line a little script
tag that calls the
Polymer constructor
and pass it the name of the
tag that we're going to create.
So right now it's
not doing much,
but we're going to add to this.
The second parameter,
second argument
to Polymer constructor, is a
set of properties and methods
that your element defines.
So if I use the console,
for instance, the dev tools
and query this
element in the DOM,
you would get a length
property, and you
would get a ready method.
This is a cool little
Polymer feature.
I'm just basically grabbing my
internal input from this tag,
using the "this dot
dollar sign dot,"
and then referencing the
idea of that element.
So it's just kind of
a convenience thing,
to get at the internals,
the guts of your element.
And that's all it takes.
We're just defining these
properties and methods,
and they get added to the
prototype of your element.
I really want to remind folks
that Web Components don't
change your workflow
for developing web apps.
So if you want to do things
like reference an external style
sheet, you can totally do that.
If you want to
reference a script,
you can totally do that.
If you want to use CoffeeScript,
if you want to use SaaS,
all is fair game in this
world of Web Components.
Ultimately, what
changes is your concept
of actually building apps.
You're composing
web applications
based on smaller chunks that
are all compartmentalized.
This is also great,
by the way, for CSP.
Give a shout to
Chrome Apps, which
is a strong CSP environment.
So you can absolutely use
Polymer in those environments
as well.
One of the core
features of Polymer
is being able to publish
properties and do data binding,
and this is super,
super powerful.
So we had the example
of my input before.
We had just this
input tag that's
in-line that style
to color it orange.
And I have two properties
on this element.
I have a type property,
which is defaulted to text,
and I have an orange property,
which is defaulted-- excuse me,
a color property, which
is defaulted to orange.
Instead, I can kill
that sort of redundancy
here and replace those
hard-coded values
with those properties
using data binding
and using the moustache.
And so now, whenever
one of those changes,
it's two-way data bound.
And I can go crazy with this.
I can set up a bunch of markup
internal to my application
and tie them together
using data binding.
So this is pretty cool.
This is using Polymer
local storage.
So now every time someone
types in this input, this value
is going to change,
and it's data
bound to this Polymer
local storage value.
And I'm automatically
going to persist
data using just data binding
internal to my component.
Very, very handy stuff.
The other thing, if you
remember from the Select case,
is that people could change the
behavior of the element using
attributes.
And so in order to do
that in Polymer, we
have this attributes
attribute where you say,
I want to publish
the type property
and I want to publish
the color property.
And so then what people can
do from the outside world
when they use your
element, is, for instance,
change the default of
that color property using
an attribute on the tag.
So they're overriding my
default of orange here to red.
And so that's how you are
able to customize elements
by publishing these properties.
Another example of using
this stuff in action
is to do something like
responsive design by default.
I can create a responsive layout
element that basically handles
all the intricacies of dealing
with responsive design.
So in this example, I'm using
Polymer media query element
that we've created
and basically using
data binding to watch for
changes on the media query.
So when this query of
the past has been set,
this query match is
going to be true.
So I'm data binding to that.
And then I can stamp out a
section of declarative markup
using the template tag.
So if [? is phone ?] is true
and that responsive attribute
is set, I can show this section
of markup in my element.
Otherwise, if it's
false, I'm going
to show this section of markup.
So now we're using
dynamic markup.
We're using data binding,
we're using reusable elements,
and it's all sort of
just working internal
to my web component.
And people from the
outside, all they have to do
is just declare this
sucker on their page.
Responsive layout knows what
to do with your content.
It does the right thing based
on the media queries in it.
So that's super, super handy.
So Polymer is many
things, right?
It's a set of polyfills to
enable this stuff today.
Again, it's landing in native
browsers near you, as we speak.
On top of that,
we have the core.
We have the sugaring layer,
which has data binding and all
that declarative
stuff so you don't
have to reinvent the wheel and
do all this customization over
and over again when you're
building a web component.
And on top of that, we have
this set of UI elements
that we want to use and
have you guys just drop
those on your page.
And everything just works
using Web Components.
The part at the top,
the little blue part,
is where you guys come
in and build applications
based on Web Components.
You can use any part
of the stack you want.
If you just want to use the
core, foundational, native APIs
in the browser, you
can use the polyfills.
You can use our sugaring layer
to make things more convenient.
You use just the
elements if you don't
want to write any code and
just drop things on your page.
That's totally, totally fine.
So that's Polymer.
I encourage you to check out our
website at polymer-project.org
to learn more.
There's a lot going on there.
There's a lot of
conceptual things
that are changing how
we build web apps.
As I was actually
researching this topic
and preparing for this
stack, I looked up Wikipedia
and actually looked at
the definition of Polymer.
"A Polymer is a large molecule
composed of many repeated
subunits, known as monomers."
I don't know if
you guys knew that.
But I read this, and
I was like, whoa.
If we replace a
couple words here,
I actually read
this as-- "A web app
is a large collection of
web components composed
of many subelements,
known as custom elements."
A web app is a large collection
of web components composed
of many subelements-- so
you're building components
out of components out of
components out of components--
and those are known
as custom elements.
So I think that's really cool.
I think when we start to
compartmentalize things
on the web, and we can reuse
them, we can share them,
I think that becomes
very powerful.
That feels super good.
So I hope you guys agree.
Check out Polymer.
Thank you for your time.
This stack will
be up at that URL.
Again, feel free to follow
me on the social channels.
Thanks.
[APPLAUSE]
