Hm good question. I don't actually know the answer. My hunch is that they're probably just different, with the front-end/UI roles tacking a bit more toward the knowledge required to do that job.

Ultimately I think this is what ::theme should help solve. https://meowni.ca/posts/part-theme-explainer/

I believe Polymer provides a shim for css custom properties support, are you currently using that or doing everything vanilla?

Laptop: pre-touchbar macbook pro for most things, and an incredibly beefy linux workstation when I'm working on chromium.

Monitor: usually just my laptop monitor, but recently got a 4k monitor for the linux box.

Keyboard: So... everyone I know is getting hooked on mechanical keyboards. It's a very clacky future :D My friend Matt Gaunt leant me his Kono White Fox which I'm going to try out next week. So far i am a fan.

Mouse: Mostly my trackpad tbh. But for my linux machine I have some fancy logitech gaming mouse (maybe the M500?) with little weights on the inside.

Headphones: Bose QC35s. Best. purchase. evar.

Soft Apps: Mostly google docs, VS Code, and Evernote. Oh and I love Pinboard for bookmarks.

I also have an iPad pro and I do UI sketches using Paper. Really love that app.

I think progress is going really well. The main hurdle we're working through right now is around privacy, and making sure that folks don't feel like they have to leak the fact that they're using assistive technology just to get an improved web experience. Alice, Dominic, and James are doing amazing work in this space (see discussion: https://github.com/WICG/aom/issues/81).

Probably the best way to help it progress is to read through the spec/explainer, and bring up any issues you see. In particular, use cases where AOM seems like it would work but maybe doesn't—that stuff is super useful.

Oof yeah, Shadow DOM and accessibility can be tough.

The main thing to be mindful of is that so much of ARIA is based on ID references, so you have to be really careful to make sure your labels and whatnot are inside the same scope. I showed off a workaround I use sometimes in this video (https://www.youtube.com/watch?v=rr3c62Wnaeo). We're hoping to make this better with AOM (https://github.com/WICG/aom) because it will let you label things with an element reference, instead of a string ID.

If I recall, I believe Shadow DOM does reset the scoping for tabindex. So if you have something that's tabindex=10 inside a shadow root, it will be first in the tab order once focus moves into that shadow scope. But it won't be first in the tab order for the entire page.

If you're doing something new I would really look at Polymer 3. I imagine Polymer 2 will be supported for quite some time, but 3.0 and Lit HTML are just really cool and give you much easier access to things like npm.

100 duck-sized horses, no question. If I had a long enough stick or like a bow staff or something, I bet I could take em.

Hm, good question. I don't know of any resources off of the top of my head... Let me tweet this question out and see if other folks in the community have ideas.

Tweeted! twitter.com/rob_dodson/status/1010968129281744896

We'll see what folks say :)

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 (developer.mozilla.org/en-US/docs/Web/Web_Componen….

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 :)

Aye aye, sir!

;)

Hey Sandra!

We're allowed and encouraged to use all browsers when building apps. Unfortunately we still sometimes see teams launching Chrome-only experiences. We have a small task force, led by folks like Alex Russell and Surma, who are doing a lot of internal advocacy to reach out to these teams and help them make sure they support all browsers.

I like Firefox Quantum, it feels nice and snappy :)

I haven't been following it super closely, but at the last TPAC it seemed like all the browsers were into the idea. It looks like there's still a lot of active discussion going on in the w3c GitHub repo.

github.com/w3c/webcomponents/issues

I think anyone interested should definitely keep tabs on those threads.

Yep! I talked a bit about the hiring process here: hashnode.com/ama/with-rob-dodson-cjiofjep90001l9v…

And the day to day here: hashnode.com/ama/with-rob-dodson-cjiofjep90001l9v…

But in addition to those answers, I'd also say that the experience of being a developer at Google has been truly amazing. The folks on my team spend a lot of time thinking about and working on their communication skills. Which means we're fortunate enough to have a team that is super supportive and constructive. We boost one another up, and that's just awesome.

haha I remember doing the sweet hacks thing but also can't recall which episode that was >:( If it comes back to me I'll post a follow up!

What do you think about the growing support amongst frameworks for compiling native elements? Cheers

Do you mean things like React Native? Or is there some new hotness that I am not yet aware of? (very possible).

So glad you're using :focus-visible!!!

Personally I'd like to see more teams bringing in folks who rely on screen readers or other assistive technology during their design process.

I'm working with a team right now that has a web product and there's a competing native app. We were all sitting in a room, kind of at the end of a meeting, and someone asked the user to just show the team what it was like using the native app with JAWS. The experience was seamless. Then they said, "ok, now do it with our site." The experience was... less seamless, haha. In that moment, the whole team kinda "got it." Like, audible gasps, saying things like "Oh wow. We have to fix this."

There's just something really powerful about having someone really show your team the barriers that the app is creating for them. I think it builds a lot of empathy, and is incredibly motivating.

I am very angry with the constant radical changes in Polymer. My team has written applications in Polymer 1 now we are still rewriting to Polymer 2, soon we need to rewrite to Polymer 3 (it should be easier) but is afraid that the scale (400+ components) can cause some problems. Now you can see that Polymer 3 is no longer alive and will be replaced by LitElement with a completely new templates system, which is practically unreadable in Polymer 3. Polymer will no longer be supported and you have left the big companies with nothing, because LitElement seems to be a completely new project, which is to replace Polymer and looks like an experiment, it ridiculous.

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 :)

Every quarter I write these things called OKRs (https://en.wikipedia.org/wiki/OKR) which is kind of like a plan for what you want to get done over the next 3 months. Often times if I'm unsure what to work on during the day, I'll read over my OKRs and see what needs attention.

These days I'm doing a lot of work :focus-visible (https://github.com/WICG/focus-visible) so I'll probably fight with some Sauce Labs tests or review PRs. One of the really interesting aspects of incubating a standard in the WICG (https://www.w3.org/blog/2015/07/wicg/) is that it's all open on GitHub (no mailing lists) so folks show up with really interesting use cases or questions. We've evolved :focus-visible a lot over the last year based on that feedback.

I also attend meetings with product teams who are working on accessibility. This could mean discussing how to make a particular experience in an app accessible, or looking at what kind of behavior we'd recommend for a particular widget in the Material design system. I find this work super interesting. Usually these folks are already well versed in the topic of accessibility, and the problems they're confronting are just new and difficult.

As far as tools go, I use a pre-touchbar macbook pro (I'm too scared to upgrade), and a lot of time in Google Docs :) VS Code is my editor and I try to put all of my random thoughts down in Evernote.

To answer your last question, I think what Polymer really got from React was their model where ui = function(state). You see this now in Lit HTML. It's a really lovely way to build components. I think the React team did an amazing thing there. I remember when our brains were all pretty exclusively stuck in MVC land and they found a way to shift things a bit. Really cool stuff :D

Great question!

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.

That's a good question. I wish I had a better answer, haha :)

One thing I found super useful was to blog. I know blogs maybe seem a bit dated these days, but to explain something in my own words forced me to understand it better. I think sites like Hashnode are also great because folks can share their posts and discuss them in an arena that's supportive and has things like community guidelines and codes of conduct.

Going to local meetups can also be great. Not necessarily for finding a mentor (though that may happen) but more so just to build a sense of community. I know that if you're learning to code by yourself it can feel pretty isolating, so having a place where you can go maybe once a month to check in with folks can really keep you motivated.

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.