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

An AngularJS Style Guide and Best Practice for App Structure

Want to know more about AngularJS Best Practices, as we use them at Google?

---

UPDATE 4/19/2015: The most current and detailed Angular Style Guide is the community-driven effort led by John Papa and Todd Motto, which you can find at https://github.com/johnpapa/angular-styleguide. Please use this instead of the one mentioned below.

---

You can now find a published copy of Google's AngularJS Style guide at https://google-styleguide.googlecode.com/svn/trunk/angularjs-google-style.html. While this documents how we use AngularJS in production code at Google, you'll notice that the style guide is heavily biased towards JSCompiler optimizations and the needs of large code bases. We don't think this makes sense for all projects that use AngularJS, and we'd love to see our community of developers come up with a more general Style that's applicable to AngularJS projects large and small. Interested in helping or leading this project? Sign up here, and choose "Style Guide for Angular" and we'll be in touch.

We've also published some new Best Practice Recommendations for Angular App Structure. One of our goals is to come up with a recommendation that meets the needs of both large and small app developers, so that we can start developing tooling that makes development easier. If you're not using this recommended structure yet, don't worry. It's fine to keep doing what you're doing. At some point, we hope the efficiency gain of having more developer tools will make it worth your time to convert over.

Code of Conduct

Don't worry, this is not a reaction to some disaster within the Angular community.

We're grateful that the Angular community is filled with really nice people. We've become a huge and diverse group. A set of written guidelines will help maintain the high level of discourse in all of our communications. Also we made Angular to help everyone build great apps so we want to explicitly state that everyone is welcome.

The code of conduct is a short document that describes the expectations we have about how we communicate within the Angular community. Please read and follow it.

If you are running an Angular event (meetup, user group, etc.), please have a code of conduct for it.

If you have questions or concerns regarding the code of conduct, you can now email conduct@angularjs.org.

AngularJS 1.3: a new release approaches

Heads up! A new Angular release is on its way. Since we plan to discontinues support for old browsers, we wanted to give you plenty of notice. As a secondary goal, this release will cover features to improve performance, and small API fixes that require small breaking changes and removal of apis that were previously deprecated. We're also making a change to how we number stable/unstable releases.

AngularJS 1.3 discontinues support for Internet Explorer 8

Why we're doing this:

• Modern browsers have evolved. Although our stats tell us that only a small percentage of users are on Internet Explorer 8, maintaining compatibility requires code that slows the rest of AngularJS down.
• In April 2014, Microsoft will be ending support for Windows XP, which means the end of support for the operating system most of Internet Explorer 8 users use.

Dropping support for Internet Explorer 8  will enable us to add more exciting features to Angular faster, decrease Angular's support burden, and cut our build time in half, while affecting only a very small proportion of users.

But what if your users still rely heavily on Internet Explorer 8? If your app needs to keep supporting older browsers, you have a few options:

