Transcript

Jen

This is The Web Ahead, a weekly conversation about changing technologies and the future of the web. I'm your host Jen Simmons and this is episode number 66. I first want to say thank you, as always, to today's sponsors, Media Temple and Squarespace. They really do help make this show possible and I will talk about them later in the show.

So I was at Fluent Conf in San Francisco a couple weeks ago. It's a big JavaScript developer conference, front-end development, web technology, web platform, and if you were listening to last week's episode with Simon St. Laurent, you already know that. One of the things that was being talked about over and over and over again is web components. It seems like every time I turned the corner, people were like, "Yeah! Web components!" I've been, I think all of us, many of us, have been hearing this rumble begin over the last several months, or maybe even further back, if you're really on the bleeding edge. A lot of excitement. There's always great new stuff and there's always excitement around it but every once in a while there's something that just, the excitement is so intense and so quick to go through communities of people that it really makes you turn and go, "Wait a minute, that one sounds like a really big deal." So I wanted to try to get a show about web components in as soon as possible and I've been looking around for just the right person and I think I may have found him. Peter Gasston. Hello, Peter.

Peter

Hi Jen.

Jen

Peter's a front-end developer? Technologist? You've been doing this kind of stuff and teaching about it for many, many, many years. You have two books out. "The Modern Web," which is all about best practices. You've written a lot of stuff about device APIs. You have another book about CSS3. You ran the website CSS3.info for awhile. And I saw your video, I saw a video of you giving a presentation at Edge Conf in London just recently.

Peter

Right, yup.

Jen

And I thought, alright. That dude. [Laughs] It's good to meet you, Peter. Hello.

Peter

And it's good to meet you. Thank you for inviting me.

Jen

Thanks for being on the show. So, what is going on with web components?

Peter

I think the easiest way to explain this is probably... it's kind of a new way of doing something we've been trying to do for a really long time. By which I mean, reusing code. Everybody talks about code reusing so much. On every project we have these great aims that we're going to reuse code. And we've been doing it since the very earliest days. It's how many of us, I guess myself included, learned how to code, was looking at other people's code and taking, thinking, "I love the way they did that tab navigation, I'm going to take that and put that on my site and make the changes for myself." This has kind of become formalized in different libraries throughout the years. We've had things like jQuery UI, which makes that code reusability easier. Even to bigger processing, things like React.js, which is going to make creating libraries through server-side generation, well, sorry, sorry, through node generation. Web components are taking these ideas and looking at what people are doing already and formalizing a process for us to do it. It's things like... you look at the web and the web is, we have many... well, HTML has many elements already. UI elements especially. We have input boxes and we have select boxes and we have the image element. They all do a job. Every element does a job. But we want more elements to do more jobs. We've been pushing this for years. We want the web to do much, much more than it does now. We're kind of running ahead of how fast the standardization process can work. That's what web components at their core allow you to do. They allow you to create your own elements. Which sounds, I guess a little dangerous. But it's not quite so simple as just writing whatever you want and dropping it into the page. You have to register these with the DOM and you have to make sure the DOM is aware of what they are and what they can do. But it allows us access to lower-level APIs of what the browser can do instead of waiting for... I'll give you a primary example of a great component I saw recently. Just a Google Maps component. Up until now, if we want to use Google Maps, we have to drop in some markup and drop in some JS files, et cetera. And we'll probably do it... different developers will do it in a slightly different way. They might use a different naming convention. But it's a common pattern, it's something we do all the time, so why don't we create a Google Maps element? We could wait for... we could propose that and we could go through the standardizations bodies and we could wait for them to create a Google Maps element for us. But we don't need to do that with web components. We can, between us, settle on the best way to create this Google Maps component, make it sharable amongst everybody and make it perform the same job in the same ay every time. And just start sharing this around the web in a way that is more consistent and has the capability to do more than we could if we all were... to make this easy, the sharing easier, than if it were done just using something like a jQuery UI, Google Maps element. At its fundamental level, that's what web components are. They're about letting us run faster, create the things we want to use, and then propose them, hopefully, for standardization afterwards.

Jen

It's an interesting example because Google Maps... right now, if you want a Google Map on your webpage, you go over to Google, you make map, and then you grab... I forget, I mean, they don't use an iFrame. I think they use either a object tag or the embed tag or perhaps the two nested together, is it? Or is it just a piece of JavaScript? But in any case, you're basically dropping in code that Google wrote. Copy paste. And then using JavaScript to sort of... it feels a little bit like a hack. Like you're kind of hacking in a piece of someone else's website in your website. The same thing with YouTube. I mean, there are a lot of ways to put a YouTube video on a page but the most common and most easy, the way that a lot of people do it, is you go to YouTube and you grab the embed code. Which changes periodically, but, you know, over the years, object or embed. And so it's that kind of... in a way, it sounds like what you're describing right now is taking that kind of stuff and bringing it closer to the metal. Making it less of a, sort of, "You don't know what this is. It's a box of stuff. Just look the other way. I'm putting a box of stuff on the page" to the browser. Like, rather than communicating that way to the browser, you're able to say, "Ok, I'm going to tell you exactly what this is."

Peter

It's also about not having all the crap that comes with it as well, you know. Quite often when you want to use a UI element, you have to copy a markup pattern. And that can be quite a complex markup pattern if we take the example of an image carousel. Which, you know, there's arguments that you probably shouldn't use image carousels, but quite often we do. And if you wanted to take somebody else's image carousel, you have to take all the markup and you have to keep in a very specific pattern and then you have to take the CSS that comes with it in order to make it do certain fundamental behaviors and then you have to take a JS file that comes with it. You know, it's very, very... there's a lot of work involved in getting that into a page. Especially if you run the risk of conflicting with scripts or markup or CSS classes that are already there. You run this risk of it conflicting with the things you have in your page already. Whereas if somebody, if we just together as a community decided to make a carousel element, we could essentially hide away all that complexity through some other kind of related technologies. I'll talk about, in detail, about those technologies shortly. But we can basically hide away that complexity. So we can take one element or, sorry, we can take one external reference file, which will be just a snippet of HTML code with everything included within it. And then we can just drop the element into our pages. We can start using the carousel, whatever we decide that's going to be called, and it will just work, everywhere. We don't have to worry about conflicts with the existing page. We don't have to worry about multiple different files and multiple different versions of different... if we use jQuery UI and we've got two different versions of jQuery UI running on the same website even sometimes, those kind of... the ideal of web components, and I'm not saying it's going to happen from the start, but the ideal of web components if that most of that complexity goes away.

Jen

Does it then make it a little less fragile? Sometimes I know you build this kind of carousel, or this whatever, this widget, and it's a bit fragile because if someone comes in and accidentally deletes a little piece of it, then the whole thing breaks.

Peter

Exactly. It makes it a little less fragile. It makes it less prone to... you know, quite often, if you bring in someone else's carousel, you bring in, quite often, a lot of different options that come with it. They'll have created this UI component with a big attached CSS file and maybe they've got themes attached to it or maybe they've got different behaviors to make it go horizontal or vertical or only show one at a time or only show two at a time. And that's a lot of complexity for one element. Whereas something like web components, again the ideal of web components, is that we keep that as simple as possible. We hide away the complexity we don't need to worry about. Or we make the element so simple to use that you don't have to worry about all this conflicting and unnecessary code that comes with it. But, again, I can't reinforce this enough: We are talking about an ideal. An idealized version of web components. I'll talk again in a little while about some of the less ideal aspects of it.

Jen

That's what I wanted to ask you. Sort of the nightmare version of web components. I mean, when I hear people say, "This is going to be awesome. We can create all of our own HTML elements and we can make the ones we wish we already had and I'm going to be able to do this awesome stuff with my website." And especially since the people I've heard... I don't know. The rant that I gave last week, when Simon and I were both on the show, we talked a lot about the need to really respect web standards and this sort of, we sort of... theorized that there seems to be rising tide, especially among JavaScript developers, in sort of disregarding web standards and disregarding a lot of the lessons that have been learned over the last 15 years about why the web is really great and what's good about it and what's good about progressive enhancement. And so it's a little bit nerve wracking. The people who seem to misunderstand progressive enhancement and disregard web standards are now simultaneously the people who are most excited about the idea of being able to write all their own elements, unique to the web project that they're working on. What’s up with that? That seems scary.

Peter

Right. I mean, yeah. We're worried about the standardization process or even the implementation process moving too slowly. This is the problem that web components was set up to address. But the benefits of that slow movement of going through a standardization process, of going through implementation by browsers, by people with lots and lots of experience in doing these things, the benefits that come with that, is generally when something is implemented in a browser, a UI element for example, it's had a lot of consideration behind it. People have tested it for accessibility. The markup is done in a way that's perfectly accessible and usable. And in the rush to create our own elements, I have no doubt whatsoever that we're going to end up with these things being overlooked. I'm absolutely sure of that. In my talk I termed it, to put it slightly more politely, a proliferation of rubbish. And I think that's going to happen. With the track record we have as developers, quite often we cut corners and we want to get things done and deadlines to meet and budgets to meet and sometimes we just don't care about stuff. And I think that's kind of unavoidable. What I would say is, the web components aren't going to exacerbate that problem. They don't bring anything that we can't do now. They're not going to correct the things that we do for us, they're not going to work like that. We have to, as a community, as responsible people, make our sites accessible and usable in the same way that we do now when we create our own sets of libraries and tools and so on. There's nothing in web components that kind of mandates things must be done in a certain way. So it is kind of a little scary in that way. The good thing is that after Edge Conf where a lot of these issues were raised by panelists and attendees, there's already been a lot of conversation about, "How do we avoid this proliferation of rubbish?" So we've got suggestions. For example, a community up-voting platform was suggested by, I'm sorry if I get your name wrong, Mary Buckham, who's written a very, very nice blog post about this. About looking at the problems, lack of quality control, fragmentation, reinventing the wheel, and suggested this idea of having peer reviews. Of having a platform that creates peer-reviewed elements and us being responsible and looking at these things in a certain way. If we look at some of the libraries that exist now for creating web components, things like Polymer and Brick, these are kind of web component UI libraries and they already have this kind of system in there. They have built into them this discussion to talk about the elements and they're all open source so that people can see problems with them, they can commit code to them, they can get changes made and suggested. I think hopefully we will see a concentration around best practice of people who want to do the right thing in the right way. And the ones who do the right thing in the right way will, I hope, become the ones that are most popular and most used. But again, we can't ignore the fact that some people are not going to do this. But that's not a problem that's specific to web components.

Jen

So you feel like the technology's neutral?

Peter

Yeah.

Jen

That we just need more, whatever, to say, "Let's really teach each other best practices and get the word out." As you said in the beginning, share as much code as possible and use this to share code rather than use this to just run off and do all of your own stuff uniquely by yourself.

Peter

Yeah, I think, as I said, the standardization process, as much as want it to move out of the way so we can move a bit faster... web components, by moving that aside, by allowing us this access, it kind of gives us much, much more flexibility in what we want to do. But it also gives us a big burden, a big responsibility of doing things in the right way. It's like, to use a simile, handing someone a gun. You can have the gun but there are certain things you have to do to make it safe and not to be crazy around it, keep it locked away and learn how to handle it properly. It's the same thing. It's a huge responsibility having this. And it's a burden that falls on our shoulders and it's up to us to step up and take that burden, take that responsibility. Not everyone's going to want to do it. But I'm hopeful that, with the conversation that's going on... it's still very early to talk about these things yet. But I'm hopeful that with the conversations that are going on, we will end up with a list of best practices that are followed and hopefully not ignored by good, responsible developers in the future.

Jen

One of the things I saw in the presentation you gave - and I'll put links to all these things you're talking about in the show notes for the show. Which people can go read at 5by5.tv/webahead/66 because this is episode 66. You explained something that I hadn't seen explained before that really helped me understand web components in a way that I was not understanding them before. That is, browsers already have things like, this is a button, this is what it does, this is an input form, this is what it does, this is a... now with HTML5, with the number input field, there's a slider, or it's not number but the other one. There's little things, little bits of things that browsers can do and there are little things that you can, when you write the code for your webpage, you're basically activating them. And then, "Oh look, there's a button." And part of what we've been talking about the last... I don't know, we seem to be on a rant this Spring. [Both laugh] A collective rant on The Web Ahead around accessibility and some of these issues. One of the things that I keep... I'm not going to rant right now... that I've mentioned too many times already, is the button and people sort of, by not using the button element, by using a <span> element instead, or by using an <a> link instead, or using a <div> instead. There's all this power that the button element actually has, especially regarding accessibility. When someone uses a keyboard and they're tabbing through the page or somebody's using a screenreader. There's some special superpowers that that element has and that the browser actually recognizes it and acts in a certain way. When developers disregard the <button> element and they use <div> because, usually it's because they're using some sort of JavaScript library that uses a <div> by default for some reason. And they're, like you said, busy, lazy, overwhelmed, don't have enough time, too many tickets, whatever. They just wanted to get it done, get stuff done. How's that come back to web components? It seems like, in a way, it's a chance to define new elements, perhaps not just for semantics, to be like, pointing to something, but because it will then have some sort of a power to it, or it will have some sort of a... like you said, a carousel or something. So there's this carousel element with a source attribute and you point to, perhaps, correct me if this is all wrong, but you point to certain sources and then you're done when you're writing the code but then under the hood there's all this stuff that's going on.

Peter

That's essentially... exactly right, exactly what you said. The UI elements that we see now are actually very, very amazing lessons at how to hide complexity. If you look at the, the example that gets bandied about a lot, is the select element with the options inside as well. When you put your options in, then it produces a drop down list of options that you can chose form. But all of that styling, the keyboard navigation that goes through it, if you're using keyboard navigation, the descriptions, everything that's in there, it's more markup that you can't see, essentially. It's hidden markup that's doing the job that makes this thing accessible and usable and secure in some cases. So we should probably just quickly talk through what web components are comprised of. The 3 core parts of them, as I would say.

The first is what we call custom elements, which is what we've mostly been talking about so far. It's creating your own elements, naming them, but also adding behavior to them. Adding methods, JavaScript methods, to them. So you can create your own API per element essentially. A lot of existing UI elements already have this. Another great example would be the video element. If you put the video element with a source in your page, it drops in a video player with controls and it's keyboard accessible and all of this. But you don't see any of that. But it's all there and it's all kind of... all of the complexity is hidden away from you. So custom elements allow you to take things like this, to take some common group of behaviors, and attach them to one single element. And the video element also has this fantastic JavaScript API so you can play and you can pause and you can get the current position of where you're watching to, it's got its own API contained inside this thing. And custom elements lets you do that. You can define properties, you can define methods, on any element you like. You could, I've seen this example thrown around a few times as well, have a table that had an API that queried its own content. So rather than having to write something that crawled through the table and looked through the values yourself, you could just expose a quite simple API so anybody could look at a table and call a method and get the value of any cell at any time. That's a really simple example of what they do. Custom elements can also actually be used to extend existing elements. You don't have to create something completely brand new. You can add new behaviors and even new markup to existing HTML elements. Again, another example is the video element. I've seen a very, very nice custom element web component which extends the video element to add in live camera input. So it takes the WebRTC, it takes getUserMedia, and attaches that behavior to the video element and exposes a few attributes and allows you to do live video input without having to know any, or without having to know much, about the getUserMedia API at all. This is just exposed through attributes and values that go inside the custom element. So it's not always creating from scratch but it's sometimes taking existing elements and adding new behavior to them.

The second part, and it's the part that probably is the simplest is just called HTML imports. And HTML imports do exactly what they sound. Like at the moment we can call in external resource files for CSS and JavaScript just by including a link in the head, HTML imports allows you to do the same with markup. So you just drop a link in the head of your document saying that you want to use this markup and everything that's in there becomes available to you through a JavaScript API so you can just... it kind of activates the elements, the new custom elements you have in your page. But it makes that code sharing really, really easy. You can just create snippets of markup and style and behavior with JavaScript, you can include it all in one single file and just refer to it, just link it in the head of your page and it kind of activates all of your custom elements.

