Duration 40:52
16+
Play
Video

Web Components and the Polymer Project: Polymer 3.0 and beyond

Steve Orvell
Software Engineer at Google
  • Video
  • Table of contents
  • Video
2018 Google I/O
May 8, 2018, Mountain View, USA
2018 Google I/O
Video
Web Components and the Polymer Project: Polymer 3.0 and beyond
Available
In cart
Free
Free
Free
Free
Free
Free
Add to favorites
51.32 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speaker

Steve Orvell
Software Engineer at Google

Steve is an engineer working on the core library of the Polymer project. He works on the foundation code, DOM scoping, and the data system. He's been on the project since the beginning about 5 years ago and has participated in the spec process for Custom Elements and Shadow DOM. Before Polymer, Steve worked on WebOS at HP and Palm. In addition to coding, Steve enjoys running, biking, and traveling.

View the profile

About the talk

Web Components are powerful, reusable, encapsulated components available natively on the web platform. As web components transition from cutting-edge to table-stakes - directly supported in nearly ever major web browser - the Polymer Project continues to transition as well. In this session, learn about the latest on the web component APIs, the Polymer library's shift to version 3.0, how it's becoming continually smaller and lighter, and the direction the project will be taking in the future.

Share

All right, I'll everyone. Thank you for coming out. We have a jam-packed talk for you. Let's get started. My name is the polymer library on the project is a whole set of the two of us spend a lot of time together instead of calling us Steve and Kevin some people just call S7 like that. Although he was the one who talks like way too much and use all kinds of crazy analogies. I don't make any sense goes on and on and on possible to find an analogy that even understand

her project in the future. And then finally we going to talk about where we're going to help evolve the web platform forward to make it even better for us at Oliver's. Alright, so let's talk a bit about and polymer. Development project started as an experiment to embed web developers right inside the Trump team and the goal was to tighten the feedback loop between developers building on the web and Engineers implementing the browser. So they experiment turn

into a full-fledged project focused on identifying developer knees and participating in the standard 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 developer so that we can all deliver better experiences to our users. This all started almost 6 years ago. Now when Alex komorowski and Dimitri Glasgow got up here at Google IO in 2012, and it was really difficult. It was overwhelming how 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 back from the future and they were coming back to report that all these problems were solved and not 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 API that help us create components for stretching or applications. I'm building reasonable widgets and the components were built on a handful of new features in the

browser. Bruce Richard, they told us about West custom Elements which let us extend HTML and make our own elements work the same way that the browsers built-in ones. Do you like inputs and buttons and this man custom elements would work anywhere that works regardless of how your building wrap next Shadow Dom let custom elements. How did the rendering so that you could create complex UI in a component that was fully encapsulated including a styling so you no longer had I had to contend with this Global soup of CSS in each other select

custom element definition scald HTML Imports and the rendering for your component with just be described declaratively in HTML and then loaded and parks natively by the browser. Dimitri and Alex put all these things together into this awesome story about an amazing future where you can mix and match components from different authors on the same page. And this was because the rules for coordination. We're no longer convention that everyone had to agree on they were built into the browser and that would allow an ecosystem of interoperable. We just

libraries meaning everyone could stop raining venting. Same day pick-up component over and over again is its web components were built on top of HTML. We got it cleared of format for describing Upon Us for free six years ago when they well it's been a bit of a long road, but welcome bonus 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 other devices right now. Everyone of you has a phone that runs there's a thriving ecosystem of

components on web components. Org. And most obvious your brain works today work rate with web components as you can see on custom is everywhere a site that tracks framer compatibility with custom helmets. So the promise of one component model that works everywhere really has come true and of course lots of developers are already reaping all the benefits that Dimitri and Alex talked about there's a lot of big sites right here within Google that are all in on web components and why some companies like Electronic Arts Coca-Cola and USA Today are using to ship really great experiences. And those

those are my all in all it's so all of these Brands and sizes have investment web components to help them Reach user on every corner of the earth. And that's the amazing thing about the web. It's what gets Steven dye out of bed in the morning is the fact that it's just 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. Okay, 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 is it like absolutely everyone using on like every single website? All right. So to explain that lets pause for a second and talk about this concept we have on the polymer team called a weirdness budget, 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 are compatible with your way of thinking or way of doing something it starts to feel kind of unwieldy and confusing and

