Introducing multi-location updates and more

Jacob Wenger

Core Developer

Today we released new versions of our Android (2.4.0), iOS (2.4.0), and JavaScript (2.3.0) clients. You can read the individual changelogs for details (Android, iOS, web), but we wanted to expand on three highly requested features shipping with this release: atomic multi-location writes, ordering queries by deep paths, and iOS 9 bitcode support. Let's jump in!

Atomic Writes Across Multiple Locations

Firebase has always supported updating multiple children of a node atomically. For example, let's assume the /user path in our Firebase database contains the following data:

{
  "user": {
    "name": "Samantha",
    "age": 25
  }
}

Using the pre-existing atomic update support, we can change the user's age and add a city without updating their name:

JavaScript

var ref = new Firebase("https://.firebaseio.com");
var userRef = ref.child("user");
var newUserData = {
  "age": 30,
  "city": "Provo, UT"
};
ref.child("user").update(newUserData);

Java

Firebase ref = Firebase(url: "https://<YOUR-FIREBASE-APP>.firebaseio.com");
Firebase userRef = ref.child("user");
Map newUserData = new HashMap();
newUserData.put("age", 30);
newUserData.put("city", "Provo, UT");
userRef.updateChildren(newUserData);

Objective-C

Firebase *ref = [[Firebase alloc] initWithUrl:@"https://<YOUR-FIREBASE-APP>.firebaseio.com"];
Firebase *userRef = [ref childByAppendingPath: @"user"];
NSDictionary *newUserData = @{
    @"age": 30,
    @"city": "Provo, UT"
};
[userRef updateChildValues: newUserData];

Swift

let ref = Firebase(url: "https://<YOUR-FIREBASE-APP>.firebaseio.com")
let userRef = ref.childByAppendingPath("user")
let newUserData = ["age": 30, "city": "Provo, UT"]
userRef.updateChildValues(newUserData)

However this was limited to only atomically updating direct children. Writing to completely separate locations was not possible. For example, say we have two top-level nodes: /user and /posts. The /posts node contains a list of all posts while /user/posts contains a list of all posts created by that user.
This is called denormalization and is a common practice to optimize your reads. Before today, in order to add a new post and assign it to the user, two writes were required: one to create the new post and one to assign the post to the user. This made code unnecessarily complex and led to verbose error handling and rollback logic to handle the case where the first write succeeds but the second write fails.
With today’s release, you can now do this in a single atomic update to both locations:
JavaScript

var ref = new Firebase("https://<YOUR-FIREBASE-APP>.firebaseio.com");
// Generate a new push ID for the new post
var newPostRef = ref.child("posts").push();
var newPostKey = newPostRef.key();
// Create the data we want to update
var updatedUserData = {};
updatedUserData["user/posts/" + newPostKey] = true;
updatedUserData["posts/" + newPostKey] = {
  title: "New Post",
  content: "Here is my new post!"
};
// Do a deep-path update
ref.update(updatedUserData, function(error) {
  if (error) {
    console.log("Error updating data:", error);
  }
});

Java

Firebase ref = new Firebase("https://<YOUR-FIREBASE-APP>.firebaseio.com");
// Generate a new push ID for the new post
Firebase newPostRef = ref.child("posts").push();
String newPostKey = newPostRef.getKey();
// Create the data we want to update
Map newPost = new HashMap();
newPost.put("title", "New Post");
newPost.put("content", "Here is my new post!");
Map updatedUserData = new HashMap();
updatedUserData.put("users/posts/" + newPostKey, true);
updatedUserData.put("posts/" + newPostKey, newPost);
// Do a deep-path update
ref.updateChildren(updatedUserData, new Firebase.CompletionListener() {
   @Override
   public void onComplete(FirebaseError firebaseError, Firebase firebase) {
       if (firebaseError != null) {
           System.out.println("Error updating data: " + firebaseError.getMessage());
       }
   }
});

Objective-C

Firebase *ref = [[Firebase alloc] initWithUrl: @"https://<YOUR-FIREBASE-APP>.firebaseio.com"];
// Generate a new push ID for the new post
Firebase *newPostRef = [[ref childByAppendingPath:@"posts"] childByAutoId];
NSString *newPostKey = newPostRef.key;
NSString *updateUserPath = [NSString stringWithFormat:@"users/posts/%@", newPostKey];
NSString *updatePostPath = [NSString stringWithFormat:@"posts/%@", newPostKey];
// Create the data we want to update
NSMutableDictionary *updatedUserData = [[NSMutableDictionary alloc] init];
[updatedUserData setValue:[NSNumber numberWithBool:YES] forKey:updateUserPath];
[updatedUserData setValue:@{@"title": @"New Post", @"content": @"Here is my new post!"} forKey:updatePostPath];
// Do a deep-path update
[ref updateChildValues:updatedUserData withCompletionBlock:^(NSError *error, Firebase *ref) {
    if (error) {
        NSLog(@"Error updating data: %@", error.debugDescription);
    }
}];

Swift

let ref = Firebase(url: "https://<YOUR-FIREBASE-APP>.firebaseio.com")
// Generate a new push ID for the new post
let newPostRef = ref.childByAppendingPath("posts").childByAutoId()
let newPostKey = newPostRef.key
// Create the data we want to update
let updatedUserData = ["users/posts/\(newPostKey)": true, "posts/\(newPostKey)": ["title": "New Post", "content": "Here is my new post!"]]
// Do a deep-path update
ref.updateChildValues(updatedUserData, withCompletionBlock: { (error, ref) -> Void in
    if (error) {
        print("Error updating data: \(error.description)")
    }
})

Deep path updates let you write cleaner code and easily denormalize data across multiple nodes in your Firebase database.

Ordering queries by deep paths

Up until now, we have been able to order queries by direct children. Here's a snippet of the dinosaur data stored in our database of dinosaur facts:

JavaScript

{
  "lambeosaurus": {
    "height" : 2.1,
    "length" : 12.5,
    "weight": 5000
  },
  "stegosaurus": {
    "height" : 4,
    "length" : 9,
    "weight" : 2500
  }
}

To read all dinosaurs ordered by height, we can order nodes by a common child key:

JavaScript

var ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs");
ref.orderByChild("height").on("child_added", function(snapshot) {
  var dinoName = snapshot.key();
  var dinoData = snapshot.val();
  console.log(dinoName + " was " + dinoData.height + " meters tall");
});

Java

Firebase ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs");
Query queryRef = ref.orderByChild("height");
queryRef.addChildEventListener(new ChildEventListener() {
    @Override
    public void onChildAdded(DataSnapshot snapshot, String previousChild) {
        DinosaurFacts facts = snapshot.getValue(DinosaurFacts.class);
        System.out.println(snapshot.getKey() + " was " + facts.getHeight() + " meters tall");
    }
    // ....
});

Objective-C

Firebase *ref = [[Firebase alloc] initWithUrl:@"https://dinosaur-facts.firebaseio.com/dinosaurs"];
[[ref queryOrderedByChild:@"height"]
    observeEventType:FEventTypeChildAdded withBlock:^(FDataSnapshot *snapshot) {

    NSLog(@"%@ was %@ meters tall", snapshot.key, snapshot.value[@"height"]);
}];

Swift

let ref = Firebase(url:"https://dinosaur-facts.firebaseio.com/dinosaurs")
ref.queryOrderedByChild("height").observeEventType(.ChildAdded, withBlock: { snapshot in
    if let height = snapshot.value["height"] as? Double {
        println("\(snapshot.key) was \(height) meters tall")
    }
})

This works great, but sometimes we want to order by descendants further down in our data tree. Let's say our dinosaur data actually looked like this:

{
  "lambeosaurus": {
    "dimensions": {
      "height" : 2.1,
      "length" : 12.5,
      "weight": 5000
    }
  },
  "stegosaurus": {
    "dimensions": {
      "height" : 4,
      "length" : 9,
      "weight" : 2500
    }
  }
}

Previously there was no way to sort these dinosaurs based on any of their dimensions since they are stored too many levels deep. Now we can use a deep path query!

JavaScript

var ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs");
ref.orderByChild("dimensions/height").on("child_added", function(snapshot) {
  var dinoName = snapshot.key();
  var dinoData = snapshot.val();
  console.log(dinoName + " was " + dinoData.dimensions.height + " meters tall");
});

Java

Firebase ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs");
Query queryRef = ref.orderByChild("dimensions/height");
queryRef.addChildEventListener(new ChildEventListener() {
    @Override
    public void onChildAdded(DataSnapshot snapshot, String previousChild) {
        DinosaurFacts facts = snapshot.getValue(DinosaurFacts.class);
        System.out.println(snapshot.getKey() + " was " + facts.getHeight() + " meters tall");
    }
    // ....
});

Objective-C

Firebase *ref = [[Firebase alloc] initWithUrl:@"https://dinosaur-facts.firebaseio.com/dinosaurs"];
[[ref queryOrderedByChild:@"dimensions/height"]
    observeEventType:FEventTypeChildAdded withBlock:^(FDataSnapshot *snapshot) {

    NSLog(@"%@ was %@ meters tall", snapshot.key, snapshot.value[@"dimensions"][@"height"]);
}];

Swift

let ref = Firebase(url:"https://dinosaur-facts.firebaseio.com/dinosaurs")
ref.queryOrderedByChild("dimensions/height").observeEventType(.ChildAdded, withBlock: { snapshot in
    if let height = snapshot.childSnapshotForPath("dimensions/height").value as? Double {
        println("\(snapshot.key) was \(height) meters tall")
    }
})

The ability to order by deep paths gives you much more freedom in structuring your data.

Bitcode support for iOS

The Firebase iOS client is now compiled with bitcode support, a new iOS 9 feature. Bitcode is an "intermediate" language that Apple uses to represent your iOS and watchOS apps. According to Apple, “including bitcode will allow [us] to re-optimize your app binary in the future without the need to submit a new version of your app to the store.” This enables you to ship smaller apps through app thinning, as well as design for future products, decreasing development time and increasing the number of platforms upon which your app runs.

Bug fixes galore

On top of the new features mentioned above, we have also fixed a handful of bugs across each of the clients. Memory leaks, cache inconsistencies, and crashes have been tracked down and fixed in today's releases.

Hack away!

All of these new features and bug fixes are now available in version 2.4.0 of the mobile clients and version 2.3.0 of the JavaScript client. See the installation and setup guides for each platform (Android, iOS, web) to learn how to get started with the latest clients.

We'd love to hear what you think of this release. Post any feedback or submit bug reports in our Google Group. Lastly, if you've built anything, don't be shy! Share your apps with us on Twitter @Firebase. We're excited to see what you build.

Read More

Vanilla JS Browser Default Java Script.

Recent days many are discussing about Vanilla JS a ZERO KB framework, it is basically plain/default JavaScript like vanilla ice cream (default flavor) and it is not really a library or a framework. Nowadays JavaScript DOM methods has been improved a lot, it is very powerful in speed operations per second. So that you no need to use any external libraries like Jquery etc.. If you are working for simple mobile or web application, I suggest use following plain JavaScript scripts.

Read more »

Read More

Continuous deployment of Node, Express application on Azure using Github

Normally we deploy the projects on Azure using Visual Studio IDE, but Azure is not just limited to all Microsoft technologies specially when the majority of developers are on open source or moving to open source.

In this post I am going to provide you a very step by step process to deploy your Nodejs project having a source control on Github to Microsoft Azure cloud.

The basic things which you need to setup before you can start your deployment are as follows:

1. Nodejs : You can download Nojejs from here  https://nodejs.org/en/
2. Github repository account: First you need to setup a new account (if you don’t already have) in https://github.com/
3. Github for Desktop: I am using Github for windows to Commit and Push my changes to Github repository, but you can use other tools as well to push your files to Github. You can download from here: https://desktop.github.com/.
4. Microsoft Azure: If you don’t have Azure subscription you can signup for 1 month free trial. This will give you $200 credit to spend on all the Azure Services: You can visit this link to Signup for a month free service: https://azure.microsoft.com/en-us/pricing/free-trial/

You don’t need to have very advanced knowledge of Node, Github or Microsoft Azure to follow the steps I have covered here but I am assuming that you have at least basic knowledge of Nodejs, Github and Azure. Now Once you have all the required setup installed on your machine, lets get started with the basic steps which is required to deploy your Nodejs sample application on Azure using Github.

Step 1 Setup your environment: Create a working folder which you want to use for your application, and start Git Bash on your working directory. Alternately you can use windows command prompt. For this example I have created a folder in my local C drive as C:/Source/NodeOnAzureSample

If you already have your application which you want to deploy on Azure you can use that. For this example I am using express-generator to quickly create a sample application using Node, Express and Jade, I am using this just to save time and keep our focus on the actual topic.

Step 2 (Optional) Setup my demo project: This is a optional step if you already have your application ready. Here I am using the command “npm install express-generator -g” to generate my sample application template with a basic welcome page. You can find more detail of express-generator @ http://expressjs.com/starter/generator.html

This will create the sample files inside node modules globally in your C:/Users/YourUserName/AppData/Roaming/npm/express folder, or you can create the files in your local application folder by removing the –g from the command.

Now run “express NodeOnAzureSample” command, this is going to create all the required folders and files which you are going to start your development.

Step 3 (Optional) Restore the dependencies: Run “npm install”, this will restore all the dependencies like jade, express, etc which your application has dependencies.

Step 4 Test the application on localhost: After executing Step 1 to 3, we have our application ready to run on local machine, lets go ahead and test our sample application by switching to the application directory and run the command “npm start” in Git Bash (you can use powershell or windows command prompt) and enter “localhost:3000” in your browser. This should give you the following screen and your sample application is ready for hosting. Now in Next Steps I am going to configure my application with Github repository.

For simplicity sake and stick to the topic, I am not going to explain the folder structure, code, and other granular details of this sample application.

Step 5: Setup Github Repository @ Guthub.com Go to https://github.com/new and create a new repository, once you select all your desired options as shown in the image below. Click on the button “Create Repository”

You will be provided step by step information on the new repository which you have created,

Copy the URL, in your clipboard or notepad, you are going to need this URL during commit and push of your local application files to github repository at github.com online.

For this example my repository URL is : https://github.com/bmdayal/NodeOnAzureSample.git

Step 6: Setup Github Repository on you Desktop: Open Git Gui and Select Create new Repository from the menu which will ask you to locate your application directory, select the folder which you want to deploy to Azure. In my case I have mapped my “NodeOnAzureSample” application to Git repository.

Once you select create, Git GUI will list all the files which are either new or modified. Next step is you need to Stage Changed files, Commit and Sign Off, to perform these first you need to setup a new repository in https://github.com which I have already explained in Step 5 above.

Select “Stage changed” –> Sign Off –> Provide initial commit message –>Commit—>and Push.

Selecting Push is going to final commit your files to online github repository, to do this you will need the URL of your GitHub repository at github.com, and this will also prompt you to authenticate yourself.

Once your files successfully pushed to online repository, you will get a confirmation message as below.

Now that your files are ready for deployment, lets switch to Azure to configure continuous deployment.

Step  7 Configure Azure website: to do this you need to go to https://manage.windowsazure.com dashboard. Select Web Apps—>And select New from the footer menu.

This is going to provide you a wizard to create a new WEB APPS. For this example I am going to use Quick Create option to create my web application and named this as NodeOnAzureSample. If the name is available you will get a green check mark next to the name. This will provide you with a URL as https://nodeonazuresample.azurewebsites.net. Once you are happy with the name click on “Create Web App” button.

You can see the site is now listed in the WEB APP list and showing as Running, now click on the URL to test your web site @ http://nodeonazuresample.azurewebsites.net/.

This is going to provide you a welcome page of Azure Web site. In my nest steps I am going to replace the welcome page with actual application which we have created and pushed in Github.

Step 8 Configure deployment using Github: Select the Web App listed in the image above and Select Dashboard from the top menu.

From the dashboard, select Set up deployment from source control from right navigation menu.

You will be provided with a list of options, where you need to select GitHub, and select Next

You will need to authenticate yourself to GitHub where you have created your repository that needs to be deployed on Azure.

On successful authorization, you will be provided with the list of your applications which you have deployed on Github, for this example I have selected my “NodeOnAzureSample” application.

Select Done when you have made your selection, and this is pretty much what we need to do to link my Github repository to Azure website.

Deployment Stage 1

Deployment Stage 2: Notice you got a new menu called “Deployments” after Dashboard. Be patience, this might take few seconds to minutes depending upon the size of your application.

Deployment Stage 3: Deployment completed, you can see the initial comments which I had provided during my Commit to Github

Step 9 Testing your deployment on Azure website: Now that your application is deployed on Azure the next step is to test my application, yes no further configuration is required. Azure configures everything for you. Lets go to the WEB APP Dashboard and hit on the URL : nodeonazuresample.azurewebsites.net

Yes our application is ready and running on Azure

Step 10 Continuous deployment: To verify Continuous deployment. Go to your index.js, in NodeOnAzureSample/routes folder and change the text from “Express” to “Node, Express, Azure and Github”

Save the file, go to your Github Desktop—> Rescan—>Commit and Push the file with comment “Changed the welcome text from Express to Node, Express, Azure and Github”

Once you complete these steps, go back to your Azure dashboard. And probably by the time you switch back to your Azure your changes might have already been deployed to your website. Lets go ahead and verify.

And here we go, on my azure dashboard above I can see the latest changes are already deployed with the comment I have provided in my github commit.

Lets test this change in my browser by refreshing the page, and yes my changes are reflected below.

This is just a simple example of how the things are simplified in Microsoft Azure. This post will give a head start to integrate Node, Express, Github and Azure.

You can use any of your favorite open source like Angular, Knockout, Backbone, Jade, etc with your favorite source control like Visual Studio, GitHuib, Dropbox, Codeplex, etc and integrate with Microsoft Azure and above all you don’t need to be a Ninja on this technologies.

Happy Coding and Keep exploring

Read More

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

Read More