TED SANDER: Thanks, everybody.
My name is Ted.
I'm here to talk about components, specifically
Angular Dart components.
I am an infrastructure tech lead that specifically
works on widgets for many of the applications
that we have at Google.
And last year, I was up here, and I
was talking at the Dart Summit about the way
that Google teams use Dart in Angular to build their web apps
and how they are very productive in doing so.
And it's been quite a great year for us.
Maybe you haven't seen it, but we've had tons of launches.
We have a lot of products out there.
We have many, many users coming to our applications
in production.
And we're getting some reviews back,
and we're really liking these reviews-- stuff
like its sleek, comfortable, feel and approachable
sophistication apparent throughout this new design.
The new, responsive user interface
that makes it easy and more efficient to use.
Nice material design animations all
throughout the website, which obviously
help making the overall look and feel infinitely better.
Now, I don't know about infinitely better.
But if a user says that about your application,
you're doing the right things.
This one is my favorite.
We haven't run into any delays in the new AdWords
UI and zero loading screens.
Even more, some tasks now seem almost instantly completed.
Now, they're not quite instantly completed,
but it is something that we strive for.
And these reviews came from three
very separate applications that we've
launched in the last year.
But you can see common patterns.
They're loving the new UI.
They're loving the speed.
They're loving the material design.
And all of these three teams are throughout the whole world.
Two of them are from Europe itself.
We're going to have one Dan is going
to talk about a little bit later,
and David is going to talk about how they've used Dart to make
their applications great.
But something that's common between these
is they're actually all using the same widgets.
And it allows our applications to get a lot of velocity
so they can all get these wonderful reviews that they can
get feedback from their users that they're just
delighted to use it.
And it's something that we really
strive for in our applications.
But we've heard from our external developments
that UI development can still feel like this for you.
It's a little slow.
You don't really want to have to write that common button.
You don't have to want to write that common tab component.
You just want to have to work on the application logic that's
special to your app that will make your users delighted,
and you don't really have to worry
about all this other stuff.
And Dart does a pretty good job with the core libraries
that let you get up and running really, really quickly.
But we want the development to feel like this,
like you're in a rocket ship.
And this is the way that development inside of Google
feels like.
You can really concentrate on your application and your logic
to delight your users and make sure
that you're doing really great stuff
rather than worrying about some of this more simple stuff.
But we've heard from you that there's
a piece missing, that there's something that's
keeping you guys from making these wonderful applications
yourself and making it hard to get those wonderful reviews
that we saw.
So today, we announced Angular Dart Components,
production-quality widgets for everyone.
[APPLAUSE]
Now, today, we're just giving you a preview
of what you'll come to see.
We've got some kinks to work out still for a general release.
But we really want to get you excited about using the widgets
and allow you to get some of these wonderful reviews, some
of these wonderful applications for you yourself.
Now, this is not just a solitary effort.
There's not just a team of five people at Google doing this.
There's actually hundreds of Googlers
that have contributed to these widgets.
Many of them are in this room today,
but there's many, many more across the entire world
contributing code and making sure
that they're production-quality and they work well
for their users and for their applications.
And we get many more bug requests from them,
too, to validate that they're working correctly.
And we're very excited to bring you into our community,
to have you use these components and help us
and to make them better so that you
can get the wonderful usefulness out of them.
So today, I really wanted to talk about three key principles
that our infrastructure team works on
and everything that we work with, widgets specifically.
And that's velocity, usability, and efficiency.
And [? Ferhat ?] [? and Maton ?] already talked to you a little
bit about this on how we do it with Angular itself,
but I'm going to talk to you about how we do it
in our widgets.
First, velocity-- letting you concentrate on your product.
You don't have to worry about the widget itself.
We provide a set of material design core widgets written
in Angular Dart for you so that you can quickly
work on the application logic that is important to you.
There's over 100 widgets that we have internally at Google,
and we're going to show you some today.
It was actually just published before I came up here,
and you can take a look.
And many of the ones that you see on the screen,
they're going to be available.
This isn't ready to be released yet,
but eventually, we're going to give you a gallery.
Internally to Google, we have a gallery
that actually allows our developers to quickly see
what widgets are available.
It gives them documentation about how to use the widget,
and also gives them examples so they
can see how the developer meant the widget to be used.
It allows us to quickly and easily see
what's possible with the widget and also how we could quickly
get those widgets into our production
and into our application.
Something else that we use a lot within--
and this isn't quite ready for release yet, but we'll see it
soon-- is that we use SaaS a lot in our components.
It isn't just that the components have SaaS.
We actually provide mixins and variables
so that you can have the material to design language
within your component so that you can have your CSS be very
semantic, and you can semantically
say what you were meaning to do.
This is valuable for what we have within Google,
because no longer do we have just variables mixed
in throughout our CSS.
Instead, it's very easy to make our CSS readable,
and we can figure out exactly what the designer meant
for the component and also what the developer meant
when they were implementing it.
So instead of having all these random variables
for material shadow, now we can just
say we want this component to have material shadow,
and it automatically gets it, and it's clear
that that's what the developer was trying to do.
You're not copying and pasting these values from somewhere.
Now, [? Maton ?] already explained
how Angular is bringing you page objects
if you want to use them to make your testing easier.
We're also going to provide page objects for the component
itself.
And this makes it that much easier for you to write tests
when you use the component.
You actually get the logic and its very simple interface
to start testing the component instead
of having to write all this code on a component
that you didn't even write yourself just to test it.
So in this example, we see that we have the material input page
object, and we can just have simple methods
to interact with it, like being able to type values
into the input and to be able to see what
the value of that input is.
Usability-- we want the components
to be usable for both our developers,
but also for our users.
Accessibility is for everybody.
It's not just for a certain set of users.
If your UIs are accessible, they make them easier
to use for everybody-- me, you, my dad, everybody.
And we actually gave a preview of this to our GDEs,
and we asked them what they thought about these components.
And you can just take my word for it
that we think that our APIs are pretty nice,
but I wanted to give you some quotes for them about what they
thought.
Monty, who couldn't be with us today, he said that coding them
has a great feel.
They have syntactic brevity.
They seem lighter and better-integrated into my app.
Faisal, who is here today and is going
to give a presentation later, he said yes, yes, yes.
I love this.
Super easy to configure.
This is the kind of reactions that we want from all of you.
So how did we do this?
How does it look like?
Well, one thing is we want these widgets
to look like idiomatic HTML.
If you notice, there's these three values right here
are actually doing all the same thing.
But the first one looks like a very-- just
like a standard HTML element that you
might find in your browser.
You can just quickly say that this button is disabled,
and it will be disabled.
The second one works, too, if you want to pass it the string.
And the third one is if you actually need a binding for it.
So this allows it to be dynamic.
This actually does save a little bit of performance
also, because in the first two, you know that it's static.
You know that it's never going to change,
so it's a little bit faster.
And then the third one will give you that dynamic nature
that you're looking for.
Sorry about that.
We also work very, very closely with the Angular Dart team.
I'm in their office pretty much once a week-- they
can attest to this-- bugging them all the time.
And we want to make sure that the components are idiomatic
Angular Dart, that it's the Angular that you would expect
to write in your own applications
that the Angular team would like to see
written for your applications.
Notice that his outputs, like you would expect
with the events that you come to love or hate from Angular,
and that it uses the standard forms library, like NG Model,
so that it just works well with the rest of Angular.
Another thing that we want to provide
is we want to make it really easy to use our models.
So in each of these widgets, they're
all backed by the same model, the selection model class.
And while it would make it easy to switch
the widgets if you needed to, that doesn't happen very often.
The real benefit of this is that you can learn an API once.
You can learn the selection model API once,
and then you can use it over and over again, very quickly,
in tons of different widgets so that you're not
learning a different model for every single widget
you want to use.
And it has accessibility built in.
We really wanted to make it easy for you guys
to have accessible applications that work well for your users.
In this example-- you'll see this
throughout all of our widgets-- we have this trigger pattern
instead of just listening for click.
We want the user to be able to interact with it with a mouse
or with the keyboard, whatever way they see fit, whatever
works better for them.
So we have this trigger pattern that we see.
Also, things such as buttons and tabs and inputs--
when you have it disabled, it will automatically
set the [? RE ?] properties for you
so that it makes sense in the browser
too if you're still getting accessibility.
So when you say something is disabled,
then it's going to work right for accessibility also.
Now, while we can't cover all of your use cases,
we hope that we make it that much easier to make
your application accessible.
Efficiency, the last topic-- performance
is the feature in our applications.
Performance is very important to us.
I think you've heard a lot about it
today, about how we're trying to make everything very, very
performant and keep everything fast.
Our users love it when our applications are fast.
It's the thing that they want the most.
It's the thing that they care about the most.
And our widgets need to be able to support that.
One way that we do this is we actually have latency tests,
like [? Ferhat ?] was telling you
earlier today, that are run on our widgets
every single code change.
And it allows us to build graphs like this.
This is a real graph that came from one of our widgets.
And if you notice the top line, that
is the cold start performance.
That's the performance the very first time
that it's initialized on the page.
Down here, that is the warm performance.
That's what happens for every other time
that it's initialized.
It's a lot faster.
This is because that's going through a JS cold loop.
It's a good amount slower, and it's pretty fast
when you've actually rendered it once.
But we want to make sure both numbers are
very good and very performant.
So you can notice there's a pretty big hump here
in this benchmark.
So what happened?
Well, my coworker Zach, he actually
came through, sent in a CL.
He was changing some of the, I think, accessibility
on something.
And all of a sudden, I got an email that night
that said that there was a performance regression.
So I emailed Zack, and I said, hey, did you expect this?
Was this what you were expecting?
Did you expect it to take about seven milliseconds longer
for this simple action?
He said no, I didn't really think it was
going to be any performance.
I thought it was going be performance neutral.
I'll go investigate it.
So he took a look, and it turns out
that the API call that he was calling was more
expensive than he imagined.
And he switched it with a different one.
And you can notice that the latency graph came back down.
And he actually made it a little bit faster
than it was before he started.
So we can quickly see when things go wrong
when things are hurting our performance
or making it better.
Also, when Chrome drops, our graphs change, too.
So we've had instances where we've
had performance regressions on our widgets,
and we've actually went to the Chrome team, and we said, hey,
did you expect this?
Was this regression something that you
wanted within your browser?
And they said, oh, let me take a look at it.
And they came back, and two versions later in Chrome,
we actually had it fixed.
So we can actually catch other problems, too.
Another problem that we're trying to solve
is layout thrashing.
So naively in your application, it's
pretty easy to read a value from the DOM, change that value,
and then reread it.
And you might think that this is OK.
But in fact, what you're doing is
you're causing the browser to reflow and to re-render
the page.
This can be pretty expensive.
It can be 15 milliseconds or longer just
between these two method calls.
And that's something we want to try to avoid as much as we can.
So within your own application-- or
within your own simple widget, it
might be easy to move all the reads before all the writes,
and make sure that it happens in the right way,
and that you don't trigger reflow.
But that's really hard to do when
you're talking about the very large applications
that we build at Google.
You can't control all the source code
to make sure that the DOM is coordinated in the right way.
So we actually have a service.
It's the DOM service.
And this is in the preview.
It allows you to say that you want to schedule a read
or schedule a write and make sure that the reads happen
for the mutate so that we don't get that-- we don't trigger
that reflow, that we're not paying
the price for the layout.
We use this in all our widgets.
And you can use them in your applications,
too, to make sure that your render speed is really, really
performant.
Lastly for performance, I want to talk about change detection
optimization.
So [? Ferhat ?] already talked to you
about how change detection can make
your application pretty slow.
If you have a naive application, it's
pretty easy to just use change detection,
and everything will work fast enough,
and you won't really notice any slowdown.
But when we're talking about the size of the application
that we build at Google, change detection
starts becoming a problem really quickly.
And our components actually help you with this
as much as you can.
We enable you to do better things
for your change detection.
And we do that in two ways.
One way is that if we have anything that's
off the screen-- anything that the user isn't actually
seeing right now, but we need it in our application--
think of a tab.
If you have five tabs on your screen,
you're only showing the content of one,
and the other four aren't being shown.
But naively today, if you just build tabs really simply,
all of those tabs are going to be in your change detection
tree.
They're all going to be part of your application.
What we do is we allow you to mark
that the tabs-- that this part of the code
may not be on the screen to the user right now.
It allows us to remove it from the change detection tree
and keep your application just a little bit faster.
The other thing that we provide is that the widgets themselves
enable on push, and they will soon enable set state.
This allows you to keep your application fast.
Because if you want to use these cool new features,
everything in your sub-tree, if you
want to make a component on push or use set state,
everything needs to support that capability.
So the components won't keep you behind.
They do support on push today, and they'll soon
support set state.
So it allows you to really build these fast applications
if you wish.
If you just want to use the standard change detection,
that works, too.
Everything will just work fine.
So again, I want to thank you from all the people at Google.
This is really a labor of love for us.
There is, like I said, hundreds engineers worked into this.
We all love these components.
I have people that work on these components that really don't
even want to do their day job, because they really
love working on the components itself.
So I hope that you guys will get a lot of use out of it.
Next year, I want to see great reviews
that we saw for our applications,
I want to start seeing them for your applications.
So go out and start building some great apps
so that we can have some wonderful stories to tell
next year.
Thank you.
[APPLAUSE]