The last part is probably the thing that most people have heard of, is the thing called the Shadow DOM. The Shadow DOM is really, really powerful but it's the part that's kind of hidden away from everything else. This is the bit that hides all of your complexity. This allows you to have, like with the video element, all the markup and everything hidden inside the element that you can't see, that's all hidden away in what's called a Shadow DOM. It's just like that DOM of the page but it's not exposed to the end user. If you have a copy of Chrome, Google Chrome - and, really, who doesn't nowadays? - you could try enabling it yourself by just going into the options for the inspector, the web inspector, there should be an option in there called "enable Shadow DOM." And then take a look at a UI element. Take a look at a video element or take a look at a select box or something. You'll see now in the inspector that you can actually see a Shadow DOM inside these elements. You can open them up and explore them and find that actually there's some really quite rich and complex markup hidden away inside these elements that you were never aware of. The Shadow DOM allows you to keep your custom elements really, really nice and simple but at the same time very, very complex. But the complexity's hidden and only available to people who actively want to find it. Whereas the end user who just wants to get a webpage written quickly, all they see is what you basically, is what they need to see.

The custom elements, HTML imports, and Shadow DOM are the 3 core pillars of web components. There are other kind of related technologies but I think we're probably getting into a little bit too much detail to talk about exactly what they do. Those 3 things are the 3 key things that you need to know about. When I first read about web components, I thought the Shadow DOM was the most powerful thing. But the more I look at it, the more I see custom elements are where the real power is. And it's custom elements that are much better implemented in most browsers. Shadow DOM has... certain browser vendors have concerns about how it performs. Its effect on page layout, et cetera. So that's not as well-implemented, whereas custom elements are, in fact, very, very quite... well, not very, very... they're quite well-implemented already in Firefox and Chrome. So you can start playing around with them and using them kind of immediately.

Jen

Yeah, I mean, I... part of what sort of just blew my mind when I was looking into this, is the... is what you described with the Shadow DOM. That you, like what you said, could get a copy of Chrome and enable Shadow DOM and that's select list that's been there since whatever, you know, 1692. [Laughs] Since the very beginning of the web, is HTML. It's not HTML that we have ever controlled in the past, it's just the thing that's there. But underneath the hood, the browser itself is actually using HTML and CSS to style and to declare this thing that's there. And so this sounds like... not sounds like, this is a chance to then get at that HTML.

Peter

Precisely. I mean, we've... yeah, as you said, we've probably not realized, or just taken for granted, not even thought about this fact that every UI element in the browser is made up of markup and it's basically opinionated markup and CSS. So every select box, every input box, every range slider, everything that's on there is made up of other HTML elements. And they're all styled in a certain way.

Jen

And that's the thing, you know, where it's... those of us who really understand this stuff, sort of, have been saying for years. Someone comes along and goes, "Can you please change the whatever in the that thing?" And you're like, "Ugh." Scoff at that person, laugh at them, like, "Oh no no no no no no no, you can't style that. That's just part of the browser. Like, that's part of the browser chrome. That's, I don't know, it's written in Objective-C, it's some code-y code code thing that has nothing to do with anything [inaudible]." And, like, ok, A, it wasn't written in Objective-C, it was in fact HTML all along, and we couldn't, in the past, style a lot of those things. That's slowly been changing as CSS has been maturing and more and more of those things we can style with CSS. But now this is like, we could actually get in there and edit the existing HTML. We could actually alter what's there. Even the things that have already been around, it sounds like. And then we can also make our own as you described. Video is fairly new, so it seems more modern and cool, but also 10 years from now it will seem old and stale except we'll have been able to do something else with it. Alter it and keep changing it and grab other people's code to make it be kind of video plus.

Peter

Yeah, precisely, I mean, that's the whole name of this. Web components is about letting us get to this area that we've been sealed off form before. As anybody knows, who's tried to style a select box in the past, it's next to impossible to make it do what you want. And that's why we've ended up with these things like jQuery UI that completely replace... not that one in particular, but other UI libraries that completely replace these elements with things that we can style. By using more HTML and CSS in a different way and they just replace those native UI elements that we've not been able to style properly. This has not gone unnoticed by the people who are making browsers. They realize that we want to be able to do this stuff and they want to be able to let us move faster and let us move at our own pace to create these things that are better than what's there now and hopefully see them standardized in the future. I've been talking to a lot of people who work for browser vendors and other devs and things in general and we're looking... one of the things that seems to be a widely held belief is that part of the reason that apps have done so well on mobile platforms and tablets is because they have quite an opinionated UI. Apple have very strong guidelines about how an app should work and Google have very strong guidelines about how Android's thing should work. And so people, when they open an app, they don't have to keep learning this brand new interface all the time. Whereas that's completely the opposite on the web. We love creating stuff all over again. We love to do this thing so much and so there is a learning curve. You can go to 10 different websites and get 10 totally different UIs with no consistency between them at all. That's part of the reason, again, that these things are being looked at, is thinking, "Let us create our own new thing." Let developers create these whole new things. And then hopefully we could maybe - and this goes back to my original point again about peer review and best practice - maybe we could start thinking about a consistent UI for the web as well. Or consistent UI patterns for the web as well. And not have them just be a very superficial layer of things that we just stick over the top. But to actually have proper functionality. To be able to, as we keep talking about, the video element or the audio element, things that work, that are part of the core browser. But we can start thinking about how we can use them in a more consistent way, a more powerful way. I think that's quite a powerful argument. You see all the time people creating pattern libraries and things like Bootstrap and Blueprint, they're ways of doing things consistently. And why can't we, sort of... I don't want there to be only one way that we, that's the only way we ever do things. But why can't we have guidelines and the way we want to do things? And so if we decide, yeah, I think this is a good guideline. I want to do it, not just in a similar way that this guy has done but in exactly the same way. So I can just take the element that he's written, drop it into my page. I can style it, add my own content and everything, but it will work in exactly the same way that his does. I think that's a big argument in the favor of web components as well.

Jen

It reminds me a bit of why Flash was so popular, or why building an entire website in Flash, so that the actually web technology was just, "Hey, this is a webpage, load my Flash movie now." And then everything else, all the content, all the navigation, all the links, everything was inside that Flash movie. In part people liked doing that because they could style the UI elements. They could make their own interface. They could create their own sliders and their own scrollbars and their own this-that-and-the-other. And I feel like part of why Flash failed, it's not the primary reason, but one of the things that we learned the hard way was how messed up that got. There's a reason why scrollbars are really hard to make. Very, very, very few people ever made a scrollbar. And there were so many Flash websites where the scrollbar was just hard to use. You'd try to scroll the page and scroll the content and basically the webpage didn't scroll, you were just stuck with a very small, usually shorter than you wanted window, and then you had to use the Flash scrollbar to go through the page. So I don't know. I think you're more optimistic than I am in a way. I think we're going to see a lot of... it is, it's very, very powerful. People should be very, very careful about this stuff.

Peter

That's what I mean. It's a huge burden. I don't mean burden in a negative way, I don't mean, you know, it's something we don't want to carry. It's something that we're going to take on. But it is a burden, we need to be very aware of what a responsibility this thing is. I do like to stay optimistic. I've seen some of the people who are working on Mozilla and Google and from the community who are creating these libraries and creating these patterns. And I believe there's a genuine desire out there to do the right thing and I always believe that if enough people are doing the right thing, then the people that are doing not the right thing will not be the ones that become the most prominent. Just a quick note on that, as well. There are a few different ways you can use web components right now. They're not production-ready yet, as they stand. I say that with absolute certainty. But there are a few projects aimed at allowing you to use them on your day-to-day. One of the which and probably the most well-known is Polymer. Polymer is driven by Google but it's a community project and another one, which kind of has the same one but falls on the Mozilla side, they have this thing called X-Tags. They both do more or less the same job. They both have a way of creating your own custom elements. They aren't quite the same as the custom elements spec. They're more like jQuery, they're like an API layer on top of these things. But what's great about them is underneath they both use a set of polyfills and a library of... yeah, polyfills and sort of best practice ways of doing things. They both have this layer underneath and they both use exactly the same layer. So these are not two companies working in total opposition to each other as many people seem to think, happens on the web too much these days. These are two companies who are sharing this essential underneath the thing of the right way to do stuff to work with browsers today, but just thinking maybe they could do a slightly better job or a slightly different job to the other one, on how we actually implement them. And then both of them on top of that have their own UI libraries which are, again, maintained by community and create patterns of things that we do. And quite often, they get shared between the two groups as well. So quite often an X-Tag, something that comes up really well in X-Tags will be adopted by Polymer and vice versa. So there is this element of cooperation that's going on together. Although there seems to be 2 competing libraries or 2 competing ways to do things, they're working in collaboration a lot of the time. And again that gives me real hope that these things are going to be done in a best practice way. But of course to go back to my original point, that's not going to happen all the time.

Jen

I assume that all of this requires JavaScript. What kind of fallbacks are there? How does this work with progressive enhancement and having that clean stack?

Peter

Right now if you don't have JavaScript... yeah, there's an absolute requirement for JavaScript right now. Progressive enhancement will be done in the same way that we have to do it now. We have to be aware of what will happen when things don't work. It would be the same if you used jQuery UI or something like that. An element that, if you create a custom element in your page and JavaScript fails or you have an error or for whatever reason it's not present, the browser will still, the DOM will still pass that element, it will understand that it's there. But it will just treat it as an unknown element. It will display it as basically... it will display the content as if it had a span wrapped around it. It will treat it as an inline block element. There will be no functionality attached to it, nothing like that. But it won't do anything bad. It won't break anything. In the same way that everything we do today kind of has dependencies on JavaScript, we have to create fallbacks for them, again if we're responsible about it. None of that's going to change. But there are lifecycle events to be added custom elements, so you can see if the DOM recognizes it. If it's already been processed and it fires events at certain times. Again, responsible coding will allow you to only bring in functionality, only bring in dependencies when you known that this thing has been recognized and is working.

Jen

I look over here at caniuse.com and I see Shadow DOM. Yeah, just to fill people in, people are probably wondering. It looks like... IE does not have any support for Shadow DOM or HTML templates and neither does Safari on Mac or iOS. Looks like all the activity is really Chrome, it's very much supporting both HTML templates and Shadow DOM. And Firefox is now HTML templates and Shadow DOM coming up soon.

Peter

