-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
507 lines (356 loc) · 32.5 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title></title>
<link href='http://fonts.googleapis.com/css?family=Roboto' rel='stylesheet' type='text/css'>
<style>
p {
font-family: 'Roboto', sans-serif;
font-size: 24px;
}
article {
max-width: 970px;
margin-left: auto;
margin-right: auto;
}
a[rel=license] {
margin-top: 150px;
margin-bottom: 40px;
display: block;
}
h1 {
text-align: center;
}
h2 {
text-align: right;
}
img {
max-width: 100%;
height: auto;
margin-left: auto;
margin-right: auto;
display: block
}
</style>
</head>
<body>
<article>
<img src="images/angular===community.png" alt="Angular === Community">
<p>
I'm going to share a story with you today. A story about Angular, passion and community.
</p>
<img src="images/angular-passion-community.png" alt="Angular, Passion, Community">
<p>
When I joined Google in 2010, I joined to specifically work with Miško on Angular (actually Google Feedback, because Angular didn't really exist back then). I joined because I saw how passionate he was about the project and I believed that with a lot of work we could make something extraordinary together. Something that would change how developers feel about the client-side web and indirectly change how regular people use the web.
</p>
<img src="images/back-in-2010.png" alt="Back in 2010">
<img src="images/dorky-igor.jpg" alt="Dorky Igor">
<p>
Those were times when the mailing list was silent because only a few crazy souls wandered in there. The pull request queue was empty and Angular had no bugs (literally!).
</p>
<img src="images/empty-issue-tracker.png" alt="Empty AngularJS issue tracker">
<p>
Shockingly when I joined, Angular had no versioning scheme, releases, irc or g+/twitter account and all the other things that you are familiar with today.
</p>
<img src="images/things-were-simple.png" alt="Things were simple">
<p>
But things were simple. Gathering feedback was quick because only a few people were willing to provide it and we were working with them directly. Making breaking changes was easy, because nobody depended on our APIs. And since there was little documentation to be had, there were few typos and and only a handful of poorly written docs (basically all 5 of them).
</p>
<img src="images/bogus-typo.png" alt="Typo in docs">
<p>
I wonder if anyone here remembers how back then we used to have a weekly release schedule which we abandoned as we approached 1.0 and things got more "serious". I can't be happier that we reestablished it again a few months ago. It's one of the best project changes I fought hard for.
</p>
<p>
I love how the Angular community is maintaining the Wikipedia page about Angular. And updates it after each release with the release version, date and code name.
</p>
<img src="images/wikipedia-release-names.png" alt="AngularJS Wikipedia page">
<p>
It really makes it easier for us to pick a unique release name each time. Thank you!
</p>
<p>
Oh and those release names? We get compliments about them all the time. Back in 2010, we felt that we need a theme for Angular. I believe that it was Brad who suggested superheroes as the theme and naturally we settled on coming up with all kinds of interesting "super"powers as the code names for our releases. We still have a ton of fun coming up with these and it's not uncommon that we get a list of dozens of suggested code names from fans all around the world.
</p>
<img src="images/code-name-tweet.png" alt="Code name tweet">
<p>
The good old days of 2010. Since then we got better at versioning and releasing (maybe too good - AngularJS 1.0.0rc12 ehm). And really good at answering the mailing list. Especially after Vojta joined at the end of 2010. But as more and more people got interested in Angular we had a harder and harder time to keep up with emails, g+, tweets, IRC and the scariest of all even GitHub.
</p>
<img src="images/angularjs-1.0.0rc12.png" alt="AngularJS 1.0.0rc12">
<img src="images/github-notifications.png" alt="GitHub Notifications">
<p>
As you've heard from Miško and Brad yesterday, Angular was not created by a decision of some VP of Engineering. <I></I>t was born out of love and passion and the project slowly built up its reputation and adoption at Google. So by the time the community growth exploded, Angular was already well established in several key projects at Google.
</p>
<p>
This allowed us to hire more people. Thank you Google and Brad for making it possible. Oh and if you haven't heard yet, Brad is the most awesome boss one can have!
</p>
<img src="images/google-brad.jpg" alt="Google & Brad">
<p>
Brian, Naomi, James, Chirayu, Jeff and Tobias joined us in our office one by one. Pete, Pawel, Julie, Matias and most recently Caitlin joined remotely after having worked their asses off on the mailing lists and GitHub. These are clearly people who are passionate about the project and were in the position to help, so we were excited to share the passion with them and have them on the Angular team.
</p>
<img src="images/team.jpg" alt="AngularJS Team">
<p>
Despite quadrupling the team in the last year and a half, the community has outgrown us by far more than that.
</p>
<img src="images/late-2012.png" alt="Late 2012…">
<p>
In the fall of 2012 (a few months after the 1.0 launch), I had the honor to be at the dotJS conference in Paris, France. Vojta gave an inspirational talk about following your passion. Because that's what Vojta does. (I don't mean giving inspirational talks, but following his passion).
</p>
<img src="images/vojta-at-dotjs-2012.jpg" alt="Vojta at dotJS 2012, Paris, France">
<p>
He was later followed by @fat (one of the creators of Bootstrap), who talked about how open source is killing passion and creativity. Burned out @fat, talked about how he loves creating new things. He described them as cute puppies. But the problem he faced was that the more passionate he was about a project, the more popular that project became, and the faster the puppy grew into a monster that he had to be a slave to. I remember quite vividly how he described himself being all tired while merging pull requests late at night while his friends were out having drinks and a good time. He finished the talk by challenging the audience to solve this problem, so that we get more people starting amazing projects but not getting burned out because of the maintenance overhead that comes with their popularity.
</p>
<img src="images/fat-at-dotjs-2012.jpg" alt="@fat at dotJS 2012, Paris, France">
<p>
Back then I wasn't brave enough to admit that I had the same problem. To admit that Angular has grown from a cute little puppy into a monster that was controlling me more than I was controlling it. A bunch of us had dinner with @fat and other speakers that night. We talked about the open source problem, but couldn't come up with a solution.
</p>
<p>
I was quite depressed about this for a few months, but I wanted my cute puppy back so I started to work on a plan to achieve this, but it wasn't without complications.
</p>
<img src="images/early-2013.png" alt="Early 2013…">
<p>
In early 2013, we worked with an undisclosed project team at Google who liked many ideas in Angular but wanted a server-side pre-rendering support. So we gave it a shot and created a version of Angular that used the same templates on the server and client and could automatically attach itself to the rendered html once the js bits were loaded in the browser.
</p>
<img src="images/server-side-pre-rendering.png" alt="Server-side pre-rendering">
<p>
It worked really well, better than any other solution at Google at that time. But it wasn't beautiful. And after the project decided to not use our solution for non-technical reasons, we abandoned the effort altogether. We learned how to make it work, but it would take another 2 or 3 reimplementations to make it into something we'd love to use ourselves. More importantly we realized that the two most important reasons for server-side pre-rendering - SEO and performance - would not be an issue for much longer, especially if we focus more on the client-side.
</p>
<p>
This learning adventure had its toll on the AngularJS project and was one of the reasons why 1.2 release got significantly delayed. To this day, I think that it was a worthy experiment because it taught us a lot.
</p>
<img src="images/has-1.2-shipped-yet.png" alt="Has 1.2 shipped yet?">
<p>
While we focused the rest of 2013 on shipping 1.2 which was long overdue, we were constantly being amazed by the things that people had created with Angular and that gave us a boost to make 1.2 quite amazing.
</p>
<p>
But to get to those results we needed to iterate. Iterate a lot. Take the animations we launched in 1.2 as an example. Those had been rewritten from scratch 3 times before we were happy with the results. Each iteration takes time. And it takes even more time when the infrastructure around the project is crumbling under our feet.
</p>
<p>
The CI server that I built for our project a few years ago started to show signs of inability to scale with the growth of our team.
</p>
<img src="images/long-ci-queue.png" alt="Overloaded AngularJS CI Server">
<p>
More importantly, by making the testing infrastructure available only to the core team, we made it impossible for the community to get automated feedback on the PRs they were submitting. This meant more work for us! Because now we had to deal with broken PRs that were often stale and needed a ton of work in order for them to be merged. This, combined with the post-1.0 popularity made the PR queue grow faster than ever before.
</p>
<p>
We tried hard, we used to have dedicated weekly PR days, where we would spend the whole day just by reviewing, fixing and mering PRs.
</p>
<img src="images/pr-day.png" alt="PR Day">
<p>
We were making a dent in the PR queue and yes, we were so obsessed by making progress in this area that we built several dashboards to show us how we were doing.
</p>
<img src="images/dashboard.png" alt="AngularJS Dashboard">
<p>
We were so desperate that we even started building robots to help us. Mary Poppins now watches our GitHub repo and guides contributors in creating a PR that is easier for us to handle.
</p>
<img src="images/mary-poppins.jpg" alt="Mary Poppins Avatar">
<p>
Some of you have nice conversations with her…
</p>
<img src="images/mary-poppins-in-action.png" alt="Mary Poppins in Action">
<p>
The bad news for us was that the graphs indisputably showed one thing - whenever we pushed harder and handled more PRs per week, we would get even more PRs in the following weeks. I assume that this is because people were encouraged by our activity so they wanted to contribute even more!
</p>
<img src="images/angular-prs.png" alt="Pending PRs Graph">
<p>
Because cross-browser compatibility was one of the biggest issues for the submitted PRs – superseded only by a lack of documentation updates and tests – we decided to share our testing infrastructure with anyone willing to contribute to Angular (or in fact any other project).
</p>
<p>
Karma, the spectacular test runner that Vojta and folks around him created, worked really well across browsers at that time already and we fully relied on it for all of our testing. But making browsers available to Karma was not a solved issue. At least not on the GitHub scale that we were dealing with.
</p>
<img src="images/saucelabs-santi.jpg" alt="SauceLabs + Santi">
<p>
At around the same time I met Santi from SauceLabs who was nothing but energetic and ready to help us solve our problem using the SauceLabs farm of VMs with browsers. Initially it appeared that the integration would be simple, but nothing in engineering is simple if it involves as many moving parts as our Travis, Karma and SauceLabs integration.
</p>
<img src="images/travis-red.png" alt="Travis with lots of errors">
<img src="images/browserstack.png" alt="BrowserStack logo">
<p>
The guys from BrowserStack didn't want to be left out either. So we worked with them as well and after more than half a year of debugging issues and fixing problems at various layers, the setup with both SauceLabs and BrowserStack works quite well and all of our PRs are being tested on the same or bigger number of browsers than our original core-team-only ci server. Since the builds are fully parallelized this solution is faster even for the core team. It was only passion and willingness to iterate and take a small step after a step that enabled us to make this a reality.
</p>
<img src="images/travis-green.png" alt="Travis with green builds">
<img src="images/1.2-launch.png" alt="1.2 launch!">
<p>
We launched 1.2 and instead of a big celebration we were fighting fires due to the "underscore" issue. An innocently looking breaking change, that we put in because we thought that it would make Angular better, completely broke everyone using certain database backends or third-party REST services where underscores were used in APIs.
</p>
<img src="images/underscore.png" alt="Underscore">
<p>
We tested the change on hundreds of apps at Google and since it wasn't causing any significant issues, we decided to proceed with it.
</p>
<p>
We screwed up! It was an honest mistake and we reverted the change quickly, but in the meantime were being accused of all sorts of things as if we set out to make life difficult to people who trusted us.
</p>
<p>
Similarly, when we announced that we are going to drop IE8 support in 1.3, many revolted.
</p>
<img src="images/ie8.png" alt="Internet Explorer 8">
<p>
The honest truth is that neither Google as the main sponsor of AngularJS, nor anybody on the core team needs an IE8 support for their apps. So for already more than a year, we've been supporting the developers with apps running on IE8 just out of pure passion for the project and ambition to provide great developer experience.
</p>
<img src="images/angulardart.png" alt="AngularDart">
<p>
When we announced AngularDart in June of 2013, only a few cheered. Primarily because of concerns that "Google was abandoning AngularJS". Nothing could have been further from truth, but it's hard to fight uninformed gossip, especially when there is one thousand more important things to spend our time on. The only way to combat it was by proving that we were serious about both AngularJS and AngularDart.
</p>
<p>
I'll be honest with you guys, I wasn't excited about AngularDart at first. But Googlers really wanted to be able to use Dart and Angular together. It wasn't easy, but we agreed to do it.
</p>
<p>
But looking back now, I think it was one of the best things we've done for AngularJS. I know, it sounds ridiculous, but it's the truth.
</p>
<p>
Over the last year we have worked very closely with the Dart team. And you know what we learned? That they are very passionate about making web faster. I might not always agree with some of the details of their decisions, but nobody can argue with me that these guys aren't sharp and passionate about what they do.
</p>
<p>
Thanks to this great collaboration with the Dart team, we were able to start building Angular from scratch. Adjusting it to the new language and ecosystem and learning a ton along the way. We learned from many mistakes we made in AngularJS, and as expected, introduced a bunch of new ones ;-) But what matters the most is that we are now taking the learnings from AngularDart and bringing them back to AngularJS.
</p>
<p>
Some of the performance improvements that were initially pioneered in AngularDart are already being used in production by AngularJS apps. Similarly, the DI system that we built for Dart is heavily influencing the future of DI in JS as you've already seen in Vojta's talk about di.js. Brian is going to talk later today about zone.js a project with mind-blowing possibilities that we started after Florian from the Dart team showed us this concept implemented in Dart.
</p>
<p>
Just the sheer opportunity to being exposed to different way of thinking and ability to start from scratch is so refreshing and really boosts creativity. I'm excited to see that the results of the AngularDart effort are now making the AngularJS and soon the wider JavaScript platform better.
</p>
<img src="images/angularjs-1.2.x.png" alt="AngularJS 1.2.x">
<p>
After 1.2 was released, we made a promise to ourselves to release faster and release often. Bring back the transparency and predictability we enjoyed in the early days, but now at a much larger scale. Not an easy task. Maybe it was my passion for Daft Punk and their song Harder Better Faster Stronger or everyone's passion for Angular, whatever the cause was, we did it despite many saying that it was impossible.
</p>
<img src="images/bleeding-edge-at-google.png" alt="Bleeding Edge @ Google">
<p>
It's not a well known fact that Google uses pre-release versions of Angular. Imagine what would the development look like if we were able to push a commit to the master branch on the main GitHub repo and within hours hundreds of Google apps would start to use that version. We do that already. We've been doing that for almost a year now. It was a game changer for us. Not only it forced us to get organized enough to keep the master stable at all times but it significantly improved our test coverage in ways no synthetic test suite can. On a rare occasion, when a regression is merged into master, we get the feedback before we even get to cut a public release. And since we can easily track the regression down to a particular commit, reverting them and making master stable again is easy.
</p>
<img src="images/revert-commit.png" alt="Revert Commit">
<p>
At Google most of the software is not versioned and we have an elaborate continuous integration service which constantly tests every component in the google-wide code base and all the components that depend on it. This allows us to iterate quickly. Deliver fixes to Google apps often within hours of the initial bug report.
</p>
<p>
I'd love non-Google applications to participate in such continuous integration scheme. This is why, back in December we started pushing pre-release builds of AngularJS to Bower.
</p>
<img src="images/pre-release-build-in-bower.png" alt="Pre-release build in Bower">
<p>
Pushing builds to Bower is only half of the iteration cycle. We also need to be able to receive your feedback, so that we can act on it. This is why a while back we established a daily team triaging party. No alcohol is served, but lots of bugs and PRs get reviewed and categorized on a daily basis. We still have a small backlog of old issues to go through, but we are doing better than ever at acting on regressions, merging small fixes and providing feedback on big ones.
</p>
<img src="images/daily-triage.png" alt="Daily Triage">
<img src="images/stats-dont-lie.png" alt="Stats don't lie">
<p>
All of this sounds great and wonderful, but in the meantime whenever we look at any Angular stats, whether it's the github activity (like opening PRs/issues) or traffic on any of our sites, mailing list, g+/twitter stream we clearly see one thing. No matter how much harder we work or how many more people we hire, we can't keep up with with the community growth out there.
</p>
<p>
GitHub recently released a new feature that allows us to see traffic on our repositories. The numbers answered some of our questions but also made us more depressed.
</p>
<img src="images/github-traffic.png" alt="GitHub Traffic">
<p>
Many successful projects have been in this situation before. Some didn't make it because the core team burned out and got overrun by the community, but there are some that embraced the community just like we did in our early beginnings and that's what we've been doing again at much larger scale in the past several months. And I believe that this can work.
</p>
<img src="images/embrace-community.png" alt="Embrace Community">
<img src="images/us-vs-them.png" alt="Us vs Them (crossed out)">
<p>
But first we need to break the us vs them barrier. Often when I talk to people from the community I feel that they are giving us more respect than what we deserve. We are just lucky bastards that have Google behind our backs and get paid for doing what we love. It's hard work, don't doubt that, but many of you with the same passion could do it as well.
</p>
<img src="images/lucky-bastards.png" alt="Lucky Bastards!">
<p>
In fact most of the core team, including me, started on GitHub, digging in the code and suggesting improvements, sending out PRs.
</p>
<img src="images/tom-gardener.jpg" alt="Tom Gardner">
<p>
Over the weekend, I was working in my small garden and my 2 year old son really wanted to help. Often when I do stuff around the house, it's too dangerous for him to help, but this time it wasn't and he was very eager. He really wanted to pick up weeds and throw them in the yard bin. The problem he had was that he wasn't tall enough to reach the top. I took a stool and a box that we just received and "helped him help me". (Only to later find out that the box he was jumping on contained a delicate light fixture). But the point is that we had a lot of fun working together and I was able to share my passion for gardening with him.
</p>
<p>
Only as I was taking these photos to share with my relatives, I realized that this is exactly what we've been doing for the Angular community. The Travis + SauceLabs build system, more tests and pre-commit checks, pre-release builds in Bower and daily triage just to name a few.
</p>
<p>
We want *you* to be able to make Angular better. But at the same time, we want to deal with the issue of the team growth vs community growth. The threat of burning out the core team. The possibility of overlooking another "underscore" issue or dropping a browser support to the big surprise of some of you. And don't get me even started about the us vs them thing.
</p>
<p>
This is why we are forming the Angular Working Group. Let me repeat a "working group". Not a committee or an experts group, but a fellowship of folks, individuals or representatives of various companies, that are as lucky as we are to be able to dedicate some of their time and expertise to making Angular better.
</p>
<img src="images/angular-working-group.png" alt="Angular Working Group">
<p>
We've already hand picked a few of you based on the quality and regularity of your contributions to AngularJS. We are primarily looking for people as passionate about Angular as we are. People that work with Angular professionally on a daily basis and care about keeping the code base stable. We'd love to help them start using pre-release versions of Angular just as we do at Google. Ideally, the members of the group should be able to delegate some of their responsibilities to others in their trusted circles. This way we can get more voices heard and make Angular harder, better, faster, stronger. This working group will enable people outside of Google to have a direct impact on the future of the project, supposing that they are willing to invest their time and effort in making this future a reality.
</p>
<p>
I believe that this can prevent another "underscore" issue from occurring and will also provide a platform for those interested in supporting legacy browsers to do so, without slowing the rest of Angular down.
</p>
<p>
I'm happy to announce that the following people have accepted our invitation to be the founding members of the Angular working group:
</p>
<ul>
<li><p>Dave Geddes (Domo) - Dave is plain awesome. Just look around at this conference that he (with the help of others) organized. In addition to organizational skills, he's technically very strong and has provided us with a ton of feedback on Angular.</p></li>
<li><p>Michał Gołębiowski (Laboratorium EE) - In addition to sending us really good PRs, Michał has been providing us with ultra-high quality feedback on GitHub for a while. He already maintains a fork of Angular with some feautures that we couldn't support due to IE8.</p></li>
<li><p>Karl Seamon (DoubleClick) - Karl is a wizzard within the DoubleClick team. He contributed a ton of performance improvements to Angular as as you'll see later today he knows a thing or two about Angular. In general I'm trying to encourage crosspolination of Google and non-Google ideas within the Angular ecosystem and that's why I invited Karl to join this group.</p></li>
<li><p>Miško and I will represent the Angular team<p></li>
</ul>
<img src="images/working-group-members.jpg" alt="Angular Working Group Members">
<p>
We have more people in mind and will be adding them to the group over time following the same criteria we used to pick these guys. High quality contributions sustained over longer period of time are the key to being considered for the working group.
</p>
<p>
While not everyone can be part of the working group (otherwise nothing would ever get done), everyone will benefit. The project transparency will increase the decision making will be distributed and we'll have more muscle power to attack more and bigger challenges.
</p>
<img src="images/bigger-challenges.png" alt="Bigger Challenges to Tackle">
<p>
Speaking of bigger challenges, there is one that all of you should be aware of. It sneaks around under different names. Web components, EcmaScript 6, Object.observer(), ever green browsers and others. It's the modern web platform that we've been waiting for for so long. It's coming and it will be here sooner than most of you realize. We need to get ready! And as you've seen in the Vojta's dependency injection talk and James's AngularDar talk, we can do amazing things when we start from scratch, without the baggage of legacy browser support and constraints of old web platform APIs.
</p>
<img src="images/new-era.png" alt="New Era is Coming!">
<p>
We decided that Angular 1.x will live on and will be the Angular for the web platform of today, while AngularJS 2.0 will the be version of Angular for the platform of the future. Future with crazy possibilities, based new standards with the focus on modularity and better code reusability.
</p>
<p>
But then again…
</p>
<img src="images/but-then-again.png" alt="But then again">
<img src="images/angular-prs.png" alt="Pending PRs Graph">
<p>
… we must find a fine balance between supporting and improving the existing Angular, while building the best Angular yet.
</p>
<p id="sorry">
I've been particularly bad at finding this balance. I owe a big apology to Rafael from the Chrome team, whom I let down by not being the partner in crafting some of the standards that the future version of Angular will use. Just like @fat at dotJS, I've been overwhelmed by the monster I helped to create and found it hard to get out. But the changes we've made over the last few months and the continual increase in quality of community contributions make me believe that the monster is being contained. And I will be able to dedicate a significant portion of my time to forward looking stuff that all of you will benefit from in 1 year or so.
</p>
<img src="images/sorry-raf.jpg" alt="Sorry, Raf.">
<p>
This is why I need you to step up! Help each other. Help us triage issues and review pull requests. Answer questions on the mailing list, stackoverflow etc.
</p>
<p>
The future version of Angular will be completely modular. Based on ES6 and the new module system. I don't want to talk too much about the details, because unless we have at least a good foundation, I'd be talking about stuff that doesn't exist and will likely never exist.
</p>
<p>
We started however and the di.js, zone.js and a nifty little logging tool diary.js are some of the pieces we are building Angular 2 upon. If you look at any of these projects, you'll notice that they are not Angular specific as it was the case of Angular 1.x. We are building a set of libraries that will work great whether you choose to use them for building an Angular web app or a server-side component for node.js. The era of monolithic frameworks is going to be soon over. The future is all about loosely coupled but well aligned components that can be used together in various combinations depending on the application needs.
</p>
<p>
It's still a bit too early for production apps to rely on many of the standards and web platform apis that are under development. But that won't be the case for much longer. So if you have high tolerance for pain and crave the possibility to live life on the bleeding edge, then keep an eye on our the projects that will form Angular 2.0. But don't stop there. Get involved. We want you to help!
</p>
<img src="images/ng-conf.jpg" alt="ng-confg 2014">
<p>
This conference has been a surreal experience for me. And a bit of an emotional rollercoaster. I've met many incredible people and experienced many interesting things here.
</p>
<p>
Just as I was flying out of San Jose, I had the best experience passing through the airport security. I met the nicest TSA officer ever and I actually stopped and thanked him for being so nice. Do you know what he told me? He said "I believe that you don't have to be an ass to be safe".
</p>
<img src="images/tsa-quote.png" alt="Quote: You don't have to be an ass to be safe!">
<p>
This suck with me and I thought about it a lot. And I came up with this:
</p>
<img src="images/igor-quote.png" alt="Quote: You don't have to be an ass to build an awesome web framework!">
<p>
Yesterday I met the nicest person here. I mean, all of you are nice, but this guy is very special. And he had a tatoo on his forearm that said: "Work Hard. Be kind. Do more". I think all of us could use a tatoo like this on our forearms, just to remind us what our values are and what we are here for.
</p>
<img src="images/be-kind-tatoo.jpg" alt="Tatoo: Work Hard | Be Kind | Do More">
<p>
While working on these slides in my hotel room. Brian and I decided to decorate our hotel room door with Angular made out of Angular. (Actually, I just grabed Brian and made him do this with me). As we were decorating, Adam walked by. I've never met Adam before, but I asked him if he wanted to help us. He said yes and joined us in building our work of art. We had a ton of fun together and chatted quite a bit. It was great, I really enjoyed it. I'd love to have a lot more experiences like this one.
</p>
<img src="images/building-angular.jpg" alt="Building Angular out of Angular">
<p>
Some describe Angular as a library, others correct them that it's a framework. Miško is still a bit dillusional and claims that it's an html compiler. For me it's a passion. It's desire to iterate and become better. It's a way of life and I want to share it with you.
</p>
<a href="http://angularjs.org/i-want-to-help"><img src="images/angular-i-want-to-help.jpg" alt="Angular: I want to help!"></a>
<p></p>
<hr>
<p>The video recording of this talk can be found on <a href="http://www.youtube.com/watch?v=h-SQvre_6qU">YouTube</a>.</a></p>
<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a>
</article>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-578396-5', 'igorminar.github.io');
ga('send', 'pageview');
</script>
</body>
</html>