Hosting Inclusive Angular Events: Ideas from AngularConnect

We care a lot about making Angular's community inclusive and welcoming for everyone. 
Guest bloggers Vicky Carmichael and Ruth Yarnit are part of the White October Events team that co-organises AngularConnect.  If you're planning an Angular meetup or conference, you might find this post helpful in increasing the reach of your event. Enjoy!  - Naomi

---

As an event organiser, you want your attendees to have an amazing time. You put a lot of thought into the content, the venue and the atmosphere – and these are all important – but your natural and unconscious biases may make it easy to forget about how your experience of an event differs from someone else’s.

There are lots of reasons an attendee may require additional support to ensure they have a great time at your event. Perhaps they have a disability or health condition that means they require special assistance to be able to access the event and enjoy it fully. Maybe they come from an underrepresented group within tech, and are experiencing a sense of isolation. Or they may be new to the industry and feel a little intimidated to be surrounded by more experienced developers.

This post outlines some of the measures the AngularConnect team are taking to improve accessibility at their conference, and offers some handy pointers for how you can implement these measures at your own Angular events. This is by no means an exhaustive list – we know there’s always more we could do. Please feel free to email us at hello@angularconnect.com if you have any comments or other ideas.

Code of Conduct

Having a Code of Conduct at your event demonstrates your commitment to ensuring all participants feel welcome, safe and comfortable without threat of intimidation or public embarrassment. Here are some tips if you’re implementing one for the first time:

• Start with a template, and adapt it for your specific industry and event. Check out Angular’s Code of Conduct, which applies to all of the projects under the Angular organisation on GitHub and the Angular community at large, including IRC, mailing lists, and on social media.
• Be sure to list specific examples of behaviours that constitute a violation of the code. For instance, the AngularConnect code includes the line: “Harassment includes offensive verbal comments, sexual images in public spaces, deliberate intimidation, stalking, following, harassing photography or recording, sustained disruption of talks or other events, inappropriate physical contact, and unwelcome sexual attention.” This makes it easier to identify offending behaviour as it happens.
• Include clear instructions for what someone should do if they wish to report a violation of the Code of Conduct, and make sure all event staff are fully briefed on how to respond to such a report. AngularConnect staff wear brightly coloured t-shirts with the word “staff” or “organiser” on the back, so that they can be easily identified from afar by anyone needing assistance. Also provide details about how you will enforce your Code of Conduct.
• Make everyone aware of the Code of Conduct. Link to it clearly on your event website, and announce it on the day(s). We include a mention of the AngularConnect Code of Conduct at the bottom of every marketing email we send. This year we also plan to display large signs at the event reminding people where the code can be found, and how to report a violation. Make it clear that you expect all delegates, speakers, organisers and staff to comply with the code at all times and in all event spaces.
• Finally, don’t just pay lip service to your Code of Conduct. As event organisers, it’s our responsibility to use our judgement and take swift and appropriate action in the event of a violation of the Code of Conduct, and to send a clear message to our attendees.

Further Reading

Conference Code of Conduct
Codes of Conduct 101 + FAQ
Conference anti-harassment policy
HOWTO design a code of conduct for your community
Angular's Code of Conduct
AngularConnect Code of Conduct

Access Requirements

Making your event as accessible as reasonably possible will help ensure you’re not inadvertently excluding anyone from attending. People you should consider include wheelchair users and those with mobility impairments, people who are hard of hearing or deaf, people with visual impairments, and people with hidden impairments such as learning disabilities or mental health issues. Here are some measures you can take:

• On your event sign up form, include a checkbox for attendees to let you know if they have any special access requirements, and a field for them to provide further information. Make sure you check the feedback in plenty of time to make any necessary arrangements at the venue, and reach out to the attendee directly if you need more information to be able to accommodate their needs.
• When selecting a venue for your event, check that it’s fully wheelchair accessible. Consider whether it has step-free access, doorways wide enough to accommodate wheelchairs, elevator access to relevant floors, and dedicated accessible toilet facilities.
• Have reserved seating at the front of the space for people with disabilities, such as wheelchair users and people with visual impairments to use, if they wish to.
• Enquire whether the venue has hearing induction loops installed in the relevant spaces and, if it doesn’t, think about hiring them in. The venue may be able to put you in touch with a supplier. At AngularConnect we’re installing a hearing loop in both of the main track spaces for use by people with hearing aids.
• Consider providing real-time captioning for talks. You can choose how to display this, but make sure captions are clearly visible to all participants. This is something we’re excited to provide at AngularConnect this year, and we’ve selected a service that provides attendees with a link that can be viewed and customised in the browser on their personal device. This service is not only helpful for people who are hard of hearing, but also those for whom English is not their first language, and anyone who finds it easier to take something in when they see it written down.
• Make it clear to people considering attending that service animals such as guide dogs are welcome at the event, and offer to provide complimentary tickets to assistants of those with disabilities.
• Invite participants to contact you with any access requirements they’d like to discuss, and commit to doing your best to accommodate them. If you need time to check whether you’re able to provide the assistance they need, you could offer to reserve their ticket in the meantime so that they don’t risk missing out.
• A full-day (or longer) event surrounded by crowds can be overwhelming for some people. If you’re running a conference for an audience of hundreds, you may wish to create a comfortable “quiet zone” for those who need to take a breather. At AngularConnect last year we had ran mindfulness sessions in our chill out area for those who need a peaceful moment’s reflection. We got positive feedback about this and we’re looking forward to bringing the sessions back this year.

