Interview: Rob Dodson explains Polymer and discuss its future
We had the chance to meet and interview a lot of very interesting Googlers during the last Google I/O. Today, it’s Rob Dodson ! We’ll release those interviews (mostly in English) in the upcoming days.
Wassim Chegham: Hi Rob, can you introduce yourself please?
Rob Dodson : Hi, my name is Rob Dodson, I’m a developer advocate on the Chrome team and I primarily work on Web Components, Polymer and lately also accessibility.
Earlier, we saw the Polymer talk, and saw tons of features coming to Polymer. Can you tell us a bit about them?
Rob Dodson : Yeah! There are a few major things that the team has been working on. One has been to improve the performance of Polymer over the past few versions. So between 1.0 to now, it’s like 25% faster on most platforms, which is nice. And we’ve been rolling out what we call the “app toolbox”. Because one of the problems we had was, we put up a collection of Web Components and people were like “I need to build an app, where is the router, where is the i18n?” And we were like, “well, we’re just a library for building Web Components, you can build those things yourself”. But people were still asking for that kind of thing. So we started off with a router called app-route, it’s just one example of the kinds of routers that you could build using Web Components. So we put that out. We also have an internationalization solution, it’s our i18n element for doing internationalization, which is very cool and it’s made by one of our team members, Monica Dinculescu.
Is it based on the i18n standard API?
Polymer CLI, our new command line tool for throwing together Polymer apps. It does things like vulcanise and crisper for you. It helps with HTTP2 server push, etc. And there is the shop app that we rolled out as sort of an example of using all these things together. The PRPL pattern is something that Kevin was showing off in his talk. It’s just basically a strategy for using HTTP 2 server push and lazy loading components to get the maximum performance on a progressive web app. I think there is probably more things, but that’s sort of the gist of it.
What about the poly-git?
Rob Dodson : Poly-git is the CDN that we’ve been working on and it’s really for development work. It’s not really meant for a production use case. Only for dev at the moment. And that mainly comes from the difficulties around deduplicating HTML imports. If you try and load from 2 different CDNs, or you try and load a local copy of Polymer and a CDN copy of Polymer, then HTML imports can’t deduplicate those and so that’s one of the reasons we’ve always been cautious about using a CDN. It’s fun for developing but really you should be in control of your resources.
So with all those tools, the Polymer lib is becoming more like a framework…
Rob Dodson : We are sort of building this, and we like to think it’s a “toolbox”. We call those elements the “frameworky bits”, the “frameworky elements” [laughs]
Aren’t you afraid that Polymer become like a competitor to Angular or other frameworks…
Rob Dodson : Not really, because ultimately our goal is to just get people using Web Components. Always, our goal has been to further the Web Components standards and make sure that they ship in all the different browsers out there. So Polymer was just one expression of using the standards together. What we really like to see is interoperable use of the components in the other frameworks and libraries. For instance, Typescript and Angular2, this is a very different model even from React and even from how you might build a Polymer app. And they all sort of make sense depending on the team and you like to work. If you’re a team of 20 developers, Typescript is a great thing because you get everyone on a consistent build flow. And at the same time though, we would love for them to just be able to use Web Components and these applications and right now you can’t. You can use Web Components in Angular 2, you can actually use Web Components in a React app as well, you just kind have to wrap them in a React “membrane”. We have never been trying to take anybody on or anything like that. We just want to make this sort of universal components and people can use them anywhere. Now the reason why we made the framework stuff, is because so many developers were like “I want to only use Web Components for my app” and we were like “OK, that’s cool”. So, for that group, we give them the router, some other things that will make that easier for them.
How old is Polymer now?
Rob Dodson : That’s a good question! I’ve been working on it at Google for 2 years. It had been worked on probably for 2 years before that. Before it was even called Polymer, it was called “tool kitchen” and it was like an internal Google project, and then the Web Components standards themselves go even further back. I think by now, we are talking about a 5 or 6 years effort in total.
Angular, for example, is more popular than Polymer. How do you explain this?
Rob Dodson : Angular has been out for a lot longer and also for a really long time, they were kind of operating in different spaces. Polymer started off almost as a science project like “can we even make this stuff work?”. And then, over the past year or so, since the last IO I’d say, we’re trying to transition it out of the science project area and into the “real” world, because we’re confident you could use this for a real app. So that means that in general, you’ve got a much smaller market of developers that really had time to use it and we’re still waiting on other platforms to add in support for some of the Web Components features. I think a lot of folks look at that, they look at the polyfills and things like that and they are like “I prefer to have something that I know, that I can use today, that gonna work all the way back till like IE8 or IE9” or whatever they’ve got to support. Whereas Polymer have for a long time been like “we are gonna live on the bleeding edge, specifically because we trying to advance these web standards”.
Cyril Balit: Without comparing it to Angular, how do you explain the lack of interest in Web Components?
Rob Dodson : I think it comes down to browser support. I think later this year as Safari starts to ship with Shadow DOM and Custom Elements, and then Mozilla starts to ship with some support too, things will change. Suddenly, using Web Components goes from polyfills – which kinds of work differently depending on the browser – to a much better experience, with better performances. It will be gradual, but I do think that more developers will start to use it, for more things. And the way I see it, people will start sprinkling this tech into their app. For instance, anybody got to distribute components like Twitter Bootstrap or PureCSS, these are libraries of just components but they don’t choose a framework per say. It would make sense for them to do a custom element because that is just the next logical leap. We’ve always said it’s a marathon, not a sprint. That’s the way standards work, they tend to be very slow to evolve. It’s the same with flex-box. They worked in a few browsers and it was awesome, right? And you had to do weird things to try to make them work on other browsers. But it took a long time for flex-box to really take off and now I think everyone is like “Oh! Thank God! I can finally use it everywhere” [laughs].
Wassim Chegham: I have a question about Google IO. Are you enjoying this year’s edition?
Rob Dodson : I am. It’s interesting. It’s definitely a new twist. I know that the lines have been very difficult for folks. Obviously, this was not the intention, but I’ve been hanging in the sandbox for like the entire day these past 2 days and I’ve probably talked with more developers at this IO than I have at any other prior IO. I’d love it if everyone could see all the talks that they want and spend as much time with the folks in the DevRel team as possible. So that’s my bright sight to the difficulties [laughs].
You, as a speaker, do you give advice to other, junior speakers?
Rob Dodson : Absolutely! So, a few things. Writing is crucially important. I think a lot of developers talk about starting a blog but then they don’t do it and it’s so important to actually do it! And a lot of people start a blog and they are like “well, I don’t know what to write about or somebody has already written about this thing” and that just does not matter. It’s always great to have your own perspective on something, right? Because you learn differently than somebody else. I can have something explained to me by 3 different people and it just doesn’t click and then some 4th person explains it to me and I’m like “I got it!”, because you put it in my language. I think it’s really important for people to write a lot and share a lot in that way. And for speaking, it’s always nerve-racking but then you get over it. You just get used to it and it’s not as scary anymore. You do it enough times and it’s great to travel and meet cool people. It’s awesome to put yourself out there as a developer, even if it’s scary.
Cyril Balit: How do you see the future of Polymer? Perhaps new features…?
Rob Dodson : There are a few things I would like to see.
Simplifying the data-binding system. The thing that drives me crazy right now is to have an object sub-property or an array of objects and you change something there and it just doesn’t update the bindings. I find that really frustrating. There are methods to do it, you have to write your observers in a certain way and you can change records and blah… I don’t like that, and so the team is working to just streamline that and really simplify it, which is really good. I’m excited about that.
The other thing is, I personally find React and the work that they are doing fascinating. I think developers like the programming model that they expressed there, and so I wanted to take as many ideas as I can from that space and make sure we’re rolling that into the standards process, Polymer and the work that we’re doing. A lot of developers love that React has this virtual DOM and that you can do this pattern of just like “here is a whole new object of state, do the diff and you figure out what changes”. So I’d love to be able to do that same thing using standards. Having async DOM APIs or a safe sort of read/write mode that batches up DOM change operations, so you can still get all the goodness that you’re seeing from the React world and still get that cool functional programming pattern but you don’t have to throw away the entire DOM. So that something I’m trying to push forward a lot, and have some more of these cool state patterns, I think Redux is really cool and I would like for Polymer developers to have stuff like that so they can feel like they know how to organize their state very clearly.
And I’m also curious to do a little bit more vanilla Web Components. So not even using Polymer but just custom elements with ES modules and stuff like that, for the people who aren’t ready to buy into the whole thing. Maybe they don’t know about HTML imports or they’re not so sure about Shadow DOM. But they would be possibly cool with Custom Element, right? And loading modules that do their definitions. So I’m gonna do some of that too, some of that edge casing work and blogging in conjunction with Eric Bidelman. That’s something we’ve been talking a lot about.
Cyril Balit: What about extending custom elements? Is it going to come back in Polymer?
Rob Dodson : That is a good question. Extending elements is still in the Custom Elements v1 spec but nobody is planning on implementing it yet and it’s unclear if it will remain in the spec. I know that the Polymer team has been working on sort of like an inheritance approach. So it might be something that is specific to Polymer that we do. We do it in some interesting way where you kind of just mixing a lot of functionalities into your prototype and maybe you’re not directly extending the element. That definitely something that I’m sure the team will be exploring post-IO.
Wassim Chegham/Cyril Balit: Thank you Rob.
Thank you guys!