I am Rob Dodson. Ask me anything.
Rob is a Developer Advocate at Google working with the Polymer and Chrome teams.
Ask Rob Dodson about:
- Developing with Google Chrome
- Polymer Project
- Web accessibility
- Web Components
- Life at Google
- Google Dev Ecosystem
- Open Source and more
Thanks folks! It was fun chatting with you all. If ever have any additional questions you can always ping me on the twitters @rob_dodson. Enjoy the rest of your weekend!
This is a big question with a long answer :)
Probably the biggest reason, in my opinion, is the "weirdness budget" that the team referred to in their recent I/O talk. https://www.youtube.com/watch?v=7CUO7PyD5zA
To pickup Polymer—really, Web Components in general—requires grokking a number of concepts like how Shadow DOM does both DOM and CSS scoping, how Custom Elements need to have a unique name in the registry and therefore must be deduplicated across large apps, etc. Plus juggling all of the polyfills.
Taking all of those concepts in, as a new developer who just wants to build a thing, is a large ask.
In hindsight, I wish that Polymer had been a bit more opt-in. You could imagine a version that only uses Custom Elements (similar to what X-Tag did initially), and then optionally lets the developer add things like Shadow DOM if they want. This maybe would have made it easier for folks to onboard.
Another thing we realized was that folks really want help managing state in their application. We largely tried to avoid this issue early on because we believe web components can be used with any state management strategy. But I think that made other libraries, in particular React + Redux seem more compelling for folks.
But ultimately our goal is to make Web Components succeed. The Polymer team is part of the Chrome team and was created to help prove out those new standards. They've done some really amazing work and it's wild to look at where Web Components were 4 years ago and how much the specs have evolved. Seeing libraries like Angular and Stencil adopt them is, in our opinion, a huge win. I think that's ultimately what we'd like to see—other libraries adopting web components as a useful part of their story.
Share your programming knowledge and learn from the best developers on HashnodeGet started
We still need more folks to understand the fundamentals of tabbing/arrowing through a site and getting familiar with at least one screen reader. For anyone not sure how to get started with that, we have a free course up on Udacity (https://bit.ly/web-a11y).
We also need better APIs. I've seen a lot of folks building pretty fancy UIs for their apps and making them accessible by flipping ARIA attributes is tough stuff! I'm super excited for AOM (https://github.com/WICG/aom), inert (https://github.com/WICG/inert), and :focus-visible (https://github.com/WICG/focus-visible).
I'd also love to see more folks using and contributing to the ARIA Authoring practices guide (https://www.w3.org/TR/wai-aria-practices-1.1/). This is basically your cheat sheet for component accessibility. It's an amazing doc put together by a handful of awesome folks. It's all on GitHub (https://github.com/w3c/aria-practices) so if folks want to try to contribute more patterns or examples, that would be great :)
I personally also want to spend more time working on cross-browser support and cross-assistive technology support. Recently I've seen teams who are building pretty complex UIs which they finally get working in one or two screen readers, only to find that another popular screen reader offers a really different experience. It's hard to stay on top of every screen reader + OS + browser combo, so whatever we can do to make those experiences more consistent would be a big win, IMO.
I was freelancing and working at a big enterprise company helping them build a design system. At one point I came across a talk by Eric Bidelman where he explained Web Components and it just seems like a perfect fit for what we were building. This was still really early days, so no browsers had actually implemented the specs yet. At the time I was doing a personal blogging challenge, trying to write a blog post every single day for 60 days. I started reading the specs (really my first time ever doing that) and trying to explain them in my own words. I also started hanging out on the (now defunct) Polymer IRC channel and chatting with the team.
Eventually Eric asked if I wanted to grab lunch with them, and after that they invited me to attend the Chrome Dev Summit. At CDS I met a few other folks and they asked me to submit my resume to see about an interview. I kind of assumed that there was no way I'd actually make it through the interview, but I took it as a fun chance to go see the campus and at least say "Hey I interviewed at Google once :P"
During the interview I met with Paul Kinlan, Paul Irish (omg!), Seth Ladd (then of the Dart team), and a few other folks. It was really cool (and a bit intimidating) getting to meet all of these folks I followed on social media. We did the classic white boarding coding thing, which went surprisingly well, and we also talked a lot about my vision for developer relations and how we could improve it. I thought it was a really fun day of interesting conversations. And a few weeks later I got the offer :)
The primary difference is that Polymer is using built-in standards to provide their component lifecycle and style scoping. For instance, a React component has lifecycle methods like "componentWillMount" and a Polymer component has "connectedCallback". React will need to ship additional code to make their component model, and those lifecycle callbacks work. Polymer, gets all of that for free because Custom Elements are built into the browser (https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements).
My advice for choosing any framework or library is to read the docs and see which one you prefer working with. Whatever makes you feel the most productive is the right one to use :)