Dietary requirements

If you’ll be serving breakfast, lunch or dinner, you should offer at least one vegetarian option available as standard. You can aim to cater for more specific requirements (such as gluten free, allergies, Kosher, Halal, vegan etc.) with advance notice. Ask all attendees to let you know about any special dietary requirements at the point of registration. Be sure to label major allergens such as gluten or nuts on food packaging where possible.

Scholarship scheme

For paid events, you may wish to make extra efforts to open up your event to people who don’t have access to the funds to buy a ticket. One method for doing this is to run a Scholarship scheme where you set aside a number of free tickets to give away to individuals from underrepresented groups in tech or those facing economic and social hardship. If you have the budget, you could also consider covering their travel and accommodation expenses. Some sponsors may be willing to support a scheme like this financially.

To get set up, design a basic online form to capture applicants’ information, such as their name, contact details, location, and their reason for applying to the Scholarship Scheme. Have a look at the AngularConnect Scholarship Fund form for inspiration. Be sure to link to the form on your site and tickets page, shout about it on social media, and reach out directly to groups working with relevant individuals to ask if they’ll help spread the word. Include clear details about who should apply, how the process works, any deadlines, and how and when you will notify them of the outcome.

There’s no exact science to evaluating the applications, but it’s best done by a small committee rather than by just one person. You should aim to award tickets to people who would otherwise not be able to attend, and who can show how the knowledge they gain at the event will be useful to them in their ongoing career.

Summary

There’s an awful lot to think about when organising a conference or meetup. As a team, we try to be mindful of accessibility at all stages of planning AngularConnect, but we know there are always more improvements we can make. We hope this post has provided some food for thought for other event organisers, and we’d love to chat with you if you have comments or ideas for additional ways to make events accessible. Catch us on on Twitter at @AngularConnect, or email hello@angularconnect.com.

Angular 2: an MIT Open Source Licensed Framework

Guest-blogger Max Sills is an attorney in Google's Open Source Office, and our expert on all things legal related to Angular.  Enjoy!  - Naomi

As of beta.2 this week, we're moving Angular 2, its related libraries, and any code snippets and examples to the MIT license.

Open source licenses are meant to protect developers by making it clear how code can be used. We want developers to be confident that they can use, fork, modify, and extend Angular without worry.

At Google we prefer to license new projects under the Apache 2 license because we feel it gives the most rights to developers and creates a strong legal scaffold for projects to grow and thrive. However, what we've heard from users in the Angular community is that you prefer the MIT license. It's more widely used within JavaScript projects, it's shorter, and it’s better understood.

So, we're changing Angular back to the MIT license.

Happy coding.

Building Mobile Apps with Angular 2 and NativeScript

Hi! I’m TJ from the NativeScript team at Telerik. We’ve been working with the Angular team for the greater part of this year to integrate Angular 2 into NativeScript, which together let you write native iOS and Android apps using your existing web and Angular knowledge. In this article I’m going to cover what NativeScript is, why we’re using Angular, and how it all works. If you’re interested, read on!

What’s NativeScript?

NativeScript is an open source JavaScript framework that lets you build native mobile apps from a single code base. NativeScript works by leveraging JavaScript virtual machines—e.g. JavaScriptCore and V8—to create a bridge between the JavaScript code you write and the native APIs used to drive the native application. As a quick example check out the following code:

var myAlert = new UIAlertView();
myAlert.message = "NativeScript rocks!";
myAlert.show();

This is JavaScript code, yet NativeScript instantiates the Objective-C-based iOS UIAlertView control shown below:

And because we know that no web developer wants to learn iOS- and Android-specific APIs like UIAlertView, we offer a large suite of JavaScript modules that abstract the iOS and Android details into simple-to-use JavaScript APIs. For instance, the UIAlertView-based code block above could be rewritten using the NativeScript dialogs module:

var dialogs = require("ui/dialogs");
dialogs.alert({ message: "NativeScript rocks!" });

This same dialogs.alert() call also gives you the following android.app.AlertDialog for your Android app:

Although the dialog example is purposely simple, this same technique can be used to build incredibly robust and gorgeous apps, by utilizing the native iOS and Android UI components that are already available and mature. The best way to see what’s possible with NativeScript is to download our kitchen sink app on your iOS or Android device. You can also peruse our showcase page to see some of the many NativeScript-built apps in the app stores already.