you're likely just punt on the whole idea. So take the electric car for an example, right? So the novel new thing about the electric cars 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 save the car had a bunch of other weird things about I like only three wheels & 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. Yeah. I'm not sure I'd buy that car and sometimes that's how we feel

it's been with polymer and what components will that original novel feature that single standard in a Republican? 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 of it the first and foremost for the polyfills at the beginning you need it probably feels to do anything with web components on every browser and not just one probably filled but a bunch of them one for each feature of web components simple

follicles, either some pretty fundamentally change how the browser worked. So having to load polyfills just to do anyting kind of felt weird. Yeah in early on using polymer at least felt like the only way to build web components of this was because those probably feels were pretty tightly coupled to a polymer yourself in another free market. The entire purpose was to break down The Silo so that you didn't have to be stuck in a silo when you when you chose a framework, right? So being forced to or feeling like you were forced to use a library like Palmer just

to use webcam on it's also kind of felt weird and then when we started out on web components a package manager called Bauer was popular at the time. It seemed like a natural fit for Distributing client-side code. Like about it's right, right, but in the meantime npm is really become the de facto standard way to distribute job is good for both client and server code and having to get your dependencies out of power became kind of a drag. Yes. I having to deal with two package managers in p.m. And our just also felt weird for developers. And then there is HTML Imports does a really good idea

but it never really panned out standard wise. This is how those guys from the future and vision. We download our web components with a platform base loader for HTML JavaScript in CSF started becoming popular. It became clear that we couldn't have two different loaders in the browser one for HTML one for JavaScript was abandoned and because of that all the standard tools that we all used like Butlers and transmitters and editors. They never really adapted to dealing with HDMI Imports, right? So over time at least using Nationwide Imports also started to feel weird. So what web

cameras have been objectively and 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 years to eliminate the weirdness around web components so that every web application could start taking advantage of the standard interoperable component model. 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 and shattered on and now Firefox

has its limitations of China 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 used feature detection two largest what's needed And then the other thing is that as of polymer 2.0 release at last year's totally separate from polymer and work transparently behind the scenes. So now polymers Justin implementation detail of your web component users of your component use it just like they would any other issue element. You don't need to know anything about polymer the way it was

kind of always supposed to be in today just with polymer you can make web components with libraries like Angel or an ionic and glimmer and all those components can work on the same page through the power of that interoperable component model. So we've come a pretty long way towards reducing that weirdness around using weapons on it, but they're still these two other things that have made weapons on his butt with polymer feel kind of weird and that's been the focus are for around the past year. All right, and today we're excited to announce the release of polymer 3.0.

With with polymer 3.0. We're building web components built with polymer into the mainstream now our boss Matt is right there. He really likes claims. He insist on putting them in every presentation. So we slipped me right there. Did you like the Flaming welcome on his cat are now being published on in p.m. So this means you'll just npm install them like you do any other dependents senior project no more contending with a different package manager just use polymer in my foot

on it. Next removing 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 models were also publishing our packages to mpm as JavaScript bottles. And this is because as of today's really sapphirefoxx 660, we just stepped in it this morning loading JavaScript modules in the browser all four of them. So exactly as you wrote it with no bundling or transpiling or sourcemaps needed during development, which is awesome

productivity boost during development to just be able to load and refresh your code in the browser. Totally awesome. We need to do to make this possible and that's the model specifiers we use to your house cuz the browser is really only so understand your else and the convention in the Indian pm and really the entire dumpster because it's low dependencies by package name not but you were all in polymer is going to fall. This convention were not going to be weird. They're so to make those Imports little bundle browser. We need to transform does mazel pacifiers for your else. Okay. So, how

do we do this? Well, we've updated the PAW Patrol's to do just that simple transformation on your source code on the fly from module specifiers using package names to your else. So let's take a look at this inaction. So many are shop demo app using the Palmer dead servers 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 Converse module specifiers from package names to your url. So you see that. Couple lines are those are converted on the Fly to Your

else which makes it being experienced great. You can just edit & Refresh that break point right there is on the exact same line as it would be in our in our editor. Joe Palmer still ships with this great edit refresh development experience right out of the box right now for those of you because we're going to have more to say on that later in the talk, but you know, the other benefit of this change moving from HDMI ports to JavaScript module. Is that code built with polymer also just fits right into the other popular tools in the community tools it understand models like typescript

