Polymer in Practice @ Comcast (Polymer Summit 2016)

Polymer in Practice @ Comcast (Polymer Summit 2016)


[MUSIC PLAYING] CHRIS LORENZO: Good
morning, London. JOHN RIVIELLO: Hello. CHRIS LORENZO: OK, I told
the people in the front to like, good morning, London. AUDIENCE: Morning. JOHN RIVIELLO: There. CHRIS LORENZO: Thank you. I’m Chris Lorenzo. JOHN RIVIELLO:
I’m John Riviello. CHRIS LORENZO: And now we have
to share the Beef Wellington story. So when I travel, I don’t
really set goals for myself as far as where I’m
going to go eat, or what I’m going to go see. I usually leave
that up to my wife. But unfortunately, due to some
poor planning on our part, she’s currently 8.5
months pregnant and– JOHN RIVIELLO: And we’re here. CHRIS LORENZO: Yeah, we’re here. Apparently it’s
really hard to travel when you’re pretty pregnant. So she’s at home
watching right now. Hi, love. And we set this goal,
because my wife is a foodie. We watch Master Chef
together with Gordon Ramsay. I’m sure some people might
have heard of Gordon Ramsay. He’s apparently from the UK. And every year, he
makes the contestants make a Beef Wellington. I’m like, wow, a
Beef Wellington. So this is a Beef Wellington. It’s kind of like a Polymer app. It has the app shell. And inside, you put the meat. And it’s just delicious. So I asked my wife, where can
we get this Beef Wellington? And she tells us
about Grenadier pub. So John and I venture out. We go see the changing of the
guards at Buckingham Palace. And we go to Grenadier,
and we’re sitting there. And we look up at the
ceiling, we’re like, look at all this
American currency. Wait a minute, we’re Americans. I have $1 bill. John’s a graphics designer. So I pull out the dollar bill. The bartender gives us a marker,
hand the dollar bill to John. And we’re talking, we’re
like, what should we do? And I’m wearing my
Liberty JS shirt, which has a Liberty Bell on it. JOHN RIVIELLO:
We’re from Philly. CHRIS LORENZO: We’re
from Philadelphia. So we’re like OK, we’ll
put the Liberty Bell on there, which happens
to ironically represent, you know, America’s
exit from the UK. So we decided to
put that on there. And then we put, of
course, the Polymer symbol. And so we got up on a bar
stool, glued it to the ceiling. And if you go to the pub,
it’s on the left-hand side. You can look up. And you can get a Beef
Wellington, or a Bloody Mary, they’re famous
for both of those. JOHN RIVIELLO: So, yes, let’s
talk a little about Comcast. That’s the company we
work for back in the US. We’re based out of Philadelphia. Comcast is the largest cable TV
and internet service provider in the US. It’s a Fortune 50 company. We have over 30
million customers, and we own NBC Universal. So that includes the whole
family of TV shows, movies, and theme parks. So my cousin that works at
Harry Potter World at Universal Studios in Orlando, Florida,
works for the same company that I do, which is pretty cool. And she has a cooler job
than I have, I think. And we use Polymer, of course. And we have over 500
components that we’ve created. So we have to work on a variety
of different web technologies at Comcast. To give you an overview
of some of that stuff. This here is the
My XFINITY website. This is where a lot
of our customers start their days to get the
latest news, check the weather, check their email. And this was built
with Ruby on Rails. This is the My Account website. And this allows customers
to go in, view their bill, pay their bill. If they’re having
issues, they can troubleshoot their equipment. They can manage their
account, stuff like that. And this was actually
built with Angular. CHRIS LORENZO: So here we
have the XFINITY Home site. This was our first Polymer
app, which we started with 0.3. It has half a million customers. And it allows our customers to
control their security system, change locks, or turn on and off
lights, change the thermostat. We also have the x1 platform. And this is Comcast’s
premier TV experience. It’s actually one of the best
ways to watch television. The guide is awesome. And we make this guide
available on all platforms. And if you happen to
be using the web one, that’s also written in Polymer. And it serves over a
million customers a day. And so the first
question, is why Polymer? Why did we choose Polymer? And so the story
starts 2.5 years ago, when our product team asked
us to build the XFINITY home. And of course, this
is the final product, it didn’t look like
this when we started. But we had this new project. And we got to choose
whatever framework we wanted. So as a lead, it
was my job to start researching what was available. And as everybody knows,
there are like hundreds of frameworks available. But I narrowed it down
to Angular and React. And I was checking
them out, and I’m like, I’ve been a web
developer for 15 years. I didn’t really
feel too comfortable with these frameworks. And so, I’m talking to my buddy
Phil at work one day, and just to give you a little
background on Phil. He’s the guy who lives
on the cutting edge. He reads all the
latest news blogs, and he watches all the latest
Chrome developer tools. And he’s like service workers–
and this is 2.5 years ago– like as soon as it was available
in Chrome Canary, he’s like, we should be using this
in Production, and Fetch, and Promises. And I’m like, Phil,
just calm down. We gotta wait until our
customers actually have this. So I’m talking to him. And he’s like, we
should use Polymer. This is my son, Theo. I taught him to say
progressive webapps. And it’s so cute
when he says it. He says, progressive webapps. And he understands
like the sounds, and he can repeat it back to me. But he has no idea
what it means. And that’s kind of how
I felt when Phil said, we should use Polymer. But unlike my son, I
was actually able to use the internet and can Google it. And was like, OK,
what’s Polymer? So I started looking through
the documentation on Polymer, and checking it out. And I got the team together. And it was time for
us to make a decision. So, of course, we asked the
white board what we should do. And we created a
pros and con’s column for whether we
should use Polymer. And one of the big things
that we really liked about it was that it was
backed by Google. And like, I am just overwhelmed
impressed by the Google team, by the Polymer team, and
how great their engineers are at building stuff. The other thing that I
really like about Polymer is it’s future oriented, right? Web Component Spec is going
to be built into browsers. So eventually, all
the polyfills go away, and we get great
speed from that. Also the documentation on the
Polymer website is amazing. Their technical
writers are great. And probably don’t
get enough applause, and we should probably
applause for them. So– [APPLAUSE] Thank you, Polymer
technical writers. That’s going to be our
best applause of the day. That’s great. And developers always
like doing something new. But some of the cons at the
time was, this wasn’t even beta. We were looking at 0.3. It wasn’t even alpha. Apparently, Taylor was like,
oh this was experimental. And I’m like, I didn’t
get the memo for that. And at the time, Polymer 0.5
and below, use Shadow DOM. We were trying to
write tests for that. And Selenium had no idea
what Shadow DOM was. So we were trying to click on
a button that was in the Shadow DOM, and Selenium
was like, I don’t know where this button is. I can’t find this button. So there was no testing. There was no tooling. Web Component Tester
was not out yet. And there was limited
browser support. It was IE 10 and above. But for XFINITY Home, we
had to use web sockets, so we were OK with that. And, of course, we decided
to go ahead with Polymer. And when we first started,
I was really nervous. Because we were building
a production ready app for half a million customers
in an experimental technology. And when I first started,
I was really nervous. I was just like, I was on the
con side, too, by the way. I was like, we need
to abandon ship. We should switch to
Angular or React. But as we were
developing, and we were like discovering
getting over the hurdles, I really enjoyed Polymer. And I really enjoyed
Web Components. To the point where, I’m excited
to go around talking about Web Components and telling
all the other web developers out there like, you
should be using Web Components, they’re great. And I’m especially excited
where the project’s going with Polymer 2.0. So ultimately, we
did finish the site. You can see, here’s another
page of our devices. Each one of those pieces
that you see on there is a component. So we have the XH
thermostat, we have XH light. And it’s really great when
your UX team comes to you and is like, hey,
can we put that light on the Overview page? And I’m like, yeah,
sure it’s just a tag, like it’s no problem. But we started this
with Polymer 0.3. We eventually released
with the Polymer 0.56. And as we were releasing,
Polymer’s like, OK, we got a 0.8 version, and we’re
checking out the 0.8 version. And then they’re like,
OK, here’s the 1.0. And now you’ve got to upgrade. And we’re like, oh,
great, we’ll upgrade. And I’m telling Phil,
like, oh this should only take a couple weeks, right? It’s no problem. He’s like, no. This is going to be hard. And we spent three
months upgrading. So I’m really excited
about Polymer 2.0 and that Google understands
the pain of upgrading. And I’m excited
about hybrid mode. And I’m looking forward to a
better experience upgrading. JOHN RIVIELLO: So let’s
talk about sharing. And if you’re playing
slide deck bingo, there are LEGOs on
this one, so keep paying attention to the
different slide deck bingo items. This is a picture of
my kids sharing LEGOs. And as I’ve learned, sharing
does not come instinctively when you’re a child. You don’t want to
naturally share your toys. And as you learn
to share, there’s some screaming and
some crying involved. And this is kind of like
learning how to share components with Polymer. But I promise you can
get through without any screaming or crying. So it’s this potential
to reuse components that got people really excited
about Polymer at Comcast. Because before Polymer
was even a term in the vocabulary at
Comcast, we were already looking at how can we make
a consistent user experience across all of our devices. Because again, we’re building
for TVs, tablets, phones, laptops, watches now, of course. So, our UX team put
together this presentation on what they called
modular design systems. Or basically, a single
component could appear different based on the context. So here’s an example here of
the XFINITY Home’s arm disarm, which in the usual context
on the right-hand side. And on the left you can see the
way it could appear or behave in a different context. So we’re no longer designing
and developing websites. What we’re building
instead are components that can expose
functionality on any website. See your camera,
record a TV show, pay your bill, really anything. So when the XFINITY
Home team started talking about the potential
of sharing components with Polymer, this got
everyone really excited. UX was excited,
Product, Business, I heard executives that weren’t
technical saying the word Polymer at meetings. I’m like, what is going on here? This is really catching on. So a little over a year
ago, I hadn’t had a chance to work with Polymer yet. And then that day came, when my
boss comes to me and he says, so John, the XFINITY
Home team, they’ve been building with Polymer. They’re talking all
about sharing components. It’s time to actually prove that
this is actually a possibility. So what I want you to do
is take that XFINITY Home arm disarm widget, and put
it on the My XFINITY website for a demo in two weeks. CHRIS LORENZO: Woah,
woah, woah woah. JOHN RIVIELLO: And
I’m like, all right. That sounds cool. You know, I’ve never
used Polymer before, but I’m excited for
the opportunity. And so I go ahead, and
I look at him, like OK, look at the documentation. Documentations
looking pretty well. I go and look at the
XFINITY Home codebase. I’m like, OK there was a
bunch of components here. I figure out which one
is the arm disarm widget. I’m like, all right,
how am I actually going to take this component and put
it on the My XFINITY website? Not exactly sure. So I talked to the
XFINITY Home developers. And the immediate response is
like, whoa, slow down buddy. You can’t just take a component
and drop it on another website. And I’m like, but that’s
what we sold this on. That’s how we got the
company to use it. And then in talking to
them, it became obvious. I mean they– as Chris said–
they started building with 0.3. They upgrade to 0.5,
they upgrade to 1.0. So they were learning
Polymer as the Polymer team was learning Polymer. They didn’t have time to focus
on making a sharable component. They were learning on how
do I make a– ship this app, ship this website. But that didn’t
change my demo date. I still had two weeks. So Chris and I, we
worked together, we looked at the
My XFINITY website. We’re like, OK, where are
we going to put this thing? We looked at it on
the right-hand side, there was a spot. So we put on the right there. And then, in two weeks,
I was at the demo. And I successfully armed my
security system at my house from the My XFINITY website. And this was a defining
moment for Polymer at Comcast. Because this proved that
yes, we can actually create shareable,
reusable components, and use this across the
board at the company, And this opened up the
door for more projects actually to be using Polymer. So right now,
Chris and I’ve been working on a number of
projects over the past year. And we knew when we were
starting these projects that we wanted to build
shareable, reusable components. This was a key aspect of
what we were going to build. So we set out to build these
components that would actually be shared across websites. And now that we’ve
been doing this for a number of months
this year, actively, and actually sharing components. We can see what it’s
like to actually do this, and we’ve come up with
a set of best practices for building shareable,
reusable components. The first one is
to use CORS, which if you’re not
already familiar is cross origin resource sharing. This is what allows
you to go ahead and if you’re on one domain,
to make an API call with Ajax or Fetch to get data. So this allows you to get
around the same origin policy by passing some headers
that say, hey, I’d like to make a request here. And then if you’re
on the white list, you can get back that
data right there. And this is a key
piece of what we had to do for the XFINITY
Home arm disarm widget. Because that was built
for XFINITY home. So when I dropped it on
the My XFINITY website, it was expecting a relative path
to the API, which didn’t exist. I then hard coded it to go
to the XFINITY Home website, and the browser just
said, not going to happen. So we had to add the
CORS headers there, and then we could then get
that API to pass through to another website. Another thing is to separate
the data from the UI. And what I mean by this
is a single component should not be in charge
of fetching, processing, and rendering data. Your UI component
should take in the data it expects as attributes and
properties and render it. Any processing should
happen outside of it. We’ve actually tried to
create data components, and that just strictly
dealt with fetching, data and processing it. That had– it kind of worked. It had some issues, Chris will
touch on those in a little bit. We’ve also tried Redux
that in early indications seems to be working well. So those are other options. But the key thing is to separate
your data from the UI there. We also care a
lot about testing. So you may be wondering,
do we practice test-driven development, or TDD? We don’t enforce that. Some developers choose to. But what we do enforce
is code coverage. So we use the Instabul plugin
for Web Component Tester. That’s pretty much
the industry standard for code coverage in JavaScript. And you can see here that
one of our Polymer projects has nearly 100
percent test coverage. And for our shared components,
in each one of those repos, we actually require 100% test
coverage across the board. And this, if you don’t
have 100% test coverage, and you try to submit
a pull request, it’ll actually fail the
CLI– or fail the CI for [INAUDIBLE] integration. So we enforce this. And this helps make
developers feel more confident about using
these Shared Components because they know that
they’ve been fully tested. So again, we don’t enforce
TDD, but we do enforce DDD. And you’re probably
wondering what I’m talking about when I say that. And actually Ben touched
on this yesterday a bit talking about how
ING uses Polymer. And that is demo
driven development. And this is one thing that I
love about what the Polymer team has done. So they’ve created
these amazing library of open source components. And in addition to
great documentation, they have these rich demo pages
that show you exactly the code you need to use,
and how it’s going to look when you use that code. So we do the exact same thing. So here’s, for example, again
that My XFINITY I’m sorry, the XFINITY Home arm disarm
widget, the two different ways that it can appear, and
the code required to do it. And our teams have agreed
that this definitely has helped focus them better
on making shareable reusable components. Because when you’re constantly
looking at the demo page, it’s pretty clear
what your goals are and what you need
to be building. This has other
advantages as well. For one, it kind of forces
you to think in Shadow DOM, even if you’re using Shady DOM. And what I mean
by that is, we’ve had developers getting
start with Polymer. And since we’re using
Shady DOM by default, they’ll have an element
that’s contained within a couple other elements. And then they’ll set
styles in the outer element that impacts the inner element. And that’s technically
possible, cause we’re just poly filling Shadow DOM. But if we were to turn on Shadow
DOM, then that would break. And when you’re building
the different appearances of each component on the
demo page and looking at it, it really forces
you to think, OK, if this component needs
to look a different way, I’m going to go ahead and
put that on the demo page. Another thing is,
so we’re again, using these on
multiple websites. If we make an update
to a shared component, we want to have to go
in and test that update on every individual website. If you have every use
case on the demo page, it’s much easier to just go
ahead, look at the demo page. And if it works there, it’s
going to work on the website. And then if there’s a new
use case you need to add, you just add it
to the demo page, and then you’re good to go. So remember DDD is
the answer to creating sharable, reusable components. CHRIS LORENZO: Thanks. So I couldn’t let John be
the only one with an acronym. So I came up with
SPC. And SPC stands for second party components. Or it could mean shared
Polymer components. It really doesn’t matter,
acronyms are everywhere. This one’s not important. What I mean by it though,
is we have this thing called the universal header. And appears on top of
every one of our sites. And it also comes with
a universal footer. And the product team wants to
be able to have this header and footer be shared
across all the sites and be easily updatable so
that they can change the link, and all the sites
get it instantly. And this thing’s been around for
probably about seven years now. And when it originally
started, it was a script tag that you would put on the page. Which would then
load two iframes. An iframe for the header,
an iframe for the footer. And everybody’s already
like yes, it was an iframe. It was pretty disgusting. And then we started using
Ruby on Rails a little bit. And we started doing
it server side. So you could make
a server side call, and get it included in
the page and serve it before the user needed it. And then, we started doing
these single page apps. And we don’t want
a server anymore. So we came up with a
new way of doing that. And what we’re doing is we said,
why don’t we make this thing Web Component? We’re like, yeah, Web
Component sounds good. So what we did was, we got the
Polymer team– or the Polaris team to create this universal
header as a web component. And what you can do
is you can actually import a web component
from another domain, from another team. So we have another team
building this navigation for us. And we import it
into our project. And now we have an XC
header and an XC footer tag that we can use just
like normal DOM elements. We got rid of the iframe,
because doing the iframe, it’s really hard to
do a responsive slate, and try to like change
the size of an iframe, and change the height. Good luck. Good luck trying that. But with this, we can now
also talk to the header. We can pass it information,
we can change its styling. We can change its z index a
lot easier if we have pop-ups. It’s just all
around much better. Also, when we first
started with Polymer, we really drank the Kool-Aid,
and thought like, everything should be a component. We were so excited,
we were like, we gotta make it all a component. And so what happens is with
a typical Polymer site, for instance, XFINITY Home. Your code looks like this,
where you load the polyfill. You load Polymer. You load your vulcanized assets. And by the way,
vulcanization wasn’t out when we first started. That came later. Every time Polymer team
like released a new tool, we were like, yes, it’s
Christmas around here! But you then put in one Polymer
component, or one component on the page, which
is your XH app. And then inside of XH app is
all these additional components. And you have authentication,
you have your API calls that are happening. You have log in page, you
have your overview page. And the problem with this
is that performance matters. We need to get something
in front of the users as quickly as possible. And for us, with the
XFINITY Home site, we actually have to
make an API call. Which then goes all the
way into the user’s home. Make ZigBee calls for all
the devices in their home. And then returns
a status back up. That can take over two seconds. We have to remember that the
color purple also matters. So you can cross that
off your bingo card. So really, the
critical path for us was getting API calls happening
as quickly as possible. If you look at the
developer tools, when you have XH app
loading, the browser has to get the definition for
that, stamp it into the DOM. Then it’s like, oh look,
at all these other modules. I’ve got to get
their definitions, stamp them into the DOM. Do all this other work. And then it’s like, oh, now
I’ll start making the API calls. So we were making API
calls almost a second into the site
loading for the user. And this was a big problem. So as web developers,
and again, I’ve been developing for the
web for 15 years now. We have to get
back to our roots. We need to remember that
Web Components are just another tool in our tool box. And really, this doesn’t
do us justice anymore, because we have so many tools. We really need like
a big red truck to carry around all our tools. Another bingo card
use the platform. This is the Polymer
motto, right? The platform hasn’t changed. The browser is still
the same browser that we’ve been
using for 15 years. Yes, it’s gotten better. It’s gotten faster. It’s been
progressively enhanced. But it’s still
relatively the same. And so, we need to remember
when we want something to happen sooner in the
browser, all we have to do is put that piece at the top. And so what we did was we pulled
out our authentication checking and our API calls. And we stopped making
them Polymer components. We just kept them as JavaScript. Pure JavaScript. And we’re actually
checking whether the user’s authenticated before
we load up the app. And we start making
the API calls as soon as they come to
the site, so we can get it. Because that’s
our critical path. And then while the
calls are being made, we load the polyfills, we load
the app, and we get started. So the user gets a
much better experience. And we’ve also checked out
this app shell architecture. It’s always great, because
we build all these apps, and then the Polymer
teams like here’s the recommendation after
we built this stuff. And we’re like, cool,
app shell architecture. It’s pretty awesome. And for those who
don’t know, this is about splitting
out your assets and giving a small
package to the browser. This is a lot faster to
process things that are small. But it takes advantage of this
notion of unresolved elements. And what that means is, when the
browser sees a web component, anything with a hyphen in it. It goes great, you’re
a web component. Wait a minute, I don’t
have your definition yet. So I’m just going to
keep track of you. You’re in limbo. And as soon as I
get your definition, I promise to come
back and upgrade you. And we can take
advantage of this, just like the app shell
architecture is doing. So here, for instance,
is how we normally create a definition for XH app. And by using IMD,
yet another acronym, import module definition. This is based on the
AMD specification. It allows you to define modules. And this was written
by the Polymer team to do modular definition
with html imports. So now what we’re
doing, is we’re defining XH app as a module. And we’re able to push
it down to the browser, but actually not load
the definition yet. And by doing that, we can then
have additional JavaScript like this loader module,
which can do checking of hey, is the user authenticated? If they’re not
authenticated, I’m not going to spend the 500
milliseconds to instantiate XH app. I’m just going to show
them the login page, or send them to the login page. Because that’s much
faster than having to do all this JavaScript processing. So that’s it for performance. JOHN RIVIELLO: So
we’ve been talking a lot about how to build
these Polymer components well and effectively. Let’s talk about building
the team of engineers who are actually going to
build these Polymer components and apps for you. So the people we’ve brought
on to work on Polymer projects at Comcast, either externally
or internally, probably only 20% had any experience with
Polymer before working on these applications. And that really
hasn’t been an issue. And I really feel
that’s due again, to Polymer’s missioning,
which is to use the platform. So if you have
engineers that have a solid understanding of
html, CSS, and JavaScript, that’s all you really need. Again, the documentation
of Polymer is great. You can go and look at the
elements they’ve created. Take a look at the documentation
there, the demo pages. You can really get a
quick understanding of how Polymer works. Chris and I also have run
hands-on training sessions, multiple times. And basically, what we do is
give a bunch of exercises. We’ll then factor in– we’ll
bring in some of the videos from the Polymer Summit. So I’m excited to see that that
library is now doubled in size. And we’ll also, of course,
use POLYCAST to bring in those videos as well. And that gets the team a
nice, quick introduction how to use Polymer in production. And from leading those
training sessions, and also reviewing
developer’s code, we’ve realized that one of the
hardest things for developers to wrap their head
around initially, are these core parts
of Web Components. And that’s encapsulation,
composition, and separation of concerns. Polymer was designed with
these principles in mind. And you should be building your
components for these principles in mind, as well. An obvious red flag to when
this is not being respected is something like this. So we’ve seen this from
a number of developers just getting started. They maybe come from building
large-scale web applications, and they’re used to putting
just a lot of code in a file. So they start trying
to build a component, and they put a ton
of code in that file. Like this one here, has
over 2000 lines of code. CHRIS LORENZO: This
is real code, too. JOHN RIVIELLO: Yeah,
Chris and I saw this, and we’re just like, oh
no, what have we done? Polymer was supposed to make
things smaller and easier to work with. And we’re still having
developers write code that’s looking like this. So we knew we needed
to refocus the mindsets of our developers a bit. So in our training,
in our code reviews, we’re basically driving home
that a component should do one thing, and one thing well. If it starts to get too
large, then just break it up into smaller components. And again, focus on
those demo pages. Because no one’s going to want
to maintain this massive demo page of all the different
permutation of a component. And once your team
can internalize those, they become a
well-oiled machine, and you can become a Polymer
champion for your organization. CHRIS LORENZO: So just to wrap
it up, we really love Polymer. Polymer has been spreading
like wildfire at Comcast, because it’s really
simple to use. It’s much easier to learn than
some of the other frameworks out there. The ability to reuse
components, too. Taking the XFINITY
Home arm disarm module, and dropping it on
another site, it blows Products’ mind
when you can do that. And it’s also much
faster than anything else that’s going to be out there. Once web components
are native and running on the metal of the Chrome
browser, or any browser, it’s so much faster than
any framework can do. So, again, that’s why
we really love Polymer. I’m Chris Lorenzo. JOHN RIVIELLO:
I’m John Riviello. CHRIS LORENZO: And
we’re from Comcast. Thank you for your time. JOHN RIVIELLO:
Thanks for having us. CHRIS LORENZO: Thank
you Polymer team.

Related Posts

Review of the Thule Archway Trunk-Bike Racks on a 2015 Toyota RAV4 – etrailer.com

Today on our 2015 Toyota Rav-4, we're doing at test fit of the Thule Archway XT two-bike rack, part number
Billie Eilish Scares Her Fan Melissa McCarthy – EXTENDED
How to Track or Locate a Mobile on Google Maps ?

3 Replies to “Polymer in Practice @ Comcast (Polymer Summit 2016)”

  1. What an incredibly succinct representation and distillation of many hours of real-life decisions and meetings. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *