Planning Angular 1.4

We had a planning meeting last week to decide what will go into AngularJS 1.4. Here is a summary of what happened. You can watch the video of the meeting on YouTube below.

Release Schedule

We decided that the first release (1.4.0) will be in Spring 2015, coinciding with ng-conf on 5th March 2015. In the meantime, we'll continue with 1.3.x releases as usual.

Work Planning

Lucas prepared a spreadsheet with a list of suggested items for 1.4 from the issues and PRs on GitHub with the most community interest. This focussed on large work items or things that would require breaking changes or considerable new API. The bulk of the meeting was going through these items, deciding whether they should appear in Angular 1.x and, if so, which release and who would own the item.

1.4 Targets

There is a tracking spreadsheet for the items that are scheduled for 1.4.

The main themes for 1.4 are as follows:

• Router - Brian - a new router for Angular 1 and 2 - Progress
• I18N - Chirayu - provide a first class internationalization story for Angular - Design Doc
• Forms - Martin - a fresh look at parsing/formatting/validation to simplify usage and maintenance (while fixing numerous outstanding issues) - Design Doc
• HTTP - Pawel - improvements to the $http service, such as serialization, JSON parsing, testing mock DSL
• Parser - Lucas - performance improvements to $parse service
• Documentation - Caitlin - redesign the look of the docs app to use Material Design

In addition, we're planning to include the following notable or breaking changes:

• $injector - Brian - throw an error if you redefine a module, to help identify bugs faster (#1779)
• $compile - Igor - provide extra new module.component helper for defining component type directives more easily (#10007).
• $compile - Caitlin - throw an error if non-optional isolated scope mappings are missing their attributes (#9216).
• Project layout/Modularity - Pete - further partition angular.js into smaller optional modules/files to reduce the non-optional core file size (useful for mobile use cases).

Github Milestones and Labels

Finally we will start developing 1.4.x on the master branch soon. To support this here are the new labels/milestones for on-going development:

Milestones:

1.4.x - use this for issues and pull requests that are accepted and scheduled to be in 1.4

Labels:

branch: 1.2.x (replaces stable: yes)

branch: 1.3.x (replaces stable: no)

branch: 1.4.x (replaces 1.4 - for triaging 1.4.x issues and PRs)

Primary Focus: (new for items that we are focussing on for 1.4 - i.e. the stuff in the tracking spreadsheet)

Other Versions and Backporting

The master branch (i.e. 1.4.x) will now receive the majority of the focus.

The 1.3.x branch will receive version specific fixes backported from master.

The 1.2.x branch will now only receive fixes for security issues and major regressions.

Video

In our continued efforts to be transparent and open about our design and development activities, we published a recording of our planning meeting: https://www.youtube.com/watch?v=Uae9_8aFo-o

Just the Beginning

The planning we did for 1.4 is just the beginning. In addition to the outline above, we welcome additional suggestions for 1.4 via GitHub. Once we've released 1.4.0, we'll continue with 1.4.x releases that include non-breaking fixes that didn't make it into 1.4.0.

Angular CLA Infrastructure Changes

As of today, we are unifying our Contributor License Agreement (CLA) checking tool with the newly rolled out infrastructure for all Google open source projects. Just as before, a single CLA signature will enable you to contribute to any open source project from Google, but the new CLA bot is much faster, more reliable and can handle corporate CLAs better.

The new CLA signature repository requires a GitHub account to be linked with a Google account. In many but not all cases we were able to link the two accounts automatically. For those contributors where an automated match was not possible, we'll ask you to re-sign the CLA or add your GitHub username to your contact info the next time you send us a PR.

To check your CLA status you can visit https://cla.developers.google.com/clas. To see if your CLA is linked with a GitHub account please click on 'Edit Contact Information' next to a CLA record where you can check and edit your GitHub account name.

Once your GitHub account name is linked correctly, Googlebot will comment on your future PRs and give it the label 'CLA: yes' (see this PR for an "exemplary" conversation with Googlebot). If you already have an open PR that hasn't been verified, you will need to comment on it for Googlebot to re-verify your CLA.

We apologize for the inconvenience, but this stuff is important for the Angular project and the community that depends on it. Thanks and stay awesome!

Using ngAria

A new feature released in Angular 1.3.0 is the accessibility module, ngAria. As someone involved in delivering this community-driven effort, I thought it might be helpful to introduce ngAria, a module which can improve the user experience for many people with disabilities.

In this post:

• What is ngAria?
• Why ngAria?
• Including the module
• New and proposed features

What is ngAria?

The goal of ngAria is to improve the default accessibility of Angular.js by enabling common ARIA attributes for directives. Using ngAria is as simple as requiring the ngAria module in your application. It then hooks silently into standard Angular.js directives and injects accessibility support into your application at runtime.

Currently, ngAria interfaces with the following directives: ngModel, ngShow, ngHide, ngDisabled, ngClick, ngDblclick and ngMessages. The list of supported attributes is currently limited; we are identifying additional ways the module can improve accessibility, described later on in this post.

Related reading: What is WAI-ARIA, what does it do for me, and what not?

By centralizing accessibility features into one module, they can be easily added and tested, allowing ngAria to grow over time. On the flip-side, automatic accessibility features are only added if the module is included, making it possible for accessibility to be forgotten—something we can’t continue to do as developers. When you include ngAria in your projects, you can improve the experience for many of your users without doing much at all. However, it’s important to inform yourself about ngAria’s capabilities and limitations so you know what it actually does to your code.

To learn how ngAria works with the directives listed above, explore the ngAria Developer Guide.

Why ngAria?

Many people in the world depend on assistive technologies such as screen readers, high contrast mode, braille keyboard support, closed captioning and more to use the web applications and services we take for granted. The popularity of MV* frameworks such as Angular.js has contributed many inaccessible web applications as our attention has gone to shinier topics such as mobile performance, databinding, automated tooling and ES6 support. We love to innovate the way we work, yet we forget basic things such as HTML semantics and supporting the keyboard.

In the past, Angular.js didn’t do much for accessibility–in fact, it made it more challenging by injecting attributes that didn’t work for accessibility, such as disabled on a custom element directive like <md-checkbox>.

See this rendered markup example:

<md-checkbox ng-model="someModel" ng-disabled="isDisabled" disabled>
    Inaccessible Checkbox
</md-checkbox>

The above checkbox directive is inaccessible because it doesn't communicate anything to assistive technologies and it's inoperable from the keyboard. Although it's easy to use directives like ng-disabled on non-semantic elements, this leaves us responsible to also manage ARIA by ourselves. A helpful framework would eliminate this kind of pain and do the heavy lifting where we needed it.

With the introduction of ngAria, common ARIA attributes are now handled by default when the module is included, helping to communicate the state of our application to users of assistive technologies.

Let's look at the same markup after ngAria has done its magic:

<md-checkbox ng-model="someModel" aria-disabled="true" tabindex="0">
    Checkbox
</md-checkbox>

Note: this example also requires role="checkbox" and aria-label to be accessible. In Angular Material, we handle this internally but those attributes could become managed by ngAria in the future.

Including ngAria

Using ngAria is as simple as requiring the ngAria module in your application:

angular.module('myApp', ['ngAria'])...

After including the module, any directives in your code that ngAria is hooked into will be automatically fitted with ARIA attributes. To learn more about ngAria's effect on directives, check out the ngAria Developer Guide.

Disabling attributes

Because ngAria's attribute magic may not work for every scenario, you can opt out of specific ARIA attributes by configuring ngAria with $ariaProvider:

angular.module('myApp', ['ngAria'], function config($ariaProvider) {
  $ariaProvider.config({
    tabindex: false
  });
});

For the full list of configurable properties, visit the API Documentation for $ariaProvider.

New to ngAria

ngMessages

A recent pull request for ngAria and ngMessages, the module for form validations, will improve accessibility by also reading errors aloud in a screen reader as they become visible. This functionality can be enabled by adding aria-live to the ng-messages directive. It's a simple way to expose dynamic content to assistive technologies and is a good example of the type of problem ngAria should help to solve.

Proposed for ngAria or Elsewhere

ARIA Role Handling

To communicate better to assistive technologies, ngAria should add missing roles to non-semantic elements such as <md-checkbox> and <div type="range">. An issue has been filed to track these two small features and more will be added as they come up.

End-to-End Accessibility Testing with Protractor

Early work has begun on a plugin system for Protractor that would allow automated integration testing for accessibility as well as ng-hint. Rough ideas for automated testing include HTML hierarchy audits, keyboard operability tests, logs for missing labels and color contrast warnings. Catching accessibility issues before they are deployed gives you more time to fix them and is a lot more fun. Stay tuned for updates as we have them!

$mdAria.expect

An ARIA service method in Angular Material aims to improve a common accessibility issue: forgotten labels, which add accessible names to elements for assistive technologies. For commonly mislabeled components, such as checkboxes or radio buttons, $mdAria will attempt to copy text content to the aria-label attribute. If no suitable text is found, a warning will be logged to the JavaScript console telling the developer they forgot a label for accessibility. We are fixing bugs with this utility as they come up and evaluating whether it could be useful in ngAria or ngHint.

Other Ideas

Some other things we have discussed or proposed for Angular accessibility: warnings for missing alt attributes, default keyboard bindings such as the escape key or question mark key, color contrast assessments and more. I'm excited to see this list grow as we dogfood ngAria on Angular Material and see it battle-tested in the community. If there are things you feel ngAria should do, please write about it in the comments or submit a pull request.

Let's Make it Better

It is our responsibility as developers to build accessible, well-tested web applications. However, the frameworks we use should do as much as possible to improve accessibility by default. As a new module, ngAria will continue to evolve as we discover common use cases it can handle or warn about. Balancing performance and developer experience with end-users' needs requires careful planning and execution, which means it will take time to get right. Consider contributing on Github if you have ideas for ngAria and feel free to comment!

Special Thanks

The module was originally contributed by @arbus, with feedback and improvements from the community through Github issues, pull requests and support from members of the Angular.js core team: Tobias Bosch, Brian Ford, Marcy Sutton and Pete Bacon Darwin.

ng-europe, Angular 1.3, and beyond

Last week we presented at ng-europe in Paris on the past, present, and future of Angular. In this blog post, we'll recap the main points and announcements.

Angular 1.3

We've just shipped AngularJS 1.3 -- the best Angular yet. With it, you get many features and improvements not found in AngularJS 1.2. Though there are many we focused on:

• Performance. With many operations like DOM manipulation and digest 3-4x faster, you automatically get snappier apps. 
• Forms. Simpler and more capable APIs let you write less code and better match user expectations when validating forms. 
• ARIA support. With ngAria, you're given a big leg up on adding and removing the correct ARIA attributes to support assistive software like screen readers. 
• Material Design. We're nearly fully functional on implementing Google's specification for user interface design and interaction. Find it now at material.angularjs.org.

If you are building web applications today, this is the version you should use. This is the tried and true version that we really believe in. With over 1600 apps at Google built with Angular 1.x, we are committed to supporting it as the first class AngularJS version for a long time to come.

One thing that is changing, however, is our support for new features and breaking changes in Angular 1.x. With a few exceptions, these will be deferred to 2.0, and will be better addressed with the new design. We'll still be reviewing PRs and responding to issues but our focus with 1.x will be on stability, security, performance, rather than features.

If you are using Angular 1.2, please check out the migration instructions to find out more about how to transition your code to 1.3.

From 1.3 to 2.0: Angular's Next Step

In the keynotes of ng-conf in January we first mentioned our plans to build Angular 2. In the last few months since then we've been brainstorming what the next evolutionary step will be for Angular. In March, we published our thoughts in design documents. We read your feedback to make sure we understood the types of things you do or wanted to do with Angular. Then we explored different approaches, built prototypes and benchmarks, and iterated on our designs to find the best one we could.

Last week at ng-europe, we presented a look at our vision for Angular 2.0 that resulted from this research and prototyping. In 2.0, you'll find the things that make Angular truly Angular (like DI, HTML-based templating, directives, and testability baked-in). But you'll also find a number of design changes aimed at adapting Angular to the recent tectonic shifts in the web platform (web components, module system, etc.), and making Angular significantly faster and easier to use in ways we couldn't achieve in incremental steps from 1.x.

Specifically:

• A unified component model that encompases "controllers" and "templates" in Angular 1.x. This means fewer concepts, less boilerplate, and better reusability. 
• A revised concept of "scope" that makes nested contexts simple to understand, and improves the division of responsibilities between components of your app. 
• Modular, mobile-first design that also scales to needs of enterprise-grade desktop apps - With over 50% of the world's population yet to connect to internet mainly via mobile, not desktop, and we want to make it easy to develop directly for these users. However desktop web apps remain important, especially in the enterprise space. 
• Support for Web Components out of the box. Many assumptions we made about the web platform in 1.x are no longer valid, and Angular will change to accommodate these. 
• Built on top of ES6, with easy transpilation to ES5. This means that you can start writing for tomorrow's JavaScript in today's browsers. Or you can write Angular 2 apps with ES5 just like you do today. It's totally up to you. 
• We're introducing AtScript, an extension of TypeScript syntax and ES6 that adds optional runtime types and annotations to help large teams build large apps and better document them. Just like ES6, you're not required to use AtScript for building your applications; it's just another tool in your utility belt. 
• Angular won't rely on jqLite or DOM wrappers in general. The DOM has significantly improved since 2009 and AngularJS doesn't need wrappers any more. In fact, removing them will give us a performance boost. You are still free to use jQuery or other DOM libraries in your directives as you wish.

Many of these ideas come from long discussions we had with Angular developers. Thanks again to everyone who weighed in on these documents! With a stable and performance-focused AngularJS 1.3 out in the world link to blog, we're now turning our attention to building Angular 2.0.

What does this mean for me?

The Angular community is what makes Angular awesome. We're sharing our plans for 2.0 early so that you can be part of the discussion as we move from concept to real code. We want your input and we're excited to hear what you think. For now the best way to do this is by filing issues on GitHub, or reaching out to us on Twitter (Brad, Igor, Brian, Jeff) or Google+, coming to our meetups and following and commenting on our meeting notes.

When can I use Angular 2.0?

If you're interested in Angular 2.0 in its current experimental state, you can follow along on GitHub and through our meeting notes. It's too soon to start building anything with 2.0 code -- we're still in the very early stages of building out the project. In the coming months you should be able to see the pieces falling into place. We're not announcing a release date because we honestly don't know yet, but we're working hard at delivering an early version very soon.

How can I learn more about Angular 2.0?

It's still very early, but watching the videos from ng-europe (when they are available) is the best way to get started. Specifically the keynotes from both days and the session on Angular 2 Core.

If you have more time and want to dig deeper, then check out all the design docs and research we put together and iterated on with the Angular community already.

For people that seek truth in code, there are first bits of code on GitHub in the angular/angular repo. There is lots more to come in the upcoming months!

And lastly you can check out some resources published by our partners, for example a TypeScript blog post that mentions "alignment with ES6" and Angular 2.0, Traceur, EcmaScript 6 and Web Components

What about Migrating from 1.3 to 2.0?

Our goal with Angular 2 is to make the best possible set of tools for building web apps not constrained by maintaining backwards compatibility with existing APIs. Once we have an initial version of Angular 2, we'll start to work on a migration path for Angular 1 apps.

We know that you have invested a lot of time learning how to build web apps with Angular. Since we are preserving most of the core concepts, this knowledge will help you be proficient in Angular 2 much faster.

What's next?

ng-europe was an amazing event for the whole Angular community. We definitely had a blast and are all energized and inspired by presentations, demos, but most importantly by all the informal hallway conversations we had there. Now is the time to start to make the ideas we showed more real and we invite you to be part of it. While 2.0 is under construction, we encourage you to build awesome apps that you want to be proud of with Angular 1.3.

AngularJS 1.3.0 – superluminal-nudge

Today, after eight months of work, over two thousand commits, nineteen beta and six release candidates, we finally released AngularJS 1.3.0 superluminal-nudge!

This release includes many notable new features:

• One-time bindings – by prefixing an expression with "::", it will only be interpolated once, and then no longer watched.
• ngAria – a new module that helps make custom components in Angular more accessible by default
• ngMessages – a new directive that simplifies writting and coordinating feedback for on form validity
• ngModelOptions – a directive that makes it easy to customize the behavior of bound models. For instance: debouncing, getter-setter-style models, update-on-blur, and more.
• Strict DI – an option for finding places in your application that will not minify due to use of short-hand DI syntax

Included in this release are over four hundred bug fixes, and nearly one thousand documentation improvements. We also improved the APIs around custom form controls and animations to make them more clear and easier to use.

1.3.0 has substantial performance improvements that reduce memory consumption, increase the speed of common DOM operations, and improve overall latency of Angular apps. You can take a look at the benchmarks in the AngularJS source code on GitHub for more information.

You can read the exhaustive list of changes in our changelog on GitHub.

By popular demand, AngularJS now officially has packages published to npm. You can do npm install angular to get AngularJS 1.3.0. We hope this makes it easier for developers to make use of some of the great tools built around npm for front-end web development.

If you're on Angular 1.2, please refer to the corresponding section of the migration docs to see what breaking changes you should be aware of. And as we announced back in December, AngularJS 1.3.0 no longer supports IE8. This allowed us to make improvements and performance enhancements that otherwise would not be possible. If you're developing an application that does need IE8 support, the good news is that most non-breaking fixes are included in the latest 1.2.x branch.

As always, please try out this new version of Angular and submit issues on GitHub if you find anything amiss.

Last but not least, this 1.3.0 release includes work from over 400 contributors. Thanks to everyone who took time to submit issues, send PRs, improve docs, and give us feedback. We couldn't have done it without you!

Here's the full list of contributors who helped with this release:

ABitTooCalm, Aaditya Talwai, Aaron Wang, Abdessamad Idrissi, Abraham, Adam Bradley, Adam Humphrey, Agam Rafaeli, Ahmad Moussawi, Ahmed Nuaman, Aiden N, Ajay Roopakalu, Akhlesh, Alan Rubin, Alessandro Bahgat, Alex Miller, Alex Muntada, Alex Sanford, Alexander Harding, Alexander Karpan, Alexandre Potvin Latreille, Allon Hadaya, Almar, Amar Patel, Amin Ogarrio, Ammar, Andreas Gruenbacher, Andreas Krummsdorf, Andrei Korzhevskii, Andres Kalle, Andrew Barbarello, Andrew C. Greenberg, Andrew Delikat, Andrew Farrell, Andrew Kulinich, Andrew Mortimer, Andrew Pham, Andrew Silluron, Andrew Silluron-Gonzalez, Andrew Tarry, Andrey Sidorov, Andy Ferra, Anuj More, Archer, Ari, Ariel Mashraki, Arjunkumar, Artem Chivchalov, Artem Tyurin, Artemy Tregubenko, Artiom Neganov, Arturo Guzman, Ashutosh Das, Ayrat Aminev, Baptiste Fontaine, Basem Mostafa, Bastian Buchholz, Ben Harold, Ben Lesh, Ben McCann, Ben Wiklund, Bernhard Hofmann, Bijan Boustani, Bill Neubauer, Blaise Kal, Bobdina, Bocharsky Victor, Boris Serdyuk, Brad Williams, Brady Isom, Brett Porter, Brian, Brian Andersen, Brian Atkinson, Brian Feister, Brian Ford, Brian Hall, Brian Iversen, Brian Nenninger, Brice, Bruce Davidson, Bruno Baia, Buu Nguyen, Caio Cunha, Caitlin Potter, Cameron Spear, Carl Sutherland, Carlo s A. Guillen, Casey Flynn, Casey Garland, Chad Smith, Chaker Nakhli, Chance, Chia-liang Kao, Chirayu Krishnappa, Choi YoonSung, Chris Chua, Chris Constantin, Chris Inch, Chris Kuehl, Chris Rose, Chris Wheatley, ChrisRose, Christian, Christoph Burgdorf, Christophe Krebser, Christopher Rains, Christopher Rose, Chung-Min Cheng, Ciro Nunes, Clark Pan, Colin Casey, Corey Burrows, Cory Boyd, Craig Younkins, Dan Barua, Dan Matthews, Daniel, Daniel Aden, Daniel Luxemburg, Daniel Tabuenca, Daniel Zimmermann, Danielle, Dave Gaeddert, Dave Smith, Dave Wells, David Bennett, David Burrows, David I. Lehn, David Mosher, David Nelson, David Pope, David Rogers, DeK, Deepak Kapoor, Denis Parchenko, Derek Peterson, Derrick Mar, Diego Algorta, Diego Muñoz Escalante, Diego Plentz, Dken, Domenic Denicola, Domenico Matteo, Dominic Watson, Drew Perttula, Dylan, Dylan Semler, Eddie Hedges, Eddie Monge Jr, Edward Brey, Efthymis Sarbanis, Eli Dalbey, Elnur Abdurrakhimov, Elwin Arens, Emile Silvis, Emma Guo, Erich, Erin Altenhof-Long, Evan Winslow, Evgeniy Tkachenko, Firexion, Foxandxss, Franziskus Domig, Frederik Creemers, Freek Wielstra, GSC Leticia, Gaëtan PRIOUR, George Cox, Georgii, Georgios Kalpakas, Gias Kay Lee, GiffenGood, Gonzalo Ruiz de Villa, Greg Fedirko, Grigoriy Beziuk, Gronblom Sam, Guilbert, Guilherme de Souza, Hallvard Nygård, Hari Menon, Hendrixer, Henrik Nyh, Hopiu, Hubert SABLONNIÈRE, Igor Minar, ImaginaryDevelopment, Isaac Shapira, Ivan Alvarez, Iwona Lalik, Izhaki, J. Bruni, Mizael Galvez, J. Michael Palermo IV, JMRodriguez24, Jack Hsu, Jack Wearden, Jake Buob, Jakub Zych, James Brewer, James Ferguson, James Harrison Fisher, James Kleeh, James Kyle, James Roome, James Vanneman, James Wagoner, James Watling, James deBoer, Jamie Krug, Jan, Jan Hancic, Janas Page, Jann Horn, Jarrett Harris, Jason Bedard, Jason Carver, Jason Farnsworth, Jason Hamm, Jason Miller, Jason Schapiro, Jason Travis, Jason Winnebeck, Jay Goldman, Jayson Harshbarger, Jeff Balboni, Jeff Cross, Jeff H. Parrish, Jeff Jewiss, Jeff Sheets, Jeff Whelpley, Jennifer Song, Jens Berthold, Jeremy Likness, Jesse Browne, Jesse Houchins, Jesse Palmer, Joe Pettersson, Joel Hooks, Joey Yang, John K. Paul, John Kurlak, John Lannon, John Papa, John Reilly, Jonathan Gotti, Jonathan Sampson, Jonathan Woodard, Jorg, Joscha Feth, Jose Martinez, Joseph Orbegoso Pea, Joseph Spencer, Josh Kurz, Josh Schreuder, Joshua Flanagan, Juampy, Juan Manuel Palacios, Julie, Julie Ralph, Julien Bouquillon, Julien Sanchez, Justin Walsh, Jürgen Walter, Kamil Pekala, Karl Seamon, Karl Yang, Kasparas Galdikas, Kebabpizza, Ken Sheedlo, Kenneth Lynne, Kent C. Dodds, Kevin Aenmey, Kevin Brogan, Kevin Western, Kindy Lin, Klaus Weiss, Kristian Hellang, Kristof Mattei, Kurt Funai, Lajos Veres, Laurent Curau, Lefteris Paraskevas, Leniel Macaferi, Leonardo Zizzamia, Levi Weiss, Louis Haußknecht, Lucas Galfaso, Lucas Galfasó, Lucas N. Munhoz, Luis Ramón López, Lukas Ruebbelke, Luke Eller, Luke Schoen, M Alix, Maarten Stolte, Maksim, Manan, Marc Lipovsky, Marcy Sutton, Mark Jones, Mark Miyashita, Martin Field, Martin Jezek, Martin Probst, Martin Staffa, Marty Kane, Mateusz Jedruch, Mathew Foscarini, Mathieu Tricoire, Mathis Hofer, Matias Niemelä, Matt Ginzton, Matt Johansen, Matt Kim, Matthew Davies, Matthew Miller, Mattias Holmlund, Mauro, Mauro Carrero, Max, Max Tobias Weber, Maxi Ferreira, Mehul Patel, Melissa Ip, Michael Barton, Michael Benford, Michael Gallagher, Michael Payne, Michael Silver, Michal Kawalec, Michał Gołębiowski, Michel Salib, Michele Beltrame, Mike Haas, MikeMac, MikeMcElroy, Misha Moroshko, Mitch Robb, Miško Hevery, Mohamed Daif, Namolovan Nicolae, Naomi Black, Narretz, NateRedding, Nathan Wiebe, Neil Giarratana, Neil Johnston, Neil Rubens, Nick Carter, Nick Heiner, Nick Van Dyck, Nicolai Skogheim, Nicolas Leger, Nicolás Andrés Gallinal, Nikita Tovstoles, Nikita Vasilyev, Nima Mehanian, Noam Lewis, Oivvio Polite, Ole Michaelis, Ole Weitz, Oliver Schmidt, Olivier Louvignes, Omede Firouz, Paolo Moretti, Pascal Precht, Patrice Chalin, Patrick Hallisey, PatrickJS, Paul Dijou, Paul Harris, Paul Jolly, Pavel Pomerantsev, Pawel Kozlowski, Pete Bacon Darwin, Peter Bacon Darwin, Peter Coles, Peter Deak, Peter Kosa, Phil Westwell, Phillip Alexander, Pop, Praveen, ROUL, Rafał Jagoda, Rahul Doshi, Ralph Giles, Renat Yakubov, René Wilhelm, Reuben Doetsch, Rhys Brett-bowen, Rich Snapp, Richard, Richard Collins, Richard Harrington, Richard Littauer, Rob Wormald, Robert Kielty, Robert Speicher, Robin Böhm, Robin Böhm, Rocky Assad, Rosseyn, Rouven Weßling, Roy Ling, RoyLING, Ryan Hall, Sadaoui Abderrahim, Sagie Maoz, Sam Dornan, Samuel Rats, Sandeep Panda, Sean Griffin, Sebastian K, Sebastian Müller, Sekib Omazic, Sequoia McDowell, Sercan Eraslan, Sergei Z, Sergio Sanguanini, Seth Stone, Shahar Talmi, Shai Reznik, Shane Keller, Shane M. Pelletier, Sharon DiOrio, Shawn Flahave, Siddique Hameed, Simon Taranto, SirTophamHatt, Smith, Smitha Milli, Sorin Gitlan, Stanislav Sysoev, Stephanie Nacios Staub, Stephen Bunch, Stephen Nancekivell, Steve Purcell, Steven Benjamin, Steven Petryk, Stéphane Reynaud, Subra, Søren Louv-Jansen, TLChan, Takashi Nakagawa, Tatham Oddie, Taylor Hutchison, Teddy Wing, Tero Parviainen, The Big Red Geek, TheMrSteve, Thiago Colares, Thom Allen, Thomas Belin, Thomas Guillory, Thomas Junghans, Thomas Tuts, Thomas Wicker, Tiago Ribeiro, Tim Kendrick, Tim Kindberg, Tim Ruffles, Tim Whitbeck, Tim van den Eijnden, Timothée Jeannin, Tobias Bosch, Tobias Leugger - Vibes, Tom Kadwill, Tom Yam, Tomer Chachamu, Tony Bergeron, Tony Cronin, Traxmaxx, Trevor Ewen, Trey Hunner, Tyler Eich, Tyler Kellogg, Tyler McGinnis, Uri Goldshtein, Valentin Waeselynck, Vic Metcalfe, Victor Berchet, Victor Queiroz, Vikram Soni, Vincent Driessen, Vitali Tsevan, Vlad GURDIGA, Vojta Jina, Warlock, Wes Alvaro, Wesley Cho, William Bagayoko, William Chen, Wladimir Coka, Wojciech Fornal, Wojciech Krzystek, XrXr, Yaron Uliel, Yiling Lu, Yuri Sulyma, Yutaka Yamaguchi, Yves Brissaud, Yves Richard, Zach Pomerantz, Zachary Babtkis, Zacky Ma, Zahid Mahir, Zak Johnson, Zhong Liang Ong, Ziang Song, Zorigt Bazarragchaa, active-low, adam77, adeelcap15, ahliddin, akerekes, alexgarrett, alirezamirian, amagee, andre, aschokking, ashley williams, asif22, b9chris, barcahead, benjamingr, bolasblack, bradwheel, bullgare, cexbrayat, cgwyllie, chadfennell, chimney-sweeper, chirag, chrisrhoden, cnlevy, corrupt, cranesandcaff, cwclark, danrbergman, dbwhddn10, deepak-kapoor, dennishall1, desertapple, doodeec, dumpweed, ephigabay, erikrahm, expilo, eydreeyawn, frandroid, fuqcool, fvanderwielen, gabrielbrasil, garetht, gdennie, gdi2290, gipsy86147, gogotanaka, grsmvg, hambyiii, hanstest, jbnizet, jeffavis, jenkins, jerryfan, jesse, jfortunato, jim lyndon, jimmywarting, jody tate, jpsimons, justmiaotou, k-funk, kalvn, kimwz, krusty, letsmakesense, linclark, ltrillaud, m-tretyak, magoswiat, marcin-wosinek, marcwright, markau, martco, matthewhintzen, mbrookes, mgerstenblatt, miknsh5, mishoo78, mjfroehlich, mkolodny, mrmrs, ncuillery, nderoche, nnennajohn, nosideeffects, oojerryoo, oweitz, paranoidandroid522, perek, plmetz, poshest, pyriand3r, raghudodda, rodyhaddad, royling, rsnapp, sanfords, sap9433, scottywakefield, sgrebnov, sixin210, skwakman, smarigowda, snicolai, spacemigas, specialorange, standup75, stucash, sunderls, sunnylost, tamakisquare, thammin, thenickcox, thorn0, tommyangelo, tpiere, ttam3d0, unclejustin, unicodesnowman, vaibhav kohli, vdyckn, venticello, victorbjelkholm, wbyoko, winkler1, winsontam, wjtk, xdhmoore, xi, zahragh, zainengineer, and 刘朋飞

Shiny new introductory course: Shaping Up With AngularJS

There are many great videos, courses, and sites that introduce folks to AngularJS.  While this may seem like well-covered ground, this new course, Shaping Up With AngularJS, sets the bar for a gentle, hand-held introduction to Angular's concepts and features.   

If you've been meaning to try out AngularJS or know folks who have yet to make the jump, this course is the one to start with.

From the good folks over at Code School:

Jump into all the angles of AngularJS with Code School’s newest Google-sponsored course, Shaping Up With AngularJS! Begin with the basics of building a real-world AngularJS app by learning about controllers, directives, services, and all the points and edges that make Angular so great.

Shaping Up With AngularJS has five levels of in-browser challenges that will get you comfortable with expressions and Angular’s special DOM marker syntax. Create review functionality by optimizing HTML forms with Angular, use directives to add a gallery and working tab navigation, and make responsive applications a breeze with two-way binding for super-fast interactivity. 

Play Shaping Up With AngularJS now to whip your script into shape!

Angular and Durandal Converge

Hello! My name is Rob Eisenberg (@EisenbergEffect). I'm the architect and lead developer behind Durandal, a JavaScript framework that has historically been an alternative to AngularJS...or you might even say "competitive" with AngularJS. So, what am I doing here on the AngularJS blog? Did I exploit the Heartbleed Bug to steel passwords and post my own content here? Far from it. Actually, Brad Green asked me if I would cross-post my latest article, written for the Durandal community. He thought you might find it interesting.

...

Frequently I receive questions about Angular vs. Durandal. "Which one should I use?" I usually have to answer with "it depends." While these two frameworks are very similar in many ways, each one has unique strengths and weaknesses. Sometimes their differences can be critically important for certain projects. This fact can make choosing the right framework a very difficult or risky decision. But, what if you didn't have to make any trade-offs? What if you could have the best of both worlds?

tl;dr

• I've been working as a member of the AngularJS 2.0 Core Team for almost three months now. We're taking the best ideas of Angular 1.x and the best ideas of Durandal 2.x and converging them in Angular 2.0 to make a truly amazing developer experience.
• Durandal 2.x isn't going away. I'll document how to migrate, but if you don't want to or can't, don't worry. Durandal 2.x will continue to be maintained.

Three Months

Back in January, the AngularJS team held their first conference, ngConf. My friends John Papa and Ward Bell attended and had the opportunity to share with Brad Green (AngularJS Manager) about some of the cool things I was doing with Durandal, as well as our NextGen focus. John thought we should meet and so he introduced us via email. I sent Brad a few links to my work and prototype demos. He was very interested, so we set up a meeting.

When I met Brad, I found him to not only be an amicable fellow, but someone who was generally interested in collaboration, innovation and advancing the web. (In fact, I've found this to be true of the entire Angular team.) What we discovered was that the goals I had for Durandal NextGen were strikingly similar to what Google was planning for AngularJS 2.0. Doesn't it just make you want to ask "Why not join together to build the best JavaScript app building experiencing imaginable?" So, we hatched a plan. There were two primary goals:

1. I would join the AngularJS 2.0 Core Team and help to design and implement AngularJS 2.0, bringing all my experience with Caliburn.Micro and Durandal into the mix.
2. Whatever ideas or critical features from Durandal did not make it into the Angular 2.0 code-base, I would build as optional plugins to Angular 2.0. Thus, most Durandal users will have a direct migration path to Angular 2.0 either by using "vanilla" Angular 2.0 or by using the Durandal "flavor" by dropping in one or more optional plugins.

The idea here is simple. Let's work together. Let's take the best ideas of Angular 1.x and the best ideas of Durandal 2.x and converge them in Angular 2.0 to make a truly amazing developer experience.

I've been quietly working towards these goals for almost three months now.

Shared Ideas

As I mentioned, Durandal and Angular already had a lot in common and our separate plans for future versions had even more in common. Here's a summary of some shared ideas we had:

• Modules - Durandal 2.x already had an extremely versatile module system based on AMD. In our NextGen we were looking to add support for ES6 modules and possibly CommonJS as well. Angular's module system was non-standard and they were looking to move towards support of AMD and ES6 modules.
• Lazy Loading - Due to Durandal's AMD module system and its internal "asynchronous world" approach, it already could eager or lazy load any component of an application. We were planning to carry this over into NextGen and even make some improvements around app packaging. Angular didn't have this as a capability but was planning to add it in 2.0.
• Web Components, Behaviors and Directives - Durandal didn't have true custom element support and its binding behaviors were tied to Knockout and required a certain bit of expertise to create correctly. We were planning to create a simpler model of custom elements and behaviors for NextGen. We were also planning to support Web Components. Angular had a very rich Directive capability but it was difficult to learn. They were planning a huge simplification in the way that directives were created and were also desiring to support Web Components.
• Databinding - Angular's binding system is awesome. Just use plain JavaScript objects and simple binding expressions in your HTML. In their next version they were planning tons of perf improvements as well as possible integration with Object.observe. They also hoped to remove the need to worry about interacting with digest and scope. Durandal relied on Knockout which required you to create special observable properties and apply bindings through a single attribute on each HTML element. It wasn't very pretty or maintainable for large projects either. Durandal was looking to possibly leverage Object.observe and/or dirty tracking for its NextGen version, making it much more like Angular.
• Modern Browsers - Both Angular and Durandal had pretty solid cross-browser support, including support for older versions of IE. However, we were both looking at a new version that was designed for modern browsers in order to remove unnecessary hacks, take advantage of new, faster APIs and generally re-imagine the JavaScript app development experience around more modern capabilities.
• Mobile - In Durandal we made some minor optimizations to improve mobile performance, mostly via view caching. We were looking to continue making improvements in this area, mostly around faster templating and binding. Angular recently added nice CSS3 animations and was planning a similar set of improvements to templating and binding. They also had some great ideas for touch gestures and other mobile-specific enhancements.
• ES6 - Aside from general "modern browser" features, we were also both looking towards ES6 language features and APIs. A lot of this has to do with  modules, loaders and promises. But since we were also taking this opportunity to do major code rewriting, we wanted to look towards the future and leverage new  language capabilities that would make code easier to write and maintain (classes, lambdas and string templates come to mind).
• Simplicity without Sacrificing Power - Both Angular and Durandal are very powerful...and both have fairly steep learning curves too. Every framework requires some learning, but we both agreed that things could be simpler.

As you can see, both projects had unique strengths and weaknesses. In some cases the strengths and weaknesses compliment one another. But there are other cases where both fall short. Ultimately, both parties came to very similar conclusions about what a "next generation" framework would look like.

By working together we can bring about an even stronger implementation of our shared vision.

New Ideas

In addition to our shared vision, both parties had some new and unique ideas to bring to the table. As for my part, those ideas consisted mostly of things that Durandal was particularly strong in but which were mostly lacking in Angular. The team has been very receptive and we're starting to see the seeds of these ideas make their way into our early development efforts. Here's a few examples of ideas I've contributed which I'm excited about:

• Dynamic View Composition - Sometimes you have to construct highly componentized screens where the models, views and controllers are all driven entirely by data and can only be known at run-time. We hope that Angular's new templating engine will support this out of the box. But, even if it doesn't, our goal is to build a directive system that is so capable that you can build it yourself without much effort.
• Convention over Configuration - Wouldn't it be nice if you could teach the underlying framework how your team wants to organize and build apps and then let it do the grunt work for you? I'm working really hard to ensure that key parts of the new API are explicitly designed around this concept and it's been cool to see other members of the team jump on board.
• Screen Activation - What happens when someone is editing data and, without saving their work, they navigate to another screen, losing their progress? Nobody likes that. Screen activation patterns provide the developer with a clean, encapsulated way of hooking into the navigation process and allowing, canceling or redirecting either when leaving a previous screen or entering a  new one. It's hard for me to think of an app I've built where I haven't needed some form of this. It's so common and it should be easy to do.

Note: We are still in the early stages of development. None of the features or capabilities discussed here are set in stone.

Progress Report

As I mentioned, I've been working on the Angular 2.0 Core Team for almost three months now. Things are trekking along and I'm really happy about the direction we are heading in. We spent the first month doing design work. We had lots of discussions and cross-examined each other's ideas. It was a great opportunity for me to really think hard about what my top priorities were. What could I absolutely not live without? Brad has an excellent post discussing the results of that process.

After a good period of design work, we set out to start writing some code. I had the opportunity to build a small, simplified prototype of the new templating engine and directive API. It served to prove out some of our ideas and was a good way to get an early "feel" for the developer experience. Since then I've been involved with work on the actual templating system, which is still in early development, but is shaping up nicely. I've also done work on the expressions parser and more recently been involved designing and implementing a new router.

Final Thoughts

It's an exciting time in the project where we're beginning to see the first fruits of our labor. I'm glad to be a part of the team and I'm confident the Durandal community is going to be quite pleased with the result. Our community stands to benefit greatly by this convergence. It will result in expansion, stronger support, better tooling, faster releases and a sustained development effort, among other things.

As a reminder, Durandal 2.x is not going away. It will continue to be maintained by myself and a core team of committers. It will remain compatible with current technologies and focused on supporting pre-Evergreen browsers much like Angular 1.x. A new release is coming in the next couple of months where you'll see some new features and many bug fixes and improvements. After that, future work will focus on Angular 2.0 and Durandal's plugins. There will be a direct upgrade path from 2.x to the new Angular 2.0-based version. I've recently blogged some tips for developing Durandal apps today, with an eye to this future upgrade. So, if you are interested in keeping that option open, please have a read through that article and take it to heart.

I hope you'll subscribe to my blog or follow me on twitter or GitHub. I'll have lots more information to share as we move ahead over the coming months.

AngularJS 2.0

As we’re starting into the implementation of AngularJS 2.0, we thought we should put pen to paper and give you some insight into how we’re thinking about the design and why we’re making the changes we are.  We’re sharing it with you now so you can help make the right choices.

AngularJS 2 is a framework for mobile apps.  It is for desktop as well, but mobile is the hard bit that we will get right first.  The AngularJS you know and, hopefully, love will still be there with data-binding, extensible HTML, and a focus on testability.  

All the design docs for AngularJS 2 are publicly available on Google Drive.  This document contains a summary of our approach and design principles with links to specific designs in context.

CAVEAT: We’re still in design and prototyping stage for AngularJS 2.  Some of this will happen differently or not at all in the final product.  

Designed for the future

We’re designing AngularJS 2 for the way the world will look when we believe folks will use it.  In particular, this means targeting modern browsers and using ECMAScript 6.

Modern Browsers

Modern browsers means the set of browsers known as ‘evergreen’ or always automatically updated to the latest version.  Building for these browsers let us drop many hacks and workarounds that make AngularJS harder to use and develop on than it needs to be.

The set currently includes Chrome, FireFox, Opera, Safari, and IE10/11.  On mobile, we’ll support something close to the list of Chrome on Android, iOS 6+, Windows Phone 8+ and Firefox mobile.  We’re looking into supporting older versions of Android, but the jury is still out. 

Yes, there are still older browsers in use, but we’re targeting these newer models as they will be the primary ones in use by the time AngularJS 2 is ready and you good developers have had time to build apps on it.

ECMAScript 6 +A (design)

All code in AngularJS 2 is already being written in ES6.  As ES6 doesn’t run in browsers today, we’re using the Traceur compiler to generate the nice ES5 that runs everywhere.  We’re working with the Traceur team to build support for a few extensions like annotations and assertions.  We call this set of extensions "ES6 +A".

Don’t worry.  Though AngularJS will be in ES6, you can still write in ES5 if you don’t want to upgrade.  The compiler generates readable JS and there are human-sensible analogs for the extensions.  See the design doc for more info.

Faster

Faster change detection (design)

AngularJS apps are built around data-binding between DOM and JS objects.  The speed of AngularJS apps is driven largely by the underlying change detection mechanism we use.  We’ve talked at length on how we hoped to make this faster by using Object.observe() when it becomes available in Chrome M35.  And we will!

After some hard analysis (detailed in the doc), however, we’ve also found that we can make this much faster and more memory efficient even before this native change detection hits browsers.  Buttery-smooth app buttery-butterness is around the corner.

Instrumented (design)

The other half of the performance equation is the code that you write.  For this, we’ll provide high resolution timing details of where time gets spent in your application.  You can see in that this is a goal in the Change Detection design, but we’ll directly support this through a new Angular-wide logging service called diary.js.

Modular

When we released AngularJS 1.0, the features were in a take-it-or-leave-it single package.  You incur the download price for every piece whether you use it or not.  Though the whole of AngularJS is very small by desktop app standards, this can make a big difference on mobile devices.

One interesting thing we noticed was that when we split out the $route into a separate library, several innovative replacements popped up.   

For performance and to enable innovation, our goal is that almost every piece of AngularJS should be optional, replaceable, and even used in other non-AngularJS frameworks.  You’ll be able to pick and choose the parts you like and write or select others that you like better.

Other Performance topics

Though there are no designs yet, there are many other areas of performance optimization we’ll include in AngularJS.  From increasing first-load time with pre-parsed templates to ensuring silky smooth 60 frames per second animations, we’ll invest heavily on a fully optimized user experience.  Please help us by highlighting areas where we should focus and techniques you can contribute to the shipping solution.  

Simpler

Dependency Injection (design)

Dependency Injection is still a key differentiator between AngularJS and other client side frameworks in eliminating much of your application’s wiring code and making testability-by-default a reality.  Though we’ve enjoyed these benefits in building our applications, we’re dissatisfied with the current implementation.  We can make it less complex and more capable at the same time.

We’ll see a less complex DI by eliminating the config phase, simplifying the syntax by using declarative-style ES6+ annotations instead of imperative.  We’ll enjoy greater capabilities by integrating DI with module loading through ES6 Modules.  We’ll also see the ability to lazily-load parts of our JS through child injectors.

The doc linked above has our initial thoughts, but this is one part of AngularJS 2 that you can try today.  See the repo for current details on the implementation.

Templating and Directives (design)

The ability to specify templates directly in HTML and extend its syntax are the bread and butter of AngularJS.  We have some lofty goals for AngularJS’s template compiler in 2.  Namely:

• Simplify the directive API
• Integrate with other component frameworks using web standards
• Improve performance
• Allow tools like IDEs to analyze and validate templates

We’re so excited about these new bits that we can hardly wait to show them off.  There’s too much good stuff to extract into a summary, so please just go straight to the design doc to find out more.

More capable

Touch animations (design)

Users are accustomed to certain touch aware usage patterns. E.g. scroll through a list using their finger, circle through pictures in a carousel, remove list entries by swiping them away. However:

• Current implementations of carousel, infinite scrolling, … don’t share a common core and by this have a lot of redundancy and different approaches.
• Current implementations mostly don't provide an option to use native scroll events, as older browsers and also some current browsers don't support them well. However, by this they prevent the optimal performance on new devices.

We want to give these scenarios first-class support for the best user experiences possible in your applications.

Router (design)

The initial AngularJS router was designed to handle just a few simple cases. As AngularJS grew, we've slowly added more features. However, the underlying design is ill-suited to be extended much further.

We’re taking a careful look at known use cases and other router implementations across many application frameworks so we can deliver a simple yet extensible router that should fit the widest set of applications.

A few cases that we’re particularly keen on supporting include:

• State-based routing
• Integration with authentication and authorization
• Optionally preserving state of some views.  Particularly needed for mobile!

Persistence (design)

Beyond AngularJS’s humble $http, many developers have desired a higher level abstraction for working with data from servers and local persistent data in the browser.  

Mobile apps need to work in an “always offline” mode with syn to the server.  RESTful services need more than we’ve provided in $resource.  Some data can be updated in batches while some needs a continuous streaming model.  

In this new persistence layer, we’ll provide clean structure for these cases and take much more out of the boilerplate currently necessary.

Q&A

When will it be done?

If you’ve been with us through the 1.2 announcement, you know that we don’t know. :)  Though we’re just posting the design docs now, we’re already prototyping many of the modules.  Dependency Injection and Zone.js appear to be usable.  All the work will be done on GitHub and we’ll continue to capture weekly meeting notes so you can follow along.

What will it be like to port an AngularJS 1.x application to AngularJS 2?

As AngularJS 2 is still in development, we honestly don’t know.  In our imagination, porting will be fairly straightforward but not free.  Taking advantage of ES6 will likely be the largest part of the job.   Templates will be largely the same with some mostly-mechanical find and replace exercises.  Your controllers contain your business logic and not much if any AngularJS API today.  Those should port easily.  The parts that will require the most thinking will be your use of Modules and Directives.

Is AngularJS 2 a replacement for mobile tech like PhoneGap or Ionic Framework?

No, AngularJS is still just the core framework.  You might still want libraries like Ionic for mobile-optimized CSS/JS components and tools like PhoneGap for app packaging and native API access.

How does AngularJS 2 relate to AngularDart?

When porting AngularJS to the Dart language, we build a new version of Angular using all the learnings we’d acquired to date.  Many of the improvements discussed in this document like improved Directive concepts and syntax and class/annotation-based DI are already present there.  

While the implementation isn’t what we’ll arrive at for 2, it’s a great preview of what’s to come.  

We’ll be upgrading AngularDart as we build AngularJS 2 so folks who prefer the Dart language can enjoy the same benefits as folks on JS.  Our goal is that there will be a single framework with your choice of language.

Other documents of interest

• High Level Design Considerations
• Parser Abstraction Notes
• Templating Implementation Ideas
• Templating Examples