and webpack and roll up and of course you can continue to use the polymer CLI. You can choose whatever tool with works best for you and your team So in Palmer 3.0, we've held the API stable and only focus on this format change formation on Imports and Bauer to JavaScript modules and then p.m. So polymer 3.0 has all the same stuff as polymer 2.0 just in a slightly different form. Let's take a look at what this change practically means up until now in Palomar we Define single file cabinets using HTML. So first you didn't Port dependencies like the polymer-based last year. So we're using a

nation important Link rail import tag to import that and then you do that. Magill Elementary associate your templates class with for your custom element with the template and then you register the element with the browser using the native custom elements register Define API single file in HTML. Are 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 and p.m. Using the

browser native important. Text Define your class. Parts the same. But then here's the change you implemented get her that returns your original template in the change here is that uses HTML function provided by polymer to convert the string into the element that polymer expect otherwise hasn't changed and we use the same platform API Custom Homes to find that we did before and that's really all there is to it pretty standard. Nothing weird here. Alright, 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 with I just want to reiterate we've held API stable and only focus on this format change from a chamel Imports and Bauer to JavaScript modules and in p.m. We're providing a tool called the polymer modulightor you convert HTML Imports to JavaScript modules automatically and also generates the package Json you need to install dependencies for men p.m. Based on what you were previously using and our sounds like a tall order an automatic migration between two virgins next. Let's take a look at the size of an

action by going into our shop Dental application that was written in National Imports in convert that to modules. So this is the shop Dental application. I'm going to reload it here in the browser. You can see in the dep tools were loading. All of our components are using HTML import. That's the 2.0 version. Right, so if we pull up the the shop out the main component for the application in our editor, you can see all the dependencies are being imported using Nationwide Imports. The template is right there in the in the HTML, and then you can see that the class is

extending from the Palmer On That Base Class that's plugged directly alter the global because what they should only for Sweden have any scoping everything had to go into the global app that's going to go through convert all of those HTML files read those and output JavaScript modules in their place. So here we can open that same Shop app component. You can see all the Imports are now in Portsmouth base classes being imported from from the module that that provides it. We're defining our class the same way, and then here's that the template being encoded right there in

JavaScript using HTML function has Steve said that the modulars are also generates your package Json based on all the divinities you were previously using in Bauer so we can just go to the consul here npm install our new mpm base app. Asian 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 not loading them using the native Muzzleloader in the browser and everything be a few things that the module laser doesn't automatically convert still they might have to hands-free

phrase. You can see the majority of the migration work is automated. Yeah, so that's a pretty awesome tool and we want to thank all of their users and companies in the community that helped us make that happen and especially a big shout-out to vodden to help us a lot varia how they will decide based using web components. That's really great. You should definitely check it out today on mpm still in pretty active development and it's already automated most everything as you just saw but there are few things you need to do.

You should definitely check it out and we love your feedback finally along with this change. We made sure that web cameras. Org the one-stop-shop for the ecosystem of reusable web components has been updated to host Elementary review AMPM was previously power inverter, encouraging the entire Community developers to go to this migration to get them onto Bauer and module is the same as the rest of the community and get them publish on webtoon. Org as well. So in this latest release, we really feel like we're removing all of the weirdness around using polymer weapons on us using

polymer 3.0. You can build and distribute web components that are truly mainstream and when you're building a web application using a web component is just like you would any other dependency it'll fit seamlessly in your workflow. Polymer 3.0 and most of the custom elements that the Palmer team maintains are available today on npm install them just like any other opiate dependency and you'll be off to the races. 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 Palmer project? Where do we go from here? Since we're holding the API stable in Palmer three as we said that releases 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. Serena twerking 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 the first thing that we did it take a hard look at improving the base class that we used to make web components. So the rendering and data binding parts of polymers base guys have really been unchanged since that one point of released a few 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 actually building applications today. So to do this we separated out kind of the lowest part of the smallest part of the Palmer Library. It's a roughly to kilobyte

layer that lets you declare an element's property API keep it in sync with this out reviews did react to changes and we really see this as a as a common substrate that any element needs regardless of what rendering models being used in place of polymers Legacy template and a to buy new system wheel are done a new library called lit HTML that we've been developing over. Test your sound is a lightweight rendering Library based on JavaScript string literals and the platforms template elements. We took those two platform features and kind of smash them together into this rendering libraries