• Keep using Angular 1.2.x.
• Use 1.3 and test (or if you're feeling lucky, hope for the best). The changes in version 1.3 won't be actively removing the hacks in Angular that make Internet Explorer 8 work. Most things that work now will probably keep working. But we're going to stop testing against Internet Explorer 8 in our CI server configuration. And we won't be fixing issues that are solely related to support for Internet Explorer 8 users.
• Look for commercial support outside the core project - the Angular ecosystem is now big enough that it wouldn't be shocking to us if a company started offering commercial support for Angular apps on IE8. (entrepreneurs: hint hint!)

Removal of deprecated apis

We are aiming at the promise unwrapping in Angular templates that we deprecated before v1.2.

New naming conventions for release versions

Since our long term goal is to move to semantic versioning (semver) for Angular 2.0, starting with AngularJS 1.3 we are replacing odd/even versioning we used previously with semver's pre-release notation.

What does that mean?

• The first stable release under the 1.3.x release train will be 1.3.0.
• Unstable releases toward 1.3.0 will use semver's pre-release notation (#.#.#-text.#) So, for example, 1.3.0-beta.1 and 1.3.0-beta.2 would be unstable releases.

New features for 1.3? Tell us what you care about.

We have a handful of things that we want to add, but we also want to hear from you! Since there is no good way to create a poll on GitHub, we are going to abuse GitHub a bit — if you care about a particular Issue or PR please post a comment with text "+1" on it. When the poll closes Mary Poppins will count the votes casted during the duration of the poll, *de-dupe* them and count them. (She'll then delete the vote comments and replace them with a summary comment.) The poll will close on January 2 and we'll use the results when deciding what to add to the 1.3 release.

OK. But when is Angular 1.3 actually coming?

We still have a few things lined up for the 1.2.x release train, and we want time to consider your votes. In spite of that you should see the first beta builds of 1.3.0 starting to roll out in January with the usual 1-2 week frequency.

On launching AngularJS 1.2: what we learned, what we're changing

You might have noticed something new since we launched 1.2... Now that we're caught up, we've begun pushing a new release every week or two to stay on top of things and keep the PR queue responsive. Unless there's something big or noteworthy, we're also no longer blogging about every release.

We learned a lot from launching 1.2. Here are our own notes on the 1.2 launch process, and what we'll be improving, in case you're curious too.

1.2 took way too long!

• The community uptake and increase in github activity alongside 1.2 caught us by surprise. We got swamped, and it took some time to get on top of the new volume of contributions. We're back in the flow now, with a few new folks on the core team, and we're taking steps to keep from getting overwhelmed.
• To handle this new volume, we needed better infrastructure in place. We were depending too much on manual processes; managing them took time that couldn't be spent on development. We've since improved the CI server, and added more automation to our launch processes and tests. We're also looking for more ways of automating and streamlining the release process.
• Some of our 1.2 goals turned out to be much more challenging than we anticipated. Animations, for example -- we realized that we needed to do something different, to make it really easy to use by thoroughly anticipating use cases, instead of putting the burden on the developer to implement. Getting it right took longer.
• Our release schedule wasn't all that well organized. Because the core team was overwhelmed, we often sat on fixes and features for too long, delaying the feedback loop with contributors. We're generating pre-release builds from the CI server and working on providing them via bower (either nightly or even after each commit) so that we can get feedback faster.

Underscore issues and the revert in 1.2.1

Shortly after 1.2, we issued 1.2.1, reverting a late change around hiding "private" properties prefixed with an underscore. We tested the change on hundreds of apps at Google, and with a few minor exceptions, nobody was affected, so we assumed it was safe to proceed. But we missed the real impact on apps elsewhere.  We reverted the change within a week, but we'd like to avoid making the same mistake again.

What steps are we taking?

• We're committing to release more frequently, reducing the feature pressure on any one release.  With a consistent release schedule, we'll have more time to fully consider the implications of the features that we add and the changes we make.  
• New pre-release builds from the CI server provide greater visibility into what we're working on. No surprises.
• Even if the impact seems small, no more breaking changes in the last release before a final major version. We learned this lesson and we really mean it.

Farewell, Disqus

tl;dr: We are removing Disqus comments from the AngularJS docs.

Problems with Disqus

Besides making it difficult to moderate off-topic or inflammatory comments, many comments are specific to past versions of Angular. We think the documentation should be versioned alongside the code so there's never a question of whether information is out of date.

Disqus has been great for allowing us to get feedback and allow developers to share tips about AngularJS, but we think there are better ways to do this now. You'll always be able to see the Disqus comments in past versions of Angular (<=1.2.2), but going forward, here's where we think the things previously posted in comments should belong:

Questions

Post questions to StackOverflow or the mailing list. They tend to get answered more quickly and stay up-to-date because of the active community there.

Bug Reports (Issues)

Bug reports should go on Github. It's useful to be able to see everyone's issues, workarounds, and the progress towards fixing them all in the same place. See the relevant section of the contributing guide for more.

Improvements to the Documentation

We think the best way to improve the docs is by directly improving the text. You can do this via the "improve this doc" button at the top of each page.