 Hi, I'm Monica. I'm that person with the cat. I'm not Weldorf on Twitter and GitHub and internet places. And I've been on the Polymer team for about two years. You may have seen me meowing about web components a lot. But I started right before Polymer 1 was shipped. This was exciting because back then, I thought web components were really cool, but nobody really knew about them. I would go to conferences and be like, I work on web components. And people would be like, I don't know what that is. Is it an iFrame? No, it isn't. And I really liked doing that because I sort of became this like traveling saleswoman door to door selling web components and be like, let me tell you how web components are right for you. And I'm glad I did that because talking to people, I sort of formed a story about the kind of teams that web components were good for and the kind of people that enjoyed using web components. And that story starts with like the world around us. The world around us is built by people like you and me and sometimes we're crafters and sometimes we're assemblers. And what I mean by that is that if you think about your kitchen, somebody made you a table and a chair and a bunch of cabinets, and maybe you or maybe somebody else assembled them together in a nice looking kitchen. You didn't go into the forest, cut down a tree, sanded it down, cut into slabs, took some screws, made a table out of it, and we're like, I crafted this out of this chair. You didn't do that. Even if you use something like IKEA, you didn't really craft that table. You assembled it. Somebody produced a whole bunch of instructions and pieces for you and you assembled them together. You took things that other people did and you made them and you glued them together and you made a thing out of it. The same thing happens if you cook. When you make a meal, you take all these ingredients and you mix them together. You don't farm your own tomatoes and corn and churn your own butter and grind your own spices. And this is very good that you don't do this because assembling is faster and it's more efficient and more performant and more accessible. I have no idea how to farm my own tomatoes. I know that because I have a plant. It's in my patio. It makes one tomato every month. I would die of starvation if that was my only tomato. And as a society, assembling is really fast for us. It was the whole point of the industrial resolution, got revolution to move from everybody crafting a lot and doing a lot of manual work and sort of assembling more and making it faster and more oriented. And the thing is the exact same truth for the web. The web is kind of like a society, but on the web, we tend to be more crafting than assembling and that's a little bit weird because that means we're not gonna progress as a society if we don't learn from societies we already have. And the reason why I like this crafters and assemblers metaphor is that web components sit really nicely as a bridge in between these two. If you think about somebody who makes components or elements, they have a lot of institutional knowledge about what makes that element good and all the heavy lifting that you need for that element. Something like paper dialogue requires a lot of really weird knowledge about animations in the CSS spec and what a stacking context is and how you can't just produce one from thin air every time you want that. But on the other hand, while somebody has made you a web component, this enables people to just pick it up and use it and form a really nice experience with it. I can use anybody's custom element, I don't need to know how it works. And that's really great because if you take my metaphor from before, this is great, it's advancing the web society as a whole, it's faster to make things and it's more efficient. The CDO of ING said this at last year's Polymer Summit and I really loved it and it stuck with me and he said that what he wants to see in the world is less crafting and more assembling, less people doing things by hand. You shouldn't have to know how to build a table from scratch to have a really nice living room. You shouldn't have to know what a CSS stacking context is to just have a modal dialogue that tells somebody there's a sale on your website. And this is true of every other industry, but it's not exactly true for the web. Like in the real world, I can be a crafter if I want to, I can be an assembler if I want to, I get to choose, I don't have to be both at once, but a lot on the web we have to both craft and assemble at the same time. And that isn't really great. And all of this comes together in design systems. So before web components, when I say design system, I mean like the elements with the elements library, the things that your brand should look like, like the colors and the padding and the margins and the visual elements that an app can use. And before web components, having a design system was very craft oriented. If you look at something like Bootstrap, which is amazing, but Bootstrap was like somebody crafted you this enormous CSS file that had all these styles and it was great, but even putting the elements in your page was a little bit handheldy. For example, this is a brand nav bar that you could have in your application. I took this from the Bootstrap site. But imagine that at some point your brand changes. Maybe you need to have like that container fluid class needs to go away. What do you do then? You have to literally go in all of this dummy produce and start deleting code or adding code. And that doesn't feel a lot like assembling to me. And of course we know this, web components came and they fixed this because now we have a custom element that abstracts all of this like garbage that we don't actually care about that somebody else built for us because the only thing you care about in this element is just that image. So that's good. But the thing is this story only works if we have tools around this. The story only works if, you know, like Bootstrap we have a catalog of elements. We know as a developer, like all of these things that are available to me and that I don't have to reinvent them from scratch that somebody already made, you know, the perfect kind of blue button that I'm allowed to use. So we made webcomponents.org which, you know, we're very well. It's a public catalog of web components and everybody can upload their components and it's got demos and it's got docs and the world was good and we're happy. Only we weren't super happy because it turns out that didn't work for everyone. There's a lot of companies like EA, like Comcast that are really sold into web components and use web components a lot but their web components aren't public. They can't use webcomponents.org because they can't publish their elements. They develop them internally. So as a result, every one of these companies basically built their own catalog. They could have forked webcomponents.org but webcomponents.org solves a different problem which is how do we let people upload arbitrary components and that isn't the problem that companies with private elements have. They just want to display this fairly limited set of elements they have. And the problem here is that there's no such thing as a one-size-fits-all. Steve told you this this morning when he was talking about elements and it's true for apps and solutions. At best you have something that works in the 80% case. 80% of developers probably want to upload a public web component. But in the 20% case, it's all edgy and weird and you have to do something different and it's usually a more simpler and assemblier solution. So in this case, I build in the elements catalog which it's fairly ugly, it's not amazing but it's also a very specific problem. You have a JSON file and in it you specify what kind of elements you want to load docs and demos for. And these can be Polymer 1 elements or Polymer 2 elements or just vanilla custom elements. They can be anything you want and the code is there for you to do this. And if this doesn't work for you, which is fine, you can fork it, you can clone it, you can fix it to make it work with your workflow and then it's good. And the world was good again. Well, it really wasn't. We again solved another 80% of a bigger problem and left 20% off. It's really great that now your developers know what elements are available for them but they also need to know how they fit together because in an organization with real workflows and real people, you need to be able to validate your prototypes against code that you actually have, not code that you think you might have. And most of my examples when I give talks are from Chrome the browser because I used to work on it and I know the developers and the workflows and this is a page from Chrome Settings. And the way the Chrome Settings page gets designed is first, we give it to a designer, Alan Betz. He's a fantastic human being and he designs all of these workflows in Sketch. He calls these sticker sheets because he basically has stickers of all the material elements that he would like to use or is allowed to use according to material design rules. And then he assembles them together and figures out the screens. And for each particular screen, he does a whole bunch of iterations. Should the bottom be on the left? Should it be on the right? Should the text be centered? And then he produces a whole bunch of screenshots and then gives them to developers. But the thing is, real elements have bugs and have problems, they have implementation limitations. And I know this because I wrote those elements so a lot of the times Alan would be like, this toggle button needs to be 16 pixels and the developer will be, it only works at 18 pixels because Monica didn't make it a resizable. Which is annoying because this means that the prototype that somebody made cannot actually be implemented. And this is what I call a, what you see is what you hope you get. You hope that the prototype that you get from the designer, you actually get to see in real life. There's no guarantee about it and it's nobody's fault that there's no guarantee, it's just not everything works like it has on paper. Because instead of what you need is a common ground or a tool that is a common ground between developers and designers so they can look at the same elements and improve that workflow. Which is what you see is what you get, a wheezy wig. And something like this has been a long time dream of many of the Polymer team members. We had this in 0.5 and it was called Designer, it was really awesome. And Justin is the visionary on our team so he set this big dream of Designer 2 which was gonna be an app that was gonna basically build an entire app for you. It was gonna let you do the UI and it was gonna let you do the JavaScript and all the data bindings and optimize shit and throw a service worker in there. And literally from using that app what you would see is what you would get. But he's always dreaming up really big ideas like the Polymer CLI and Lit HTML which you'll see tomorrow so he's never actually finished this. But lucky for you I have incredibly small ideas and very little patience. So I had two free weeks and basically stole his milkshake and built this other thing. Which is more like a getting started tool. It gives you the ability to create something like a prototype but not a full blown app. It doesn't work super well all the time but it helps you get started because what you do is you deserve Justin's tool but we don't have it yet. So instead you get a WYSIWYD which is like a version of that and I'm gonna show it to you. Maybe, okay. So I really, really, really hate live demos and I'm really, really nervous about it. So hold all of your fingers crossed and toes in. Okay, so this is WYSIWYD. You can, oh, I just got a screen saver. It's going well. Okay, it's in polymerlabs.github.io slash WYSIWYD. The code should be open sourced very soon. It's kind of terrible but you'll live. So here's what the app does. It has a couple of panes and one of the things that it lets you is you can select some elements and drag them in. So I can do something like a div which is a native element. I can resize it. I can move it. I can change some of its styles so I can make a background color. And if you see over here, it has properties. I'm gonna zoom in. So it's got like a class list hidden and title. There's also things like custom elements. So for example, I can find God, a good one. Paper input, paper input is my favorite. And when I add it, paper input has different kinds of properties because we actually crawl the prototype chain so that we look at what properties or attributes your custom element has. So in this case, you can see that I have something like value and labeled and disabled and the pattern and all that goodness that comes with paper input. And you can change them. You can change styles. Flex is just the collection of the flex attributes that you might use. And once you're satisfied with the code that you've been producing, there's a code tab where you actually get the code for this element. It's got two imports, the Polymer element and paper input, which makes sense. Let me zoom in. And then as you scroll, it basically gives you an index.html that has both the element definition and the declaration at once. So we have our app and then the DOM module for that app. And you can see that it's got all the styles like I added a div, I added a paper input and here they are in my template. And then it has the element definition at the bottom. You can also see a live preview of it, which is where we actually render the code because I don't trust that designer pain, so I give you this. And because this code isn't editable, because again, that would be a very complicated app and then I would have to like re-render everything. There's also an option to pop this out into a JS Fiddle where it's a conference Wi-Fi, it's amazing. There it is and it's your paper input and it does all the things. And you can from here on start adding logic or JavaScript or whatever you want. Cool, so let's build a thing. Let's delete all the things first and then build a thing. What I'm going to try to build, again, thoughts and prayers, is a YouTube app where basically I'm gonna bang on a paper input and then get a whole bunch of YouTube videos related to that input. And in particular, they're gonna be related to cats because why not? Let me see how I'm doing for time. Okay, so one of the tabs that I didn't show you over here is the samples tab. And these are basically combinations of elements that I've added because I really don't like rebuilding the same thing over and over again. And again, this is the kind of app that you would be able to clone and fork and take home and you could add your own samples for whatever team you have or your particular workflow. So in this case, I'm going to start with a header sample which is basically an app header with a toolbar in it and it has a div. And over here, I'm gonna rename my div to meow tube and put some emoji in there. You can tell that I've practiced this. Let's put a television too. Sweet. So that's it. And now when I save it, it's there. If I preview it, it's there. If I look at the code, I actually have an app header with all of its attributes, a toolbar, and everything else. Cool. So I have my thing and now I wanna render my results. So in here, I'm going to add a DOM repeat because I'm probably going to get a whole bunch of results. Actually, I need an IronAgeX first because we're gonna need to ask YouTube for this. So in my custom elements, IronAgeX, here it is. And IronAgeX has a bunch of things we need to populate. A URL, for example, which I'm going to paste because nobody can remember this unless you're ziling probably. A bunch of parameters. So here is things like your API key, your query, which in this case, I'm hard coding to cats. Oh, what do you care about, which is the snippet? Handle as JSON. So this basically tells IronAgeX that whatever it gets back from the server, it should be a JSON. We wanna set auto to true so that the moment we refresh the page, it actually fetches this. These are just attributes that you can get from the IronAgeX documentation. They're not made up or anything. And last response, I wanna populate an object with this. So here, I'm gonna put videos. And what this means is that IronAgeX is going to get an JSON object from the server and then put it in this video's object. This is just a regular Polymer data binding. If you're familiar with data bindings, it's just it. It's exactly how you would write it. Cool. So now I have my IronAgeX, it's set up. And then I'm gonna create my DOM repeat. And this is where everything can go south. So, DOM repeat, here we go. I have it. I'm gonna drag it in. It's hanging out. It doesn't look like anything. I also have a paper card sample, which basically has an image and a link in it. And I'm gonna move it around so that it goes into my DOM repeat. So there's these arrows here because sometimes dragging and dropping is infuriating. So if you don't wanna do that, you can just traverse the tree. Speaking of the tree, here on the left-hand side, I haven't shown you this yet. It's basically all of the elements in your app so that you can see the hierarchy and you can click on them and select them because again, dragging and dropping is infuriating. And I know this because I built this and it was just rage. Okay, we have IronAgeX. It's getting data for us. We have a DOM repeat, which repeats, stamps the same thing over and over again. So it's gonna stamp one of these paper cards for every result that we have. And we need to tell the DOM repeat to take the elements from IronAgeX. So, IronAgeX was populating an object called videos and because I've memorized this demo, I know that videos actually has a sub-object called items. That's the one I care about. So here, videos.items is what I wanted my DOM repeat. Now the DOM repeat is gonna take every single thing in this object and create an item object. So to this paper card, I can now give my item. So, I have an image. The image should be this thing that I'm gonna paste called item.snipit.thumbnails.hi.url. Very memorable. And then for my link, I'm going to change the text content to be, let me zoom in again. Item, ooh, hello. Item.snipit.title. And then for my href, every snippet has a video ID. So it's gonna be item.id.videoid. And now if everything goes well, if I go to the preview, I get nothing, amazing. Something that didn't go well. So let's figure it out. We have our image and we, oh, maybe we don't have data. Let's wait for it for a little bit. Nope. Okay. Pardon me? Oh, way louder and thank you. See, drag and dropping. All right, so let's move this one back and move it into the DOM repeat. Nailed it. Thank you. I'm honestly kind of surprised that worked, I'll be honest. So it looks a little bit terrible because links are, you know, display inline and we don't have an input. So let's do that now that we know our thing that works. So first of all, we're going to change our link to be display inline block so that it's sized correctly. And then because I don't want it to grow so that all my things are still aligned correctly, I can also add extra styles. So the thing that I did in here is that as a lazy developer, I didn't ask, I didn't add every single CSS style to this designer because I'd be crazy. So instead, I give you the option to just add whatever you want. If you add garbage, nothing's gonna happen because the CSS parser is smart. So in this case, I want an overflow auto and then that'll be great. So I have my DOM repeat, I need my input. So let's add a paper input again in here. And then I'll drag it into here and then move it before the DOM repeat. And my paper input is going to have a label and it's gonna say, find your meows. And whenever you type it into an input, it has a value property. So I'm going to save that into a query property. Cool. And now all I have to do is give this query to the IronAgeX. So if we move back to IronAgeX, it used to have this parameters object that you know about. And one of the things in here was cats or the query queue. So I'm just gonna add my query here and still keep the cats because it's a meow tube. We only look at cats. Why would you ever want to look at anything else? Now let's just check the code for a second before we run it. Have a whole bunch of styles, a whole bunch of inputs, a whole bunch of DOM that I didn't have to create. I just like dragged and dropped it and typed into some text fields. And that was awesome. Now if I look at the preview and I look for a burrito, I get burrito cats. Here is a wet cat. And if I open that video, it should work. And it does. Here's your favorite cats just getting wet and miserable. Ah, that's it. That was my demo. Cool. So this is live. It's polymer labs.github.io slash withewid. If Elliot didn't forget about me, he'll probably switch it to open source now so you can actually check the code and judge me and complain about it later at the party. And I think I have like one more slide to tell you about if we can switch back to the suite. Oh my God, it worked. Never doing a live demo again till tomorrow. So because we had that 80-20 problem, I know that this is not going to fit all of your problems and it's not gonna fix every single workflow out there and it's probably gonna enrage you because drag and dropping is kind of annoying. But the best thing about it is because it's open source and because of how I try to build it, you can take it, you can fork it, you can clone it, you can change it and make it work for you. Maybe you need a marketing site assembler where you just build things so that your marketing team can put together, I don't know, pamphlets, whatever marketing does, something awesome that sells and gives you money. Fork this tool and build it into that. Maybe you need a designer where your designers can use four of their UI elements to build things. Please fork it, please build it into that and give it to your team. Maybe you want designers instead of designers instead of designers because why not would you want that? In particular, if your name is Dan Friedman and you get a bigger screen so you can do nine of them inside of each other, best use of designer ever. Wendy said this morning that her dream was to bring web components to every browser and every developer and I think the way we're gonna really do this is to start thinking more about visual tools. It's not all about your CLIs and your web packs and your gulps and whatever other tools you use. Sometimes assembling is really visual and we haven't been really good at building visual tools for visual people. So I hope that this at least proves that there's a value to do this, that it's kind of exciting to build this and to use this and it takes it a little bit closer because we're now a little bit closer to just assembling more things and crafting less. Thank you.