less than 3K today. But because it's based on new and in some upcoming Sanders that we're going to talk about even that can mostly melt away in the future. We're calling this new Base Class lit element. So let's take a look at it in action. So we start but just make me a sandwich shops / module. We import lit element there from in p.m. Using and it's HTML tag, then we use our standard pattern. We make a class that extends lead element. We declare our elements property API here, we're declaring a first last and pay properties users can set those either email or as properties in

JavaScript. This is pretty similar to Apollo realm insofar element makes use of lit HTML and its HD malfunction a Texas train containing static HTML and embedded JavaScript Expressions describing where they dinnae McHale. You should be set behind the scenes is converted to a template element with some information about where does dynamic sports are renters this content to the element Shadow Dom and then that render method is actually called whenever in any of the element's properties changed and lit HTML behind the sea. And keep seeing spouse by ensuring

that the static content is rendered only one and that the dynamic parts are updated just as needed to find just like we always do and that's all there is to it. So you may notice at this little Matt uses the functional reactive pattern that was popularized by react. Jsx. But since we're running standard JavaScript here were using tag 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. Right, and we see lit element as a lightweight next generation

replacement for polymer. 3.0 is polymer element. It's just about five KGB that's around a third the size but it has just what you need for making elements that leverage unidirectional data flow, of course mix and match elements made with little man with elements you made with polymer 3.0 or any other web components. Alright both lit HTML and lit element are available today on MVM and you can start using him with Lyn element. We have a solid new base class for building custom elements and apps out of its components. But when you're building a web application,

you don't have to build all the components yourself right now, that would be kind of crazy. So that brings us to our next new product a new element set. So from the earliest days of the Falmer project, we've always provided a high-quality Library if you like opponents to help you get started building Rich user interfaces out of what components and yesterday Google announced a new iteration of material design. IO is focused on Steam ability in our team is making a new set of elements expressing this new design language called material web components. These elements will be replacing the

Palmer teams paper elements, which are based on an older version of the material design elements that 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 And this is going to ensure that the new set is automatically kept in sync with the latest material design guidelines. So the news that is actually built using lead element 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 webcam on it. All right. We have a

preview of the material web components available and get up today. Some of them are now to mpm but they're working progress and we hope to hear a quickly and have them all ready for the very soon follow me besas with lid element and a new element set with material web components the last productize all of these things together into the into and out building experience. And today it has everything you need to build scalable high-performance Progressive web apps right out of the box using all of the latest iPhone features. So, of course we're using webcam on his for

factoring the UI in again, those are built using litter when are new new Base Class uses service worker for offline storage that uses the purple pattern for efficiently serving application and we're integrating Redux for top-down scalable State Management the kit comes with several different starter templates and has tons of documentation for ramping up their zero can take commands for building unit testing screenshot testing and applying all that's included. So you can get going with the pwa starter kit by cloning that get help repo and there's a whole weekend there that tells you how

to get started but also Monica niculescu 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 State Street. So you should definitely go check that out. He's amazing soccer polymer web components of ecosystem into the mainstream and with lid element material web components and pwa starter kit building web applications with web components is easier than ever. Okay, but remember the Palmer project mission is not just a bill tools on top of the platform but also to

help people solve real-world problems 14 minutes and 37 seconds. We're going to finish up with a lightning around through a bunch of new platform apis and future is at the Palmer team is helping shape and providing feedback on in the standard process stuff. We have CSS Shadow Parts. This is a proposal that provide a first class solution for theming web components. So we talked about how shall provide styling encapsulation it protects the inside and outside of the Shadow Dom from being accidentally styled. However, sometimes you want to Style Elements inside the shadow down

from the outside and the classic case is applying fee. For example, you might want a button to have rounded corners or an input to look special when it's focused. 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 a way to style any property on an element in the shadow. You can only style the ones that you were supposed to your custom property API, right? And this is where she has a show Parts comes in. So it's already Works. Let's take the native input element. For example, it has a placeholder attribute that

shows the value when you haven't typed anything. It's usually used to tell the user what to type. So this is a nice feature about off and developers want to be able to style the placeholder to make it match the theme of their website, right and what you mean I know is that the native input is actually implemented in the browser using 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 inputs shattered on and the platform exposes a special colon colon placeholder pseudo

element in CSS that you can select on the input to style it right we can make it Orange in sidered and we can do that without the input having to leak other implementation details of How It's implemented. I'm trying to think of some elements that you shadowed on. So let's get a slider element called my slider and you want to allow users to customize the way the thumb looks of the thing you drive left and right to set the value. Shuttle, Parts introduces a new parts and tax in CSS that we can use to select items in the shadow root. So here we can

select colon colon part on the my slider and passed the thumb as the thing we want to select in there and give it a custom style so we can make the thumb orange if that's our our theme for what side is the power to Define pseudo elements for our own Pokemon is just like the native platform has always done for its its built-in elements, right and to do that all the developer of that. My Slater element needs to do to expose the thumb as a Styler basotho element is to add a part of Butte to the right with the you know, the name you want to that right Dawn node in your salary. And what's

great about this is a developer decides exactly. What styling is encapsulated in the shadow Dom and what's T-Mobile from the outside? So the CSS working group is already agreed to advance to send tax and it's being implemented in Chrome right now, and we really think that's the official auto parts are going to unlock generalized aiming for what kind of been missing up until now you can go check out that drops back here and Monica right up a really nice explain her on her blog that you can check out there, too. Okay, so next step is a big advancement for custom Elements, which is the

ability to scope and 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. Sprite however up until now custom elements were defined globally for the entire page now practice really this has been mostly fine, but it can sometimes be a problem and to see how let's walk to a little example real quick. A big team building a big application in responsible for the contacting you you see you find a fancy button component think I'll be great you put it in right there. So let's say that I'm on a

different team and I'm responsible for the detail View and my teen find a different fancy buttons. That looks awesome. And I want to use it in my cabinet and both of these components need to work in the same page. So since the fancy button tagged name can only be associated with one class right now in custom elements the browser one actually let you define to elements with the same name. So both named both teams would have to like cooperate on picking the same fancy button or name it differently or something. I got right. Let's take a look at that problem. So what's up

my registry just to go in for that class that you want to use and then you'll make a new custom element registry. So previously they were just one of these globally. Then you can Define that fancy. Button tagged name just in this registry not the whole page. And then finally, you'll tell the shatter route to you just this registry for its scope tree. So this way the contact you in the detail view. Can you tell their own registry allow you to use that seem fancy. That's what name but with different implementations on the same page. So we think this Edition is really going to help a large

organization is managing a lot of complexity a lot of dependencies in their application adopt custom elements The Proposal got positive feedback at a reason w3c meeting this year and you can follow along on this GitHub issue and provide feedback on the issues linked to your I can actually for all of the things we're talking about go check out the issues in and comment on them and give them your use cases and feedback that be great. So with CSS Auto Parts in custom element Registries a couple of long-standing pain points are going to be addressed really nicely making webcam on it's easier to

use look at a couple of features that will enhance the way that we load components in the browser. At 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 buy your El Sol isn't mentioned earlier jobs. Your modules can only really be loaded by your house since browsers only really understand your house right now, but everyone use a package name this provides a lot of flexibility like the ability for 10 p.m. To put the package just where it needs to be on disc and frankly. It's just more convenient

means that you need some kind of tool today to make them loadable in the browser. It wouldn't be great. If you didn't have to do that, right? That's the one thing that the polymer tools during development have to do is transform this but that's where Gene Maps comes in. So Packers named Maps introduces a new Json format that will be understood by the browser that map's model package names to URLs that the browser can load ideas that this would be generated by your package manager at like 10 p.m. Or your cdns providing your modules what 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 in taxes still kind of up in the air, but then you'll be able to use in all of your source code or your your dependencies and have them load natively in the browser. So just the way you would in in note. So we're really excited about how this is going to remove the need to use tooling to load resource in the browser a big step forward for beautifying the entire Community both front end and server software packages can work out of the box in either context. There's an explaining for the

proposal here on GitHub and go check it out again, please provide your feedback. That's how the stuff gets done. So the next thing we're working on related to loading HDMI modules. So as we mentioned earlier issue Mill Imports kind of field to catch on mostly because they weren't designed to coordinate with the JavaScript module odor in the browser that started kind of emerging at the same time is actually not shift everywhere, right, but I really like you and there's pretty broad agreement in the w3c. That's 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 muzzleloader The native modulator today only understand JavaScript, but if they see my muscles are implemented that seem loader would just love being able to load a shame Elle and this really unlocks a lot of possibilities the HTML can bring in the components template and then you could use it in a script please. Thank you template in your component just like that. Look a lot

