Web Components and the Polymer Project: Polymer 3.0 and beyond (Google I/O ’18)
Articles Blog

Web Components and the Polymer Project: Polymer 3.0 and beyond (Google I/O ’18)

August 15, 2019


[MUSIC PLAYING] KEVIN SCHAAF: All right. Hello, everyone. Thank you for coming out. We have a jam-packed talk for
you, so let’s get started. My name is Kevin Schaaf. STEVE ORVELL: And
I’m Steve Orvell. KEVIN SCHAAF: And we’re
both the lead engineers on the Polymer library. And we also do a lot of
coordinating and planning on the project as a
whole, so the two of us spend a lot of time together. STEVE ORVELL: Yeah, in
fact we work so closely together that instead of
calling us Steve and Kevin, some people just
call us “Stevin.” KEVIN SCHAAF: Yeah, we’re kind
of interchangeable like that. Although, Steve is the one
who talks like way too much and uses all kinds
of crazy analogies that don’t make any sense,
goes on and on and on. STEVE ORVELL: Yeah,
well, this guy, he doesn’t even like
science fiction. So it’s impossible to find
an analogy that he even understands. KEVIN SCHAAF: All
right, all right. Well today, in this
talk, we’re going to go through where we’re
at with web components and the Polymer library. STEVE ORVELL: And
then, we’re going to cover where we’re taking the
Polymer Project in the future. KEVIN SCHAAF: And
then, finally, we’re going to talk about where we’re
going to help evolve the web platform forward to make it
even better for us developers. STEVE ORVELL: All right,
so let’s talk a bit about web components
and Polymer. The Polymer Project
started as an experiment to embed web developers
right inside the Chrome team. And the goal was to
tighten the feedback loop between developers building
on the web and engineers implementing the browsers. KEVIN SCHAAF: So the
experiment turned into a full-fledged
project focused on identifying developer
needs and participating in the standards process
to address those needs and bring them to the browser. We also produced
polyfills and libraries to encourage the use of
these new features, all with the goal of driving
the web platform forward, to make it more capable
for us developers so that we can all
deliver better experiences to our users. STEVE ORVELL: This all started
almost six years ago now when Alex Komorowske and
Dimitri Glaskov got up here at Google I/O in
2012, and they talked about how web development at
that time was really difficult. It was overwhelming how much
developers had to work around the limitations in the platform
and write a lot of code for really basic concepts, like
breaking down your application into components. KEVIN SCHAAF: They
did this whole schtick about how they were these
engineers coming back from the future. And they were coming
back to report that all these
problems were solved and that the web
platform had become a really awesome capable
platform for building applications. They told us about these new
things called web components, native web platform APIs to
help us create components for structuring our applications
and building reusable widgets. And the components
were built on a handful of new features in the browser. STEVE ORVELL: The
first feature they told us about was
custom elements, which let us extend HTML and
make our own elements work the same way that the
browser’s built-in ones do, like inputs and buttons. And this meant
custom elements would work anywhere the web
works, regardless of how you’re building your app. KEVIN SCHAAF: Next, Shadow
DOM let custom elements hide their rendering so
that you could create complex UI in a component
that was fully encapsulated, including its styling,
so you no longer had to contend with
this global soup of CSS and come up with
conventions on your team to avoid stomping on
each other’s selectors, that sort of thing. STEVE ORVELL: And last,
they proposed a new way to load those custom element
definitions called html imports and the rendering
for your component would just be described
declaratively in html email and then loaded and parsed
natively by the browser. KEVIN SCHAAF: Dimitri and Alex
put all these things together into this awesome story about an
amazing future, where you could mix and match components
from different authors on the same page. And this was because the
rules for coordination were no longer convention
that everyone had to agree on. They were built
into the browser. STEVE ORVELL: And that
would allow an ecosystem of interoperable
widget libraries, meaning everyone could stop
reinventing that same date picker component
over and over again. And since web components
were built on top of html, we got a declarative format for
describing components for free. KEVIN SCHAAF: Yeah, that sounded
like a really awesome future six years ago when
they told us about it. So what’s happened since then? STEVE ORVELL: Well, it’s
been a bit of a long road, but web components
became a real thing. And frankly, most of what they
predicted actually became true. The vast majority of web users
have native web components running on their
devices right now. KEVIN SCHAAF: Every
one of you has a phone that runs native
web components, it’s true. STEVE ORVELL: Yup. There’s a thriving
ecosystem of components on webcomponents.org. And most JavaScript
frameworks today work great with web
components, as you can see on custom
elements everywhere, a site that tracks framework
compatibility with custom elements. So the promise of one component
model that works everywhere really has come true. KEVIN SCHAAF: And of
course, lots of developers are already reaping
all of the benefits that Dimitri and
Alex talked about. There is a lot of big sites
right here within Google that are all in
on web components. STEVE ORVELL: And
some companies, like Electronic Arts,
Coca-Cola, and USA Today are using components to ship
really great experiences. And those Google companies, you
better tell us what those are. KEVIN SCHAAF: Right, so YouTube,
Chrome, and Google Earth are all all-in on
web components. So all of these brands and sites
have invested in web components to help them reach users on
every corner of the earth. And that’s the amazing
thing about the web. It’s what gets Steve and I
out of bed in the morning, is the fact that it’s this
one platform that reaches every user on the earth. So a ton of people are
using web components, and that future that Dimitri and
Alex talked about back in 2012 really has come true. STEVE ORVELL: OK,
but really, has it? I mean, while it is true
that a ton of people are using web components,
not everyone is. And if they’re truly as
revolutionary as they seem, why isn’t like absolutely
everyone using them, like every single web site? KEVIN SCHAAF: OK,
so to explain that, let’s pause for a second to
talk about this concept we have on the Polymer team
called a weirdness budget. STEVE ORVELL: Right. So when you’re
learning something new, there’s really only so many
kind of weird new concepts you can deal with at one time. If there’s too many
things that really aren’t compatible with
your way of thinking or the way you’re
doing something, it starts to feel kind of
unwieldy and confusing, and you’re likely to just
punt on the whole idea. KEVIN SCHAAF: So take the
electric car for an example. So the novel, new thing
about the electric car is that you never need
to go to the gas station. You just have to
learn one new thing. You have to learn to
plug it in at night. That’s it. But in addition to
that, say the car had a bunch of other
weird things about it, like only three wheels and funky
doors and, like, only one seat. The novel benefit
of not needing gas would be lost because of all
the other weird things about it. STEVE ORVELL: Yeah. I’m not sure I’d buy that car. And sometimes that’s how we feel
it’s been with Polymer and Web Components. While that original
novel feature, that single standard
interoperable component model has been really compelling,
and a ton of developers have been really
successful using it, we think Web Components
have been held back from their full potential,
because, for some people at least, they’ve exceeded
that weirdness budget a bit. KEVIN SCHAAF: So first and
foremost were the polyfills. At the beginning,
you needed polyfills to do anything with Web
Components on every browser, and not just one polyfill,
but a bunch of them, one for each big feature
of Web Components. STEVE ORVELL: Yeah, and
these weren’t simple polyfills either. Some pretty fundamentally
changed how the browser worked. KEVIN SCHAAF: So having
to load polyfills just to do anything
kind of felt weird. STEVE ORVELL: Yeah, and early
on, using Polymer at least felt like the only way
to build Web Components. And this was because those
polyfills were pretty tightly coupled to Polymer. And that made it feel like
using Web Components was just like siloing yourself
in another framework. KEVIN SCHAAF: Right. And the entire purpose
the Web Components was to break down
these silos so that you didn’t have to be
stuck in a silo when you chose a framework. STEVE ORVELL: Right
so being forced to, or feeling like you
were forced to, use a library like Polymer just to
use Web Components also kind of felt weird. KEVIN SCHAAF: And then, when we
started out on Web Components, a package manager called
Bower was popular at the time and seemed like a natural
fit for distributing client-side code,
like Web Components. STEVE ORVELL: Right, right. But in the meantime,
NPM has really become the de facto
standard way to distribute JavaScript for both
client and server code. And having you get your
dependencies out of Bower became kind of a drag. KEVIN SCHAAF: Yeah, so having to
deal with two package managers, NPM and Bower, just also
felt weird for developers. STEVE ORVELL: And then
there is HTML Imports. So it was a really good idea,
but it never really panned out standards-wise. This is how those guys from
the future envisioned we’d all load our Web Components,
with a platform-based loader for HTML, JavaScript, and CSS. KEVIN SCHAAF: But then once
JavaScript modules started becoming popular,
it became clear that we couldn’t have
two different loaders in the browser, one for
HTML, one for JavaScript. And so over time, the HTML
Import spec was abandoned. And because of that, all of the
standard tools that we all use, like bundlers and
transpilers and editors, they never really adapted to
dealing with HTML Imports. STEVE ORVELL: Right. So over time, at least,
using HTML imports also started to feel weird. KEVIN SCHAAF: So
while Web Components have been objectively
successful, there have been some legitimate
reasons for developers to hold off using them. And that’s been a big
focus of the Polymer team over the last
couple of years, to eliminate the weirdness
around Web Components so that every web
application can start taking advantage of
this standard interoperable component model. STEVE ORVELL: Right. So first let’s take a
look at the polyfills. Now, the great news
here is that you almost don’t need them at all today. Last year, both
Chrome and Safari shipped a standard version of
custom elements in Shadow DOM. And now, Firefox has
implementations behind a flag and will ship pretty soon. So you need zero polyfills
for both Chrome and Safari and, soon, Firefox. And for older browsers
or other ones, the polyfills now
use feature detection to load just what’s needed. KEVIN SCHAAF: And
then the other thing is that as of Polymer 2.0
release at last year’s Google I/O, the polyfills
are now totally separate from Polymer
and work transparently behind the scenes. So now, Polymer is just
an implementation detail of your Web Component. Users of your component
use it just like they would any other HTML
element and don’t need to know anything
about Polymer, the way it was kind of
always supposed to be. And today, Web Components are
made not just with Polymer. You can make web components
with libraries like Angular and Ionic and Glimmer. And all of those components
can work on the same page through the power of that
interoperable component model. STEVE ORVELL: So we’ve
come a pretty long way towards reducing that weirdness
around using Web Components. But there’s still
these two other things that have made Web
Components built with Polymer feel kind of weird. And that’s been the focus of our
team for around the past year. KEVIN SCHAAF: All
right, and today, we’re excited to announce
the release of Polymer 3.0. [APPLAUSE] STEVE ORVELL: With
Polymer 3.0, we’re building Web Components
built with Polymer into the mainstream. Now, our boss, Matt, who’s right
there, he really likes flames. He insists on putting them
in every presentation. So we slipped them
in right there. KEVIN SCHAAF: Did you like
the flamey Web Components? OK. STEVE ORVELL: OK. KEVIN SCHAAF: All right. STEVE ORVELL: Good. KEVIN SCHAAF: So the first
big change in Polymer 3.0 is that the Polymer library and
all of the elements we produce are now being published on NPM. So this means you’ll
just NPM-install them, like you do any other
dependency in your project, no more contending with a
different package manager just to use Polymer in
Web Components. STEVE ORVELL: Next, we’re
moving from HTML Imports to JavaScript modules. And this is going to match
how the mainstream of code is being written today
in the community. But we’re not just
authoring in modules. We’re also publishing
our packages to NPM as JavaScript modules. KEVIN SCHAAF: And this is
because as of today’s release of Firefox’s 60– we just tested it this morning– the current version
of every major browser natively supports loading
JavaScript modules in the browser,
all four of them. So native modules let you run
the code that you write exactly as you wrote it with no bundling
or transpiling or source maps needed during development,
which is a awesome productivity boost during
development, to just be able to load and refresh
your code in the browser. STEVE ORVELL: Yeah,
it’s totally awesome. But there’s just
one thing we need to do to make this
possible, and that’s to convert the module
specifiers we use to URLs. Because the browsers really
only to understand URLs. And the convention in NPM and
really the entire JavaScript ecosystem is to load
dependencies by package name, not by URL. And Polymer is going to
follow this convention. We’re not going
to be weird there. So to make those important
loadable in the browser, we need to transform those
module specifiers to URLs. KEVIN SCHAAF: OK, so
how do we do this? Well, we’ve updated
the Polymer CLI tools to do just that simple
transformation on your source code on the fly, from module
specifiers using package names to URLs. So let’s take a look
at this in action. So here, we’re loading
our shop demo app using the Polymer depth server. So during development, you’re
loading the exact same code that you wrote in your editor– all the same files right here,
no bundling during development. The only change
is that the server converts module specifiers
from package names to URLs. So you see that, the
just top couple of lines there, those are
converted on the fly to URLs, which makes the
debugging experience great. You can just edit
it and refresh. That breakpoint right there
is on the exact same line as it would be in our editor. So Polymer still ships
with this great edit refresh development experience
right out of the box. STEVE ORVELL: Right. Now for those of you who
really like developing in HTML, stay tuned, because
we’re going to have more to say on that
later in the talk. But the other benefit of this
change, moving from HTML ports to JavaScript modules, is
that code built with Polymer also just fits right into
the other popular tools in the community, tools
that understand modules, like TypeScript and
Webpack and Rollup. And of course, you can continue
to use the Polymer CLI. You can choose
whatever tool works best for you and your team. KEVIN SCHAAF: So in
Polymer 3.0, we’ve held the API stable and only
focus on this format change, from HTML imports in Bower
to JavaScript modules in NPM. So Polymer 3.0 has all the
same stuff as Polymer 2.0, just in a slightly
different form. So let’s take a look at what
this change practically means. Up until now in Polymer, we
defined single-file components using HTML. So first, you’d import
dependencies, like the Polymer base class here. So we’re using an HTML
import, a link rel import tag to import that. And then, you’d use
a DOM module element to associate your template’s
class with– for your custom element with the template. And then, you’d
register the element with the browser using
the native custom elements register– or custom
elements-defined API. So this is what kind of a
typical single-file component looked like in Polymer
2.0 all in HTML. STEVE ORVELL: And
in Polymer 3.0, we’re defining
single-file components using JavaScript
instead of HTML. So to do that, you first
just make a standard module. You import your
dependencies directly from NPM using the browser’s
native import syntax. Define your class. That part’s the same. But then, here’s a change. You implement a getter that
returns your HTML template. And the change here is that you
use this HTML function provided by Polymer to convert the
string into the element that Polymer expects. Otherwise, the syntax
hasn’t changed. And we use the same
platform API customElements define that we did before. And that’s really
all there is to it. Pretty standard,
nothing weird here. KEVIN SCHAAF: All right, so this
may sound like a big change. But providing our users
a smooth migration path between major
versions has always been a really strong focus
on the Polymer Project. And so again, I just want to
reiterate with Polymer 3.0, we’ve held the API stable
and only focus on this format change, from HTML
Imports in Bower to JavaScript modules in NPM. STEVE ORVELL: Yeah, and to help
users migrate their existing code, we’re providing a tool
called the Polymer modulizer. It converts all imports
to JavaScript modules automatically and also
generates the package JSON you need to install dependencies
from NPM based on what you were previously using in Bower. KEVIN SCHAAF: OK. So that sounds like a tall
order, an automatic migration between two versions. So next, let’s take a look
at the modulizer in action by going to our shop
demo application that was written in HTML Imports
and convert that to modules. So this is the shop
demo application. I’m going to reload it
here in the browser. You can see in the
dev tools, we’re loading all of our components
there using HTML Imports. STEVE ORVELL: That’s
the 2.0 version. KEVIN SCHAAF: Right. So if we pull up the shop
app, the main component for the application
in our editor, you can see all the
dependencies are being imported using HTML imports. The template is right
there in the HTML. And then, you can see that
the class is extending from the Polymer element base
class that’s pulled directly off of the global. Because with HTML Imports,
we didn’t have any scoping. Everything had to
go under the global. So now if we run the
modulizer command on our app, that’s going to go through,
convert all of those HTML files, read those
in, output JavaScript modules in their place. So here, we can open that
same shop app component. You can see all the imports are
now JavaScript module imports. And the base class is being
imported from the module that provides it. We’re defining our
class the same way. And then, here is that– the template being encoded
right there in JavaScript using the HTML function. As Steve said,
the modulizer also generates your
package JSON based on all the dependencies you
were previously using in Bower. So we can just go
to the console here, NPM install, our new
NPM-based application, run the dev server. Now, we switch back
to the browser. I’m going to hit
Refresh right here. You’ll see that, automatically,
all of these modules have been converted. We’re now loading them
using the native module loader in the browser. And everything basically works. There may be a few things
that the modulizer doesn’t automatically convert still that
you might have to hand-tweak. But as you can see, the
majority of the migration work is automated. [APPLAUSE] STEVE ORVELL: Yeah, so
that’s a pretty awesome tool. And we want to thank all
of the users and companies in the community that
helped us make that happen. And especially, we want to
give a big shout-out to Vaadin that helped us a lot. They have a widget set based
using web components that’s really great. You should definitely
check that out. So modulizer is
available today on NPM. It’s still in pretty
active development. It already automates most
everything, as you just saw, but there are a few
things you need to do. You should definitely
check it out, and we’d love your feedback. KEVIN SCHAAF: And finally,
along with this change, we made sure that
webcomponents.org, the one-stop shop for the
ecosystem of reusable web components, is being updated
to host elements distributed via NPM. It was previously Bower. And we’re encouraging the entire
community of Web Component developers to go
through this migration to get them onto
Bower and modules, the same as the rest
of the community, and get them published on
webcomponents.org as well. STEVE ORVELL: So in
this latest release, we really feel like we’re
removing all of the weirdness around using Polymer
and Web Components. Using Polymer 3.0, you
can build and distribute web components that
are truly mainstream. KEVIN SCHAAF: And when you’re
building a web application, using a web component
is just like you would any other dependency. It will fit seamlessly
into your workflow. STEVE ORVELL: Polymer 3.0 and
most of the custom elements that the Polymer team maintains
are available today on NPM. Install them just like
any other NPM dependency, and you’ll be off to the races. KEVIN SCHAAF: All
right, so that’s where we’re at with web
components and Polymer today. And that future that Dimitri and
Alex talked about back in 2012 really is coming true. So where does that put us
today with the Polymer Project? Where do we go from here? STEVE ORVELL: Well, since
we’re holding the API stable in Polymer 3.0, as we said,
that release is really mostly about getting our existing users
kind of into the mainstream. But we’ve always
really wanted Polymer to be just a really
thin sprinkling of sugar over the native platform APIs. And having completed
all that work, we’re really returning
to that core vision. So we’ve been working on a
whole new generation of products that are thinner and lighter
and more loosely coupled. And we see these as the
future of the Polymer Project. So let’s take a look at
what we’ve been working on. KEVIN SCHAAF: All right, so
the first thing that we did is take a hard look at
improving the base class that we use to make Web Components. So the rendering and
data binding parts of Polymer’s base
class have really been unchanged since the
1.0 release of years ago. And since then, we’ve had a lot
of ideas kind of stacking up on how to make it smaller and
use more platform features and focus on how developers are
actually building applications today. STEVE ORVELL: So to do
this, we separated out kind of the lowest part of the
smallest part of the Polymer library. It’s a roughly
two-kilobyte layer that lets you declare an
element’s property API and keep it in sync
with its attributes and react to changes. And we really see this
as a common substrate that any element needs,
regardless of what rendering model is being used. KEVIN SCHAAF: And then, in place
of Polymer’s legacy template and data mining
system, we layered on a new library called lit-html
that we’ve been developing over the past year or so. lit-html a lightweight
rendering library based on JavaScript string
literals and the platform’s template elements. So we took those two platform
features and kind of smooshed them together into
this rendering library. It’s less than three
kilobytes today. But because it’s based on new
and some upcoming standards that we’re going to
talk about, even that can mostly melt
away in the future. STEVE ORVELL: We’re calling
this new base class LitElement. So let’s take a look
at it in action. So we start by just making a
standard JavaScript module. We import LitElement
there from NPM using– and its HTML tag. Then, we use our
standard pattern. We make a class that
extends LitElement. We declare our
element’s property API. Here, we’re declaring a first,
last, and type properties. Users can set those either
as attributes in HTML or as properties in JavaScript. KEVIN SCHAAF: This is pretty
similar to a Polymer element so far. STEVE ORVELL: Yeah. Yeah. Yeah. Then, we use their
render method. And this is where LitElement
makes use of lit-html and its HTML malfunction. It takes a string containing
static HTML and embedded JavaScript
expressions describing where the dynamic
value should be set. Behind the scenes, it’s
converted to a template element with some information about
where those dynamic spots are. LitElement renders this content
to the element’s Shadow DOM. And then, that render
method is actually called whenever any of the
elements’ properties change. And lit-html, behind
the scene, keeps things fast by ensuring that
the static content is rendered only once and that
the dynamic parts are updated just as needed. Finally, we call custom
elements defined, just like we always do, and
that’s all there is to it. KEVIN SCHAAF: So you may notice
that this LitElement uses the functional reactive
pattern that was popularized by React and JSX. But since we’re writing
standard JavaScript here, the issue malfunction
is a standard part of– we’re using tagged
template literals which is a standard
part of the platform. So we have the full
power of the language, but we don’t have
to compile the code to make it work in the browser. STEVE ORVELL: Right. And we see LitElement as a
lightweight next-generation replacement for Polymer
3.0’s Polymer element. It’s just about five kilobytes. That’s around a third the size. But it has just what you
need for making elements that leverage
unidirectional data flow. KEVIN SCHAAF: And because
they’re web components, you can, of course,
mix and match elements made with LitElement
with elements you made with Polymer 3.0
or any other Web Components. STEVE ORVELL: All right,
both lit-html and LitElement are available today on NPM,
and you can start using them. KEVIN SCHAAF: OK,
so with LitElement, we have a solid new base class
for building custom elements and apps out of components. But when you’re building
a web application, you don’t have to build all
the components yourself, right, Steve? STEVE ORVELL: No, that
would be kind of crazy. So that brings us to our next
product, a new element set. So from the earliest days
of the Polymer Project, we’ve always provided
a high quality library of UI components to
help you get started building rich user interfaces
out of Web Components. KEVIN SCHAAF: And
yesterday, Google announced a new iteration
of material design here at I/O. It is
focused on themability, and our team is making a new
set of elements expressing this new design language
called Material Web Components. These elements will be replacing
the Polymer team’s paper elements, which are based on an
older version of the material design. STEVE ORVELL: Yeah. And for this new
element set, we’ve teamed up with the material
design engineering team here at Google that’s
in charge of supporting all of the platforms
that Google builds for. And this is going to ensure that
the new set is automatically kept in sync with the latest
material design guidelines. KEVIN SCHAAF: So the new set it
actually built using LitElement that we just talked about. But again, that’s just
a implementation detail under the scenes. From the user’s point of view,
it’s just a Web Component. STEVE ORVELL: All right, we have
a preview of the material web components available
on GitHub today. Some of them are
published now to NPM, but they’re our
work in progress. And we hope to iterate
quickly and have them all ready very soon. KEVIN SCHAAF: OK, so we
have a solid new base class with LitElement and a new
element set with material Web Components. The last product ties
all of these things together into the end-to-end
app-building experience. And today, we’re announcing
a new PWA starter kit. STEVE ORVELL: It
has everything you need to build scalable,
high-performance, progressive web apps right out
of the box, using all of this platform features. KEVIN SCHAAF: So
of course, we’re using Web Components
for factoring the UI, and again, those are built using
LitElement, our new base class, uses service worker
for offline storage. It uses the PRPL
pattern for efficiently serving your application. And we’re integrating Redux
for top-down scalable state management. STEVE ORVELL: The kit comes
with several different starter templates and has tons of
documentation for ramping up. There’s zero config commands
for building, unit testing, screenshot testing,
and deploying. All that’s included. KEVIN SCHAAF: So you can get
going with the PWA starter kit by cloning that GitHub repo. And there’s a whole wiki in
there that tells you how to get started. But also, Monica
Dinculescu from our team is going to be giving a
whole talk on that coming up in just an hour after this
talk, at 3:30 on stage three, so you should definitely
go check that out. STEVE ORVELL: Yeah, you should
definitely check that out. KEVIN SCHAAF: She’s
an amazing speaker. OK. STEVE ORVELL: All
right, so to recap– we went over a lot
pretty fast there. Polymer 3.0 is bringing
the Polymer Web Components ecosystem into the mainstream. KEVIN SCHAAF: And with
LitElement, Material Web Components, and PWA starter
kit, building web applications with Web Components
is easier than ever. STEVE ORVELL: OK, but remember,
the Polymer Project’s mission is not just to build tools
on top of the platform but also to evolve
the platform, to make it more capable and
ergonomic and help people solve real-world problems. KEVIN SCHAAF: OK, so we have
14 minutes and 37 seconds. We’re going to finish up
with the lightning round through a bunch of
new platform API and features that
the Polymer team is helping shape and
providing feedback on in the standards process. OK, here we go. STEVE ORVELL: All
right, so first up we have CSS Shadow Parts. This is a proposal that
provides a first-class solution for theming web components. KEVIN SCHAAF: So we’ve talked
about how Shadow DOM provides styling encapsulation. It protects the inside and
outside of the Shadow DOM from being accidentally styled. STEVE ORVELL: However,
sometimes, you want to style elements
inside the Shadow DOM from the outside,
and the classic case is applying themes. For example, you
might want a button to have rounded
corners or an input to look special
when it’s focused. KEVIN SCHAAF: And while you’ve
previously been able to do this using CSS custom properties–
that’s kind of what we’ve done up until now– there wasn’t that way to style
any CSS property on an element in the ShadowRoot. You could only style
the one that you exposed to your custom property API. STEVE ORVELL: Right. And this is where CSS
shadow parts comes in. So it’s actually modeled on the
way the platform already works. Let’s take the native
input element, for example. It has a placeholder
attribute that shows a value when you
haven’t typed anything. It’s usually used to tell
the user what to type. KEVIN SCHAAF: So this
is a nice feature. But often, developers want to
be able to style the placeholder to make it match the
theme of their website. and what you may not know
is that the native input is actually implemented in
the browser using Shadow DOM. It has been for years. And the rendering
of the placeholder inside that element,
that rendering that says, “enter value,” that’s
actually just an element in the native
input’s Shadow DOM. And the platform exposes
a special colon, colon placeholder
pseudo-element in CSS that you can select on
the input to style it. We can make it
orange and centered. And we can do that
without the input having to leak other implementation
details of how it’s implemented. STEVE ORVELL: Aha. That’s the problem that
we’re trying to solve. We’re trying to theme custom
elements that use Shadow DOM So let’s say, for example,
you had a slider element called mySlider, and you want
to allow users to customize the way the thumb looks. That’s the thing you drag left
or right to set the value. KEVIN SCHAAF: So Shadow Parts
introduces a new part syntax in CSS that we can use to
select items in the ShadowRoot. So here, we can select colon,
colon part on the mySlider and pass the thumb as the thing
we want to select in there, and give it a custom style. So we could make
the thumb orange, if that’s our theme
for our website. And so this gives us the power
to define pseudo-elements for our own Web Components,
just like the native platform has always done for
its built-in elements. STEVE ORVELL: Right. And to do that, all the
developer of that mySlider element needs to do
to expose the thumb as a stylable pseudo-element
is to add a part attribute to the right– with the name
you want to that right DOM node in your ShadowRoot. And what’s great about
this is the developer decides exactly what styling is
encapsulated in the Shadow DOM and what’s themable
from the outside. KEVIN SCHAAF: So the
CSS working group has already agreed to
advance this syntax, and it’s being implemented
in Chrome right now. And we really think
that CSS shadow parts is going to unlock
generalized theming for Web Components that’s kind
of been missing up until now. STEVE ORVELL: Yeah. You can go check out
the draft spec here. And Monica wrote up a really
nice explainer on her blog that you can check
out there too. KEVIN SCHAAF: OK, so next
up is a big advancement for custom elements,
which is the ability to scope new HTML tag names to
a specific part of the page. So remember, custom
elements allows us to associate a custom
element class with a HTML tag name in the browser. STEVE ORVELL: Right. However, up until
now, custom elements were defined globally
for the entire page. Now in practice, really,
this has been mostly fine. But it can sometimes
be a problem. And to see how, let’s walk
through a little example real quick. So say you’re on a big team
building a big application, and you’re responsible
for the contact view. You see, you find a
fancy button component you think would be great. You put it in right there. KEVIN SCHAAF: So let’s say
that I’m on a different team, and I’m responsible
for the detail view. And my team finds a
different fancy button that looks awesome. And I want to use
it in my component. And both of these components
need to work in the same page. So since the fancy
button tag name can only be associated
with one class– right now in custom
elements– the browser won’t actually let you
define two elements with the same name. So both teams would
have to cooperate on picking the same fancy
button or name it differently or something like that right. STEVE ORVELL: Right. So let’s take a look at how
custom element registries will help us address that problem. So with the custom
element registries, you’ll just– you’ll import
the class that you want to use. And then, you’ll make a new
custom element registry. So previously, there were
just one of these globally. Then, you can define that
fancy dash button tag name just in this registry,
not the whole page. And then finally,
you’ll tell a ShadowRoot to use just this registry
for its scoped tree. So this way, the Contact
View and the Detail View could each have
their own registry allowing you to use that
same fancy dash button name but with different
implementations on the same page. KEVIN SCHAAF: So we think
this addition is really going to help large
organizations managing a lot of complexity,
a lot of dependencies in their application,
adopt custom elements. The proposal got positive
feedback at a recent W3C meeting this year. And you can follow along
on this GitHub issue and provide feedback on
the issues linked here. And actually for all the
things we’re talking about, go check out the issues
and comment on them and give them your use
cases and feedback. That’d be great. So with CSS shadow parts and
custom element registries, a couple of
longstanding pain points are going to be
addressed really nicely, making web components
easier to use. STEVE ORVELL: Yeah. Now next, we’ll look
at a couple of features that will enhance the way
that we load components in the browser. And first, we have a
new browser feature called Package Name Maps. And this will allow us to import
JavaScript modules by name in addition to by your URL. So as we mentioned
earlier, JavaScript modules can only really
be loaded by URLs, since browsers only really
understand URLs right now. But everyone uses package names. This provides a
lot of flexibility, like the ability for NPM
to put the package just where it needs to be on disk. And frankly, it’s
just more convenient. But again, it means that you
need some kind of tool today to make them loadable
in the browser. And wouldn’t it be great if
you didn’t have to do that? KEVIN SCHAAF: Right. That’s the one thing
that the Polymer tools during development
have to do is transform this. But that’s where Package
Name Maps comes in. So Package Name Maps
introduces a new JSON format that will be understood
by the browser that maps module package names
to URLs that the browser can load. And the idea is that this would
be generated by your package manager, like NPM
or your CDN that’s providing your modules, whatever
knows the location of all the modules. And you’ll just tell the browser
where to load your package map. It might be something like this. The syntax is still
kind of up in the air. But then, you’ll be able
to use package names in all of your source code
or your dependencies, and have them load natively in
the browser, just the way you would in node. STEVE ORVELL: So we’re
really excited about how this is going to remove the
need to use tooling to load your source in the browser. And we also see this as
a really big step forward for unifying the
entire JavaScript community, both front
end and server-side, where packages can work out
of the box in either context. There is an explainer for
the proposal here on GitHub. You can go check it out again. Please provide your feedback. That’s how this stuff gets done. KEVIN SCHAAF: So
the next thing we’re working on related to
loading is HTML modules. So as we mentioned
earlier, HTML Imports kind of failed to catch on,
mostly because they weren’t designed to coordinate with
the JavaScript module loader in the browser that started kind
of emerging at the same time and is actually now
shipped everywhere. STEVE ORVELL: Right. But a lot of our
users, they really like using HTML to
define components. And there’s pretty broad
agreement in the W3C that supporting HTML as a
way to define components is still a really good idea. So we’re helping to define
a proposal for HTML modules. Now, this is a way
to load HTML but with the standard
JavaScript module loader. The native module loader today
only understands JavaScript. But if HTML modules
are implemented, that same loader would just
load– be able to load HTML. And this really unlocks
a lot of possibilities. The HTML could bring in
the components template. And then, you could use
it in a script, please. Thank you. [GIGGLING] And that’d
be really easy. Use that template in your
component, just like that. Look a lot like HTML
Imports does today but, you know, natively
with the JavaScript module loader– with the
modulator loader, then. KEVIN SCHAAF: Yeah. All right, so with
HTML and modules, we’re really hopeful to get away
to write single-file components that leverages the
native parser, that keeps HTML JavaScript– or HTML
and CSS in their native format without needing to encode
them into JavaScript, which feels kind of weird today. The proposal is being discussed
on GitHub in this issue. We’re still working out
a lot of the details. But we’ve also created
an experimental tool that you can check out right
now to help refine the design. It lets you write all modules
in this specular format and then applies a [INAUDIBLE]
transform to convert them into JavaScript modules
that can be loaded natively in the browser. So if you’re interested
in this proposal or if you want to continue to
write your components using HTML, you should
definitely check that out. STEVE ORVELL: Cool. All right. So package name apps
and HTML modules are both going to make loading
components in the browser a lot more convenient. And that brings us to the
last new browser feature that we’ll discuss. And that’s HTML
template instantiation. It’s an extension to the
existing template element, but it adds API for updating
dynamic parts of the DOM. So here’s an example template
with some static elements. And you may not
actually know this, but cloning a template like
that is the fastest way to create a tree of DOM. It’s actually faster than
creating elements imperatively, like many libraries do. But in practice, of
course, real applications need to update that DOM as well. So in this case, we
probably wouldn’t put that name, Bob
Smith, statically in a template like
that, would we? KEVIN SCHAAF: Right. We’d probably fill that in
from a variable that’s loaded from a database or something. And we might need to update that
spot in the template later on. And really, there’s
been no way to do this built into the browser. In fact, a lot of
JavaScript libraries are focused on this one thing,
like creating a tree of Dom and then updating
it dynamically. So template instantiation
provides a way to tell the native
template element where the dynamic parts will be. So we’ll be able to create
what’s called a template part and attach it to a spot
in the template to tell it where it can be updated. And so right here, this is where
we wanted to update the name. And that’s the only part of
this template that needs to be– needs to be changed. Everything else is static. And we can tell the browser
about that ahead of time. And then, once we’ve created
parts in the template, there’s a new API
called create instance on the template element. And this’ll stamp a copy
of the template, all of that static content,
into a thing that looks very similar to a document
fragment that can be appended using the normal Dom APIs
But then, the cool thing is that the instance
also knows about where all the dynamic parts
are in that template without having to walk through. We can just call
getParts on the instance, and then, each part
has a set value API that we can call to
update that part of the DOM. And then finally,
you just call commit on the instance to apply a
batch of changes all at once. STEVE ORVELL: Cool. All right. This looks like a
pretty low level API, and it kind of seems
like it’s going to mostly be used in library code. But let’s take a
look at what users are going to gain from
adding this to the platform. So as we said earlier,
it builds on top of the existing
template element, which is already the fastest way to
create a static chunk of DOM. But by adding this
new part API, we think this will end
up being the fastest way to update Dom as well. And this is because
today, any library that deals with rendering has
to locate these dynamic spots in the DOM manually
each time you create an instance of the template. And if you’re using
a VDOM library, those have to walk
through what could be a pretty big
chunk of static nodes just to find what
needs updating. With Template
Instantiation’s getParts API, you can just ask the
browser for that list of spots that needs
updating, without needing the runtime overhead or the code
to walk and find those spots. KEVIN SCHAAF: So
another cool thing is that the API is proposed to
have batched updates built in. So logic to update
the dynamic parts of a template and a component
could be– potentially be spread across multiple
frames and committed in one batch, which
is really cool, because a lot of frameworks
are experimenting with this concept of
spreading work out across multiple frames. So this feature is
also being designed as low-level flexible
primitives that can be incorporated into as
many frameworks as possible. For example, we think this will
replace a large portion of what our new rendering library
lit-html implements, make that faster. But the Angular team has also
been involved in the feedback process for this spec and
is interested in using template instantiation as well. STEVE ORVELL: Last, while
the initial proposal for template instantiation
has an imperative API that we’ve seen,
it also paves the way for a future declarative
syntax for describing where those dynamic
parts are just directly in the template’s HTML. And that, together
with HTML modules, unlocks a potential
future where components could be defined
completely declaratively, which is pretty cool. So template
instantiation promises to make rendering Dom, a problem
that every framer contends with, faster, simpler,
and with way less code. It’s a really exciting
proposal started by Apple. It has strong support now from
all the major browser vendors. It’s still in very
active development. You can check out the
explanation there. And that issue there has some
of the latest discussion. KEVIN SCHAAF: All right,
so you guys still with us? All right, let’s recap. All of these features
that we talked about are going to help make
the browser way more capable and easier to use. So CSS shadow parts and
custom element registries are going to make those
features, Shadow DOM and custom elements, a lot more robust. Package name apps
and HTML modules let us load our source
code with fewer tools. HTML modules and
template instantiation unlock declarative
component authoring, and template instantiation
makes dynamic rendering way more [INAUDIBLE]. And if we take all of
these features together, that means that we can
rely more on the platform, more on the browser to get our
job done, and ship less code that has to run and be delivered
over the network to our users. STEVE ORVELL: All right,
so as you can see, we have a pretty exciting
next new round of features that will help evolve the
platform, make it better. All right, that’s it
for everything happening on the Polymer Project. So here the main takeaways, what
you should learn from today. KEVIN SCHAAF: All right,
so Web Components are now a standard part of
the web platform that you can use in any app
that you’re making today. So if you’re not using them or
you haven’t checked them out, now is the time. There’s no excuse. STEVE ORVELL: Polymer
3.0 is out today. It provides a really
smooth migration path for existing users to a more
modern development workflow, authoring in JavaScript
modules, and using NPM for your dependencies. KEVIN SCHAAF: The
Polymer Project is moving forward with a new
generation of products focused on improving the developer
experience of building web apps with LitElement,
Material Web Components. And the PWA starter kit. STEVE ORVELL: And as you’ve just
seen in that lightning round, we have a ton of
great new platform features on the horizon that
will make that experience even better. KEVIN SCHAAF: All right,
again, I’m Stevin Schaaf. STEVE ORVELL: And
I’m Stevin Orvell. KEVIN SCHAAF: All
right, thank you for– STEVE ORVELL: Thanks a lot. KEVIN SCHAAF: –listening. [APPLAUSE] [MUSIC PLAYING]