There was, quite recently, a fairly well-known episode where the Webkit team announced that they were pulling the Shadow DOM from the Webkit engine. Because it actually was implemented there from a long time ago. It was actually implemented there, an early version of it, when Chrome was still based on Webkit. The Chrome team implemented Shadow DOM. And in fact, I think this is still the case, if you open up the inspector tools, the web inspector tools in Safari 7, there's still an option there to view the Shadow DOM. You can actually see the thing that's inside and it will display the elements that are there in existing UI elements. It just doesn't have that API to allow you to create your own. So it's not quite the case. This was actually announced by the Webkit team a little while ago, probably before Christmas. And it's not the case that they don't believe it as a technology and they're not having nothing to do with it. It's that it was implemented by a different team, they don't have anybody there to actively maintain it. And the spec is still very much in a state of flux, it's changing all the time. So Shadow DOM, although it was in Safari, and kind of is in Safari to an extent, it's been sort of pulled back. But they have said they're still working on all the other web components features, just in a separate branch. So they are working on it, work on the stuff is going ahead by Webkit, it's just they're being slightly more cautious about it. Firefox or Mozilla are full-steam ahead. They've got custom elements you can use right now, I believe, in Firefox 28 or possibly 29 when that comes out. They're working on that. And I follow quite a lot the bug reports. They're working on the other aspects of it, HTML imports and the template element, which you mentioned briefly, is already in there. So Mozilla are behind it. The Blink team are behind it. The Webkit team are behind it, albeit more cautiously. The one we're not sure about at the moment is Microsoft. We don't know their position because of course they don't develop in the ocean... in the ocean. [Laughs] They don't develop in the open. They might develop in the ocean for all I know, but they don't develop in the open. Although I've heard and I can't confirm this, I don't want to make promises, but I've heard that they are behind it and there will be announcements about it sometime in the near future. But until we actually see that we can't make any promises about it. Shadow DOM is the one that, at the moment, as I said, people have concerns about it. Valid concerns about it. And so that may be slightly slower to appear than the rest. But I think something like custom elements, in the way it is now, feels fairly uncontentious and as I said Mozilla have embraced it wholeheartedly. I think we'll start to see that happening in other browsers in the very, very near future. But the good thing about all these things is they can exist on their own. When we talk about web components, we're talking about a suite of related technologies. They're not things that necessarily have a dependence on each other. Just that everything makes everything else a little bit easier. Custom elements is the real core thing that we have to worry about. Shadow DOM just enables you to... I mean, it gives you more, it gives you, encapsulation of your content as I said. It lets you hide away content to make it less visible to the day-to-day developers. HTML imports make that shareability much easier and the template element, which I don't think we explained properly. Just to make people clear, what it is, the template element essentially hides... well, it means any markup inside the template element will not be passed by the browser when it's rendering the DOM. So anything that's in there is hidden away. If you've used anything like, any tools like Handlebars or Moustache or client-side templating engines, the template engine is kind of a native way of doing what they do. Getting blocks of code, which don't need to be rendered immediately, but are then rendered afterward using JavaScript. They're kind of activated when we've got data to fill them in. So the template element makes client-side templating that little bit easier. It doesn't do a lot but it does that one thing very well. And that's, as I said, that is also fairly uncontentious, I think by most browser vendors. It's already in Firefox, it's already in Chrome and will doubtless follow in others in the future. It just makes the other stuff that little bit easier, that little bit more efficient. But everything can survive in isolation. All of the technologies in the web components suite can work in isolation, they just work better together.

Jen

Are Polymer and X-Tags sort of structured the same way? These are things people could use now? If they use them now, will they begin to learn some of the techniques and perhaps best practices, or perhaps learn the hard way, don't do that again, in a way that's very similar to how things are going to be once the official specs arrive in browsers?

Peter

Yeah and that's precisely what they're for, really. Polymer especially is kind of, they use... Polymer is a library of polyfills or a layer of polyfills and then a core layer on top of that, which is as I mentioned, think of it kind of like jQuery. It provides an API. As jQuery provides a more convenient API to JavaScript, so the Polymer core kind of provides a more convenient API to creating custom elements without you having to know everything about custom elements and everything about the Shadow DOM. It does a lot of that hard work for you. Then they have the layer on top which is the UI library. But it also polyfills support where it's not present in other browsers. I would hesitate to say you could use it in production state, although a few websites have. Most notably the Polymer project itself is built using Polymer. Dogfooding as it were. But they are very clear on their site that it's still in alpha because things are subject to change. Whether you bet your site on this still working in the near future, I would probably hedge my bets a little bit in that case. But you can definitely start building things with it right away. And it's the best way to get to learn these things because a lot of the... where the specs are in flux for things like... custom elements is now fairly stable but Shadow DOM is still very much in flux. So where these specs are in flux, things like Polymer core will actually smooth over that a bit for you. Again going back to jQuery, if something changes in JavaScript itself, the jQuery API could maintain its same endpoints and hide that change from you. That's kind of Polymer and X-Tags is the Mozilla equivalent and the only difference is their UI layer on top is called Brick. But they're basically exactly the same thing. They'll hide those changes from you as much as possible so if you want to learn how to do them you won't be learning how to create web components using the web components API but you will be learning web components, the methodology and the reasons for doing things in that way, those will be taught to you by using those libraries. I really recommend to people to go out and try one or both and just give them a try on when you've got a spare 20 minutes or something. Because once you get hands-on with these things and you start playing with them, then suddenly it's like something opens up in your head and you can start seeing opportunities for everything. Some of the elements that have been made already... like, we started off doing UI elements. We started off doing, you know, wouldn't it be cool if there were an input box that also displayed something below it. I can't think of a perfect example of that right now. But then people started thinking, "Well, why do they have to be UI elements? Why can't we make them do anything?" A great one recently was, you can do XML HTTP requests as an element. Why not? You could just drop that element in your page, feed it a couple of parameters, and it will return to you the values that you wanted to get from it. So we already have kind of some elements like this in browsers now. We have a link element, which goes in the header of your document, which goes off and fetches a resource and brings it back to you. There's nothing exposed to the browser UI, it just does a job. But once you start thinking this way, you suddenly realize there's so much opportunity to do things. Combine 3 different technologies that we use everyday and drop them into one element and just make it super easy for people to use. I don't think we talked about... we talked a little bit about semantics earlier, but I think you touched on the point which was really good, is that it kind of makes markup become meaningful again. Which is really good. If before you had a carousel which was made up of 25 nested divs. Although you could put class names on them to add some semantic value, isn't it more meaningful to someone who comes and looks at your markup afterwards, if someone's maintaining your code and they see an element there called "web carousel" or something like that, it just becomes more meaningful. The values we pass into it, the attributes it has, can have real meaning and they make the webpage less, they make the markup lighter and cleaner and a little bit more meaningful. I think that's the real positive side of web components and custom elements which I find really attractive.

Jen

So. Semantics. Somehow when I think about web components for doing things like having a more powerful video tag or having some kind of input form that makes more sense for the content that's getting added to the site instead of being forced into this 1990s style input form. That kind of, where HTML meets functionality, it does... I am starting to get excited. Like, oh, yeah. But it seems like there's a little bit something different. There's a possibility that people could think of web components, when they first hear about them, and you know, "write your own elements." That interprets that as, using HTML or making your own HTML elements to do the kinds of things we normally use HTML for. Which is very flat. You wrap a paragraph around a paragraph, you wrap a list around a list, you wrap section, an article. There's not a lot of functionality that happens with those choices. A lot of those choices are essentially, you're communicating to screen readers, to the browser itself, to archival, people in the future, for archival reasons, you're communicating to something like Instapaper, how to style the page. But you're not... there's no functionality, right? Could you see where people would want to create their own elements in that way? And make something more semantic? And why would that make sense if no one else, if nothing else out there, like Instapaper, like Google, search bots that index the web, or a screen reader, have any idea what that stuff means?

Peter

I think you certainly could do that. I don't think that's a primary function of why they were dreamed up. But I can also definitely see cases where... you know, large organizations sometimes have their own internal components libraries. I'm thinking about for example React.js is Facebook's own component library and it was also used by Instagram. They work on such a huge scale sometimes of these things that it makes sense just to have things that only work for them. Maybe it doesn't need to be crawled by Google or whatever but it helps to be able to describe their markup or their patterns in a certain way. And I could definitely see a case for having it in that case, in those cases. Say you, you know, you could build your own components library that's only ever used across your huge site which just adds meaning only to the people that work there. I can definitely see that. Whether that could be abstracted across multiple sites across the web, I see maybe less use for it. Perhaps it's just my own lack of foresight and ambition that I can't immediately picture that happening. For me, I think the exciting bit is the UI elements and especially extending existing elements as I mentioned earlier. I think that's a really, really exciting thing to do. To take the hard fort, meaning that we have already that's been implemented and honed over 25 years in the world web side, and just being able to add new behavior to it. I thought the other day, for example, of an input box which, as you type, say input type=credit card for example. As you type numbers into it, it just automatically recognized what type of credit card you're using. We've seen widgets built like that already that do that kind of thing, and I just think there's huge scope out there for making those really common, painful little tasks that we have, go away. For me, personally, that's where I think the big wins of web components are going to come. I should say, I'm looking at this from a developer's point of view. I'm looking at this as someone who's written HTML for, gosh, so many years I can barely recall, 13 or 14 years I've been writing markup and things and wishing I could do things better and wishing this thing did this or having to compromise by using external UI libraries. But I can imagine that people who have different needs from the web, the people who create browsers for example, or the people who work on these huge websites like Instagram or Facebook, as I mentioned before, I can see where they could probably have a completely different requirement of web components than I have. That's where I think, from having spoken to different people at different places, everybody seems excited about it in maybe slightly different ways.

Jen

It's interesting. There is something... [pause] it feels like something that we're going to find out in the next 3 or 4 years, we're going to figure out what this is. It's like everybody's very excited about getting some kind of super power but nobody's quite sure yet how that is going to change the world and why that's going to be good, they just think it's going to be good.

Peter

Right, it's like sending your first Tweet or something. When Twitter came out, everybody's first Tweet is like, "So what does this do?" The people who wrote Twitter, even the people who, I'm sure when they realized what they had they thought it was quite exciting, I don't think, I'm sure at the time they never thought that in the future you'd have the President of the USA sending Tweets and live Tweeting revolutions from around the world. Sometimes we can't see the thing until we've got a few years into it. It's like the analogy I heard used, which was quite good is like, if you were in the beginning of the 20th century and looking at airplanes, you'd be going, "Well, they're slow, they're fragile, they crash a lot. I can't see what these things are for." Things quite often get written off or just not even appreciated until somebody builds on the things that have already been done. There's this kind of incremental progression and we start to see clearer pictures of patterns emerging and I think, I genuinely feel that this is going to something that we see with web components. Even if it's not in the exact form that they are now. We have to remember this, you know. While I can see a broad agreement amongst browser vendors to implement these things in more or less this way, there is still some disagreement and things have already been dropped from the spec and marked as perhaps we'll come back and look at this again in the future. So it's entirely possible that things will change a bit. But I think broadly this idea of letting us create the UI that we want to have, letting us create the behavior and the elements that we want to have, is such a powerful one and I think once people realize that, I can't see any way that we'll go back on... this all will be dropped and we'll chose something entirely different instead. But again that could just be a lack of foresight and imagination on my part.

Jen

Well, it's interesting, too, because HTML5 did bring different input fields, for example. And yet so often I see them not being used. So people could easily be using a number or some kind of other select element to vastly improve the user experience of the website that they're on, and yet they, even if it's a new site, it gets coded up as if it's 2002. It will be interesting to see how this works out. If people are already not using elements that totally work today... I don't know. I don't know what I'm saying.

Peter

I take your point. I completely agree. It becomes kind of, it's really forced on you when you're using a mobile device, for example, and they ask you to enter your telephone number and you have to kind of switch the keyboard to a different way and you go, "If you'd just used a number input in there, that would have been so much easier." I think this is all kind of all fairly new. We talk about HTML5 and the number element, sorry, the number input type and all that, but it's probably only been maybe 3-4 years since that was introduced and fairly broadly implemented. There's a slight delay in getting that education out to newer generations and also perhaps I think we've been kind of slightly hamstrung by this notion that we can't use HTML5 because it's not ready yet or it's not fully implemented in browsers or I can't use it because Internet Explorer 6 is still around or 7 is still around or 8 is still around. Sometimes those are absolutely valid concerns and sometimes you have to put in extra work to make these things fully, degrade gracefully or progressively enhanced and you don't have the time in your budget to do that kind of stuff. Sometimes I think that's a valid concern but I think sometimes people are just too, or can be kind of just too nervous or take it as read as if something hasn't got 95% support in browsers then they're not interested in using it. Web components I think at the moment it's a bleeding edge thing. Even with libraries like X-Tags and Polymer, I think it's probably going to be, honestly, towards the end of the year or even into next year before we start seeing real production use. It's something that's coming. But I think it's such a change to the way we do things. It's such a big responsibility, such a big burden for us to take on, that I think it's really, really important for us to start talking about this stuff now. That was brought home as I mentioned at Edge Conf. I was there, I was really excited about it, we had representatives of Instagram and Google and Mozilla, loads of people on the panel were all really excited about it. The questions that came from the audience were about accessibility and performance and security and in the rush to want to use these things, you sometimes forget about that, and then all these questions, all these concerns, really bring it home to you again, "Wow, we have got this incredible burden on us." So it's great that's being talked about now. It's great that it's being talked about so far ahead of time so that we can address these problems and start thinking about these things early. So that when we are ready to use them, hopefully we'll have settled on ways that we think are the best ways to do things.

Jen

Yeah, I mean I think it is why I've been so rant-y the last several months about web standards and best practices, accessibility and progressive enhancement because it does feel like there's an edge here where we could blow all that stuff off, go running off with these new superpowers, and just create, like you said, rubbish. Create websites that are less usable and less successful instead of more so. It sounds like what we really need to do this year, in 2014, is just continue to teach each other and remind each other and think again about why is it that those kinds of things are important. Take time to learn things, learn more about semantics and accessibility, how to write really great HTML. What good HTML looks like.

Peter

Maybe if 2013 was the year of workflow, maybe 2014 will be the year of empathy. I'm really hopeful that we can start seeing more of a conversation and reminding ourselves about, we're not just doing this because the tools are cool, but we're doing this because we want to build great, useful things for people.

Jen

Yeah, well said. Thanks so much for being on the show and explaining web components to us all.

Peter

Thank you. I hope I've done an acceptable job to your listeners.

Jen

Yeah. People can follow you on Twitter, right? Your username is @stopsatgreen.

Peter

@stopsatgreen. Which sounds kind of, very, esoteric and perhaps mystical but it's just an anagram of my name.

Jen

Oh! [Laughs] You don't stop at green lights?

Peter

No, exactly, that's what people think. "Oh, this guy, he goes against the grain. When there are green lights, he stops." But no. It's just a convenient anagram of my name.

Jen

And they can also read lots of things that you're writing, over at your website broken-links.com.

Peter

Precisely, yup. And do feel free, everybody, to get in touch with me and tell me where I've been talking rubbish and where I've been talking perhaps a little bit of sense. Because it is really important we have this conversation about these things and I can point you in the direction of some really interesting community-led discussions around the power and responsibilities of web components.

Jen

Great. And it sounds like people can join in, there's a really great place to join in, become part of an open source community, invent stuff, get to know people.

Peter

This is the best thing about these. Things like Polymer and X-Tags and Brick, they're all hosted on GitHub. Anybody can drop in pull requests or raise issues and there's conversation going on this stuff. If web components were just being developed in secret by, you know, the team at Blink or something like that, I think we'd all be a bit more nervous about them. But the fact that everything is going on the open is really important.

Jen

Nice. Nice. Well, and people can follow the show on Twitter, @thewebahead. It'd be fabulous if you wanted to go over to the iTunes store and leave a review or a rating. People have been jumping in to help out with transcripts for the show. You can go to transcripts.thewebahead.info. The repo is on GitHub and you can open up a new issue and say, "Hey, I'm going to work on episode 66, I want to transcribe it." I think we're going to get some momentum going behind this effort and end up with a lot of transcripts of the show, so I'm really excited about that. People can follow me, @jensimmons, on Twitter and come back or subscribe, I guess, really, go subscribe to the show to find out what's going on next week. So, thanks again Peter so much.

Peter

Thank you, pleasure was mine.