like HDMI ports does today but, you know natively with the doctor module letter with the modulator then. All right. So when they do not let module is we're really helpful to get away to write single file cabinets that leverages that the native parse error that keeps a smile on JavaScript in 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 in this issue. We're still working out a lot of the details but we've also creating an experimental tool that you can check out right now the channel for find

the design on modules in this particular format and then applies to build giant Transformer to convert them into JavaScript modules that can be loaded made in Italy 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 cool. All right, and I are both going to make a lot more convenient to the last new browser feature that will 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. 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 dumb. It's actually faster than creating elements. Apparently like many libraries do real applications need to update. Dom as well. So like in this case, we probably wouldn't put that name Bob Smith statically in the tablet. Like that would be a variable. That's what it from the database. There's nothing 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 on fact that a lot of JavaScript libraries are focused on this one thing like creating a tree of Dom and then updating a dynamic lean. Totipotent sensation provides a way to tell the native template element where the dynamic parts will be. So we'll be able to call create what's called a template part and attach it to a spot in the template to tell it where I can be updated and so right here. This is where we want to update the name and that's the only part of the template that needs it needs to be changed. Everything else is static and we can tell the

browser about that ahead of time. And then once we create a person that template there's a new API called create and since on the template element and they still stamp a copy of the template all 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 about it is that the incident also knows about where all the dynamic parts are in that template without having to walk through right we can just call get parts on the incense in Indonesia part has asset value API that we can call to update that part of

the dumb and then finally just called commit on the instance to apply a batch of changes all at once cool. 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 build the top of the existing template element, which is already the fastest way to create a static chunk of dumb butt by adding this new part API, we think this will end up being the fastest way to update on as well. And this is because today any library that deals

with rendering has to locate these Dynamic spots in the Don Manuel each time, you you create instance of the template walkthrough. What could be a pretty big chunk of a static just to find what needs updating with implementation get parts API, you can just ask the browser for that list of spots that need updating without needing the runtime Overhead Door the code to walk and find those spots. Another cool thing. Is that supposed to have bashed updates built-in. So logic to update the dynamic parts of a template in a component could be potentially be spread across Full frames and

committed in one batch, which is really cool because a lot of Frameworks are experimenting with this 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 are new rendering Library litter smell implements make that faster but the angular team has also been involved in that in the feedback process for the back and is interested in using to play the same station as well. Last while the

initial proposal for Kaplan and sanitation has an imperative API that we've seen it also paved the way for a future declarative sentence for describing where those parts are just directly in the template. They came out and that together with a Chevelle modules unlock the potential future where components can be defined completely declared it like which is pretty cool to make rendering Dom a problem that every frame r contends with faster simpler and we play Let's go. It's a really exciting proposal started by Apple and has strong support now from all the major

browser vendors feeling very active development. You can check out the explainer stand there and that's that issue. There has some of the latest discussion All right. So let's recap all of these features that we talked about going to help him make the browser way more capable and easier-to-use. So she has a shadow parts and custom element registry are going to make those features. Shout it on a custom elements a lot more robust package name maps and HMI module is let us load our source code with fewer tools. They smell modules in Templeton sanitation, unlock

declarative component authoring a green ring way more performing and if we take all of these features together, that means that we can rely more on the platform or on the browser to get our job done and ship left code that has to run and be delivered over the network to our users. Make it better. All right, that's it for everything happening on the polymer project. So here the main takeaways which is learn from today. All right, so we are now at 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. Okay falling out today a provides a really smooth migration path for existing users to a more modern development workflow authoring a JavaScript modules and using npm for your dependencies. The Palmer project is moving forward with a new generation of products focus on improving the developer experience. The building web apps with lid element material web components and the pwa starter kit. NSU just seen in that lightning round. We have a ton of great new paw print pictures on the horizon that will make that experience even better. Alright again,

I'm stepping shop and I'm 7 or valve First Coast News.

Cackle comments for the website

Buy this talk

Access to the talk “Web Components and the Polymer Project: Polymer 3.0 and beyond”
Available
In cart
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “2018 Google I/O”
Available
In cart
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “Software development”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
159
app store, apps, development, google play, mobile, soft

Similar talks

Jeffrey Posnick
Software Engineer at Google
Available
In cart
Free
Free
Free
Free
Free
Free
Eric Bidelman
Senior Staff Developer Programs Engineer at Google
Available
In cart
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “Web Components and the Polymer Project: Polymer 3.0 and beyond”
Available
In cart
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
558 conferences
22059 speakers
8245 hours of content