ng-conf 2015 Day 1 Keynote – Brad Green and Igor Minar

ng-conf 2015 Day 1 Keynote – Brad Green and Igor Minar


BRAD GREEN: I’m Brad Green. IGOR MINAR: Hello, I’m Igor. [APPLAUSE] BRAD GREEN: If you’ve been
following our team for a while, you know we’re a group that’s
driven by our principles. So this morning, we’re
going to talk about one of our core principles,
which is being, hopefully, good caretakers
of the Angular community and the Angular code base. But practically,
what we’re going to talk about is why we’re
here, where Angular 1 is going, and where we see Angular
going in the future. I hope you like it. IGOR MINAR: But
before we start, we should give our thanks to
the ng-conf organizers. I bet that many of you
don’t know that– yeah. [APPLAUSE] I bet that many of you don’t
know that ng-conf is not organized by somebody at
Angular, the Angular team or at Google. It is completely
community-driven. BRAD GREEN: So we have
already given welcome. So we can go to maybe thanking
the people who are with us on the live stream. We’ve already thanked
them a little bit. But maybe one more little
round of applause for everybody who’s tuned in from home. [APPLAUSE] IGOR MINAR: Hey, guys. It was midnight last Sunday. We were working on
this presentation together with Brad. And we asked ourselves a simple
question, why are we here? We thought about it. It’s very simple. Why are we here? Why are we doing Angular? And then we realized
that we never answered this question to you. So we scrapped the
presentation we’d been working on for months,
and we started from scratch. BRAD GREEN: When we
started Angular in 2009, answering this question
was really easy. We were trying to make
ourselves much more production and building web applications. We were building Angular for us. IGOR MINAR: Angular really
solved these problems for us. And it solved
problems for you too. You adopted it, and
you became part of it. Not only did you adopt Angular,
you contributed to Angular. You contributed code,
documentation, videos, and tutorials and more. In this way, Angular was
not just about us anymore. We felt this trust
that you gave to us and felt the responsibility
that came with it. BRAD GREEN: So over the
last five years, many of you have also told us that
Angular’s solving your problems. It’s gone from something
that’s just been for us here at Google to something that a
lot of people around the world enjoy. IGOR MINAR: In the
past presentations, we’ve always paid special
attention to community and the Angular ecosystem. We think that Angular, even if
it was technically flawless, could never be
successful without you. We also think that the
developing we do on Angular and the way we do it
results in superior results. BRAD GREEN: So today
we’re going to talk about how we’re evolving
the Angular of today, given this responsibility
that you’re trusting us with. But because of this,
we’re also going to talk about how
we think we want to evolve Angular in
the future and why we’re going to work on Angular 2. IGOR MINAR: Let’s take
a look at how we work. I mentioned that the way
we develop Angular results in superior results. And there are actually three
commonly used developing models that we see out there. There is closed source. There is open source export. And there’s open source with
deep community involvement. The difference between
these is in how the control and the
workload is distributed and how the feedback
is looped back into those who have the
control and do the work. BRAD GREEN: So the main
differences between these are the distribution of
control and how the feedback is being looped back into those who
have the power to do the work. In the closed source project,
the team does all the work, but they don’t share
the source code. And they get to listen to only
the feedback that they want to. IGOR MINAR: With
open source export, the team shares the
code and tolerate forks. But they don’t really
accept any changes back to the moon repository. And they get to pick only the
feedback they want to hear. BRAD GREEN: We believe Angular
belongs in this last category. IGOR MINAR: So this way
of building Angular, we are able to
build software that is more robust because
it takes more use cases and perspectives into account. It also results in software that
has more integration points, so it fits better into
existing ecosystems. And because of the
higher adoption rate and contribution
rate, it’s also software that has fewer bugs. BRAD GREEN: And we hope that
this process where all you can be part of Angular
community and its work is a more trustworthy model. And trust is kind of a
hard thing to measure, but we think it’s
really important. IGOR MINAR: Trust and software
quality, benefits aside, we also get to work with very
many talented people inside of Google but also outside. And we are very grateful
that we get to call these people our friends. And many of you have joined
us today, either in person or virtually. BRAD GREEN: One of
the last big benefits we’ve had on the Angular
team from this model is our ability to hire some
really high quality people. For most of the people that
we’ve brought on recently, we’ve actually gotten to know
you by your contributions to the Angular community. IGOR MINAR: Let’s talk about
how the ng team or the core team expanded over the last year. BRAD GREEN: So last year
when we were here at ng-conf, we talked about how our team
had grown up until 2014. Well, we’ve continued
to grow and expand based on the expansion
of the Angular community and with all the projects
we’ve undertaken. IGOR MINAR: But not
only did we hire more people for the
core team, we also took many of you that
were active participants in the Angular development
and made them core team members on the Angular team. These include people like
Martin Staffa Shahar Talmi, but also developers sponsored
by companies that are working with us on the team. BRAD GREEN: So Igor,
why would a company sponsor their developers to
work full time on Angular? IGOR MINAR: Well, this
is what Amadeus did. They realized they were
betting big on Angular, and they wanted to have
a stake in its future. They didn’t want
to sit on sidelines and just watch where
Angular’s going. They wanted to be
participants in this. And they decided to invest in
the Angular core development and have a stake in
its future direction. We thought about this
and realized that this wasn’t such a crazy idea. And because the
developers were led by Pawel Kozlowski, a well
known figure in the Angular community, we felt
pretty comfortable about taking them onboard. BRAD GREEN: Yeah, so
this development model, where big companies
invest in Angular, actually allows us to
scale faster and do more. And we’d like to see more of it. If any of your companies
are interested in this, the first step is being
seen as a contributor to the Angular community. IGOR MINAR: Back in
October, we announced that Pete Bacon Darwin took
over as the Angular 1 lead. I was the previous
lead on Angular 1. But other projects like
internationalization, or C infrastructure,
package management, and bits of Angular
2 were distracting me and were not allowing
me to focus on Angular as much as it deserved. This is why Pete stepped up. And with Pete and
the team around, now we have a dedicated person
to lead and evolve Angular further. BRAD GREEN: So as a lot of
you are happy to tell us, you’ve picked Angular as your
solution for building web apps and that we can’t stop
in Evolvian’s future. And we agree. IGOR MINAR: When
we asked you, what are the most pressing
issues in Angular 1.3, you told us that
the routing was too limiting, that building
applications for users that were in more than one region
was too difficult because of insufficient
internationalization support. And you also told
us that you really liked the performance benefits
we delivered in Angular 1.3, and you don’t want
us to stop there. BRAD GREEN: So some
of the big work we’re doing feature-wise
for Angular 1 is work that we’re going
to share with Angular 2, starting with the router. We built this new
router for Angular 2 and then back ported
it to Angular 1. It focuses on mobile use
cases and complex situations in big apps. Brian will talk about the
new router later today. You can hear all about it. Internationalization is
important on desktop, but it’s actually
critical on mobile where you’re trying to
penetrate emerging markets. So you can hear about
this from [INAUDIBLE] who’s going to come up and
talk about this new model for Angular. Better performance and the
rest of the improvements in 1.4 are going to be covered by Lucas
and Pawel in the talk right after this one today. IGOR MINAR: So the
1.4 release candidate will be out in the
next week or two. And this will make it
the fastest release we’ve ever made. I would like to thank Pete
and the rest of the team for improving our
processes, which made it possible to deliver
these features to you as quickly as we did. BRAD GREEN: Good job, Pete. [APPLAUSE] OK, while we’re on the topic
of Angular 1 development, we should give you an update
on our material design project. IGOR MINAR: So Material Design
is Google’s answer to single UI specification that
spans desktop, tablets, mobile phones, also
wearable devices. With Angular Material,
what we did is we implemented the specification
using Angular directives. BRAD GREEN: So Angular
Material’s now in beta release. We’ve got 29 of the most
commonly used Material Design widgets developed. They’re built for mobile. They look beautiful, and they’re
built to address accessibility out of the box. IGOR MINAR: Along
with these components, we also built an application
oriented layout system that is based on flexbox. And we added theme software
so you can customize the look and feel of the application. BRAD GREEN: So we’re headed
towards a 1.0 release for Angular Material on
Angular 1 this summer. And after we get
that work completed, we’re going to start delivering
this beautiful experience for Angular 2. IGOR MINAR: With
1.4 almost finished, we have started to look towards
wherever Angular 1 is heading, what’s next for it. And because we expect
that many of you will want to migrate to Angular
2 as quickly as possible, we’re setting the primary
theme for the future Angular releases to be the paving
the path to Angular 2. But we want to take your
input into account as well. So we can listen to your
feedback and use that to gauge which
priorities or which features we should prioritize. BRAD GREEN: While
we’re on Angular 1, we should talk about how
we’re going to support it. When we were at ng-europe,
back in October, we showed that there were
over 1,600 applications written in Angular, checked into
Google source code repository. Now there are nearly
2,000, and we’re really excited about how fast
this is growing at Google. IGOR MINAR: Every month,
nearly one million of you visit angularjs.org. And about 100,000 of you
interact with the Angular team on GitHub. BRAD GREEN: We often
get asked the question– because you guys and actually
a lot of developers at Google rely on Angular 1
today– how are we going to split our development
between Angular 1 in Angular 2? IGOR MINAR: We want to
drive our development based on your feedback. And we want to split
the time we spent between Angular 2 and
Angular 1 based on where you’re spending your time. BRAD GREEN: So our
website at angularjs.org is where we all go right
now for documentation, news, and other Angular resources. Today I’d like to announce our
previous site for Angular 2 at angular.io. We’re going to use the traffic
between these two sites to gauge interest
in the community as to where you’re
spending your time, along with interactions on
GitHub and other sources. IGOR MINAR: We’ll
use the signals to decide where to invest. But one of the primary
principles we’ll use is that we’ll continue
releasing Angular 1 releases until the vast majority of you
might migrate to Angular 2. BRAD GREEN: So we’re also
going to keep track of this and make the numbers public. We’ll release them online at
conferences like this one, so we can all
together decide where we’re going to invest in
the future of Angular. IGOR MINAR: This will
actually put the burden on us to make Angular 2
more attractive, easy to learn, and
easy to migrate to. BRAD GREEN: So now
that we’ve said we have some migration
that’s going to happen, we better have a plan. IGOR MINAR: We
thought about this, and we came up with
two strategies. We’ll label them big
bang and incremental. BRAD GREEN: In the
big bang scenario, this is where you
would decide that we’re going to stop
development– stop feature developments– on Angular 1,
migrate all of our templates and JavaScript to Angular
2, make sure it all works, and then resume
feature development. IGOR MINAR: This is
the approach that you might want to use if you
want to take advantage of all the features of Angular
2.0 as quickly as possible. There will be actually
some teams at Google that will do just this. BRAD GREEN: So because the
incremental strategy that we’re going to talk about
in a minute is going to require that
you load both Angular 1 and Angular 2 libraries,
this big bang strategy might also be most
appropriate if you’ve got a mobile app
or other scenarios where the total payload
size is really important. IGOR MINAR: We also
understand that this big bang strategy is not for all of you. And this is why we also
have a second plan, incremental strategy. And our new router that Brian’s
going to talk about in a bit supports this one. But there are
actually two options. One is you start using
your application– you keep on developing Angular
applications as you are today, but you start migrating some
of the views to Angular 2. And the new router will
support mixing and matching both versions. BRAD GREEN: You can
also go the other route where you rewrite your
top level application controller using the new router
to build a shell for your app. And then one by one, you can
migrate your individual views to Angular 2. IGOR MINAR: For
now, we are planning to provide a migration guide. And John Papa,
yesterday, commented to helping us write it. BRAD GREEN: Thank you, John. IGOR MINAR: Thank you, John. [APPLAUSE] We are also thinking of how
could we help you with dueling. We have some ideas
about this, but we still need to think through this. BRAD GREEN: Right. But you don’t have
to wait for us. One of the best ways you
can prepare for Angular 2 is to follow the best practices
that we know on Angular 1. John Papa and Todd Matto
have consolidated these into an online style guide,
and John will present these at his talk later tomorrow. IGOR MINAR: We already mentioned
that one of the entry pods, one of the possibilities,
is using the new router. And together with ASICs
modules and ASIC in general, this will make the
migration easier. Brian will cover
this later today. BRAD GREEN: Lastly, if
you’re using TypeScript, you can get more
help from your IDE when you go to refactor or
migrate your code to Angular 2. You can hear more about the
details of what a migration strategy might look like
from [? Mehal ?] in his talk on the subject tomorrow. IGOR MINAR: To summarize
the themes for Angular 1, we are delivering or working
on some exciting new features, like the router,
internationalization, Material Design, but we are also
committed to supporting you. And we have a dedicated
team for that. We are also working on
migration strategies to help you to get to Angular 2. BRAD GREEN: All right. So now let’s talk
about Angular 2 and why you’d want to
migrate in the first place. IGOR MINAR: Over
the past five years, we’ve had the privilege to work
with thousands of developers from Google or outside. And we listened
to their feedback. And we kind of summarized that
feedback in several things. You said that you wanted
more consistency in Angular applications, more simplicity. BRAD GREEN: You wanted
to be more flexible. You wanted to be much faster. And all of this should
sum up to you being more productive developers. IGOR MINAR: When we
looked at where we were and where you
wanted us to be, we realized that we couldn’t
get there with the Angular 1 architecture, at least
not without making very painful breaking changes. This is why we came
up with Angular 2. BRAD GREEN: So Angular
2 is now in alpha. And you can go see its
status on angular.io. While it’s not ready
for building production applications quite
yet, we did want to cover what
we’ve done to date. IGOR MINAR: As you probably
haven’t had the chance to work with Angular 2 yet,
you might be wondering, how is Angular 2 different? Are the features that I
like in Angular still there? How will the
investment [INAUDIBLE] into learning Angular and
writing Angular applications map to this new framework? BRAD GREEN: So while the syntax
and semantics have changed a bit from Angular 1, you’re
going to find, I think, all the things that you grew to
know and love about Angular 1 already in Angular 2, from
dependency injection, data binding, directives,
to Karma, Protractor, and the rest of the testing
story, accessibility, and the rest, all
improved across the board. IGOR MINAR: We’re really
excited about the simplification of many of the
existing concepts, but we’re also very
excited about adding new, very powerful ones. We’re going to cover many of
these over the next two days, but let’s talk about
some of them now. BRAD GREEN: Let’s talk
about productivity. This is has been
a theme in Angular from the very beginning. In Angular 1, we
limited ourselves to building productivity
enhancements with just what the browser
gave to us at the time. And we made it pretty far. Recently, in the
last year, we’ve been focused on making developer
productivity enhancements to JavaScript itself. IGOR MINAR: Last
year, at ng-europe, we announced AtScript. This was our answer to looking
at what developers needed when building Angular applications. And it was a proposal how
we could extend JavaScript and make it evolve. BRAD GREEN: So starting
with AtScript 5, or what we just call
JavaScript today, we wanted to see if we can
help to move the ECMAScript 6 adoption faster by
supporting it in Angular and promoting it here. We love ES6 for its basic
developer productivity features, and it helped
avoiding language pitfalls. IGOR MINAR: We also got excited
about optional type system as delivered in TypeScript. And Dan and Andrew
are going to talk more about this later today. BRAD GREEN: And
lastly, we wanted to be able to express metadata
concepts about our code. Annotations allow us
to do this, and they allow us to much more
succinctly express what we need to do when
we define data binding and directives in Angular. IGOR MINAR: But we didn’t want
to create a language extension that was specific to Angular. The types of metadata
annotations, these are generic features that any
developer can benefit from. This is from day one. We decided that
whatever we are going to work on within this area
of language extensions, it is something that we
wanted to take to tc39 and standardize as a regular
feature in the JavaScript platform. BRAD GREEN: Yeah, we’ve
made some progress there. One of the parts of the tc39
process that’s really critical is to show, in
some live examples, how some of these proposed
extensions are actually good. And so we worked with Erik
Arvidsson and other members of the V8 team on
Chrome at Google to build the features of
AtScript into Traceur. Now Traceur is a transpiler that
takes features of the proposed standards in ECMAScript
6, 7 and now AtScript and links them into JavaScript
that works in today’s browsers. And so using Traceur
and AtScript syntax, we’ve been developing Angular
2 successfully for over a year now. IGOR MINAR: After an
announcement about AtScript, we found that there are
many people that care about the same things we do. We talked to the
Chrome team building V8 that not only is implementing
the E6 features into the VM, but they’re also working
on creating a sound type system that will deliver
faster performance and more predictable performance
for JavaScript applications. We also talked to
Closure Compiler team at Google, which is also
working on adding E6 support the Closure Compiler in addition
to adopting TypeScript style of types annotations. These are the tools
that will enable us to take advantage
of these features before they’re baked
into the browser. And we also talked to
the Facebook team that works on flow, and we had
really good discussions about JavaScript and
types in JavaScript. BRAD GREEN: We’ve also had
many good conversations with some of our friends at
Microsoft on the TypeScript team. In fact, we’ve made
so much progress with them I’d like to
bring them on stage now. Please welcome
Jonathan Turner who’s a program manager
for TypeScript. [APPLAUSE] JONATHAN TURNER:
Thank you, Brad. Thank you, Igor. Really excited to be at ng-conf
in beautiful Salt Lake City. This is a fantastic
venue, and I’m really excited to be a part
of this conference. So I want to take us back
to November of last year and talk about a
collaboration that started between the Angular
team and the TypeScript team. When Angular announced AtScript
and some of the features that they wanted to see part
of JavaScript, the JavaScript standard, a better
declarative way for working with rich
libraries like Angular, the TypeScript team
got really interested. So we reached out, and we
formed a collaboration. We met up and started talking
about what would be possible if we started taking some
of those features that’s part of AtScript and put
them into TypeScript, merged it with the
type system, merged it with how the compiler
output JavaScript code. So I remember sitting around the
table with Misko, with Anders from the TypeScript team,
looking at these problems and kind of solving these
engineering problems one by one. As we saw earlier, we had this
nice ideal of these layers, where ES6 builds on ES5. You’ve got types on top of that
and annotations on top of that. But as we’re starting to
unpack each of these problems, we had to be kind of honest. Back in November, what
the actual reality was was kind of not so clean. Each piece needed a
couple more features to bring it up to maturity. So the TypeScript team took
this in our challenging, loving selves as engineers, looked at
it, and started tackling it. So we tackled it in two ways. The first way is that we started
incorporating more and more of ES6 into TypeScript. And with TypeScript 1.5,
which is the upcoming version of TypeScript, we will
now have very rich support for ES6 in TypeScript. We also worked with
the Angular team closely to incorporate
annotations. So we have a nice
declarative way of working with
libraries like Angular, where you could have a nice
separation of concerns. And we took the
Angular feedback, and we also worked with Yehuda
Katz from the Ember team and with Rob Eisenberg to
create a nice, rich design that we then implemented
as part of TypeScript. I’m happy to announce today that
the next version of TypeScript really fills out
this story where we have ES5 and types
sitting on top of ES6 and annotations
working with all types. We have nice tooling across
all of these features and nice is ES3 and ES5
output as part of this. We’re really exciting. Thank you. [APPLAUSE] We’re really excited
to see what you all do. And I look forward to
hearing from you later. Thank you. BRAD GREEN: All right. Thanks, Jonathan. And thanks so much to the
rest of the TypeScript team. [APPLAUSE] So with this convergence,
we’re happy to announce that we’re going to retire
the term “AtScript.” And we’re just going to call
it all TypeScript from here on out. [APPLAUSE] You can hear more
about how TypeScript works with Angular 2 in a talk
that Jonathan and his partner will do tomorrow. IGOR MINAR: Well, we are
incredibly excited about all these new features
and productivity wins that our collaboration
with TypeScript will give us. I want to stress one thing. All of these features will
be completely optional. You’ll be able to take
advantage of Angular 2 whether you’re using ES5,
the new standard ES6, or you can go all the way in
with all the optional types and annotations
provided by TypeScript. BRAD GREEN: But we’re not done. For this to become a
standard, all of our partners are going to have
to come together. And we’ll need even more
partners to make this happen. IGOR MINAR: This is a very
long term investment, just like Angular 2. We think that this is
a really hard problem, but it’s a hard problem
that’s worth solving. BRAD GREEN: So while we’re on
the subject of other language options, we should
talk a little bit about our investment in Dart. If you use Dart, you’re
probably happy about it. But if you don’t,
you might ask us, why are you supporting Dart? Well, the simple reason
is that you benefit from this in a couple ways. Number one is you have a much
larger team working on Angular because of it. . And number two, we’ve learned
a lot from our relationship with the Dart team. We benefit from these
learnings in the JavaScript side of Angular. IGOR MINAR: Some
of you might know that we’ve had a version of
Angular for Dart for over a here now. We built it because there were
teams at Google that wanted to use Angular with Dart. And they funded our team
expansion to get it done. But we had a problem. We were not working
as a single team. We were two teams, each working
on separate innovations. BRAD GREEN: One of the
things we realized, though, was that the
majority of Angular code is purely algorithmic. And what we imagined was that
maybe we could write all of it in one language and transpile
to another language. And we’ve done this,
and this has allowed us to join the two teams. IGOR MINAR: We have
a process in place that allows us to
design and implement every feature in Angular using
AtScript or now TypeScript. We then transpile this
into Dart or JavaScript. And for the calls
or for the code that needs to touch
browser APIs, [INAUDIBLE], both in Dart and JavaScript. Then we combine this
output into a package that we ship as Angular 2
for JS or Angular 2 for Dart. BRAD GREEN: So again,
what this means to you is that there’s now a
team of Angular that’s double the original size working
on all the features for you, from performance to the new
templates, ITN, accessibility, all of it has a much bigger
team building Angular today. IGOR MINAR: We should
thank the Dart team for the great partnerships
we had with them. Kasper Lund helped us
rewrite our expression parser to be much more efficient. We got the idea of
zones from Dart. And we also saw the benefits
of optional type system while building large
applications in Angular Dart. These are all the
features that we’ll be able to take advantage
of in Angular 2, whether you’re using
JavaScript or Dart. BRAD GREEN: OK, while we’re
kind of on the subject, we should also talk
about something that I have a sense
is going on, where when there’s two
technologies in a space that cover the same
feature set, there’s some idea that they must go head
to head, that two will enter and one will leave. So whether it’s Angular verses
React or JavaScript verses Dart– we don’t really
see it that way. IGOR MINAR: Take
Ember as an example. Yehuda, as was
mentioned, helped us with designing the
annotations for TypeScript. But also, we had really
good collaboration with the Ember CLI teams
and the Broccoli teams. Steph and Joe understood
that working together will allow us to get
more done faster. And we will get benefits that
will be available to both Ember and Angular communities. BRAD GREEN: So
wherever possible, we would love it if you
guys could help support us in engendering a kinder
attitude towards collaboration in the open source community. [CHEERS AND APPLAUSE] Because this is really the
promise of open source. If it Looks good,
just copy it in. [LAUGHTER] We think we can
get a lot more done if we can all work together
and even be friends. When you guys talk
to us, you tell us that Angular is awesome, but
it could be a little easier to learn. There’s parts of Angular
that– well, there’s actually a lot of concepts to learn. Some of the errors
may come as surprises. And some of the APIs, maybe
directives in particular, are just downright
hard to learn. IGOR MINAR: Ben
depicted his experience with learning Angular
using this diagram. It looks like a very exciting
but bumpy coaster ride. It is our goal to straighten
this line for everybody in Angular 2. BRAD GREEN: So Igor, maybe
tell us, how did we get here? Why is it not a smooth
line in Angular 1? IGOR MINAR: It’s all my fault. [LAUGHTER] No, in the early days, five
years ago, Angular was simple. We designed it with the
focus on productivity, reducing boilerplate,
making testability easy, and providing us with structure. But the use cases we
were targeting back then were much more
limited than those that we deal with when building
complex applications today. Take components
as a good example. When Angular started, there
were no components in Angular. We just had templates
and controllers and a way to bind the two. But as we were building
bigger and bigger applications with Google or
outside, we realized that this was not
going to scale, that we needed a
better way to address composition and reusability. And component model was
something that we needed. We implemented,
and it was awesome. It took off. But now we had two ways of doing
many of the same use cases. And there was confusion. In Angular 2, we are
solving this problem but completely embracing
the component model and making it the default. This will remove
a lot of confusion that is just in Angular 1. This is just one
of the examples. BRAD GREEN: So when
we looked at all that we’ve learned from you over
the last five years of Angular, it pointed to the fact that
we could be much simpler and that we should go
this way for Angular 2. IGOR MINAR: One of the
first areas we looked at were the directives that
we ship with Angular. There were many of
them, and we realized that we could just reduce
them to four generic templates and concepts. This means that the API
service is much smaller for you to learn. And you will be able to
get done the same stuff you were able to do with Angular 1. BRAD GREEN: So
this generalization doesn’t just make Angular
easier to develop for, but it makes your
applications more consistent. We mentioned the style
guide for Angular 1. But unlike Angular
1, Angular 2 is going to have a style
guide from the very start. IGOR MINAR: But we won’t
stop with a style guide. We’re actually
building a tool chain that will help you create
and refactor the application as you build it. We’re not, however,
starting from scratch here. We have these great partnerships
with TypeScript and Ember CLI, which allows us to
make a good progress. We don’t have enough to
show at this conference yet, but be assured that
we’re working on it. Not invented here
is not something that is dear to our hearts. Brad, have you ever tried to
include JQuery UI component in your Angular
application and realized it wasn’t working until
you called $apply? BRAD GREEN: I always do that. IGOR MINAR: See, we
solved this in Angular 2. We’re using this nifty
feature called zones that we learned about from Dart. And what the zones
allows us to do is to hook into the
browser event system and intercept those events
that are interesting and trigger the
synchronization between Angular and the rest of the platform. BRAD GREEN: Very cool. As a matter of fact,
we talked about zones when we were here last year. And you can find the taught
by Brian Ford on YouTube, if you want to learn more. So unidirectional data
flow is at the heart of the new change detection
strategy for Angular 2. And what this means for
you is that you can easily predict what the performance
characteristics will be of any change you
make to the system. It’ll also make
it much clearer as to what’s happening when you
see side effects that you don’t understand. IGOR MINAR: If you’re
wondering if you will still be able to use two-way
data binding with forms using ng-model, rest
assured that what we are building, even
though under the hood works differently,
for you as developers, it will still have declarative
syntax that is familiar to you. BRAD GREEN: So maybe
you’re like me, and you’ve spent some time
developing some Angular code, and you’ve made some hard to
find typos somewhere, maybe in your template, or
controller, or directive. In Angular 2, we’ve
made the syntax change so that it can be statically
analyzed by linters and IDEs. And this means that we can
find the problems for you before you ever have
to run it in a browser. IGOR MINAR: As our repertoire
of use cases expanded, we realized that we need to add
more features to existing APIs. For example, directives–
we added more features, but by doing so, we made
the API much more complex. In Angular 2, we are
building three special case APIs for different scenarios. So you don’t need to wonder,
like, which options to use. You’ll be able to just go for
either component or behavior directive. And you’ll get all the default
options out of the box. We love it when web
platform evolves. It makes our lives simpler. A lot of the
simplicity in Angular 2 is because we’re able to take
advantage of browser features that just recently were
made available for us. A good example of this is
the ECMAscript module system. With ES6, we now have
a single module system that we can rely on. This was not something
with that we had when we started with Angular 1. For browsers that don’t
support these features yet, we have transpilation
or shimming that will just make it work
and will bridge the gap. BRAD GREEN: Yeah. Similarly, when we wrote
directives for Angular 1, there was no analog for
this in the web spec. But today, with
web components, we can take advantage of many
of the features in there to do some of the work
that we used to do. With features like the template
element and the Shadow DOM, a lot of our code goes away. To sum it up, we’re
basing Angular onto these new
standards that’s going to make it much easier
for us to interoperate with other libraries
and preserve our longevity in the future. IGOR MINAR: When we started
working on Angular 2, we made a decision to focus
on performance from day one. When we were working on
Angular 1.3, one of the things we realized was we
didn’t have a good way to measure performance. We also didn’t understand
how and where the time is spent in the browser. What we did is we built
a suite of benchmarks. One of them we call Deep Tree. This benchmark allows
us to replicate behavior similar to that we see in a
complex Angular application. In order to understand
how fast we can be, we built a baseline
implementation of the benchmark. We used just pure
JavaScript, no Angular, and all the performance
tricks we could come up with. The code is super ugly. You would never want to write
the application in this way. But it just tells us what
is the theoretical maximum that any framework on the
browser platform can achieve. To start with, let’s look at
how well Angular 1.3 is doing. BRAD GREEN: So then
we started to look at what takes time in Angular,
and where could we be faster? Misko came in one
day with a crazy idea on how we could maybe make the
code that we generate easier for virtual machines to inline. This technique we now have named
ultra fast change detection is almost 10 times faster than
what we can do on Angular 1. And it’s all because of the
new architecture for our code. This combined with
several other changes that we are able to make
because of our new architecture, we become dramatically
faster for Angular 2. [APPLAUSE] IGOR MINAR: Another
the performance trick that this new architecture
allowed us to use was something that we knew
about for a long time, but we just couldn’t
use in Angular 1. In Angular 1, whenever
we destroy a view, we have to throw away all the
data structures and DOM that was created for that view. In Angular 2, we know when
it’s safe to reuse these data structures in DOM. And this makes rendering
similar components much faster. The impact of this is the
most visible in two use cases, in the infinite scrolling
and in back and forth navigation in the application. BRAD GREEN: So the
way you can think about this is the yellow bar
for Angular 2 out of the box is first time rendering speed. Angular 2 with view
cache is the behavior you get when users revisit
things that have already been rendered for you. [APPLAUSE] But there’s more. IGOR MINAR: The
last performance– BRAD GREEN: Wait, wait. No, there’s even more. [LAUGHTER] So speed is not the only
thing that comes into play. When your memory is
limited on Desktop, or in particular mobile
devices, it’s really critical that you become conservative
with how much memory you use. Because when the
garbage collector runs, it can slow down your app. It turns out that these changes
we made are not only faster but they’re much more
memory efficient. IGOR MINAR: Can I go now? BRAD GREEN: Now you can go. [LAUGHTER] IGOR MINAR: The last
performance trick we want to show to you is how
Angular 2 can take advantage of immutable data structures. We already mentioned
that in Angular 2 we have a new change
diction system. And this new system is much
more flexible than the one we have in Angular 1. What it allows us to do is
to treat different objects differently. So when we come across an
object that we recognize as an immutable
data structure, we know that we don’t need to
do check it because it’s not going to change. This can have significant
improvement on the performance of our application. BRAD GREEN: So to show it off,
we built this other benchmark to test virtual table
scrolling speed. We can see in Angular
1 that as we increase the number of tables that
we’re trying to scroll, the performance slows down. In Angular 2, it’s
dramatically better. But it’s still, you
can see, that it’s linked to the total number of
elements that we have to watch. When we use immutable
data structures, however, you can see
that we’re totally decoupled from the number of
elements that we need to watch. We’ve gone from an
order n algorithm to an order one algorithm. [APPLAUSE] IGOR MINAR: So to
summarize, to go back to the original question we
asked ourselves, why are we here, Why are we doing Angular? The answer is
actually quite simple. We love Angular, and we learned
a lot while building it. But we also know that Angular
can be significantly simpler. It can be significantly
more consistent. It can be more flexible,
more productive, and much, much faster. While we are
committed to Angular 1 and evolving it
further, we also know that it will be
irresponsible from us to not lead the community in
the direction towards Angular 2. BRAD GREEN: OK,
one more question might be on your minds. You know that I love
answering this question. I hate predicting
the future, but you know what we can do
is look at what we’ve done to date and our velocity. And so back in
February, we announced the alpha of Angular 2. And you can find out
about it on angular.io. Today, we’re shipping a preview
of the Angular 2 website. And while I don’t like
to predict the future, I will let you in on something
that’s going on at Google. This May, we’re planning on
migrating the first application from Angular 1 to Angular 2. And these are big apps. We’re going to
take the learnings from that and from feedback
from all of you who use Angular 2 to figure
out when we’re done and we can call it ready. [APPLAUSE] IGOR MINAR: Now that we
answered the simple question, why are we here, I think
it’s only fair to ask you, why are you here? Think about it. And if you are here in
person, come and tell us. If you’re joining us online,
you can use Twitter or Google+ and post to us using
hashtag #whyruhere. BRAD GREEN: All right. Everyone, thanks so much. You can find these slides
at this link on the screen. We’ve also started a Reddit
Ask Me Anything session. We’re going to be taking
questions now and tomorrow. And then we’re
going to answer them live at the last session at
4:00 PM tomorrow afternoon. For any questions we don’t
get to in the live session, we will answer them in
the next week on Reddit. Thanks so much. Let’s have a great conference. IGOR MINAR: Thank you! [APPLAUSE]

13 thoughts on “ng-conf 2015 Day 1 Keynote – Brad Green and Igor Minar

Leave a Reply

Leave a Reply

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