 So I'd like to welcome on the stage a bunch of people from Polymer engineering team to answer all your questions So first Justin Fagnani is an engineer on the Polymer tools team Monica is an engineer who you've met many times today and yesterday on the Polymer team Rob Dodson developer advocate extraordinaire expert in all things web and general internet celebrity Wendy Ginsburg the product manager on the Polymer team itself who gave the keynote yesterday and Steve Orville the mastermind or one of the masterminds behind the Polymer core library and engineer on the Polymer core team as well All right So we have two microphones One microphone up here two microphones up here So please come up ask your questions. This is an open space. This is a safe space. We love being here with you There are no such thing as dumb questions. Please come up ask us anything You can also tweet at us at the hashtag ask polymer and we're looking through those tweets live And so I'll be I'll be looking through a machine up here to try to get some of those questions delivered to our panel as well All right Great. So to kick us off. I have a question in the barrel Which is that? Lots of exciting stuff coming out yesterday and today with Polymer and MPM and ea6 modules Lots of excitement about how to develop components also a little hesitancy for a lot of folks who really enjoyed being able to author HTML in HTML So is there anything that you're thinking about in terms of how we can kind of better support that use case that has been so special to So many Polymer developers of authoring HTML in HTML Please Yeah, so I mean I first want to say that we hear you We spent a lot of time yesterday and today talking to people who were you know kind of lamenting the loss of Authoring in HTML and it kind of makes sense because that's something that's been a little bit unique about Polymer and You people have chosen to use Polymer and that's why you're here because you like it a lot And so it's definitely got us thinking about ways we can you know help support that kind of style and that kind of workflow Even as we move to JavaScript modules It's important to note though that also our philosophy of using the platform kind of means that like when the platform gives us a Tool and in this case kind of denies us another than one that we were hoping to use The we our choices in a sense made for us a little bit We have to go to JavaScript modules because that's the native loading solution on the web but we can look at ways to kind of layer the project and Provide ways to you know Have some tooling or something like that The important thing is that Polymer 3.0 is very very early in preview stage And so there's a lot of time for feedback and a lot of time for experimentation with solutions to give you the You know the ability to write HTML in HTML The same Yeah, I mean the actual string that you write is the same template. In fact, you could draw a line from every line in a HTML import to a line in a JavaScript file and there would be a one-to-one correspondence between every line in there We're just following Sember and that's why you have to bump the major version. Yeah So we hear you we have some interesting ideas on how we can You know serve the best of both worlds Yeah, I just add quickly that you know again based on feedback The reality is Modules are here today and we want to support them You know, but there's some spec work potentially to develop an HTML extension to those modules And that's something that we'll be thinking about and you know Evaluating and seeing kind of you know if our users are really clamoring for HTML On our own team, I will say that there was definitely a bit of like difficulty ripping that band-aid off But we're also excited about some of the new things that modules are gonna provide. I mean lit is an excellent interesting direction and You can't do that in HTML. So You know, we're gonna be experimenting and listening for feedback So a closely related question that should hopefully be quick if I'm working on a new project right now Should I target 2.0 or 3.0? 2.0 definitely 3.0 is very very early and the other thing to note is that the When we published core and all the elements those were literally converted automatically by a tool minutes before we published them up It was like one process So if you're on 2.0 and you keep pushing forward and you do that we're gonna take you to 3.0 automatically In fact, you can tell that they were published while we were here because we Got rate limited by github on the conference IP Wi-Fi so that if anybody was trying to use the github API you couldn't do it because Justin did all of it No, we used to get up token that wasn't us. Oh, there's just so many people in the code lab Yeah, I think you know a little bit of straight talk to steal Gray's term is you know We're really aiming as Justin said to earlier to you know, not change the API between 2.0 and 3.0 Just as little as we have to absolutely have to you know, and actually Kevin's app that he built He transferred the whole thing using the you know the tool that Justin's team has built And you know it had some bugs for a while But you know the latest version works pretty seamlessly and the kinds of I mean, you know I think Justin sort of obtusely mentioned we're changing as little as we can or maybe was Fred We're changing as little we can honestly like give me give you just one example. There's the Polymer import href What did that do it created an HTML import? Well, there's no more HTML import So you have to do that differently, right? This is like about what we're gonna change. That's the only change Yeah, and in fact this this brings up a good point You know if you're vending open source elements out there We actually recommend that when you use the converter you do not change the API of your elements at all Treat them is having the same major version even if you bump the major version because it's now modules Because that one that means when your users run the converter, they will automatically be compatible with your element So we look at this transition is is not really an API breaking change. It's just a repackaging All right, let's go to a live question I have a question regarding tooling and improving developer experience. Is there any opportunity to you? And you were developing and to have provided hot module replacement Like you are coding and you immediately see the changes in browser hot module reloading. Yeah, that's a tools question. Yeah, I mean We we don't have any work planned on that There are several ideas on how you can do that One of the things with hot module reloading is you often get into a problem where if you're replacing some JavaScript It's hard to huh It's hard to replace the state that might have gotten in a certain, you know states through some path of code that you took So I was just talking with some people today about ways we could make templates auto reload In Kevin's been looking at using redux, which You know has some facilities for that kind of stuff that can replay your state We don't have any media plans, but it's an interesting and open question Yeah, I will say that Kevin kind of alluded to in his talk that we're considering ways You know, we're not really at prepared to say exactly what we're ready to build right now but we'd like to improve the overall developer sort of end-to-end experience and You know Kevin demonstrated using redux as a good way to do that and a tool like that works Well with something like hot module reloading and you know, there's something that I think we can explore Without can really committing to anything. I mean frankly I think we'd love to be able to build something that community can also contribute to you and and you know If that's a useful feature, that's great. Thanks All right, so we've another question about tools Which is what are the plans for all the various tools that polymer tools team builds when it comes to polymer 3? So a polymer CLI what's gonna happen with polymer bundler will it be replaced by webpack plug-in? Etc. Yeah, so there's a little bit to be figured out there But I'm kind of on the mind that we have two different paths to explore here Probably at the same time one is we have existing customers who are using the CLI and her Successful and happy and we want to keep them moving forward into this world without them having to ditch our tool chain So we have been adding support for NPM. We now have an NPM flag on the CLI and poly serve and WCT And we'll probably try to add support for modules as an incremental choice that you can add into your project as you go But we also want to enable people to like not have to use our tools Because we're so different from everyone else to be able to use roll-up and webpack And all these other options that everybody else has out there So we're definitely gonna take care of you and keep our tools moving forward It could be we're look at opportunities to replace some of our custom stuff with something that the community already has So we have to do less work But we're also going to explore the idea of you know If you have an existing project and you want to sprinkle polymer in you can do that without having to buy into our tool chain Make Rob happy With Polymer 3 and the transition to NPM. What was the kind of reasoning for Choosing to go with yarn and a flat dependency tree as opposed to using NPM and peer dependencies It's getting all the questions here happy to do it though. It's really the platform again a Lot of people Kind of think they've been using JavaScript modules Because there's been support in all the compilers That will will turn yes, six syntax into common JS or something But it turns out that the web compatible modules are a little more restrictive than what people have been using say in the Node or like webpack ecosystems and they require that you import by path Just like HTML imports and so HTML imports and Bauer worked well together because Bauer installed flat And then you can import polymer by importing dot dot slash polymer, right? So we have that same situation on NPM JavaScript modules require importing by paths if you want to import from another package You do import dot dot slash and that package name and that kind of forces us to have packages in a flat layout And yarn does that NPM currently doesn't I hope they consider adding that feature and then we'll be able to use the NPM client as well Yeah, I think there's there's really two reasons number one is you know custom elements Have a you know when you define a custom element. Nope, that's used can't use it again So that doesn't really work well if you have to be careful about that So loading a dependency twice is bad for that the other reason is loading dependency twice is horrible for Performance, so you know relying on a tool to make your page completely not suck and load the same code over and over and over again Is not ideal. I think When we install flat we ensure we don't do that Thank you. I think actually it is worth pointing this out a little bit. So It's also important to understand that your client side dependencies You definitely want those to be flattened as Steve was saying you don't want to ship 10 versions of the same thing to the client That sucks, right? Your dev dependencies all your build tools and things like that Those can actually still have like the nested node install And so there may be a little like fine-tuning that we need to do here to make sure that like it's very easy and ergonomic For developers to sort of like be like, okay, cool. I flattened my client side stuff and I one of the things you tried out was Different yeah So like these are my client side dependencies These are my like normal nodes or build or whatever dependencies Flat and one don't flat on the other and we still have a lot of work to give everyone templates that they can start from that are Set up to serve and build in the proper way. So we'll we'll be coming out with that in the coming weeks Yeah, but like just personally like I even though there is a little bit of work and overhead involved sometimes in flattening your client side dependencies The flip side of that is, you know, I think with webpack you have What is it the common chunks plug-in or something like that? So it's like I mean you're you can either de-dupe this at install time and handle it yourself that way And at least then you've got like a gooey kind of walking you through it Or you've got to like put this whole thing into your build process to de-dupe your packages so you're doing it one way or the other usually and Personally, it seems like doing it as early as possible in the install process is a good thing Let's jump to a question from Twitter Which is what about accessibility? So how does polymer work with voiceover and screen readers in general? Yeah So how does polymer work with accessibility I mean generally like fine I can't think of anything that is like, you know painfully broken the biggest issue is going to be around Shadow DOM so Most of the stuff that we do in accessibility to build Relationships so you say for instance you have attributes like are you labeled by and things like that where you actually say This element is labeled by that other element and you use an ID reference to that other element So literally like CSS ID reference, right? The challenge there is with Shadow DOM right you're creating this little scoping bubble Your IDs are scoped to that bubble and so you can easily end up in situations where you've got something in the Shadow DOM that you Would really like to label or you'd really like to refer to you with like aria controls or something like that and You're unable to do it. You just like can't get down there So there are a few things that we're working on to fix this that aren't actually like polymer specific But are just like web platform stuff So probably the most important is the new accessibility object model which you can find that on github.com slash Wicg slash a om am and this is basically like adding a programmatic API to accessibility and making it a lot easier for you to Imperatively like so, you know like set up relationships in JavaScript between elements and say like hey I've got this element here and I have access to its accessible node property And I can actually then give it a an actual like node reference in JavaScript Then I could you know hop through shadow boundaries and things like that That's probably the most important thing that I think we're doing to fix this and that that'll that'll help web components Obviously, but it'll also just make accessibility more broadly across the platform easier for developers. I think Let's go to a live question since when I started using polymer was Because I could just serve up data on a flat But just in gen X or a static server But most of the examples I've seen now or over the past year have always been through a dynamic node server or something like that. So I just want to make sure that you know One of the that's gonna stay in polymer that you can just serve from a static server all of the things that I build are always from a static server. That's like a moniker rule so They always work the only time reduce extra things is to bundle But there is no requirement is just Inboards and that's one of the reasons why modules require paths is because the browser needs to figure out The exact URL to load and then with yarn flat it'll be able to find it and load it Yeah, I mean the one thing I would add is Because of the way that custom elements version 1 is defined because of the current existing browser support and because of our Desire always to ship really optimized sets of code to the browser We do sometimes what's called differential serving to serve just the right bundle, you know, like for IE 11 We can't serve ES6. This is why we will sort of provide tools to let you serve the optimized thing Hopefully that's gonna go away soon The next year or two I'm really happy with all the tooling and documentation you guys have provided to Help move users from polymer one then to polymer two and now to polymer three It's like, you know really made it as turnkey as possible for folks like myself But my question is, you know, there's still obviously a lot of projects in code out there with polymer one still And using the zero dot X web components polyfill What do you guys have in terms of a long-term support strategy or end-of-life plan for? Polymer one and you know obviously eventually polymer two and those zero dot X poly fills as well Can you repeat the question for anyone watching on my video or live stream? Sorry sure. I mean Taylor Yes, so question was around end-of-life support and just general kind of long-term support for a polymer one and poly fills yeah, I mean so Basically, there's the native features that we rely on is one part of the question and you know, this is sort of Web standard practice, right? Those will not be removed for centuries probably until like that We actually do crazy stuff like, you know, how many people use these things But so those won't go away really and you know polymer we are supporting hybrid mode. So I think I Can't say exactly, but we intend essentially to kind of adopt a similar policy where as long as there's need will continue to support it And unless Taylor tells me differently Does that also include the v0 shadow dom implementation in Chrome? That's a good question. Yeah. Yeah, I mean, this is really what I'm speaking to you I mean the policy bit basically one of the reasons the web is great is because it really doesn't break and you know Chrome kind of leapt ahead of everybody with v0 shadow root and You know, this is going to be available as long as people are using it The way Features are removed from Chrome is that we keep tracking them? We have a percentage of pages that are using it. You can see that as well Sorry, yeah public information from status.com. Yeah And they have to drop below like a very small threshold like zero point zero three percent Of all pages are using this feature and if it drops below that then You're confident enough that it's basically just like old pages or unused pages or just we're sorry. We're gonna break you So I don't think we're nearly close enough and we're not there's no chance. We're gonna go there in the next year one thing that is happening soon that's gonna make Monica excited, but If anybody was here still on like 0.5 or anything and you're using the deep selector in CSS or the shadow selector Yeah, that's who those are going away very soon in Chrome and that will change the styling of your page So we've been trying to urge people to get up to Polymer 1.0 and stop using that for the last couple years Hopefully you have they're basically getting replaced by the descendant selector So like it's not gonna make your style not get applied but deep is just like it becomes a descendant selector So it's not gonna go into shadow roots or anything like that. Yeah There's been a little little warning in the console for quite a while, but it's very it's weird I have this like innate reaction now. I see the warnings. I'm just like clear Like if you're like me like you gotta fix your stuff. Yeah, definitely going to break. It's definitely getting removed Yeah, luckily. I've seen some sites that I'd hopefully they've moved. It doesn't break them that bad All right, let's jump to another Twitter one How optimistic are you and what are your feelings about other browsers agreeing to native element extension? And what can we as the developer community do to like help? Is equals yeah I will take this one my cross to bear Is equals is a great idea where the the idea of extending a custom element or the idea of adding your own set of functions and behaviors and prototypes to a native element this idea very clear here is agreed on by all Browsers the implementation of this idea is not agreed on by all browsers So the current is equals implementation in particular is not is very content like contentess and is not agreed on by all browsers and this means that We would like to we will continue fighting for something like is equals It will probably not be as equals in the state that it is Hilariously enough as equals is a likely contender one letter off But basically there is a need for extending custom elements. There are things that you cannot do unless you are a native element For example submit forms so in parallel with us fighting for this API to actually work We're also fighting for browsers to actually know just fix the form element form elements should look at custom elements There's no reason why the form developed 20 years ago should not look at something developed now. So It's a hard question. We're working on it. We're trying very hard to write specs. Ritza. It's an ongoing battle I'm not I don't know if this is entirely accurate, but I'm gonna say it on stage as if it is If you add a shadow root to an element that you've type extended like so Let's one of the one of things is like oh select right select is amazing and it has all this built-in accessibility and Presentation to it and my understanding is if I extend that and then add my own shadow root like all of that goes away And so it doesn't even work. It's like let you do it. Yeah, okay Just dies so like yeah, so there's like a lot of things that you might Like think that you want to do with is equals that actually just aren't going to quite work And so then it does become a bit of like a weird API where it's like you get some stuff But not all the stuff and the browser is not very good at like pinky swing like I pinky swear I'm not going to do bad things because I've read there's like these 20 Things that I can add a shadow root to but not these other four or something. Yeah, so I definitely think personally Yeah, I want just them to sort of like expose the primitives or fix the elements I want like the label element and the form element and all these things just either just work with custom elements Or let me sort of imbue my custom element with Formness and label nests and label ability and things like that in one day one day. This will happen. Yeah promise I'll just add personally. I'm not personally. I'm not very optimistic just speaking for myself only Again, because I think this concern for example that Rob brought up around shadow roots is a really good idea of the Larger problem, you know in v0 custom elements, you could extend input But you couldn't add a shadow root to it So what you could actually do it was kind of limited why because it had this native legacy Implementation and this is really the larger concern is that these native elements have this long history You know C++ plus plus implementation and crazy specs before custom elements was even a thing So the long-term fix is to expose those APIs and make those available to any custom element Just wants them and maybe there's a shorter term fix It probably isn't gonna be is it may be some crazy thing And you know, we know that people really want this and so we're definitely kind of got our fingers on the pulse of that and And we'll be pushing for something because I think you know the exposing the guts of input so that you could do it All yourself is probably a 25 year project Yes, so, you know, we probably need something in the meantime and if is is objectionable You know, we'll be pushing and sort of pushing people for some better solution And I'll give a little shout out to Marika's talk earlier today. All of these discussions are not in some secret back room These are all happening out in the open on public mailing lists So you have good use cases and on github beyond github So you're really passionate about it Please go and like tell everybody you're very upset that is equals is not a thing because Specifically W3C or github.com W3C slash web components. Yeah, there you go It's the only way we get things done by proving that you actually want something like these equals They don't believe me. All right. Let's go to a live question. Thanks. So my question was in fact related to the previous one But first I'd like to thank you for letting us use the bleeding edge of this pack right now before it was You know recommended and given the the is attributes is gone What's the the migration path that you would propose to the currently implemented? Elements that they're using is attribute especially those that are using specific parsing context like templates script table tr and stuff like that Wait, do you want to repeat the question? I think we're getting it from the big So think that I did with form for examples of iron form was an extension of form you convert it into a wrapper and then you Put content in it. So basically all of the Extra is equals things that you were doing you put on a wrapper element, but that for tr is kind of Yeah, tables are tricky tables are tricky. Well, remember that you can style. Yeah You can style things as tables with CSS so you could move to yeah, but you got a style thing like a template What's right template time Yeah, you cannot so yeah, I mean what what Palmer did. I mean, yeah, it's not super pretty We're not gonna lie But this sort of decoration pattern is essentially this is what Palmer did with like we used to in polymer 1.0 We had template is Dom repeat we for sort of compatibility We did some magic where we sort of made that work in polymer templates in 2.0 But the way that we actually make that work is we have a DOM dash repeat element Expects a template inside of it and it works that way. This is a general pattern that's gonna basically work again It's not super pretty, but it's what you can do Thanks, thank you for this. It was great. Yeah, actually you need to bring them back That's just on the polymer project website There's still a mention about an upgrade tools to 2.0 from 1x any update on this On the upgrade tools. Yeah, there was a mention about it was from 1.0 to 2. Yeah So, you know last year we said we're we're gonna make this upgrade tool and then This is kind of my bad a little bit It seemed like most of the feedback was like, oh, it's really easy to upgrade and the things that were tricky to upgrade We're actually gonna be impossible for a tool to automate things like converting a content Tag to a slot tag where the content had actually had a selector. There's no way We can just automatically determine what the slot name should be everywhere and apply it So it seemed kind of to us for a while that everybody The we were hearing from was kind of satisfied with how easy it was to upgrade and then it seemed like more recently We heard an uptick in number of people who were asking about about the tool and wanted it So also recently we started converting all the internal Elements inside Google from one to two and a Peter an engineer on the tools team has been working on the tool Quite recently. It's not very clean code. We've just been like hacking at it to do whatever upgrade we could And so we're planning on releasing the version that we have for internal External pretty soon. Okay, then do you have a suggestion to lint old element to find? You know quickly what has to be changed to zero right rather you know going to each element and you know searching for specific things But you know something too late, so it's highlighted a Way to highlight in your code, you know what to be changed like Yeah, we can certainly if there's cases where we we can't determine what it should be We can output a message that says, you know, this needs to be updated by you Okay, thanks. All right, we're running long time. Let's do one more live question. Hello My question is Do we have any Tutorials or videos for the making something like neon animation because we really loved in the love the neon animations in the polymer one I think the question about neon animations in its future, right? So is it is is it if it is we have a blog post that Elliot wrote you probably saw one stage before On the polymer summit site that kind of explains what happened to neon and animations and what's going to happen to neon animation Yeah, so yeah, my question is like Is there any some new videos or tutorials like neon animation because in the version to it is deprecated, right? Will there be replacements for neon animation? Yeah, I don't think so the problem with you on animation is that it's fundamentally a Flawed concept that we thought was going to work in dozen like it doesn't actually add anything in the current state that it is amazing to the web animations polyfill API and We had a team the team that actually works on the web animations API Look at making a new and better neon animation and what it ended up being was the web animations API So it turns out just like a declarative rappel would be amazing, but it just doesn't really work well, and If you want it just a jar of spiders Yeah, I'll also plug Valger and another engineer on the team made a code lab for performant to expand collapse animations and Just by going through that you can see you know something Pretty typical that anybody would want to build and how he does it and then you can learn yourself and maybe apply that to some other projects Thank you Let's close out with a question that I love which is What would each of you see as your number one Request or a current hole in the web platform a feature or some change that you would like to see made to the web platform to make it better There's two I'll go one and hope somebody else does the other one I think right now for web components We're looking pretty good with the native implementations at least in chrome and safari The one piece that seems to be left to make everything much better is the theming support in CSS for shadow dom So that's the part and theme CSS spec it just got promoted to working draft or editor's draft. That was a good one. I want to take the other one I know it's fine. Okay So yeah, that would just help that would just help everybody's theme across their shadow roots That was mine For better or for worse for some reason I care about inputs and forms despite never actually Using a form on anything that I've ever made so what I would like to see in the web platform is Input being less opinionated and forms being less opinion native elements being less opinionated about their tag name So form caring about more than just input and you know input type equals color actually working on all of the browser is because it's Not yet Yeah form an input I would like form an input to succeed at their job Yeah, so mine. It's kind of related to that like there's a lot of things that native elements can do There's like a lot of built-in magic I've been working on accessibility a lot the how-to components that we all worked on Accessibility was like the primary driver behind that work We were like how do we build tabs and trees as custom elements and make sure they are like really like Robust and accessible right fully keyboard accessible doing all the right things with aria everything we can possibly try and Then there's still places where we come up short because there's some stuff that we just can't do in the browser today The label element and things like that you click on a label and it focuses your control That's a cool magical behavior that like Just there's no easy way to get that you're gonna have to make your own custom element label now And then you end up just reinventing like all of html to get all these little features So I'm really excited about a on and other you know other stuff like Being able to hook into forms. I think these are probably some of the most common things folks have brought up And we've kind of been pushing for them for years. I actually think people are listening a little bit more right now Definitely both forms. I think forms are actually a good Yeah, good hope we're like finally getting through just some folks there So yeah, that's really what I want I want I want to make sure the future of html is accessible and that's easy for developers to do that to do the right things And it's not like this arcane art to make something accessible I think that The biggest frustration I have is when there's like a really cool feature And not every browser has it of course, you know trying to bring down polyfills And I think a way that that could happen is Oddly enough through payments and commerce on the web because the more we allow users to buy things and spend money there The more companies pay attention large companies that have tons and tons of sites and have tons and tons of tons of developers And so we can start doing more stuff with payments I know that Chrome payments just came to desktop We'll start attracting a lot more attention and then hopefully companies will start putting a lot more attention into their browsers or paying attention in standards meetings and stuff Yeah, people on the team know that the thing I care about sort of the most is performance And I think I've said this before but you know I think with custom elements we have an opportunity to add things to the browser that makes it faster Makes us able to do things custom in custom ways faster I care about this for a couple reasons Obviously, I want things to be faster so that we can all make stuff that's awesome and better for users but there's another reason and You heard yesterday and Alex Russell's talk. He's talked a lot about mobile CPUs Now he only talked about that for like five minutes but he works in the same office as us and We have to hear him talk about that for like hours and hours and hours and hours and I would like to have things faster. So I don't have to hear that venting Much anymore Alex, he's joking. We love to talk to us All right, great So Matt's gonna come on in a second with some closing remarks and some very important announcements So please be sure to stick around but thank you so much to the panel