Where does Angular come in?

One of our guiding principles when building NativeScript was to allow developers to leverage their existing skills. As such, NativeScript lets you write your app logic in JavaScript or TypeScript, style your app using a subset of CSS, leverage npm modules, and even use native iOS and Android libraries. So, it seemed logical for us to extend this skill reuse to another library developers know and love: Angular!

At Telerik we’ve long been fans of Angular. We first shipped Angular integration in our popular Kendo UI library nearly two years ago, and we continue to see a ton of demand for Angular from our community. But integrating Angular 1 into NativeScript was impossible, as Angular 1 was tightly coupled to the DOM.... and in NativeScript there is no DOM or browser; NativeScript UIs are native UIs.

Enter Angular 2.

One of Angular 2’s biggest architectural changes was decoupling the Angular framework from the DOM. Whereas Angular 1 was limited to browser-based environments, Angular 2 opened the door a number of different rendering possibilities, including NativeScript. And since earlier this year, we’ve been holding weekly meetings with the Angular team to turn this vision into a reality.

How does it work?

If you know Angular 2, you already know a lot of what you need to know to use Angular 2 in NativeScript. The one big difference is that browser-based elements such as <div> and <span> are not available—instead, you must use NativeScript’s UI components to build your interfaces. Let’s look at an example.

NativeScript apps are primarily made up of three types of files: JavaScript or TypeScript files (for logic), XML files (for defining UI components), and CSS files (for styling). If you create one of each of these files with the same name—e.g. main.js, main.xml, and main.css—NativeScript knows to use the files as a unit. For instance, here’s the full code you need to build the dialog example presented earlier in this article—notice the use of `"loaded"` to tie the XML and JavaScript files together.

<!-- main.xml -->
<page loaded="loaded"></page>

/* main.js */
var dialogs = require("ui/dialogs");
exports.loaded = function() {
    dialogs.alert({ message: "NativeScript rocks!" });
};

Normally in a NativeScript app, your next step would be adding a bunch of UI components to your <page> in main.xml—components like <slider>, <switch>, and <tab-view>. But with Angular 2 in the picture you can build your UI using the Angular 2 component APIs. Here’s an updated version of main.js (this time built with TypeScript), that shows how to build a “Hello World” page with NativeScript and Angular 2. Look over the code below quickly, and then we’ll break it down in detail.

Note: Using Angular 2 in NativeScript currently requires TypeScript, which is why I’m writing the code below in TypeScript rather than JavaScript. In a future release we will remove this limitation and let you use JavaScript directly.

// main.ts
import {nativeScriptBootstrap} from "nativescript-angular/application";
import {Component, View} from "angular2/angular2";

@Component({})
@View({
  directives: [],
  template: `
    <stack-layout>
      <button text="Hello World"></button>
    </stack-layout>
  `
})
class HelloPage {}

export function loaded() {
  nativeScriptBootstrap(HelloPage);
}

If you’ve built anything with Angular 2 before most of this code will look familiar. There are really only two differences to note:

• nativeScriptBootstrap() vs. bootstrap()
• In an Angular 2 web app, you call the bootstrap() function in the "angular2/angular2" module to initialize your components. In NativeScript apps you need to call nativeScriptBootstrap(), which is a lightweight wrapper of bootstrap() that does some NativeScript-specific initialization.
• The UI components in the template
• In an Angular 2 web app your “Hello World” button example would probably be rendered as <div><button>Hello World</button></div>. But in NativeScript apps you need to use XML widgets that NativeScript is able to render in native mobile apps. This example uses a <stack-layout> element, which is the simplest of NativeScript’s layouts, and places a single <button> element within it. Here’s how those controls render on iOS and Android.

         

What else can you do?

Once you have the basics down you can really start to leverage your existing web and Angular skills. For instance, want to change the look of your button? Just apply any of NativeScript’s supported CSS properties. For instance, if I add button { color: red; } to my app’s main.css file, I get a button that looks like this:

         

Want to add some behavior to the button? Just add a tap handler using Angular 2’s event binding mechanism. The following code alters the previous main.ts example to show an alert when the app’s button is tapped:

import {nativeScriptBootstrap} from "nativescript-angular/application";
import {Component, View} from "angular2/angular2";
import {dialogs} from "ui/dialogs";

@Component({})
@View({
    directives: [],
    template: `
        <stack-layout>
            <button
              (tap)="showAlert()"
              text="Hello World"></button>
        </stack-layout>
    `
})
class HelloPage {
    showAlert() {
        dialogs.alert({ message: "NativeScript rocks!" });
    }
}

export function loaded() {
    nativeScriptBootstrap(HelloPage, []);
}

There’s a whole lot more you can do in a NativeScript app—like using npm install to add JavaScript utility libraries to your app, installing NativeScript plugins to add some powerful native functionality, or trying out NativeScript’s rich animation APIs to move UI elements around the screen—but let’s take a minute to step back and consider why we’re taking this approach to building apps in the first place.