Only registered users can comment.

  1. Thank you polymer team you guys might have saved the industry with this one for real! I'm loving this!

  2. YESSSSSS!!! I feel like we are back to 2009 javascript is going to become simple again… no tooling!!!! ahhhh Jquery days…. so easy to just code without 4 hours of setting up webpack and thirty thousand other loaders

  3. Second breaking release in a shorter time. Same promises as always, I am sure things wont work. Have you documented testing the es6 way now?

  4. Why lit-HTML and not hyperHTML?
    https://gist.github.com/WebReflection/fadcc419f5ccaae92bc167d8ff5c611b

  5. Wow!! Huge congrats to both Stevins and surely also to all of the Polymer Team!!! Your greatness just comes through somehow. Thanks for 3.0 and all things to come, from all who use "the one platform that reaches every user on the Earth".. Thanks for making (technical) life so much easier and more enjoyable for all…
    Fantastic presentation!!! You guys just gel and flow very well. Keep up the great work!!!

  6. I really want to wait for the polyfills to become obsolete before working with web components.
    Working with web components with polyfills feels almost completely different from how it's going to work in browsers with native custom element and shadow dom implementations. You don't need to do all these ridiculous workarounds.
    Performance is going to be a lot better, too.

  7. 3 years passed, Chrome browser is only single browser that truly support shadow DOM v1.
    – Safari partially supported. But they are fixing the remainig bugs in their implementation.
    – Firefox is developing it.
    – Edge still has no plan.
    Shadow DOM spec still be a W3C draft not recommend standard.

  8. Yay for HTML Module, writing the template in js is really a pain point, let's hope it's going to be shipped soon

  9. Great news from Polymer. However, the recording of the presentation could be improved. Could you fullscreen the slides whenever Steve or Kevin are pointing out examples on the slides?

  10. Go HTML Modules ! Thank you Justin and all the polymer team for working hard over the years to make the web more awesome with open standards.

  11. Thanks so much Polymer.. Few years ago I was still not sure where I was going to lead my life and my career, I've always wanted to work for the web but now I can say how much Polymer helped me to take that decision to concrete when I first discovered that project, its strong meaning in improving technologies and the wonderful team that's behind the curtain. All these excitements was like a big revelation, and I just want to say thanks. Polymer 3.0 was more than expected. Now the big dream is to be able to use all that framework without the need to use a middleware server to transpile or to resolve npm modules. But yet now it really feels like coding inside the browser and the joy is real.

  12. Dear Google! Why do you keep showing presenters waving their hands for minutes, and then showing slides for seconds? I see their gestures look professional and I appreciate that, but can we read the slides, please?

  13. ok, you said it yourself: encoding templates in JS literals is 'kind of weird'. YES, while i see the need for moving along this consequence is a major step backwards. We urgently need HTML modules!

  14. Dart and POlymer were like bread and butter,too bad Google made the stupid decision of abandon Polymer.Dart,and Server sdie Dart.

  15. Polymer 3.0 changes everything… except subproperty changes are still not observable. notifyPath & notifySplices are so cumbersome!

  16. I really liked the presentation. It got me thinking it would be really cool if HTML imports and template instantiation could be declared together with some type of HTML statement. I think the GitHub issue already mentions the idea of a way to import HTML using a HTML tag. But what if you could also set the dynamic placeholders with attributes as well. For instance, some syntax like <link rel="template" type="text/HTML" firstName="Jane" lastName="Smith" />. I think it would be pretty powerful to be able to do all that without even needing JavaScript. What do yall think? Let me know if it had already been suggested.

  17. Web components are not available at webcomponents.org for Polymer 3.
    From where do we use components to design pages.?

  18. Ok I only watched it until 21min. I just can't anymore. This is absolutely horrid!! Instead of showing the code example for lithtml he zooms in on the speaker. Hey Google remove this video you are causing more harm than good for Polymer with it.

  19. what about webcomponents from polymer team? Basically Polymer 3.0 is just plain library without anything in terms of infrastructure.

  20. Who on earth though that css "shadow parts" is good idea? I mean, first people insist on keeping syntax separate, disregarding the domain, keeping to their page as document roots, even though paradigm shifted to components (of all things, regarding web component lib). When they invent all kinds of fluff syntax and woo woo to bridge the gap they themselves insisted on having. Just use css in js, m'kay?

Leave a Reply

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