Tuesday, September 1, 2015

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

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.

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:

All code for a given component in one file

Encourages developers to keep templates small and refactor when they get too big

Advantages of separate template files:

Angular 1 developers familiar with this approach

Easier to share with designers and other non-developers

Generally better intellisense support in editors today

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:

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.

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.

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:

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.

"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.

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.

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).

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

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.

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).

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

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.