The benefits of using NativeScript and Angular 2

The examples presented in this article have been purposely simple to introduce basic concepts, but think of how much work you’d have to do to build these simple Android and iOS apps using traditional native development approaches. For iOS you’d have to launch Xcode, drag a UIButton control onto a Storyboard, figure how to change that button’s text, and use outlets in Xcode to tie your button to an event handler written in Objective–C or Swift. On Android you’d have to figure out how to accomplish the same tasks in a completely different environment (Eclipse or Android Studio).

With NativeScript and Angular 2 you can build that same button in a few lines of code; you can write that code in JavaScript/TypeScript; you can place that button in an Angular 2 component; you can style that button with CSS; you can install JavaScript modules to help you out from npm; and at the end of the day you only have one code base to maintain. This is why we’re excited about NativeScript—it brings a familiar web tool set to the native app world.

And it gets even better. In addition to skill reuse—aka being able to write native apps with JavaScript—using Angular 2 in NativeScript opens up one other cool possibility: the ability to share code between your web and native apps. After all, NativeScript code is just JavaScript code, so as long as that code isn’t tied to the DOM, there’s no reason that code can’t run in NativeScript. And with Angular 2 support coming to NativeScript, you even have the potential to share your Angular components. Let’s look at an example.

Sharing code between web and mobile apps

Suppose you need to write a simple checkbox component for your next Angular app. For your web app you might use the following TypeScript to implement the component:

import {Component, View, EventEmitter} from "angular2/angular2";

@Component({
    selector: "checkbox",
    templateUrl: "checkbox.html",
    input: ["checked"],
    output: ["click"]
})
export class Checkbox {
    public click: EventEmitter = new EventEmitter();
    public checked: boolean = false;

    public onClick(): void {
        this.click.next(this.checked);
    }
}

Above I define a component with a single checked input (or property) and a single click output (or event). I use Angular’s templateUrl option to define the component’s template in an external file named checkbox.html. That file contains the following HTML:

<input type="checkbox" [checked]="checked" (click)="onClick()">

Here’s where things get cool though. Now suppose that you want to make this component work on your NativeScript iOS and Android apps. What code would you have to change?

Only the template.

Seriously, that’s it. All you need to do is define how your component gets rendered on each platform—web and native. For instance, continuing the previous example, to get this code working in NativeScript you only need to swap out the contents of checkbox.html. The version of the template below uses the NativeScript <switch> widget:

<switch [checked]="checked" (tap)="onClick()"></switch>

By using two different templates, your component can now render on three platforms—the web, iOS, and Android. Here’s what that looks like visually:

It gets even better. NativeScript actually includes support for a few common web APIs, most notably XMLHttpRequest and fetch() This support means you can write your components for the web, and let NativeScript translate these APIs to native code for your mobile apps. As one example, because of NativeScript’s XMLHttpRequest support, Angular 2’s HTTP component works out of the box in NativeScript already. Here’s what that looks like visually:

Obviously not all code makes sense to share across all platforms, and you’ll certainly want to fork your code in places to handle individual platforms separately. But at the very least NativeScript and Angular can help you share code for the mundane things in your app—such HTTP calls and model objects—and in certain cases you may want to share entire interfaces.

We’re excited about the potential this architecture provides to the Angular world, and we can’t wait to see what you build with it.

Awesome! When will this be ready?

Our Angular integration is currently in an alpha state, much like Angular 2 itself. If you’re the type of developer that likes digging in early, head to https://github.com/NativeScript/nativescript-angular and follow the instructions in the README to get up and running. You may also want to check out our TodoMVC example, or Sebastian Witalec’s presentation on NativeScript and Angular 2 from Angular Connect—each have more advanced examples of NativeScript and Angular 2 in action.

Long term, our Angular integration will roughly follow Angular 2’s own release schedule; therefore, you can expect a stable release of NativeScript’s Angular integration around Angular 2’s own stable release date.

But although NativeScript’s Angular integration is in an alpha state, NativeScript itself is a production-ready framework being used to develop a wide variety of apps today. If you’re interested in learning more, take an hour and go through the NativeScript getting started guide. You’ll build a functioning iOS and Android app, and learn whether NativeScript makes sense for your next development project.

If you want to keep up to date with the latest with our Angular integrations, bookmark our weekly meeting notes document, and follow @nativescript on Twitter for updates. If you’re looking for help, or want to chat with others in the NativeScript community, head over to our Google Group. Overall, we’re excited about bringing Angular 2 to a new mobile world, and we hope you are too.

How Google Uses Angular 2 with Dart

Dan Grove and Kevin Moore from the Dart team are guest blogging this week on how Google uses Angular with the Dart language.  Enjoy!  - Brad

Google is always busy building new web apps, and recently a lot of that development is using Angular 2 for Dart. Just last week, the Google Fiber team launched Google’s first production Angular 2 app, written in Dart. Take a look at their just-launched Angular 2 for Dart app:

The Fiber team has lots of company within Google - Angular 2 for Dart is being quickly adopted by many other Google teams.

Dart is an open-source development platform from Google that makes web and mobile development more productive. The Dart language is a concise yet expressive language that’s familiar to developers coming from Java, C#, ActionScript, and JavaScript. The Dart platform gives you an instant edit-debug cycle, great core libraries, a canonical package manager, a powerful semantic analyzer, and IDE support via IntelliJ IDEA and WebStorm. You can run Dart code compiled to JavaScript on all modern browsers.

We’ve worked closely with the Angular team as they’ve developed Angular and Angular 2, and we’ll be working together going forward. The Angular team’s initial experiences with Dart shaped many different aspects of Angular 2—for instance, Angular 2’s new change detection system and template compilation. Both of these features dramatically sped up Angular 2 for both JS and Dart with 3x faster startup and 2.5x faster rendering than Angular 1. This sort of speedup makes a big difference for our users, especially on the mobile web.

We started our collaboration with the Angular team by working on Google’s internal CRM application, Greentea. The Angular team built the initial version of Angular 1 for Dart as Greentea was built, providing lots of feedback to the Dart team. By working with the Greentea team and the Angular team, we were able to make large improvements in Dart compilation to JavaScript, Dart-JavaScript interop, and IDE support for Dart.

Once Greentea was up and running, the Angular team started working on Angular 2. We’re thrilled to have Dart as a first-class language for Angular 2. Beyond Google Fiber, teams that have publicly announced that they’re currently moving to Angular 2 for Dart include:

• Greentea, Google’s internal CRM system.
• Google AdWords, the largest advertising system at Google.

The Google Fiber team told us that they chose Angular 2 for Dart because “Our engineers were highly productive as their projects scaled to many engineers. Dart’s support for strong typing, its object-oriented nature, and its excellent IDE integration really worked for us.”

We're continuing to improve the tools for writing and deploying apps that use Angular 2 for Dart. For instance, we’re adding Dart Analyzer support for Angular 2 templates, which will allow navigation and refactoring across Angular 2 templates and Dart code. We’re also dramatically cutting the JS that’s output by the Dart2JS compiler—“Hello, World” is down to 82KB gzipped, and we’re continuing work to slice that further.

We hope that sharing our experience will convince you to give Angular 2 for Dart a try. Angular 2 for Dart is available for you to try as a Developer Preview now—take a spin through the Angular 2 Getting Started tour now!

Dan Grove and Kevin Moore for the Dart team

Angular 2 Survey Results

This is a guest post from Jeff Whelpley and Patrick Stapleton. Though they're not full time Angular team members, they are incredible contributors to the Angular community. I think this post is a great summary of what users want to see from us. Enjoy!

- Brad Green

---

A couple weeks ago, Patrick and I sent out a survey to Angular developers with questions about how they plan on using Angular 2. We got over 2,100 responses and a lot of additional feedback. All of the results are posted below with some context and analysis.

Disclaimer

Originally we were only thinking about getting feedback from the small group of developers that are already spending most of their day working on Angular 2. This quickly changed, however, as more and more people started submitting responses. Angular 2 is only in alpha and you cannot build production apps with it yet. It is probably safe to assume that many people who responded are just starting to learn about Angular 2. Therefore, we now view the results in terms of what developers think they will do in the future rather than what they are actually doing right now.

With that disclaimer out of the way, let’s get to the results…

---

Transpilers

Which approach do you prefer when hacking Angular 2? (choose one)

TypeScript	45.0%	950
Babel	33.2%	700
Not sure	11.3%	238
ES5	9.0%	190
Other	1.6%	33

Analysis

For the first 1,000 results or so, TypeScript was in a dead heat with Babel but then TypeScript started to pull away. This is not surprising given that the Angular core team has a preference for TypeScript. We had a great discussion about TypeScript vs Babel on Angular Air and we concluded that much of the decision is going to come down to the personal preferences of the team.

Although sticking with ES5 is not a good long term strategy, a number of developers have used it to help with the transition from Angular 1 to Angular 2. If you are thinking about sticking with ES5 just because you don’t like transpilers, however, you should give them another shot. Transpilers in general have vastly improved over the past year.

"Other" Transpilers

A couple people wrote in that they use both TypeScript and Babel which may seem a little odd at first, but both teams have discussed ways that they can potentially work together in the future.

There were about a half dozen responses for Dart and 1 for Closure Compiler.

Also, there were 7 responses for CoffeeScript, presumably from the Ruby/Python crowd.

Template Syntax

Which template binding syntax will you use? (choose one)

bind-prop="val"	56.7%	1192
[prop]="val"	43.3%	912

Analysis

This was initially one of the most surprising results, but the more we thought about it, the more it made a lot of sense. Although the Angular core team prefers the second option (i.e. [prop]=val which is the canonical syntax), most developers seem have the same initial reaction. It feels weird and unfamiliar (is it even valid html?). The first option (i.e. bind-prop="val") looks and feels like Angular 1.x template code.

Despite this, it may be interesting to note that all developers we know who hack on Angular 2 every day use the canonical syntax in most cases. It was weird at first, but we all got used to it. Remember that when Angular 1 first came out, everyone was freaking out about using non-standard attributes that start with the prefix ng-. Initially many Angular 1 developers thought about either prefixing attributes with data- (ex. data-ng-bind) or using the xmlns notation of ng:*. Those ideas quickly faded away, however, once people realized they didn’t provide any real benefits.

"Other"

I thought this was sort of interesting:

@jeffwhelpley I like simplicity of [prop]="val" for properties and a strong distinguish of events by "on-" prefix.

— Grzegorz Biziel (@gbiziel) August 19, 2015

Some of this particular concern will go away once text editors properly support Angular 2 syntax highlighting, but it is nice that you can mix and match the canonical syntax with the alternate syntax as you please. For example, even though we use the canonical syntax for binding and events, we prefer the alternate syntax for vars:

*ng-for="var item of collection"

instead of:

*ng-for="#item of collection"

We suggest trying out different variations of syntax yourself. Don't shy away from the canonical syntax just because it feels weird. Finally, keep an eye on out for what others are using in examples online and at conferences. More than likely, the community will converge on a set of standards over time.

Template Location

Where do you prefer to keep your templates? (choose one)

Both	47.6%	1008
External file	46.5%	986
Inline	3.4%	73
Not sure	1.8%	39
Other	0.6%	13

Analysis

We have a strong preference for inline templates, but there are a number of use cases where separate template files make more sense.

Advantages of inline templates:

1. All code for a given component in one file
2. Encourages developers to keep templates small and refactor when they get too big

Advantages of separate template files:

1. Angular 1 developers familiar with this approach
2. Easier to share with designers and other non-developers
3. Generally better intellisense support in editors today
4. More natural home for large templates that can can’t be broken down into smaller pieces (ex. forms and layouts)

We think that the numbers in favor of inline templates will increase over the next year as developers get familiar with Angular 2 and intellisense support increases. As far as sharing templates with designers, it should be noted that in the React world, there has been some success getting designers to modify inline templates.

Routing

Which routing mechanism do you prefer? (choose one)

Component Router	36.7%	776
UI Router	33.0%	698
Not sure	28.1%	594
Custom	1.7%	35
Other	0.4%	9

Analysis

There are a few things to keep in mind while looking at these results:

1. There is a lot of hype around the new router and it has the support of the core team which is why it is in the lead.
2. That said, many of the developers that have been working with Angular 2 so far have experienced frustrations (i.e. things not working or features missing) which is why it doesn’t have an overwhelming lead.
3. The UI Router doesn’t yet have any Angular 2 support, but it is what many developers use with Angular 1 apps and what they expect.

This is not an ideal situation, but we believe that this is just a short term issue. Many of the problems developers have encountered with the Component Router have either already been fixed or are in the process of being addressed. There are also plans to integrate the UI Router with Angular 2 in the near future. So, by the time Angular 2 is released, developers should have two great options for routing.

Data Libraries

Select any of the following data-related libraries that you will likely utilize on a majority of your Angular 2 projects: (choose multiple)

RxJS	38.7%	522
Immutable.js	34.7%	469
Firebase	33.3%	449
angular-meteor	23.8%	321
Falcor	14.5%	196
Other	9.1%	123
BaconJS	6.6%	89

Analysis

There are a lot of libraries out there that can help you manage your data both in Angular 1 and Angular 2. Some interesting notes for each library:

1. RxJS

This library implements observables, which are objects that model push-based data sources. We think the popularity of RxJS in Angular 2 boils down to two primary things. First, a great API for handling one or more asynchronous operations (this is why RxJS is used in the Angular 2 core http module). Second, performance gains from using observables with Angular 2 change detection (reducing complexity from O(N) to O(logN)). For more information on RxJS, check out our discussion with the creator of RxJS on Angular Air. For more information on observables, take a look at the proposed implementation of observables in ES2016.

2. Immutable.js

It is probably safe to attribute the popularity of Immutable.js to React. As mentioned further below, a significant portion of Angular developers also use React. An even bigger portion, including many of the Angular core team members, are aware of the concepts and ideas coming out of the React community and have started to use those concepts in their Angular development. Lee Bryon from the React team gave a great talk earlier this year about the benefits of immutability in general. One of the biggest benefits of using immutable objects in Angular 2, is that it reduces change detection complexity from O(N) to O(1). In other words, change detection occurs in constant time that is not linked to the number of bindings on the page.

3. Firebase

Firebase has always been extremely popular in the Angular community and I wouldn’t expect anything to change with Angular 2. In fact, the numbers here can and should be much higher because we didn’t include Firebase as an option in the survey when it was originally sent out. We added Firebase and angular-meteor after 50 responses were already submitted.

4. angular-meteor

Uri, the creator of angular-meteor, hit me over the head about five minutes after I posted the survey and I quickly added it as an option. There is a strong, vibrant community around this library and it supports both Angular 1 and Angular 2.

5. Falcor

The new kid on the block (just recently released) has been getting a lot of hype since it is backed by Netflix and has been frequently touted by Jafar Husain over the past couple months. Falcor leverages asynchronous data binding in Angular 2 and can be extremely powerful if you have a mostly read-only application.

6. Bacon.js

Bacon.js is another observables library, but not as popular as RxJS.

"Other" Data Libraries

There where a number of other libraries in responses including:

Angular 2 Data

This library isn’t available yet (which is why it wasn’t in the survey), but is being modeled after Ember Data to provide a higher level interface for your data in Angular 2. Other data libraries may be used in conjunction at lower levels. We talked with the Angular core team about Angular 2 Data on Angular Air.

Relay/GraphQL

Created by Facebook and part of the “React stack”, this library is similar in concept to Falcor, but with more features and more complicated (Jafar compares the two here).

Breeze.js

Works well with Angular 1 for caching, model validation, offline support and more.

Server Rendering

Will you use the server rendering features when they are available in Angular 2? (choose one)

Yes	27.2%	566
Sometimes	25.9%	539
No	25.7%	534
Not sure	21.2%	442

Analysis

We split this question out from the general Angular 2 features question below because Patrick and I are heavily involved in the effort to get Angular 2 rendering on the server. As we discussed on Adventures in Angular, universal rendering is fundamentally better than client-only rendering so the only question is about how much effort it takes. We view this result as very positive since we haven’t released the feature yet and only a handful of developers have used it yet. So, if 52.7% of developers think they will use server rendering on at least some of their projects now, we feel really good about gaining a majority of the mind share by the time we release this feature.

Track our progress on the Universal Angular repo and/or follow us on Twitter (@jeffwhelpley and @gdi2290). Also be sure to tune into Angular Connect in October for an update.

Editors

Which editors will you use most often when hacking on Angular 2? (choose multiple)

Webstorm	43.0%	907
Sublime	39.0%	822
VS Code	30.1%	634
Atom	25.0%	528
Other	11.2%	237
VIM	10.7%	226
Emacs	1.6%	33

Analysis

It is interesting to see the most feature packed IDE, Webstorm, in the lead. There are many “enterprise” developers that use Java or .NET along with Angular and they are used to heavier weight development environments.

On the other end of the spectrum, VIM actually got more responses than I thought it would. Our friend Mike Hartington from Ionic is an avid VIM user and thinks it works really well with Angular 2 and TypeScript.

Most of the Angular core team has started to use Visual Studio Code. If you haven’t tried it yet, Visual Studio Code has a Sublime-like feel and it works really well right out of the box with TypeScript.

"Other" Editors

The numbers for Webstorm and Visual Studio Code would even be bigger if you combined them with their “sister” products that people wrote in (ex. IntelliJ and RubyMine with Webstorm and VS.NET with Visual Studio Code).

A half dozen developers also strongly recommended Brackets.

Build Tools

Which build tools do you plan on using when hacking on Angular 2? (choose multiple)

Gulp	72.4%	1464
Grunt	39.5%	799
Webpack	23.6%	478
SystemJS	17.0%	344
Browserify	16.3%	330
JSPM	12.8%	258
Other	3.1%	63
Broccoli	2.3%	46

Analysis

Clearly Gulp is the winner here, but it should be noted that most of these tools can be used at the same time and are not mutually exclusive. We were not surprised to see Webpack have such a strong showing.

Also note that since JSPM uses SystemJS behind the scenes, we can effectively add it to all responses with JSPM that didn’t already have SystemJS. That would put SystemJS usage on par with Webpack.

"Other" Build Tools

There were many write in submissions for simply using npm scripts. Other options submitted by more than five people included Gradle, Meteor's build system, RequireJS and Bower.

Frameworks

What frameworks other than Angular 1.x do you use regularly today? (choose multiple)

jQuery	54.7%	1111
React	26.8%	545
Only Angular	24.2%	491
Backbone	12.6%	255
Meteor	9.7%	196
Other	8.3%	168
Sails	3.8%	77
Ember	3.8%	77

Analysis

As much as we like to think about the future of the web, the fact is that everyone still has to support older browsers and no library does that better than jQuery. Even so, it is amazing to see how predominant jQuery still is with Angular developers today.

Also interesting to see more than 1/4th of Angular developers also using React. There is a lot of hype around React, but it is based on some really good ideas. You could argue that number is going to increase over the next year as React becomes even more popular or you could argue it will decrease since Angular 2 has adopted many of the best concepts from React (and thus less motivation for Angular developers to go outside Angular).

"Other" Frameworks

If we could have changed one question on this survey this would have been it. We forgot to include 4 frameworks that a number of people wrote in about:

• Ionic  — An extremely popular library for building hybrid mobile/web apps that uses Angular. The Ionic team are huge fans of Angular 2 and are one of the only groups writing production-level code on top of Angular 2 today.
• Dart  — I am sure someone outside Google uses Dart, but I just haven’t met that person yet. In any case, it will be interesting to see if Dart remains popular inside Google given the decision not to include the Dart VM in Chrome and the fact that Angular 2 with TypeScript addresses some of the problems that Dart is trying to solve.
• Polymer  — Unlike Dart, I have actually met a number of groups that are using Polymer in the wild. Polymer will likely never be as popular as Angular, but as modern browsers become more prevalent and web component standards solidify, there will be a niche for Polymer.
• Aurelia  — A framework similar to Angular created by a former Angular core team member.

Features

Which Angular 2 features ar eyou most looking forward to? (choose multiple)

Change Detection	65.0%	1298
Web Components	57.9%	1157
Zone.js	53.1%	1060
Component Router	42.3%	845
DI updates	39.4%	788
Server Rendering	37.1%	742
i18n	29.2%	583
Animation updates	25.7%	513
Other	3.6%	72

Analysis

As I wrote about last year, many developers love to hate Angular. In that article I wrote:

The typical anti-Angular rant usually includes one or more of the following gripes:

1. Subpar features (ex. routing, model layer)
2. Missing features (ex. server rendering, async loading)
3. Cumbersome and/or confusing APIs (ex. injection arrays, service/factory/provider, directives)
4. Fundamental design decisions (ex. working off the DOM, dirty checking vs KVO vs Virtual DOM, mutable data vs immutable data).

Let’s match up these Angular 1 issues with the top Angular 2 features that people are excited about:

1. Change Detection

Change detection in Angular 2 completely eliminates most of the fundamental design decision issues from Angular 1 (issue #4 above). Right out of the box, Angular 2 change detection is faster than Angular 1. You can see evidence of this in a number of experiments that developers are starting to come out with like this recent blog post from the Meteor team. You can also use immutable or observable data as you wish to make your app even faster. In addition, the design of change detection allows for unidirectional data flow which makes your app easier to reason about. In short, the developer has full control over how change detection works in Angular 2 and can optimize it for their specific situation. It’s no wonder this is the top feature people are excited about.

2. Web Components

To be quite frank, we don’t think most developers care about Web Components. When we talk to developers about this, they talk more about the component-driven design of Angular 2 rather than integration with actual Web Components. Building your web app with a highly structured component tree in Angular 2 solves many of the issues with cumbersome and/or confusing APIs in Angular 1 (issue #3).

3. Zone.js

This library has many uses in Angular 2 core, but the most notable benefit is that it eliminates the need for developers to use $scope.$apply() whenever they change data outside the context of Angular. This is huge.

4. Component Router

When it is ready, the Component Router will address one of the biggest subpar features of Angular 1 (issue #1). It will also enable the asychronous loading of different components (issue #2). We talked with Brian Ford about the Component Router on Angular Air.

5. Dependency Injection

One of the biggest noticeable impacts of the Angular 2 DI system is that Angular no longer needs to call toString() on a function to get the arguments as string tokens. This means no more minification issues with Angular and no need to manually declare the string tokens with an array (i.e. issue #3). Overall, the DI interface is much cleaner and more flexible. Pascal wrote a great blog post about the Angular 2 DI system that explains more.

6. Server Rendering

This is one of the biggest missing features from Angular 1 (issue #2) and it is going to be awesome. We explain the motivations behind this feature and how we are building it into Angular 2 in our recent AngularU talk.

"Other" Features

There were a couple other notable features submitted including:

• Native integration (both NativeScript and React Native)
• Material Design integration

Demographics

What is your Angular 1.x experience level? (choose one)

Novice / beginner	13.9%	292
Experienced (simple apps)	27.6%	581
Advanced (1+ large prod app)	37.2%	784
Expert	21.3%	448

Analysis

This survey was originally intended for more advanced Angular developers, so we were happy to see that a majority of the responders (58.7%) came from the Advanced or Expert buckets. However, since we changed the focus from “what are people using” to “what do people think they will use”, it was also great to get a healthy showing from less experienced Angular developers. As a result, we feel that this survey is a pretty good representation of the Angular community as a whole.

Final Word

A really big thank you to the thousands of Angular developers that participated in this survey. Also thanks to the dozens of friends that reviewed this post and provided feedback. In particular, thanks to Brad Green for giving us the chance to do a guest post on the official Angular blog.

We found the results extremely interesting and we hope that this blog post helps everyone in the community get a sense of what other developers are thinking about Angular 2 so far. That said, keep in mind that the responses to these same questions will likely be quite different a year from now after Angular 2 has been released and developers are using it in production. We will have to do a follow up to this survey at that time to see how sentiment has changed.

Jeff Whelpley | GetHuman | @jeffwhelpley
Patrick Stapleton | Angular Class | @gdi2290