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, 2015Some 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:
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:
- Subpar features (ex. routing, model layer)
- Missing features (ex. server rendering, async loading)
- Cumbersome and/or confusing APIs (ex. injection arrays, service/factory/provider, directives)
- 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
