Building modern apps with Polymer & Web Components

Building modern apps with Polymer & Web Components

MALE SPEAKER: Bidelman [KOREAN]. [APPLAUSE] ERIC BIDELMAN: Hello. Everyone say cheese. Thanks for coming. So we’re going to
talk about Polymer for the next 40 to 45 minutes. I’m really excited
about Polymer. Polymer is a new
library for the web that we’re building
at Google to help developers use Web Components. So a little bit
about myself so you know who is talking
to you up here. My name is Eric Bidelman. I work on the Google
Chrome team as part of the Developer Relations team. You can follow me on Google+ or
Twitter or my website, there, that I try to blog on, but
unsuccessfully, very much. HTML5 Rocks articles. I write a lot of
stuff for HTML5 Rocks. So if you want to learn
about all this cool stuff I’m going to talk about today, feel
free to visit those articles there. Does anybody see the
Easter egg in this picture? There’s a little– the
incognito guy for Chrome. He’s on my glasses. It’s pretty cool. So Web Components. What are Web Components? How many people have heard
about Web Components in general, or the technology behind it? A couple of people? OK. You guys are in
for a real treat. Anybody that is a web developer
in the audience, I think, understands this stuff
once they see it. It’s very, very powerful. And there’s a lot of
stuff that the browsers are adding in order to make
developers’ lives easier. So Web Components. An example of a web component. The blink tag is
back in the browser. But this time, you can implement
it as a new custom element. So essentially, that’s
what Web Components are. That’s one facet
of Web Components– you can implement
new tags in HTML. And this one– it doesn’t
use the browser internals. It just uses CSS animations
to do the blinking effect. You guys are probably
familiar with this one here. [MUSIC_-_PSY,_”GANGNAM_STYLE”] ERIC BIDELMAN: But what
this gangnam-style tag does is somebody declares
this tag on their page, and boom– as soon as somebody
hovers over this little thing, it plays the song using
the Web Audio API. And there’s a little dance
using CSS animations. It’s kind of a silly
example of a web component. But again, all
somebody has to do is declare this thing
on a page, and they get all this other
stuff for free, encapsulated in this component. But we can do more than just
regular tags or silly examples. We can actually wrap up entire
applications and functionality inside of a tag. So as a user, I can declare
the photo-booth tag on my page. And this particular
example just wraps the getUserMedia API
that Alex talked about. So I’ll allow that. So it runs a little bit of
JavaScript in the background. And so as a user, I just
have this thing on my page, and boom– I have photo sharing,
sort of video capabilities with a little CSS filter
action right on my page. And it’s even got an
API to do snapshotting, which is kind of cool. It just renders out to a canvas. But again, all of this comes
for free just by somebody putting that on their page. It’s getting kind of crazy. If you don’t like the way the
native HTML elements behave– say, you’re not too
excited about a button, doesn’t look really
good, you have to add a click handler
to it or something– you can create a
web component that says my button is a
special type of button. It’s going to be a mega button. And this mega button
is not a normal button. It actually, when I mouse over
it, it has some crazy CSS. And it’s actually got– [MOO] ERIC BIDELMAN: –a default
behavior that moos at you. So again, kind of interesting
and silly for the web. But I can basically redefine
the way native buttons behave in HTML by
using Web Components. So if you take a look at
actually real world examples on the web today, a really
sort of quintessential example is a tab component. These are everywhere. Every library has
a tab component. This is what it
looks like in jQuery. There’s a bunch of markup. Some of it’s meaningless to me. You’re overloading ULs and LIs. This is what I
believe what YUI does. Instead of a declarative
markup approach, they’ve taken more of
a JavaScript approach– an imperative approach. So you include your
HTML in JavaScript, and then you call
a render method. This is Angular’s
version of creating what they call directives–
custom elements. Their version of
custom elements. And so you write a lot
of JavaScript code. And the reason all
these are different is because the APIs in the
browser– in the web platform– haven’t existed,
until now, to be able to really, really define
what a tab component means semantically, and
easily, and consistently across these
different frameworks. This is Kendo UI’s version. This is Sencha’s version. Every one is different. It’s pretty insane. It’s insane as this picture. But what about–
not just components. What about whole applications? If you take a look
at the DevTools, if you open up Gmail–
how many people think that his source
code is readable? Yeah, nobody. Exactly. So it’s all divs. We call this div soup. It’s meaningless to a developer. I can’t maintain this. I have no idea what it’s doing. Some of the stuff is obfuscated
for performance reasons. But at its core, we don’t
have the primitive tools to describe what
Gmail should be. What? What? This is how we build web
applications, you guys. And it feels really dirty to me. But what if Gmail Chat, for
instance, looked like this? What if it was meaningful again? What if markup was meaningful? So instead of a
bunch of divs, I had something like a
Hangouts module tag– a custom element
to describe this. Inside of that, we
have a hangout-chat. I’m chatting with Paul and Addy. Just an HTML attribute
that I’ve added. My profile ID is included
in this HTML element. Inside of that, I
have a discussion tag. This is totally legible. It totally makes sense. And each one of these
tags is a message. And it’s got semantic data,
such as my profile, the date and time it was sent. And it really, really
just makes sense from a developer standpoint. I have a demo of this. This is my web component,
my Gmail Chat Hangout web component. I’m talking to Paul
Irish down here. And I can type to him. I’m going to try
to type with one hand, just a bunch
of characters. I can create a new
component in each one of these– I’m talking
to Larry Page now. He knows Spanish. But these have functionality. These components wrap up
this collapsible widget. I can add new ones. And if I dive into this
using the DevTools, I can see that ultimately
what I’ve implemented here is that the Hangout module. Inside a hangout-module,
we have a bunch– we have the discussion tag. And inside of these, we have the
custom element hangout-message. And so I’ve done
this using Polymer. And that’s what I’m
going to talk about now. But it just makes
sense when you’re implementing this stuff
using Web Components. So this feels really good. I’m really happy about this
direction as a web developer. So the better tools that we’re
adding to the web platform come in sort of three or
four different flavors. And the whole Web Components
notion– they all share this umbrella
term– is made up by several different
specifications. And so the first is Shadow DOM. Shadow DOM’s a
new API that we’re adding to the
browser that allows you to do DOM and
style encapsulation. So styles don’t bleed
into your component. Styles that you define
inside don’t bleed out. That makes a lot of sense when
you’re talking Web Components. HTML templates. Proper templating in a browser. The template element allows you
to define sections of markup to be used for later. This is really handy
when you’re stamping out a bunch of dynamic DOM. Custom elements is
another specification as part of Web Components. And this is sort of the
core API behind this stuff. It allows you to create new
tags and tell the browser about the gangnam-style
tag or the photo-booth tag. And you can also extend existing
elements if you want to. And the last piece of the
Web Components ecosystem is what’s called HTML imports. And this is really cool. It’s a very, very simple API. Essentially, we get a link tag. And instead of a
rel=”stylesheet”, it’s a rel=”import”. And you can reference
an HTML file. And it’s essentially
like a #include, if you’re familiar
C++ for the web. You get to bring in another file
of HTML, CSS, and JavaScript all bundled together. And then somebody can
bring that into their page and start using it. So that’s really cool. It’s a way to
distribute and bundle common markup, common
JavaScript, and common CSS. Alongside of these four
main specifications, we have other primitives that
we’re adding– the browser to adding– to do things
like data binding. If you’re making a web
application these days in a framework– Angular,
Ember, one of these frameworks– likely is that you’re going
to be using data binding. This is really popular. And so some of the
primitives that are going to allow this to
be native in the browser are things like Object.observe. So being able to get changes
when a JavaScript object changes– get notifications
of what’s going on, what has changed. And so that increases
performance and allows you to write really,
really slick web apps. Template is an example. Being able to stamp
out dynamic markup. And Mutation Observers,
sort of the equivalent of Object.observe in the DOM. So being able to decide
and make modifications when DOM has actually changed. So if somebody
removes a note, you can get a notification for that. So all in all, a
bunch of new APIs. I’m not going to talk about
these at any detail today. I’m going to talk more at a high
level, at the Polymer level. But essentially they’re
a collection of new APIs that you as web
developers can play with. All right. So let’s talk about Polymer. So what is Polymer? How many people have
even heard of Polymer? Cool. A couple of people. Awesome. So my take on Polymer is–
and the goals of Polymer– is that it’s a new
library for the web. It’s a JavaScript library. It’s built on top
of Web Components. That is very at its
core– Web Components– and the specifications
that I talked about before. And it’s designed to
leverage the evolving web platform in modern browsers. And what that really
means is that we want to teach developers how
to use some of these new APIs and use them all
really well together. As you’ve seen in
this last slide, there’s a bunch of
new stuff coming. We want to highlight an opinion,
a way to use all this together. Each one of these
technologies can be used totally
separate by themselves. That’s part of this
magical picture. But together, they really form
an awesome, awesome story. So what is Polymer? This is a diagram that we have. It’s our architectural
conceptual diagram. First, it’s a library. It’s about 48 kilobytes for
the evolving web platform. And it enables the use of
things like custom elements and pointer events and Shadow
Dom and HTML imports today using polyfill libraries. And so we actually
have, as I mentioned before, an explicit goal
to support the latest version of every browser. And one reason behind that is
because polyfilling something like Shadow DOM– which, if you
are familiar with the details, or you read more later and
your mind sort of warps because it’s a very,
very complex topic. And actually supporting
that in older browsers with limited
JavaScript capabilities is almost impossible. So it’s a polyfill library. That’s this red layer. That’s sort of the
foundation all of Polymer’s built on top of. It’s built on top
of Web Components. And you can think of that
red layer as that foundation. The next layer up–
the yellow layer– is what we call the Polymer
core library, the sugaring APIs. It’s a little bit of extra
special sauce, if you will, that sits on top of
the fundamental APIs. But it makes things really
easy for you to develop. So I’m going to show you some
of those examples in a bit. But it makes developing Web
Components a lot easier. Let’s just put it that way. And it also
expresses our opinion on how to use these
different APIs together, which I think is really awesome. One level up from that
is the green part. These are the elements. So we’re interested in building
a comprehensive set of UI elements and just
general awesome utility elements for the web. So these, again, sit on
top of Web Components. They use the Polymer core. And they sort of
represent the visual layer of what we think Web
Components can be. So it’s a lot of stuff. And we have three
main philosophies. And basically, you’ll hear
me say this again and again and again, and that’s to
utilize the modern web platform. We want to sort of push the
limit of where the web can go. The second one is interesting. And it’s conceptually hard
for people to understand this when they first are
introduced to Web Components. And it’s that everything is DOM. We really want to make
markup king again. You saw the example
of the Hangouts Chat. That’s all declarative. It’s very declarative. And as a user of that
code, it’s very easy to write a web app
just using markup. The browser understands HTML. So everything is an
element, the green layer. And the last one is
eliminate boilerplate. Who likes to write
a bunch of code over and over and over again? I should put my hand
down because I hate that. And we do too on Polymer. We want to make
your lives easier. Nobody’s going to
use Web Components if you have to write
1,000 lines of code just to get one component done. So we want to be opinionated. We want to teach developers
how to use this stuff. We want you to be able to pick
and choose the parts you want. If you remember the
architecture stack, you can sort of, as
a developer, come in at any one of these levels
and pick and choose the part that you want to develop on. If you just want to
use the raw APIs, you can use the polyfills. If you want to use
the special sauce, you can use Polymer core. If you want to use our elements,
just drop them on your page and you don’t even have to worry
about doing any development. That’s totally cool as well. And we want to
evolve with the web and be a constant feedback
loop to the standards process. This is really, really
important on Blink and Chrome. The Polymer team is
constantly talking to the Blink engineers,
the Chrome engineers, about performance issues,
or how do I do this, or why is this sort of
slow in the browser. And so we want to
inform and make these APIs rock solid for
developers to play with. So I want to invert that pyramid
and start with the elements. I want to highlight this
notion of the green area, which is embrace DOM. Everything is an element. What does this actually mean? So the first thing that
we have is actually this polymer-ajax element. This is an example element
that we’ve created. And so we can actually perform
AJAX using DOM, using markup. What? That’s crazy. But it’s actually really,
really powerful and really cool. So we have this
polymer-ajax element. And as a user, I
put this on my page. I give it an URL of a
JSON feed, for instance. And it’s also got this
configurable params attribute that I can pass in a
serialized JSON object. So we’re going to
essentially get this feed, this YouTube
playlist, as a JSON feed. So I drop it on my page. And I read the documentation
about this particular element. And I recognize and
see that it fires this polymer-response event. So when that feed
has been processed, and then the request
has been made under the hood on that element,
I can listen for that event and then use your standard
JSON parse to get at the data that it returns to me. So I can run this real
quick and show you it’s exactly what I
have on this page. So I have just this element
declared on this page. I’m listening for
this polymer-response. And boom– I have my instant
playlist of YouTube videos. So the important takeaway
here is that it’s just markup. The only code I’ve written is
your standard query selector, your standard add
event listener. It’s just DOM. It’s just HTML elements. I’ve just defined a new
functionality, a new behavior, and that’s being able
to do AJAX using markup. That slide is out of place. Everything is an element. We can do things like
reading files in DOM. So how many people are familiar
with the FileReader API? Being able to read
files in HTML5? So you can do this. This is a FileReader API. And what this element
does is essentially wraps that JavaScript API. So instead of writing
a bunch of code, I can just declare this
Polymer file on my page. And I can configure this readas
attribute that it defines. I can decide to read the
file as a data URL, an array buffer, a binary
string, or text. This sort of just maps
to that JavaScript API. And same type of deal. I’ll wait for the
polymer-result event. I’ll attach that listener. And then I can process this
element’s .result property. This file object also has a
blob property you can set, so this is how you actually
pass in the file to read. In this case, I’m just setting
it to this string, abc. And then I call its read method. So this Polymer file
element has an API. It’s got a read method. It’s got a result property
that I can get at that data. And all I do, again, is just
declare this on the page. So I’ll hit Run. And boom– I’ve read
this file that I’ve set using the read method. It’s given me a data URL back. And if I open that, you can
see, up at the top there, the data URL that’s
produced is that abc. So that’s really cool. You can imagine attaching
this element to a file input, for instance, and then
having the user select files. And then reading that
using nothing but markup, instead of a bunch
of JavaScript. Everything is an element. What about things like layout? All right. We have CSS for layout. What if we made that
more declarative? Something like this. So we have a polymer-flex-layout
element that we’ve created. And these are ideas we’re
sort of toying with. What does a web
component look like that is sort of a utility element? It’s responsible for
managing its children. So this Polymer flexbox layout
essentially wraps CSS flexbox. And it’s got parameters
that you can configure. So it’s got this vertical
one that my children are being rendered in a
flexbox column right now. Instead, I can switch this. So if declare this
element like this, without that vertical
attribute, that container knows what to do
with its children. It applies the CSS for flexbox. And you can see that now I have
flexbox in a row orientation. Inside of it, I
can also customize how my elements flex using
this special attribute that this element knows about. So all of this stuff is sort
of wrapped up and encapsulated. And this particular element
is aware of its surroundings, essentially. And it renders
stuff using flexbox. I don’t know if you guys
have tried to use flexbox, but it’s a little bit difficult
to understand sometimes. And I can add a bunch
of children to this. And each one of
these just knows what to do because it’s part
of this container that understand CSS flexbox. You can reorient these. And so it all just works. And so this is really
cool because we’re using an element to do layout. And structurally,
you can read this and understand exactly
what’s happening. And we’re actually
working and sort of experimenting with a
number of different non-visual elements. So these are a few examples
that we’ve been toying with. So you have things for layout,
like flexbox and CSS grid. We have a couple of
tags to do views. So polymer-page is sort of a
single page app type thing, that you can implement
a single page app. Elements for libraries. Things to bring in shared
state and Google JavaScript libraries. A couple of data elements. So this is really cool. This one, polymer-localstorage,
essentially just wraps the HTML5
local storage API. You give it some
data, and boom– it just handles storing
that data for you offline. You saw AJAX and JSONP. And there’s also things for
behavior and interaction that we’re experimenting with. So signaling– sending
events to other components and sort of notifying those. A polymer-selector, being
able to do tri-state, sort of a selection-type widget. These are very common things. A lot of these that you
do in a standard web app. And we’ve essentially just
packaged these up as an element that you can just drop in
your page and start using. Conceptually, it’s
a little bit weird that you’re including
some markup on your page. Like polymer-localstorage–
it doesn’t render anything. It’s sort of this
utility element that just exists on the page. But once you see the
examples later on, I think it’ll really
start to make sense. So as part of this green layer
as well– this Polymer stack— we’re also experimenting with
the UI that sort of sits on top of these core utility elements. And just a couple examples here. You have your standard tab
widget, your toggle strips, your toolbar elements. You have things like
polymer-ui-card, which essentially gives you
sort of swiping capabilities. So you just drop
this on your page, and you get touch
for free, you get swiping for free, which
is really, really nice. You don’t have to worry about
any of that stuff anymore. Your sidebar-type menu
item, implementing some widgets that
sort of follow you, and this arrow that follows you. A lot of this stuff
is just really natural in the world
of Web Components. And this one’s pretty cool. This one– if you
polymer-ui-theme-aware, if you embed this
within a container, the whole page or the container
takes on the theme that you specify. So it’s a really kind of
an interesting and cool way to do theming of an entire web
app just by placing in one tag. A lot of these– I
will mention the UI, polymer-ui– use those
underlying non-visual elements to get the job done. So they reuse the components. And that’s actually one awesome
benefit of Web Components, is that they’re reusable. You don’t have to start
over each and every time you create an app. You can reuse the existing
functionality and sort of mix in new functionality. So that’s a little bit
about thinking declaratively as elements first. Now let’s talk about how you
actually build a web component. And that’s where this yellow
layer, the Polymer core sugar APIs come in. The philosophy of
this section is we want to eliminate
boilerplate. There’s a lot of
tedious code that you have to write in order to
work with these standards– the Shadow DOM, the
custom elements. And we want to make
that very, very easy. So we’re taking a
declarative approach. The first couple ones
you’ll see here– core features of Polymer–
they’re all declarative. So instead of registering
elements in JavaScript, you’re declaring
them using what we call the polymer-element syntax. You can extend the
elements very easily with this extends
property that we have. You could do things
like data binding. So if I want to data bind
this inputs value to the foo property, I can do that
with the double mustache. Very similar to any other
framework out there. Declarative events
are pretty cool. You don’t have to do things
like attach an event listener. You can basically just use on
dash, whatever event you want. And then give it the handler
that you want to be called. Publishing properties. A lot of this stuff
I’ll go through. Being able to detect
when a property changes. Somebody changes
something on your element, you want to be
notified for that. And you get a callback
for that if you define it. So the moral, the
takeaway here is that we want to be
declarative as possible, and we want to write less code. And what I mean by writing less
code is something like this. This is an example of
creating a custom element– my-input at the
bottom here– that’s the tag we’re creating–
without using Polymer. This is what you have to do. So the first thing is
you’ll have a template tag with some markup
that you’ll declare. Maybe it’s got some styles
in it to style this input. And then you write a
bunch of JavaScript. You write a prototype object. You create shadow root using
the ShadowRoot API for this. And it’s kind of messy. This is very repetitive. If you’re implementing
a web component, you would have to do
this each and every time. And then you call
document.register at the bottom here. So instead, what
we’ve done is we’ve decided to take a
declarative approach. We want to preach and
practice what we preach. And so instead of writing
a bunch of JavaScript, you declare a Polymer element. So you just declare this
using this special tag, which itself is implemented
using the primitives. It’s implemented using
document.register, which I think is really cool and
sort of an “Inception” moment. But you Polymer element, the
tag that you want to declare, MyInput. You can pass in a
constructor, so people can use the new
operator in JavaScript to create [INAUDIBLE]. And the important piece
of this particular example is this noscript attribute here. And that basically just means–
this element is dead simple. It’s just a bunch of
markup with some styles. It doesn’t have an
API in JavaScript. It doesn’t have any
properties that are set. And then we just
include that template that we had before in
the previous example. And that’s how you define a
custom element using Polymer. It’s all declarative. People can then declare
MyInput on their page. They can create it in
JavaScript using createElement. Or they can use new. The point is, it’s the
same web platform and APIs that exist before. You’re just allowing developers
to create new elements. If you want to, we can
use default attributes. So this is pretty cool if you
have something like Bootstrap, and you want to include
maybe a common CSS class on every element
that’s created. In this case, including
other attributes in your Polymer
element definition will include those on the
element when it’s created. So somebody declares
MyInput on their page. And every instance
that’s created in the DOM will actually include that
class active in that custom attribute. But as you saw, we have
more complex elements. So what about the photo booth
application or the “Gangnam Style” application? At some point, you’re probably
going to need to define an API. You’re going to need to give
your elements some properties, some functions. So what we can do with
this is actually take off the noscript at the top, and we
can inline some script inside of our Polymer
element definition. So now we’re
working with markup, we’re working with
styles, and we’re working with script inside of
this self-contained component. So we’ll call the
Polymer constructor and pass in the name of
the tag we want to create. The second thing we can do
is we can beef this thing up. So we want to give it
a couple properties. We can give it a type property
and default it to text. We can give this
element a color property and default it to orange. And we can also define methods,
such as the created callback, to be notified of when
things happen on our element. So essentially
what we’re doing is defining an API
for this element. I will also mention that we
can clean this up quite a bit if you want to. Your standard web
development best practices still exist in the
world of Web Components. Instead of having inline
style tags, if you want, you can reference a style sheet. Instead of referencing
inline script tags, you can reference an
external JavaScript file. So if you’re a fan
of CoffeeScript, if you’re a fan of
Less or Compass, you can totally use those
pre-compiled languages and then embed those inside
of your component to use. It’s also, for those who are
familiar with Content Security Policy, CSP. This a great way to get around
the issues that CSP has. Where this really
gets sort of magical is through published
properties in data binding. And this is one of
Polymer’s core features, and what we think is
very, very powerful. So this is the exact element
that I had in the last slide. It’s got that input tag. And we’re making
a special input. The only difference here now is
that I have this inline style tag for the color. So I’ve just moved
that from a style tag, just directly on
the element there. But you can see there’s a
little bit of an issue here. I’ve got this type
property on my element, and I’ve also got this color
property on my element. But they’re being duplicated in
the markup up at the top here. That’s kind of
ridiculous, so why don’t we switch
those to mustaches? So instead, now we can use data
binding to tie this element’s type property and
its color property to the values of that input. So those two are now linked
via mustaches and data binding. Very, very cool. Something else we can do is we
can publish these properties. So using this
attributes attribute on our Polymer
element definition, I can say I want
to publish the type property of my element,
and my color property, and allow users of my
element to actually pass in those as attributes. So you can see, as a
user of my element, they can override
my default orange color with the red value
using an attribute. So that’s what the
published properties do. It essentially takes
your JavaScript world, and says– OK, allow people
to customize me via HTML. And that’s where the declarative
nature comes into this as well. And we can go crazy with this. We can add a bunch of data
binding inside of our element, and link things together just by
using synchronous data binding. So for example, I can add
value property on MyInput and then link that
to a text area. So every time somebody types
in the input, my text area is just updated automagically
via that data binding. So things become
very, very powerful. And you ultimately have
to write less code. You’re not attaching
event listeners or watching for changes. It all just works
via the data binding in published properties. So a real world example. This, using some of the
sugaring APIs in the real world, is to use the
polymer AJAX element inside of another element. So maybe you’re creating
this new element. It’s called youtube-videos. And then people can declare
it on their page at the bottom here and query for cat
videos or Chrome videos, or whatever they want. And they can customize it
just by this query parameter. So we publish that query
string, that query property. Inside of polymer-ajax, it’s
the same thing as we had before. But we’re not writing
any JavaScript anymore. From the outside
[? row, ?] we had to write JavaScript to
listen for a response, and process that using JSON. Instead, we can just set
up data binding on some of the properties that it has. So for instance, it had
that params property if you remember from before. Instead of passing
a serialized object, we can pass in a
data-bound variable params. And so I can set that to an
actual object in my element when it’s created. So we have binding via
object, which is really cool. Instead of using the alt=json,
it’s got this awesome handle as parameter– if you read
the API documentation, that we can configure
it to do JSON requests. And instead of
hooking up JavaScript to process the
Polymer response, we can data bind to this
attribute, and use a property. And essentially when this file–
or when this request– is made, the response is
going to be filled. And we can do things like
render out template data inside of our element. So synchronous. Basically, you
can set up binding for anything that cares
about a certain property. And it just works. It just sort of updates itself. You can use the template
element to repeat over the list of entries
and print out an LI title for
each one of those. And so that’s really, really
a core fundamental thing of Polymer, is
using data binding. Another real world
example is reusing the polymer-file element
inside of another element. So we can create
this read-me element. And this one’s pretty
cool because it actually uses data binding as well. So no JavaScript here. Instead, we’re binding to
that result property it sets. This is a Polymer feature. It’s called a changed watcher. So when my result
property changes, my resultChanged
method will be called. So that’s really nice. You can observe
properties really easily. And something else
this element does is set up a default
declarative click handler. So instead of doing things like
attaching an event listener, I just declare on-click,
and give it a string. And the string maps to a method
on my prototype, on my element. And so when somebody
clicks this element, it’s basically going
to start the file read. And it’s going to call
that element’s API. It’s going to call
its read method. One other cool little feature is
sort of this jQuery-like syntax that we have. It’s called automatic node
finding, at the top here. And it essentially allows
you to do $., and then the ID of an element
inside of your element to sort of get at things. So it’s very easy to pull
things out of the DOM. You saw an example
of some of the things we’ve added to the template tag. So template, again,
is a new primitive that’s part of
the Web Components collection of specifications. But what we’ve done
in Polymer is sort of beefed it up a little bit. So you can do things like
conditional templates. Just activate this
section of markup, if this property is true. And this is using
data binding again. Or you can do things
like expressions. If isActive is true,
or alwaysShow is true, show this particular
section of markup. In the previous example,
you also saw iteration. And you could have
multiple levels of iteration iterating
over a property as well. So for users and user, stamp
out this particular markup. And then within that, you
can have named scopes. So this user has a files object
that you can then iterate over. So really powerful stuff,
creating markup dynamically based on a data model,
rather than just declaring it statically. Another feature we have
is anywhere you use mustaches– these double
mustaches for data binding– you can
set up expressions. So you can do things
like addition. Jill has her daughter’s
children plus her son’s children equals her grandchildren. Something else
that’s pretty cool is you can dynamically
apply classes to elements internal
to your component. So for example, if
user selected is true, and user type is super, it’s
going to apply the active class and the big class
on my div there. That’s pretty handy
if you want to do just sort of dynamic styling. And the last version of this
is conditional attributes. And this is really nice for
things like Boolean attributes. If you have a checked
attribute with the checked, and then the question
mark at the end, it basically says
add this attribute if this property is true. So again, really, really
utilizing the data binding capabilities. And if it’s not true,
that checked property, or that checked attribute,
won’t be applied in the markup. I want to take you on a
quick tour on everything is an element, and show you
some of this stuff in action. Actually, I think have it
ready to go right here. This a tool we
showed off at I/O. And it’s basically
a playground for you to come in and
play with elements. And these are some
basic, bare bones elements that we’ve created. But it’s essentially– I can
show you some of these really quickly. We have our Tabs widget, and
it just works as you expect. We have a Star Rating
widget that works. There’s a Toggle Button. And these are some of the
things that I’ve showed. And if we actually dive
into the code here, you can see that everything
is a custom element. We have the g-tabs
element, g-ratings element, g-togglebutton element. So what we can do is we combine
these all together using Polymer. So I’ll use the
double mustaches, and I’ll bind to this
selected property– this attribute
that it publishes. I can bind this value
of the Ratings widget to the same property. And some place in
here– well, if I add another one,
what should I add? Let’s add the Menu because
the Menu has different states. So basically, this
code just updated. It’s got the declarative
version of that g-menu. And it’s got also a
selected attribute that is defaulted to zero. Instead, I’ll just
switch that over to using data binding as well. So now I’ve linked all
three of these selected states to the same property. And hopefully, if I
select one of these, you can see that
they all update. So as I select one
in one element, the Ratings widget is changing. And there’s an off by
one error, but whatever. And the Menu’s also changing. And if I do the same– if
I click this one– again, everything’s just kept in sync
via data binding in Polymer. What’s really neat about
this particular app is that you can actually
embed it inside of itself. So you can do sort of
an inception-type thing. And that’s really thanks
to Web Components. Everything is compartmentalized. Everything is self-contained
and encapsulated. So you can have the
app within the app, within the app within the app. It’s really crazy, but it all
works thanks to Shadow DOM. So we talked a little
bit about the elements. So everything is an element. What does that look like? The green layer. The core layer, which is the
yellow stuff– data binding, changed watchers. And I really, really just want
to iterate on the platform level. The stuff that
Polymer is built on is ultimately the web platform. We’re not implementing
a bunch of JavaScript. We’re actually
using the APIs that are being added to the browser. So a couple things on this. The first is that if you’re
familiar with custom elements– custom elements have the
notion of life cycle callbacks. These are methods that you can
implement on an element that basically gives you
notifications of when it’s created, when it’s inserted
into the page, when it leaves the DOM, and also when
the attribute changes. So you get to know what
happens on your element. And Polymer has first class
support for this stuff because again, at its
fundamental level, everything is built
from that web platform. I will mention one quick
example of using something like this is maybe you have
a really complex element that opens an index DB database. Or you’re doing
something very complex. And then when the
element actually is removed from the DOM,
you want to do cleanup. You want to clean up the
database, you want to close it. And that’s what these methods
are really designed for, is to be able to do
complex things like that. Insertion points
are a complex topic. It’s part of Shadow
DOM, but Polymer also has first class
support for this. So insertion points are
really cool because you can have a user use your
Tabs widget, for example. And they include a bunch of
markup inside of the Tabs widget. Maybe title tags that
are H2s, and section tags for the content itself. And inside of your Shadow
DOM, the polymer-element– the web component–
you use content tags. These are insertion points. And you can select out
very specific markup from the user’s
markup and render that into particular locations
inside of your element. And so it’s really cool
because you can say, I just care about these
particular elements, and I’m presenting you to
look like a Tabs widget. So I actually have
an example of this. It’s a little experiment
I did using AngularJS, which is an awesome framework. And at the top here, you
have a web component version. And you have an Angular
directive– their version of custom elements
at the bottom here. You can see the markup
is strikingly similar, and I’ve designed
it to look that way. But the code is very different. So the code for the
Polymer element, it’s all declarative
and whatnot. And Angular, they have their
own API to create directives. But the really needs
anything about this is that you can– because
everything is an element and everything is DOM– I’ve
set up data binding using Angular’s data binding. So this is an
Angular application. I have my web component here. And I’m binding the heading
property to this attribute here. And you can see the
Angular version also has this same attribute. So now these two are
linked via data binding. And so this is
outside of Polymer. It’s two frameworks sort
of working together. And you can see
when I update this, both those headings are updated. And that’s really the
core concept here, is that everything is DOM. And because everything
is an element, it just feels like native HTML. Nothing has changed. Shadow DOM also has the
ability to do scoped styling. Really, really awesome
feature of Shadow DOM. So styles don’t creep
into your element, styles don’t bleed out. Anything you define in it
will just sort of be there. The two properties
that Shadow DOM has for this,
apply-author-styles and reset-style-inheritance, are
also first class citizens. You just define them on your
Polymer element definition. And then that’s how
you control the look and feel of your component. The last piece that we have
first class support for is HTML imports. And they’re really,
really simple to use. You just declare a
link rel=”import” and reference an HTML file. But this becomes
really powerful when, say, I create a new
component, and I want to reuse someone
else’s toolbar. I really am a fan of
somebody else’s toolbar. I really like their
menu item tag. I can use two imports to bring
those into my application. And then define a new element. Define an awesome menu element,
and reuse those toolbar menu items inside
of my own element. And then package this
up using an import, put it up on a URL someplace. And people can then
bring this whole package into their application. So they can then use
my awesome menu tag just by referencing my resource. This is really, really
cool, because you can imagine a
world– or something like Twitter Bootstrap–
exist as a web component. And so you get all the
CSS, all the JavaScript, and all of the HTML as
one relocatable resource. That’s something new that
the web hasn’t had before. So Polymer is many things. This is, again, our
architecture stack based on the foundation that
the course of specifications– the sugaring layer, the
elements that we’re building. The little guy on the
top is the blue part. That’s the apps
that you’re going to build on top Web Components
using the entire stack, or just pieces of the stack–
whatever you want to do. I encourage you guys to
absolutely go and check out our website, It’s actually a shining example
of using Web Components. We’re sort of dogfooding Web
Components all over the place. Our build page, in particular,
has these little widgets on it. These are just Polymer
elements, Web Components. So you can see that this
uses the polymer-ajax element to query a resource and get the
data back, if tests are passing or not. Looks like we’re doing
pretty well today. And it’s also got
more information on the elements and
the core technologies. If you want to learn more
about that red layer– the platform layer
that’s being added to all the modern
browsers– I encourage you to check out my
presentation at Google I/O, Again, the HTML5
Rocks articles are absolutely amazing and
very, very detailed. So if you really want to get
down and dirty with this stuff, go check out these resources. Lastly, I’ll leave you of
why you should be excited, and why I’m excited
for this stuff. As a web developer,
my productivity has actually skyrocketed
building stuff off Web Components. Again, I can create a component
and reuse that everywhere. It’s DOM, it’s
JavaScript, and it’s CSS. You saw the tab example
before with the jQuery version and the Ember version
and the Angular version. They’re all different. What if they all built
their tab components off of Web Components,
and the APIs were very easy and intuitive to use? You can say what you mean again. Somebody else can
read my markup, that’s just a bunch of custom
elements, and really understand what’s going
on in the web application that I’m creating. Re-usability. Don’t reinvent the wheel. Interact with other frameworks. You saw the example with Angular
talking to a web component. And the last one is
good software practices. Good paradigms
that we’ve used all over the place in
other languages, bringing those to the web. So thanks to Shadow
DOM, we have things like object-oriented
programming to some extent. We have encapsulation
to some extent. And that stuff that hasn’t
been able to be achieved before outside of the
world of Web Components. So with that, I really
appreciate you guys’ time. Thank you for listening to
me ramble to you up here. Hopefully I didn’t
speak too fast. I will put these slides
up on a URL some place. Feel free to follow me
on Google+ or Twitter. And I will post the links there,
along with the demos and stuff that you saw today. So I’m happy to take
questions now or later. Thank you for your time. [APPLAUSE] ERIC BIDELMAN: Are you
guys all just blown away? Yeah, question. AUDIENCE: Yeah. I thank you for a very
good presentation. ERIC BIDELMAN: Thank you. AUDIENCE: So my question is that
one of the issues for Polymer could be a deployment
of all our browsers. So could you share
current status of that? ERIC BIDELMAN: Sure. Whoa, I just totally slid out. As I mentioned before, actually
one explicit goal of Polymer is to support the latest version
of every modern, evergreen browser, which means
the browsers that update themselves. And one reason we really
wanted to focus on this is one, for technical reasons. It’s very hard to
polyfill certain APIs in libraries that don’t support
certain JavaScript features. Because ultimately,
everything that this sits on is enabled through polyfill
libraries in JavaScript until the browsers
have these modern APIs, so you can get rid of
that red layer completely. And the other reason
is that we want to stay up to date
with the web platform. So as things like web animations
get added to the web platform as the native API, we want to
use that right away in Polymer to do really cool, slick
animations for our elements. Things like pointer events,
when those are native. Some of this stuff
is never going to come to older web browsers. So it’s going to be very hard
for us to sort of envision and show developers really
the true path forward. Having said that, we
have pretty good support across the board for
the different browsers. And mobile is also
pretty well supported. but super old browsers,
unfortunately, it’s very, very challenging. Question, yes? AUDIENCE: Yeah, I’m
wondering what’s the performance implementation
of Web Components? I think that you should
indicate using the [INAUDIBLE]. The other thing, the
other [INAUDIBLE] kind of a browser itself. And I’m wondering, where
are the [INAUDIBLE] using a component should
be in this catalog. ERIC BIDELMAN: Yeah. That’s a really good question. And I’ll just repeat it for
anybody that didn’t hear it. The question was, what’s the
performance characteristic of Web Components compared
to other sort of libraries and frameworks, essentially. So one thing about
this is right now, if you use Polymer in a
browser that doesn’t support the native APIs, you’re
going to be using libraries. You are going to be using
JavaScript libraries. One reason frameworks
exist today is to help developers
build web applications. And they’ve gone through
sort of great lengths to implement their widgets,
their libraries, their core APIs because the primitives–
these fundamental technologies of the platform– Shadow
DOM, custom elements– haven’t existed. Now I can imagine– and really
hope– we get to a point someday where every framework
uses a lot of these platform capabilities. So the whole web gets
faster because everybody’s using the raw APIs
added to the browser. Excuse me. Right now in Polymer,
you get libraries. But in browsers that
support these APIs natively, things are much, much better. You can use the
native platform APIs. So it’s part of the browser. It’s part of your stack. And so that’s really the
cool part about this, is that if you choose to buy
into Web Components today, that extra layer of
library sort of goes away. And so things just automatically
work and get faster. Performance in general is, I
think, a very challenging topic because it covers many,
many different facets. So I think you’ll hear some
really awesome presentations today in everything from
rendering to network to browser and JavaScript performance. Yes? AUDIENCE: I see that
you’re [? about ?] there. How far can you go
[INAUDIBLE] Internet Explorer? ERIC BIDELMAN: Yeah. This table is not
even that up to date. Internet Explorer
10 is the browser we’re choosing to support
because it has some of the JavaScript
APIs that allow us to polyfill Shadow DOM. Having said that, it doesn’t
have mutation observers, which I think is why this
has a limited usable. So IE 11 just came out,
which has mutation observers, even though they’re
a little bit flaky. So that is going to be really
the true version of IE that is going to support a
lot of this native stuff. Any other questions? Yes. AUDIENCE: [INAUDIBLE] of when
you [INAUDIBLE] You [INAUDIBLE] may or may not want the
users of the new element to [INAUDIBLE] inside
the element [INAUDIBLE]. And [? altogether ?] that the
user of the element, if they want to change
something, or they want to find a variant of
the element by, for example, [INAUDIBLE] the custom element. Do you have any control
over [INAUDIBLE] elements? ERIC BIDELMAN: Yeah. So the question was,
how much flexibility do you have controlling–
when you use somebody else’s component on your page, can
you customize it yourself? Can you drill into it and
maybe tweak it a little bit? And then also, maybe as
a component author, can I do things sort of
outside of my box? And the answer is yes. So this is the web platform. You can do anything you want. It’s JavaScript,
you can do anything you want to [? limited
?] capabilities. And that’s part of what
Shadow DOM gives us, is it raises the bar to be
able to drill down into things. It gives us things like DOM
encapsulation and styling encapsulation. But in JavaScript, I can
totally, as another developer, drill down into
someone’s Shadow DOM and maybe tweak
things if I want. And that’s just sort of
a fundamental way the web and JavaScript works, You could also say as
an element consumer, if I’m using somebody
else’s tab strip widget. I can choose to bring that into
my app, and then extend that. If I don’t like
the way it looks, if I don’t like
its APIs, if I want to add new and additional
APIs on top of that element, I can choose to extend
that element using Web Components and
the extends attribute. And then give it
a different look and feel, or flare it
up with some extra APIs. So the APIs in general
are there to help you do things like that. But they also allow you to sort
of have this encapsulate world as well. So there’s some guarantee
that your component remains a component how
you intended it to be. That’s a good question. Cool. So I think we’re out of time. Feel free to come and
ask me questions any time throughout the day. Thank you. [APPLAUSE]

17 thoughts on “Building modern apps with Polymer & Web Components

  1. Love this. Polymer is the future, and the future is now. Combined with Dart, it brings a whole new meaning to web development.

  2. Wow this was a wonderful talk,I actually came away knowing a ton of things I can start using now 🙂 that's always awesome, your talk is like your code, concise 🙂

  3. Great presentation. Can anyone help me to get started with that? I have already played with iron ajax to create a list and its really simple and fast… but i really cannot understand how i can do, that clicking on menu will call website content using ajax and will place it into element that holds the content. (i am using starter kit) Like polymer-project/../docs/.. when menu element is clicked, then a ajax request is done to get the content. in quickstart all the subpages (home, users, contact, ..) is already inside index.html its like a show hide the content. I cannot find any resource or samples of applications / websites like this. Since i want to build "app" that is more website than app, then placing registration, rating, categories, dashboard,…. into one html looks to be crazy (i forgot that when i created page "offers" and called them with ajax, it loaded them on document redy and not when menu were clicked, whitch is not option in my case)
    Thank you

Leave a Reply

Your email address will not be published. Required fields are marked *