 Thank you, Andrew. Is this thing on? Yeah. Okay. Good. Hi there. We are the warm-up act for Jake Archibald And we're gonna be talking about components here, which is okay. By the way, that's fine. I'm good with that So my name's Dan. I'm just gonna briefly introduce people and then we're gonna then we're gonna have a talk a brief talk and then we're gonna get into it so My name's Dan Applequist. I work for Telefonica and I do Firefox stuff Firefox OS and I and I co-chair something called the tag in W3C Which is kind of the technical architecture steering board for for W3C On our panel today. We have a Panoply of stars here. We have Nicole Sullivan from Pivotal Labs Who is a proponent of a component-based systems and she's the creator of object-oriented CSS type of mattoch and CSS lint We have Alex Komorowski from Google who's a product manager on blink and polymer With Pete Hunt from Instagram slash Facebook member of the React core team We have Soledad Pinedes from Mozilla who's working on things like mortar brick and X tag We have Peter Gaston Who is a creative technologist and an author and Speaks about web components and we're gonna hear him speak right now So without further ado, I'm gonna ask him to come give a kind of intro talk. Tell us about components. Thank you very much Okay Better login first, excuse me And my screen is locked embarrassing, but I can get over it. Don't worry. I'm a professional I've done this thousands of times before stood up here and embarrass myself thousands of times before Thanks, so good morning, I'm here to do a quick talk about Introducing web components. I know some of you know them already, but I want to kind of give a little Overview for everybody about basically the why the how and the when of web components Don't use that hashtag. That's the oh, no, that is the right to hashtag. I corrected it Good on do use that hashtag. I corrected it. It's okay. My name is Peter Gaston I tweeted stops at green. I'm broken right for broken links.com and I take technologist and front-end lead Which is a very cumbersome job title for an agency here in London So it's kind of my job to think to look at new and future web technologies and Evaluate them and see when we can use them and one of the things I'm most excited about the moment is is web components So I'll be very much playing the role of the excited everyone developer in this panel of stars. We've got here Ever since we've been developing for the web we've been copying other people's stuff That's there's no shame in that. That's how the web kind of grew. That's how everybody got their knowledge I learned by copying other people's stuff. I'm sure most of you did here as well The view saw the view page source is one of the finest inventions of the web well done to the original early browser Makers for kind of making that possible for us But as we've as we've done that it's kind of become quite cumbersome to copy other people's stuff It used to be you know, we nick a little line of code here and a line of code there But then it just gets bigger and bigger and more and more involved to actually do that But we still want to reuse other people's stuff and we want to reuse our own stuff across our own websites as well Some of the early efforts are kind of making this copying and sharing easy were Java applets If anybody's about for the web over 10 years ago There's a very very good chance you had a photograph of a house on a lake with a rippling lake underneath it That would have been made with a Java applet and then we had dynamic drive Which was the best place to go to if you wanted animated stars to follow your mouse around the around the window But we started becoming kind of more professional with the way that we wrote our code afterwards to make it more shareable to make it More reusable we had fantastic efforts like Nicole's object oriented CSS which become like you know Very very popular loads of people use it and have been even more formulaeized into things like them languages like or protocols like them And in terms of other sharing we've a we've even had kind of whole elements whole UI elements Libraries grow up to enable us to start using to stop having to code our own carousel 5,000 times and instead copy the carousels of other people Efforts like jQuery UI and more recently bootstrap have enabled us to do that. We write our code in a certain way and things just happen Even bigger much more Powerful ways of doing this Power some of the biggest sites on the web today We're looking at things like React which is written by Facebook and Instagram who Pete here is going to talk about later today and Fantastic hosts the financial times have their own version in fruit machine. These are kind of Template constructors you put in JavaScript and outputs all the code for you And you can power that through node and you can build whole very very powerful scalable systems But just based on this idea of copying and reusing other bits of code other elements So this is not an idea that web components is kind of a formalization of all these ideas It's looked at all the things we've done in the past and it's kind of said well people want to do this Let's make a standard way of doing it Let's make an easier way of doing it that hooks into a kind of a low level of the APIs and of the browsers And makes this much much easier to do so where the goal is Reusability the answer is web components There are three There are three kind of core parts to web components So big bud the first parts Let me gather my thoughts. There are three parts to web components. The first is what are known as custom elements Custom elements when I first read about web components I thought they were kind of more of a background thing and shadow Dom was the big thing that everybody was really talking about But in fact as I see it as I look at it custom elements are web components They're the core thing without anything else custom elements of the bit we really really want to use The idea behind custom elements is that basically everything is an element Everything we do and everything we have on the web is an element That's kind of a core thing that drives the polymer project, which I'm going to talk about in a little bit But it but custom elements themselves For a long time we've had elements like Image and if you provide a source to that image element it puts an image in the page at that point And we've had things like inputs if you say input the typing it was arranged It outputs for you a UI element in a consistent way across all the different browsers, so We want to do that. We do we like having those consistent UI elements, but why stop there Why not have everything be an element everything we do all the time could be an element? So why not have for example a Google Maps element you give it a latitude and a longitude a longitude and outputs a Google map into your page at that point Why not extend existing elements so we can say the video element which we generally have in the page anyway Also accepts video camera input we extend it with web RTC Why not have Ajax calls be elements why not put them in the page we do that all the time We want those results. We want to put those results in the page at this consistent place So why not make this into an element as well? creating a Custom element is very very simple you create a new prototype object You can add methods to it You then register those elements into the DOM by giving a unique name Which has to be hyphenated like this to make it compatible with current and future standardized HTML elements and Then you just tell it which prototype to use and that's basically it you registered the element with the DOM you've given it some methods You've given it some properties and then you can just include it in your page So you can do anything without that is exceptionally exceptionally powerful all of those things I just showed you before Google Maps the Ajax calls the videos they all start by basically doing this But once you've written this that's not really I mean that's kind of nice that you've contained all this You've attached all these properties to this element, but then you want to share that element You want to make it shareable everywhere. So that's where the second part of web components comes in These are called HTML imports and they are simplicity itself They're just like including a JavaScript file or referring to an external CSS file But it's using snippets of HTML markup. Hopefully with all your attached behaviors So you put a new link element in the head You say it's a link out is an import link and you give it an href And then that allows you to take your custom element and apply it to all of the pages on your site But more than that it also allows people to take that same code that you've written that same and import that same snippet file And apply it across all their sites too So it's immensely reusable, which is really really cool. The final part the final core part of web components is the shadow DOM Shadow DOM is a nice idea. It's not vital to web components, but it makes them really really nice and useful and It actually exists right now many of you might have seen this already if you open up Chrome and even in I think it's even in Safari still and you choose the show shadow DOM option You can see the markup inside these UI elements that we use for example If you have an input type equals range if you view the shadow DOM of that you can see it's actually built of other elements They're just not exposed to the user They're hidden inside that and that's what a shadow DOM is it's the DOM inside the DOM that's hidden from the from the from the user In most stances that kind of powers the element the simplicity of the element There are also a few things which aren't part of the web components spec or but are related to and make it way Way more extensible and useful one of them being the template element which allows you to drop markup into your Into your document and not have it passed or not have it rendered until you explicitly tell the browser to render it we have mutation observers which Look for changes in the DOM and fire an event when they happen And we have scoped styles which allow you to apply CSS only two specific elements as opposed to being globally scoped as they are at the moment So who's on board at the moment most of the work is being done in Chrome If you look in Chrome nightly or the dev channel, there's a lot of this stuff that maybe you have to enable it through flags But it's all in there because of that a lot of it comes into blink sorry into opera naturally as well as they're based on the same blink engine Firefox is doing an awful lot of work in this as well custom elements are in there I know they're working heavily on the shadow DOM and the rest of the suite Microsoft we're not sure about at the moment But I think the signs are good because they're involved in some of the extra stuff like mutation observers And also they've got history in this internet explorer five actually had this thing called HTML components Which is really similar to what web components do nowadays So in this case kind of Microsoft is sort of the the proto hipsters of the web components see Finally there's Safari and really who knows If you want to use them today, you've got two choices or you've got two main choices There's two libraries called polymer and X tags one's kind of they're both public But one's kind of driven by Google one kind of driven by Mozilla Polymer has its polymer core, which is where you do the registration X tags has its X tag core Polymer has a UI a set of UI elements on top and X tags have brick which do the same job and they both share This platform underneath they both use the same platform to polyfill where these things are not present natively Which is really really good and makes it the fact that whether you choose one or the other You're still working into the same code base underneath, which is really helpful for kind of moving forward The outcome that we get from this is meaningful markup We get reusable elements and hopefully in the future who knows even a consistent UI Maybe the web could have a consistent UI like native apps have That might be something that we want to move towards to make it easier for people So we can stop reinventing the wheel on every site we build the challenges are To put it politely a proliferation of crap If we let people create their own stuff, they're going to create some crappy stuff, but that's not a reason to move on that's not a reason to to stop viewing them and performance people flag performance accessibility and Internationalization and those are all the things we're going to talk about today So web components are the future for better or worse. Thank you Okay. Well, so Given our Thank you. First of all for that for that intro, I think that gives us a lot to think about and I think it it nicely Intras us to our first questioner. I'm going to ask Yoav Weiss to Stand up hopefully and to yes, thank you and to ask the first question of the day Hi We're all aiming towards better page load times HTML imports can include other imports ES6 modules can include other modules To what extent does using components breaks web performance by breaking parallelism? So performance immediately, so that's first of all, I'd like to I'd like to ask Pete to to maybe You know as you're a company that that that has a strong emphasis on page performance and on performance You know, what's what's your view on that? You want to just get the trolling out early? Yeah, basically. Yes Well at Facebook, we found that flexibility is the most important thing that there's not a silver bullet to initial page load performance You can actually Improve page load performance by deferring certain things. So for example, we found that actually adding JavaScript to the page Can improve page load performance if the JavaScript isn't driving an important part of the UI At the same time that we found we found that the raw kind of if you want to just say What is the fastest way to get a UI into the browser? It's server rendered HTML every time So for us, we're not going to adopt a system that requires you to either server render or to client render I think that the the trendy term for this is called like isomorphic JavaScript, but Every system that we have we need to make sure that that we can choose where on that spectrum Do we want to server render or client render and at which point do we want to push that data down the wire? Which is one of my big concerns about web components because it's blocked on the JavaScript execution and it's tied tightly to the DOM APIs So HTML imports the top-level import from the main document does block rendering just like a style sheet does There is an async attribute that you can use to say do not block anything and then within imports themselves Which are not blocking the main page from executing script or parsing and that kind of thing You might have a complex interdependency of different things We found it's much better in that case too It's much easier to reason about if you don't have if you do block those those contacts as you're loading together resources However, one thing they remembered to is that web components provides a set of new tools that don't take away any tools So there's certain best practices that we've discovered and that will remain so for example when you're doing development Sure, you might want a bunch of different HTML components and separate files But when you deploy to production you might you might want to compress those and minify those into one resource We've also found that you can do a lot of interesting things like using these tools and using async and some judicious Use of that some of this stuff you could for example to find a very simple component. That's just markup That's actually in the head of your document so that loads very very quickly for the user and then load the more complex component and use that when it after it loads. Yeah, I'm actually I Think I like HTML imports. They seem pretty good They seem like one of these tools that you can use to shoot yourself in the foot or not As with many tools and yeah, I mean like like that's a sign that it's a good tool Can I have a little bit dangerous to make sure that you would have multiple versions of the same component and load the simpler version first So layer on a more complicated version again It's extra tools and one thing that's interesting in this is with these extra tools We found today on the web platform. We've got a set of tools in the web platform Some of her kind of janky and busted, but they're what we've got we've added a few more tools on the end What I found is that we found a lot of best practices today that we've all sort of discovered using this set of tools that we've got and actually adding a few new ones brings question, you know Opens a possibility for different best practices that are actually even better And one of the cool things about this is I feel like on the polymer team and people who are using polymer and X tags We're kind of the pioneers. We're discovering this stuff and saying oh my gosh That's an interesting pattern that looks really crazy before but actually now makes a lot of sense So a number of folks have been experiencing with that kind of stuff We don't know what the best practices are for every case obviously to come over to this side of the room First of all, I wanted to ask something about it. Did you did you have a performance related comment? I have this thing I mean when you require kind of like complicated you I maybe it's not the mother of a page You're going to be talking about the nap. You're in that different space So I don't think you can really consider the same case. I Don't think it's equivalent. It's like you I mean Instagram is a different case I guess it's like a hybrid between an app and showing content But the case we are we're having with components is many times you're building a complex app like with you eyes and stuff You really need to wait for the whole thing to wait like to load like before you can start like it has to block You can optimize and everything but has to look at some point you need to wait It's like it's all about option value though, right? Like we don't want to commit to a technology where you have to say these are my performance characteristics and the way that I That we're starting to think about Initial page load performance now is that when you open your Mac laptop or you open an app on on an iOS device You see a static screenshot of the previous version of the UI before the real UI actually initializes Now wouldn't it be great if we could build all of our web apps like that We could render it on the server send down a static HTML page that can be cached And reanimate it with JavaScript. So I'm just I hate that Kill but you have the choice though. Okay, would you want that choice? I guess the point is it's still up to the developers to figure out how best to use these tools for their particular uses So can I say as it like a Someone who's not involved in the high level of creation and kind of an end user of them for us the choice often comes down to Is it better than what we've got now? So if we want to use something like jQuery UI or something or an existing UI library do Web components make that faster or better. I can't really tell that until we have them natively and they're implemented I think personally, I think there will be better But I don't I can't really test that until we're all finished implemented I want to come back to the server side rendering point you made and I know react has a mode where you can sort of ships down the rendered components directly in the main body and we actually have found this is an example where Some people have explored using going all web components teams at Google who are prototyping on this actually found they were People who are big opponents of server side rendering they actually found in some limit in some cases that it was actually faster to just heavily cash the components client side and then just ship down the Sort of component based markup and have it inflate locally That's pretty similar what we found as well But we found that the best thing is that you want some of your components rendered server side some of them rendered client side And choosing that mix Well, because I think the rendering is going to take a lot longer client side Yeah, the performance characteristics of how much CPU you have on the machine network speeds latency that kind of stuff will definitely I think so also, I wanted to Open things up to the To to the audience here, and I'm looking over to Andrew. Is there I mean where how? Okay Just want to make sure So Yeah, the other thing too is that we found again the polymer team in particular is on is actually part of the larger blink team So polymer is the way I think of it is kind of almost a means to an end I'm making sure there's good feedback going into the specification process because it's very hard to design complex specs In a room just through discussion It's also we're identifying use cases that make a lot more sense in the web components world And we'll literally yell over back, you know, hey Adam, this is something that we run into a lot This is a very common pattern I say oh, yeah, we can actually you know if that pattern is going to be common we can do Obquisitions in the engine so imagine this new world. You'll see that different patterns become more common or things that are Will be Interesting though because if you look at the UI libraries that are out there, you know bootstrap or jQuery UI or object-oriented CSS any of them They're solving the same 50 problems over and over again So while I really like web components and that you can do anything with them I think maybe the browser should have solved those 50 things like tabs and carousel and some basic stuff That's on like every site in the universe that we need zero JavaScript for those things So we actually should should move on to the next to the next Bookmark that save it and let's let's bring it to the rest of the discussion. So next I'm going to ask Jonathan Fielding To ask his his question So how do components help or hinder responsive design given that many queries of the orphanology Components, how do components play well with responsive design approaches? Okay, so I'm gonna hand that one over to sell it out first. Okay I've got mixed feelings about that. I think that you shouldn't be building Components that not too much about the look and feel of the app That thing should be something from the outside. I think like If you're like involving your component with Aesthetics, maybe you're doing it wrong. I think like it should be about Functionality at least in my view and I think it's a view of everyone else like and I mean even you have shadow them and you have a scope CSS and things You can't really put too much Look and feel inside that thing because you want to be able to see him from outside and have break bones and everything So if you put everything to a component, it's not going to be reusable I think actually there's cases where you don't want styling or you don't want to be too opinionate There's other cases. I think we're developers would love I think bootstrap is a great example where it's a well-designed set of things that you can use that play together nicely and I think there's a lot of room here for like a opinionated UI components But again because people can choose to use them or they can choose to do these different libraries But it's a tool and there's going to be a spectrum of uses I think yeah But you can't really put the whole set of break points inside the components It's just going to be a component works only for this page and it's not going to work for another set of designs That's that's why it's such as I mean it could be nice good enough I mean that's what we're doing break make it look good enough so that it's not that ugly But don't don't try to assume things that people are going to want to make it decent Yeah, I think web components kind of put a much stronger onus onto the developer now than it has to and what's been kind of From the browser makers in the past to people are going to start seeing how hard it is to create for example a select element And make it accessible and make it responsive and make it work across platform And we don't have kind of these dedicated teams to do that. We have to work this stuff out for ourselves We're going to see this a few more times in some of the other topics we talk about I think it's how much more of a burden that becomes on us as developers But it's also like a good responsibility the fact that we are shaping these things in the way that we want to use them We want to be in the future. So you say a burden. I say it's empowering developers So to your point earlier Nicole you were talking about why don't we just ship carousel specks your carousel and ship it? Before web developers weren't on the same playing field as browser vendors So like we could implement some of these built-in controls using things like shout it on that you guys couldn't use And so one thing that we're excited about on the polymer team in particular is this idea that people can play around Like there's a exit X desk gift at someone sharing yesterday. It's really cool Like I don't know if that should be standardized and shipped in browsers But the cool thing is that people can use it and it feels just like a built-in element And if everyone is agrees that those are the semantics that we should use and everyone loves it Maybe that is a target for standardization because now we have developers are empowered to experiment and to play around in Explories in the same tools that but how frequently has someone made a built-in element for picking something and in fact on my mobile phone It doesn't work or in you know some other contexts They haven't tested for or they're really used to an Android browser And so they made it exactly mimic that and so then in whatever I'm using it feels weird and has this uncanny valley Like it's sort of that thing, but it's not really quite that thing Yeah, I think that this is kind of what we were touching on earlier and what I really want to jump in for is There's kind of like two things where native apps are kicking the web's ass The first is is performance and like we can go into that forever But the other thing is that the widgets that you implement on the web don't behave exactly like they do on Native devices or you don't have them rather so you have to basically polyfill them and they don't have exactly the same so you know While I kind of believe in the extensive the extensible web manifesto where we want these primitives to build whatever we want It's also important to get kind of the integration with the system level components So your UI table view actually feels like a UI table view on an iOS device And it the equivalent feels like the equivalent widget on Android So I'm gonna go to the to the audience a little bit. We have Remy Sharp somewhere All right, so let's let's go to Jake It regards to the responsive design thing Yeah, like having everything as components makes total sense, but don't we have a fundamental problem that we don't have a component model for Responsive design when we use media queries. They are to the viewport not to the component So the question is about, you know What they're being Restated without restating it. I read Tabakkins wrote a very thoughtful article on this thing because having responsive components that are just responsive to kind of in themselves And not to the viewport is a great idea and it's been floating many times But there are very very hard technical problems to overcome before that. I can't actually remember exactly what he said Basically any time you're going to have rendering that where the child can influence the parent and the parent can influence the child You can have loops in your rendering and that can't work like we that that can't be a thing that can be implemented And so yeah, it comes up perennially that people want To be able to have like a media query on a particular elements with but like we need to let that go. It cannot work That's a very thoughtful post on this. I can't remember his conclusions One thing that we found is in polymer where we really embrace that everything is an element almost to an extreme Is that you build your app kind of and you're like, oh, I'm always going to talk about all thing And then next week you write another app that has like tabs with you know Different applications inside of it kind of and so it's important as a component author to think not just how am I using this But what other contexts could I be used in some of the tools like media queries might make more sense? For elements as well. But again, there are some challenges to deal with there before we move on to the next topic I we have Sorry if I'm mispronouncing your name, but narcisso What we found especially in highly designed applications that's really important to preserve the separation between functionality Components should be about the behavior Is there anything architectural or a component author to just worry about the behavior and then not make too many assumptions about what the behavior is like? Thoughts, quick thoughts. You could, I mean, it's up to the component author to do what they want. I think there's gonna be a spectrum of opinionated UI components that are themeable and ones that have no opinion on UI. But I think there's scope style, which helps with this. But also, I think that, you know, that only gets you to a certain point, right? Like, at some point, you know, the appearance of your element has to be coupled with changes in behavior as well. So I think really focusing on the composition of elements and how, you know, if I've got a component, like, do I want that full dropdown functionality? Like, what if I want to add separators inside the dropdown element and that developer didn't think of it? So we need to think really in terms of composition, not only of styling, but also of behavior and the way that data flows between components as well. So before we move on to the next thing, I just wanted to, Jonathan, you're on the queue. Quick comment. So if you've got some bookouts you want on the mobile and you've got some bookouts you want on the mobile, some stuff on the responsive site, would you show and hide different components? It's going to be up to the developers in different cases. We've played around with on the Polymer side. Most of the UI elements we have now are just explorations. Well, and just like building the UI libraries of, you know, that have come up until now, I think there are UI libraries that are very opinionated, like this thing is going to be exactly this width and it means you can only use it when magically that's the width you need. And the better UI libraries and the ones that have sort of emerged are the ones that build tabs that fill in whatever space is available. There was also an earlier part as part of the earlier web development suite. There was an idea of these things called decorators which are HTML markup applied with CSS. So you could apply different markup and use your media queries in that way. But again, there were like insurmountable technical problems in doing that and that's had to be dropped. So I don't think this is something that's going to be easily achieved. I'm going to have to cut it off there because we need to move on to the next thing which is Joshua Peek. Can you please speak your mind? I've done a lot of work on GitHub's implementation of content security policy. I'm wondering how web components fit into CSP. Polymer and other polyfills make use of eBell and HTML imports to be able to declare the scripts in line. In general, how will web components become another attack vector and what's the general story for security in web components? So again, we're adding some new tools without taking others away. It is possible to use web components within a very restrictive CSP environment. For example, Chrome apps have a very restrictive CSP environment and although by default in Polymer we recommend people define their script right in line with the templates. There's a version of our vulcanized tool that will allow you to actually have those external scripts that will evade CSP policy and not be developed. In the main comics of the page. Other thoughts on security in general as well? Like it really occurred to me when I was reading this question about, I think I added the thing about can web components be a vector for attack in some way. And I guess thoughts on that from any of the panel. Have you thought about that? I think we should define. I mean, you still have the same content, origin, restrictions. It's just a JavaScript. It's not different JavaScript. It's still in that it's running the same way that all the JavaScript is running. So you should still get your browser angry if you do something inappropriate. So I think we should define. Haven't tried to break it yet. And there are a number of attack vectors. If you use third-party content, for example, you don't have, if you don't use CSP and cores effectively, there's attack vectors on the web today. This doesn't change any of that if you're using someone else's hosting of the components, I'm sure. To be clear, by the way, Shadow DOM does not provide a security boundary. That's a misconception that sometimes we see from people. We have iframes for the security boundary, but Shadow DOM just provides a much stronger style encapsulation. But ultimately, it's a boundary that can be crossed. Any thoughts on security or CSP? That's really not my area at all. No? OK, maybe we move on then, actually. So now I'm going to ask Stuart Cox. Can you get Stuart on that? Cheers. Yeah, so do you think web components open the door for developers to abandon semantics? Are we going to end up with a million different home starting to select widgets? And what is the meaning of a tag name if that happens? So I'm going to ask Nicole to field that one. So I'm probably going to give a little bit of an unpopular point of view here. I like semantics on a gut level. But when I'm making a decision about what to do for a project, I try to keep in mind what I'm actually trying to get out of it and what semantics actually give me. Because in a lot of cases, we give way too much weight to semantics when we aren't getting enough out of it for basically the value that we're trying for. So basically, I think that there's semantic value in accessibility. And we get that from ARIA roles. And now our roles, what I think is great about ARIA roles is that they're divorced from whatever markup you happen to have used. And so we're no longer relying on some implicit connection. But instead, we're basically getting the semantic value from something we can tag on to anything. So I think that that's important. And then the other value that we get is developer maintenance and how developers will understand our code later. Because those are basically the only two things that use semantics. And I think that actually being able to write custom tags has a chance to make it. And being able to hide a bunch of junky markup gives us a fairly good, not junky, but presentational markup basically gives us a chance to be able to have cleaner HTML that contains just the things that are relevant to understanding what's going on. I think you say abandoned semantics. I mean, we've abandoned semantics. If you open up the DevTools Inspector on any page, you see a whole bunch of stuff that's meaningless. The cool thing about shout-on is you can take that presentational gunk that's required and sort of store it off to the side. And so if you look at pages that are written in a Web Components-y style, you look at it and you can understand it. It actually makes sense reading it. I also think that we abandoned semantics because the components that we're shipping in the browser, things like input and select, they're great. But there weren't that many of them, as you were saying. There's no carousel built into the browser. And so this allows us to create that carousel. Maybe for the carousel, there shouldn't be, just because it's an off-UI pattern. But I'm saying this allows us to create those things and actually represent them more semantically in ways in the document. Yeah, so we were thinking about some... I got Remy on the queue. I just wanted to pull him out. Sorry, yeah? Can we get Remy and Mike up here? So, well, we're rushing to make all these libraries like brick polymer and so on with Russian crate web components. And this kind of hangs a little bit off of the blocking thing, but we're making old mistakes. We're repeating old mistakes. Like local storage is a good example of new technology that came out a few years ago that there was big kind of throw of arms and it's not asynchronous and we're warned against using it. But we're repeating the same mistakes when we leave the opportunity with new technologies to not make these mistakes and make sure that everything is good for going forward since it's effectively a clean slate, right? So... But there's no such thing as there. Like, we are always going to make mistakes. Like, we're going to... No, no, sure, sure. No, no, I agree. Unknown mistakes that we're going to create in the first place but knowingly develop against mistakes. Well, I think that a lot of those mistakes come from this, we're not sure if the browser is an SDK or a runtime. So it wouldn't make any sense for you to have your OpenGL calls be semantic, right? But OpenGL is a very performant API. So why do the data structures that we render to the rendering engine we have available to us, which is the DOM, why do those have to be semantic? Why do we even think about that? Why do we think about... We talk about, you know, we need to make this performant and expressive and sometimes those are at odds with each other. So I think that the reason why you get things like synchronous local storage is because the fast API, the fast primitive, is an asynchronous call, right? But the easy API is a blocking call. And so we need to basically make a decision, like, are we going to make the browser an SDK? Are we going to make it like Visual Basic or are we going to make it like Lib C, right? And it's still this kind of frank and sign of irony. The thing is that the web community prefer the easiest solution. We always take the shortest route to actually getting the thing live. So it means we, like, kill performance in the browser or take up as a community because we're great copy and paste. We're great just ripping off all of your code. So if you have the opportunity to, like the baseline doesn't have those kind of blocks built into it or mistakes built into it, then that seems like the right... So for me, this is a very complex topic and I'm not going to pretend to know all the details. I've watched this be argued many, many times by very, people much smarter than me in this issue. And inevitably, after hours of discussion, everyone goes, oh, I get it now. But it's one of those things that's very hard to explain. I can't do it effectively. Maybe we have some of those smart people in the room. So first of all, Florin Egger. Can we get him and Mark and Mike? If we are not... I wonder if you're not hiding a lot of stuff in abstractions when we're using web components. Doesn't it affect maintainability and actually hurt reuse because we're building, again, the 100 different select boxes because we all have just a little bit different use cases? I think using web components, it's very clear. It makes your code much more maintainable because you can think more in your local context. You don't have to worry about what other... Someone else for on the page has done what kind of styles they put in the global style sheet. Because you have scope styles, because you have this nice encapsulation mechanism, you can think much more locally. And it's really freeing as a developer to be able to think like that. Because today, if you have more than three people working on a site together, they have to coordinate. They have to say, well, don't do this thing and please make sure your selectors don't accidentally select over into my area. And actually, my personal experience on a lot of people who have used web components so far has been it's actually far, far far more maintainable. I don't know if anyone else... It's like the... As I mentioned before, it's like, is it better than what we have now? What we do now is we just get a load of dibs with classes attached to them and attached to things like that. And it's all put directly into the markup of the page. It's all in the DOM tree. Now, I think that what web components bring through encapsulation, through scope styles, I think that makes that better and more maintainable. It's not gonna stop people from writing, as I said, a proliferation of crap. That's never gonna end. That's what we do until we find the... Maybe we settle... That's the web for a proliferation of crap. Until maybe we settle on something like brick or polymer or the two of them together, come up with something that we're all so enamored with and we decide to let's be mature about this and stop reinventing everything. When have we ever settled on anything? But one thing that I think is very important about this is that web components, to the extent they pretend that they're just other elements, to the extent that they're taking configuration through attributes or methods and properties on the prototype and that they admit events when interesting things happen, it doesn't matter how they're implemented on the inside. So you can use an X tag component, right next to a polymer component or within one another and it just works. So I agree with the spirit of abstraction and encapsulation, but web components deals primarily with scope style and honestly Nicole solved that a couple of years ago and with object-oriented CSS. So I think that that's solving... Well, except that in order to make object-oriented CSS work, you have to have a lot of developer rigor and everybody has to be on the same page about making sure... It isn't even on the same page. When someone's just learning CSS, they're gonna make a thousand mistakes before they're ready to write something that's really encapsulated and then there are other problems where you can't encapsulate it, right? Everything, styles are going to flow through to children. Yeah, I'm speaking from a very Facebook-specific perspective where we can control our engineering organization. But the problem is that that's the easy part. Do you do that? That's hard for just even a large organization who's being paid by the same person. We run this at Google all the time. Well, we have a little bit of a single class they inferred. Before we move on to the next question quickly, I have experienced building things with compliance to usable things and they work great. If you want, I can show you. If you don't trust all these guys there. Wait for the break. One more comment maybe from the audience before we... Guy from Akamai? Can we get it? Yeah, just a brief. I mostly wanted to kind of highlight some of the comment that Remy was getting to. So I mean, when you look at the existing successes we have, like Node is one of these claims to fame is that it forces you to be asynchronous, right? A lot of the problems that we have on the flip side of that, if you look at the async widgets that, anything that didn't ship as async widget before, I'll leave it to Facebook or Twitter, we're stuck with those things now. So I do think that there's strong merit in taking away some of the flexibility for in favor of performance or in favor of keeping, helping it, making it a little bit harder to shoot yourself in the foot. So to be clear, H&L imports don't block script and parsing of the main document. They don't, they do block rendering just like style sheets do today. But again, if you want to render something fast, you can put things directly in your document. You don't have to use H&L imports for everything. That should be the default. The recurring theme within Facebook engineering is one word and it's predictability. It's like you wanna know what's going to happen when you do something. With Node, you know everything is gonna be async out of the box unless you're using a weird like C extension, right? With the DOM, like yes, there is a fast path but it's so easy to fall off the fast path. Like you don't know what's gonna happen. You have no way to predict what's going to happen because you have to reason about the entire system as a whole. Which I think is an argument for building abstractions on top of fast underlying primitives like you talked about. And I think that's the way forward. I don't think baking more functionality into this unpredictable DOM is the way forward. We're gonna move on. I'm sorry, Christian, but you'll have a chance to talk later. So the next topic is gonna be introduced by Cormel Lesinski. What's the story of internationalization of components? Does the user of the component can inject strings in the component or does the component have to have hooks for internationalization? Again, this is an area where the best practices that people are still being pioneers in this space to see what these new tools do. In different cases, it will depend, I think. But if you experiment with number approaches on Polymer, I think that it will depend for different code bases, potentially. I can't speak to the spec, but we've been building component architectures at Facebook for a long time and it's made internationalization a lot easier because your components, you basically say, hey, this is my internationalized text label component. And you drop that in wherever you need internationalized text. Or, and within that, you can have tokens like, oh, this is my user's gender component and it'll look at the user object and it'll say, oh, is this male or female? And put the right string in there. And so when you build with a component architecture, the composition possibilities make internationalization a lot easier. And we built tooling around that for our own systems, including React and XHP, that people don't even really think about it so much. They just wrap their strings in the right tags. This will be one where I think, sorry to bang on the same drum again, but it puts more of the emphasis on you doing the right thing. If you make UI elements, and I think if I'm not mistaken, all of the UI elements we have at the moment don't include any text by default. So you just drop your own values into that. But if you create a UI element that does have text in there by default, the onus is on you to put something in there to make that internationalized. Or make your work open source and let other people do that for you. So one medical I wanna make is that because web components get this interoperability for very cheaply, I think X tags and brick interoperability with Polymer is a great proof point for that. It means that today it's different than what happens today. So today as a developer, you pick a framework. At the beginning you say, well this framework has 20 widgets that look pretty good, I guess. But then you get to them and there's, maybe the calendar widget isn't accessible or isn't internationalizable. And because the competition is on the framework level, you don't necessarily get the framework at the component level. Whereas with web components, it's... But how am I thinking of the frameworks that we have today, the amount of stuff you have to pull in in order to make anyone, I mean you could choose, pick and choose and take one piece from one framework and one bit from another, but the amount you have to pull in in order to do that. My worry is that each component is gonna depend on a whole bunch of dependencies and they're gonna end up actually pulling in way too much. Part of the reason that's the case today is because we have to create our own parallel universes and use the DOM just as sort of the rendering layer and that's it. Actually, one of the cool things about Polymer is most of the code size is that layer of polyfills which is completely unnecessary if the browser you're using ships, shadow DOM, custom elements, each and more important, et cetera. So it goes way, way, way down in size as browsers ship those natively. Back to the topic. I think custom elements are just DOM elements so you can just use your current libraries for internationalization. Say IATNM. Yeah. Or L10N. Yes, I've been trying some tests and it works great with mobile and everything. You just do us, like add your custom data attributes to translate things and it translates things. I mean, it's just another element so it's just that once you create it but it works like any other thing works. Any other comments to call? Did you want to? No, okay. So I think given that, we'll move on to our next possibly related topic. Which is what's going to be asked by George Thomas. Hi. How can web components be used to enhance accessibility? Can shared standards for interaction be developed to the agreed upon for common components? So accessibility is incredibly important. Actually Alice Boxhol, who's going to be speaking on one of the later panels is on the Chrome accessibility team and has been working very closely with some folks on the Polymer team and the web component standards folks. We shouldn't rattle too much into general accessibility issues because we're going to have a whole panel on that later. So I was almost reluctant to feel this question in the panel but what are the web component specific issues that have cropped up around accessibility issues? So our understanding or belief in Alice can correct me if I'm wrong here is that actually we think that it should be possible to make things just as accessible as before. But in addition, because people can be, because there can be competition level components, there'll be much more pressure on component authors to create accessible and nationalizable components. And so actually accessibility is one of those hard things for developers to wrap their heads around sometimes. It's one of those things they put off till the end. But if you use a component that's already made accessible, that's actually great for users because it's more likely that you don't have to do all that thinking yourself every single time you use it. So I'm actually more hopeful that accessibility will get better in the components world. It's hard to see it getting better than native UI controls though. And you can, yeah. So the best practices of using native UI controls where necessary or where relevant makes sense in that ARIA is a fallback if you don't, for some reason. So I'm like the world's biggest DOM hater here and I'm excited about Shadow DOM because being able to style a select component is like the prime example of how awesome Shadow DOM is I think. Because we have our custom select element component at Facebook that matches our interface guidelines. And it's like a zillion lines of code and then a zillion extra lines of code on top of that to get the tab behavior rate for accessibility. Now, the browser and the operating system have already done all that work for each platform so we can leverage that with Shadow DOM. So I'm really excited about that. Additionally, the way that we use a component architecture at Facebook, we don't use the web component standard but we use the same kind of ideas of encapsulated UI elements rather than templates or traditional MVC is we have a library that has been developed that is already accessible and ready to go. And you just, you know, people who don't know much about accessibility just go in, pull it off the shelf, drop it in. Yeah, I mean, we've been talking a lot about kind of creating your own totally bespoke custom elements but we shouldn't forget that that's a big part of it as well, is extending existing elements becomes very, very easy through web components as well. You can take your select box which we seem to be using as the default go to for whenever we talk about it and just add your own things to it. But the underlying, you know, the markup inside that inside the Shadow DOM still remains as accessible as it was before. When we are creating our own elements, again, we have to build, we have to make accessibility into it. But you can put ARIA roles onto these things. You can do all that. If you view the Shadow DOM of any element that exists out there, you'll see that they've got ARIA roles in there already. We should be using that as a model of best practice. But it is a concern because people- I know- There's a lot of accessibility thrown around here by non-experts. I'm very scared of what's going on here right now. Okay. We have a whole session on that later. And we're going to talk about ARIA later, actually, I think, yeah. I do notice that there, we have zero people connected to the system. So, okay, that's what I thought. So if there's somebody who wants to ask a question related to this, okay. Yes, Jeremy? Yes, this is related to accessibility and semantics as well as you pointed out, Nicole. It's one of the reasons for semantics to exist is exposing hooks, for example, to assistive technology. But to say then, we're all sorted because we've got ARIA. So no problem. First of all, ARIA is intended as a stopgap solution working towards native semantics. That's the end goal. ARIA is to get us there. Also, the whole point of web components is that we can invent these new browser elements effectively. But then in order to make them accessible, we are restricted to what ARIA can do. Then we're just passing the buck to ARIA. And unless there is a concept of ARIA components, then web components will always be using a small pool of accessibility hooks, which limits their scope, which kind of goes against the whole point of web components. I agree with Christian that we aren't necessarily, I might expere on accessibility, I guess, maybe this is their best effort to the accessibility panel. Well, you just need to make the primitives you have for composition as expressive as possible, right? Like the only way to solve this problem is to be able to compose more complex things out of simpler things that are accessible and somehow make the system as a whole accessible, right? So web components need to be, or whatever component architecture you use, need to be as expressive as possible. And it's not just ARIA attributes, it's not just styling, it's behavior. And I think you have to be able to compose with the full power of a real programming language to do that. And you need to be able to override specific bits of functionality. So part of it is kind of the architecture of the system you're using. And part of it is the power of the primitives that you have, which is why I think composing with DOM elements isn't powerful enough. And I think you have to compose with like Turing complete programming languages to do this. I think you're also bringing up something important, which is that the whole web community is suffering with the fact that the accessibility side of web standards and the web and other side of web standards don't talk to each other nearly enough and haven't figured out how it's supposed to work together very neatly. And so I think a lot of this, we don't actually have answers for it, isn't? I mean, yes, we're not accessibility experts, but also we don't know how it's supposed to work together. And the standards teams themselves aren't really working together. Other gentlemen in the front row, can you introduce yourself as well? Hey, Matt Wom. The question was kind of phrased of like you have accessibility on the web today. How does that apply to Polymer components? Is there anything Polymer and just web components in general can do that would be basically make accessibility better? In other words, ignore what today is. If you could change it and make web components accessible, ignoring everything now, what would you do? Like for me, you could add lifecycle events saying you're gonna get focused, deal with it. Like that should be part of the web component. They have to deal with that at that point. Yeah, I'm not an accessibility expert, so I guess that's... I mean, this is kind of what the shadow dom is trying to solve, right? Like select boxes seem to be pretty accessible. At least they do the same semantics that the operating system does. One of the things, and Nicole mentioned this before, is the more native UI you expose in the browser, the more you can reuse from the experts that have actually implemented it right. Remy, I see your hand up, but we are gonna move on and we are gonna pick up this topic, hopefully in Christian's accessibility panel as well. So I hope that we revisit this as well. Our last question of this topic. Some guy named Andrew Betts possibly needs to ask this. So it's a longie. Until web components are more widely supported, in what use cases would you consider polyfills like Polymer or X tags? Actually, I've got one already. In what use cases would you consider polyfills like Polymer or X tags over alternative component frameworks? So what extent do the existence of polyfills hinder or slow down the implementation of web components? So I think... I couldn't hear that. Polyfills, so the question is really related to polyfills and I think the crux of it is, are the existence of polyfills gonna hinder or help the adoption or the implementation of web components within browsers, in general in the developer community any thoughts on that? I think it will help the adoption with other browser vendors because it allows developers to use the technologies today in a way that actually works quite well. It's just when the native implementation is there, it's much faster. So like shout-on, for example, is a very complicated thing to polyfill and it's not possible to do it 100% perfectly. CSS in particular is very hard to polyfill correctly there. And then when it's in support natively, it's just much, much faster. It's not too done in the script. I see somebody who might know something about polyfills asking a question. It's not specifically polyfills, but when we get to the day when we're including Polymer and we're including this other web component that comes from another website and another web component from another website and all the magic is kind of tucked away between my ex-gift tag. Those web components are gonna be carrying all their own JavaScript, for instance. What if they all pull in their own jQuery library or polyfills library for all that they want to polyfill? Different versions of jQuery. Yeah, different versions of jQuery. The version's not prompt because they're gonna be sandboxed off, right, I assume. Sure, but that's a lot of code. But the overtake for having four or five web components where they're all pulling in a JavaScript library like jQuery, that is jQuery, but from different locations. How do we deal with that? How do we not end up returning to the days of dynamic drive where we're just slapping in big blocks of code and going, okay, it works. So one of the cool things about HTML imports too is they can do de-duping of those resources. Different components can rely on the same thing and it won't be redounded it twice. And of course, if you use some kind of minification step before you push production, you can make sure that you take care of that. But of course, if you have different versions of jQuery, you're gonna want to avoid that as a developer just like you do today. You don't want to use... What I'm talking about is, it's like I'm using brick and polymer together because you've got different web components I want to use both of them. How do I get, how does that even get surface to me? So Leigh-Don, what's the X tags perspective on this? I think it's pretty much the same. I mean, you have to be responsible, you have to be minifying, just choosing the components you want, it's just like if you just load the whole jQuery UI, it's like huge. And it's the same with brick, if you download the whole thing, it's not that huge, but it's still a lot of things you might not want. But you can choose, build your own distribution. I mean, you've got scripts for packing things like as they do, I think we call it a smush. I don't know why. It's like a fundamental problem with software though. It's a big process. If you coded in the 90s, you know, like DLL hell and that kind of thing. So I think that the pipe dream of like pulling components off the shelf and dropping them in is way more nuanced than people normally say it is. Like for us, we just run it through a build system and we de-dupe and alert when there's different versions. You're using your own web components, so you're not using anyone else's web components? Well, we have a component-based architecture that like we own the whole stack, so. And they also have a backend that is component-based and matches up exactly with the front end part of it, so that changes it. Practically today, Polymer and X tags, I use the same layer of polyphilis below. Remember, that's a layer that, that's where the bulk of the code is in Polymer in particular. And remember, that goes to zero over time is the idea. I don't see how that's true though. Like yeah, that's true in a really simple component, but as the components want to do all these rigidity things, it's going to have the same amount of code that any library that would have done the same thing has now. Not necessarily, because to the extent that today, a number of frameworks have no other choice, but to retreat to script and to create their own world that uses, again, DOM as just a sort of DOM rendering service. In a world where you're working more closely with DOM, you don't have that overhead where you have to create your own world and create your own concepts that's parallel hierarchy in the script. In a world. All right, so I'm being told from the front row that we need to wrap up. I think that my personal wrap up maybe closing statement might be a web component, some assembly required, right? But what is it, vague but interesting, maybe. Okay, so we'll leave it at that. Thanks very much, and thanks to our panelists.