7 Best JavaScript Frameworks of 2015

http://www.techaltair.com/7-best-javascript-frameworks-of-2015/

7 Best JavaScript Frameworks of 2015

June 24, 2015 By Nitish Singh Programming 9 Comments 

JavaScript is one of the most popular front-end languages and today, we will go through the best JavaScript Frameworks of 2015.

The language came into existence 20 years ago and was developed by Brendan Eich.

The need to manipulate the front-end pages gave rise to JavaScript. JavaScript is also popularly known as EMCAScript and the latest EMCAScript 6[standard] is implemented by Mozilla in their latest build.

JavaScript is used mainly as a prototyping scripting language, which offers dynamic typing as a key feature.

JavaScript has seen tons of improvement from the day it came into existence. It is no more limited to just frontend workings, node.js a framework capable of doing server side manipulations easily.

Overall, JavaScript is worked upon by tons of developers on the daily basis. The result? Tons and tons of useful JavaScript frameworks and libraries.

Brief History of JavaScript

JavScript came into existence in 1995, exactly 20 years ago from now. The man behind this beautiful scripting language was Brendan Eich, and there are three major corporations which foresee the development of JavaScript all these years are NetScape, Mozilla, and ECMA International.

JavScript frameworks are developed at a rapid pace and it showed tons of promise. The introduction of node.js enabled a complete application to be developed by JavaScript.

The major implementation of JavaScript is SpiderMonkey, V8, Chakra and others.

JavaScript or Java?

Whenever I write about JavaScript, I make sure to cover the difference or similarity between JavaScript and Java. Many beginners confuse JavaScript with Java, and they are not to be blamed for such confusions. The name “Java” in “JavaScript”, can easily confuse anyone.

So, why the name was chosen? The reason is completely market-oriented. At that time, Java was a popular programming language and to ride the popularity of Java, the team chosen the name, “JavaScript”.

Why use JavaScript Frameworks?

Using JavaScript frameworks can improve the rapid development of your web application. Creating a web application in pure JavaScript can be a great learning experience, but it not viable in the real-world scenario. To make use of the shorter and faster code, frameworks are used.

Rapid development, especially rapid prototyping is possible with the help of the JavaScript framework or library. For example, Angular.js is used to power single page web apps.

Most of the frameworks use MVC principle, but there are frameworks that use other principles such as MVP, MVVM, and others.

Difference between Frameworks and Libraries

The term frameworks and libraries can be confusing for many of us. The truth is that both of the terms are used interchangeably by the developers. But, there is a subtle difference between the two terms.

Frameworks, for example, provide better control over the functioning of the web application. The web application’s features and functions are inverted through the framework rules. The rules are pre-defined and help to improve performance over different platforms. On the other hand, libraries are a bunch of collective methods which can be used by the programmers and doesn’t come under any rules or regulations.

Frameworks offer more collection of libraries into a box, which is further refined by protocols of use.

Best JavaScript Frameworks of 2015

JavaScript Frameworks

1. Angular.js

Angular.js is the front-runner of the JavaScript frameworks, and is one of the most popular JavaScript frameworks out there.

Angular.js was released in 2009 by Google, and no one would have guessed that it will become so popular in the near future. Angular.js gives the power in the hands of the programmer and lets them build single page web apps.

The creation of single page web apps is aided by so-called directives. Directives help to add reusable code to the application and provides the necessary functionalities to add dynamic functionalities to the web application. DOM manipulation is easy, and you can easily add behavior and CSS to the HTML DOM elements.

Visit Official Website

2. Backbone.js

Backbone.js is minimalistic JavaScript frameworks that aim to provide the necessary backbone to a web application. The framework is open source in nature and is available under the MIT license.

Backbone.js is extremely popular framework can act as the base of a complex web project easily. It provides tools such as model building using key-value binding, tons of enumerable objects with usable API and much more.

With the core of the web application set, you can use other frameworks on top of it. The main feature of Backbone.js is its ability to be used in other big projects. The small size also helps the cause and brings the right mix of performance and functionality.

Visit Official Website

3. React.js

React.js is one of the most popular front-end JavaScript framework.

Why Front-end? Becuase it can easily used to create the UI part of your project. In simple words, it acts as the V in MVC. The magic is achieved by using a virtual DOM and it can also be rendered on the server side with the help of the node.js.

The front-end component can easily be made interactive with React.js and big companies such as Facebook and Instagram use it to their advantage.

With only 2 years of age, the framework is making news already and can be your UI framework for creating interactive and powerful web application.

Visit Official Website

4. Meteor.js

Meteor.js is the JavaScript framework that many JavaScript developers will vouch for. The framework is famous for one big reason and that is the ability to create full end-to-end web applications with it.

There is no need to use any other library or JavaScript framework and from its inception in 2012, it has gained a lot of popularity and community.

The community continuously improves the framework by contributing to the core of the application. Another reason for its success is its modular design, which enables developers and contributors to tickle through different sections of the framework.

The framework can be used to create real-time web applications with emphasis to almost all the phases of development including backend, frontend, database and business logic.

Visit Official Website

5. Ember.js

Ember.js is yet another popular JavaScript framework. It is mainly used to create complex web applications. It uses the MVC principle.

With 3 years of development, it uses two main mechanics to pull up things. The first being the two-way binding method that Angular.js uses. The two-way binding method makes sure that nothing goes out of sync. In short, if there is a change in the view, then the equivalent change will be reflected in the model and vice-versa.

Another module that makes Ember.js irresistible is the fastboot.js module. The fastboot.js module works similar to react.js ability to render DOM on the server side. This way, complex UI can easily be rendered on the server side, and served to the client side for fast rendering.

These two major features really brings the power to the Ember.js applications. Scalability is less of an issue, and you can easily get the most out from the framework. It is also easy to learn and there are tons of learning material available online.

Visit Official Website

6. Polymer.js

Polymer.js is new and is released by Google in the year 2013. The framework offers web components — the ability to create them and extend the already existing HTML web components.

In 2015, they released a stable production ready 1.0. It is not as popular as other frameworks, but surely useful for many projects out there.

Visit Official Website

7. Aurelia.js

With only 5 months of age, Aurelia is the new kid on the blog. With a professional team backing up the project, the framework production version is already out.

The framework takes the hints from Angular 1 or 2 and uses them to create something power we have not seen. The architectural design is also modular and offers great control over the framework.

Surely, a framework to watch out in 2015.

Visit Official website

Wrap Up

Today, we listed the 7 Best JavaScript frameworks. These frameworks offer both functionality and agility. Each of the frameworks has their own place in the industry and it depends on the project requirements. There is a lot of add to each of these frameworks, but I will cut it short and let you decide for yourself the framework best for your project.

Do you think, I missed something? Comment below and let us know!

Is Angular.js or Ember.js the better choice for JavaScript frameworks?

https://www.quora.com/Is-Angular-js-or-Ember-js-the-better-choice-for-JavaScript-frameworks

As one of the authors of Ember.js, I frequently get asked: "Should I use Angular or Ember?"

I think the answer to that question has a lot more to do with what kind of application are you building? than is Ember better than Angular?

While there are a few superficial similarities—they both use bindings and are more helpful for writing web applications than, for example, Backbone.js—they quickly depart from one another in how they expect you to approach building apps.

Let me first discuss the inspiration for Ember.js. Starting in 2009, I worked on SproutCore while at Apple, in addition to contributing to the suite of web applications that became what you now see on iCloud. In that environment, I was surrounded by some of the best Cocoa developers in the world.

Now, here's the thing about client-side web applications: they're not really breaking new ground. The fundamental model has been around since the 80's: code running locally on a computer, fetching data from the network, and then rendering it locally and putting it on screen. Really, the only thing that's changed is that the code is running inside the sandboxed environment of the browser, and the "binary" is loaded as you need it instead of being installed by the user onto their hard drive.

To me, the obvious thing to do is to look around and ask: What have the people who have come before us done? And I think it's hard to argue with the success of frameworks like Cocoa, both on the Mac and on iOS, in aiding developers in writing apps that users love.

We want developers to be able to build ambitious web apps that are competitive with those native apps. To do that, they need both sophisticated tools and the right vocabulary of concepts to help them communicate and collaborate.

With Ember.js, we've spent a lot of time borrowing liberally from concepts introduced by native application frameworks like Cocoa. When we felt those concepts were more hindrance than help—or didn't fit within the unique constraints of the web—we turned to other popular open source projects like Ruby on Rails and Backbone.js for inspiration.

Ember.js, therefore, is a synthesis of the powerful tools of our native forebears with the lightweight sensibilities of the modern web. 

Now, Angular: I actually really like Angular, Google, and all of the developers I've met on the Angular team. In fact, we had once discussed how we might unite our efforts, but—excuse my French—the synergy just wasn't there.

Angular, in my opinion, is much more of a research project than Ember.js. Just look at the terminology: Ember talks about models, views, and controllers. Angular's guide requires you to learn about things like scopes, directives and transclusion.

I am all in favor of research projects, and I wish them the best. But, as Jeremy Ashkenas always says, look at the apps in production.

Big companies have invested serious time and energy in Ember.js, and the results speak for themselves. The new version of ZenDesk has been rewritten in Ember (after they got frustrated with Backbone.js and moved off it). The entire web experience at Square is Ember, because they wanted a beautiful and responsive UI on the web and institutionally know that those can be delivered using concepts borrowed from Cocoa. Many of Groupon's mobile web apps are Ember.js. There are many, many more startups finding success with Ember.js, and in turn, contributing to it and helping grow the community.

The majority of apps that I've seen written in Angular are demos or internal Google properties.

Yehuda and I have been extremely aggressive about getting real users of Ember involved in the design and maintenance of the framework. This keeps us honest and makes sure features we add are not things we think are neat but are driven by real problems developers are hitting today.

In fact, for the past few months, the majority of the work on Ember.js proper has been done by a core group of community contributors, from different companies. If Yehuda and I got hit by a bus tomorrow, Ember would be fine. If our company went under, Ember would be fine. By making this a truly community project, instead of a "by Google" project, I believe we get an order of magnitude more man-hours contributed to it.

Back to technical details. From their own website, "AngularJS is what HTML would have been, had it been designed for building web-apps." I think that that philosophy is evident when looking at their apps. The user interface is defined by HTML tags, decorated with attributes (like `data-ng-repeat`) that have semantic meaning.

Ember.js uses Handlebars to describe the HTML that makes up your application interface. Now, aesthetically, we can argue whether you prefer Handlebars syntax (which uses, for example, the 

{{#each}}

 helper) or annotating HTML with additional attributes like Angular does. I personally think that the HTML attribute approach is a little noisier and hard to read, but I think that anyone can get used to either one. If Ember.js didn't exist and I had to use a framework that uses data attributes, I wouldn't cry.

But leaving aesthetics aside, I believe that our approach to using string-based templates gives us several advantages, both now and in the future:

• String-based templates can be pre-compiled on the server. This signficantly reduces startup time (because there is effectively no computation required at app boot) and means that rendering a template is as simple as invoking a function.
• Angular requires you to traverse the entire DOM at app boot time. The bigger your app is, the slower it starts.
• If you ever want to render your app on the server (for indexing by Google crawlers or to make first loads display faster), Angular requires you to boot an entire browser environment like PhantomJS, which is resource-intensive. Handlebars is 100% JavaScript strings so all you need is something like node.js or Rhino.
• String templates are easy to divide up and load lazily, if your app starts getting large.

Additionally, Handlebars only lets you bind to properties, while Angular allows you to embed arbitrary expressions that live update. Many people initially see this as a limitation of Ember, but in fact:

• Ember.js makes it extremely easy to create computed properties in JavaScript, which can contain arbitrary expressions. We just require you to specify your dependencies so that we can be smart about when we update. Only things that change are updated.
• Angular must recompute those expressions every time something changes, which means the more bound elements in your app, the slower it gets.
• Because Ember.js only allows you to bind to properties, we will very easily be able to take advantage of the performance benefits of ECMAScript 6 features like Object.observes (http://wiki.ecmascript.org/doku....). Because Angular invented their own subset of JavaScript with a custom parser (https://github.com/angular/angul...), it would be difficult to allow browsers to optimize this in native code.

Angular, in general, relies on something called dirty checking to determine when changes have been made. Dirty checking is when you scan each object and all of its bound properties, comparing the current value to the last known value. If it changes, you go update the binding. As you can imagine, this gets very expensive the more objects you have.

The Angular guys are smart and they made this tradeoff very carefully. Their reasoning is:

• With dirty checking, you don't need to use accessors. You can say 

  person.name = "Bill"

   instead of 

  person.set('name', "Bill")

   like you would in Ember.js or Backbone.js.
• Why would you ever have so many objects in DOM that this would end up becoming a bottleneck?

Needless to say, we made the opposite decision. Miško Hevery describes the tradeoffs they made on StackOverflow: http://stackoverflow.com/a/96939....

He points out, with dirty checking, that you can never have more than 2000 bound objects at a time. (Note that only one of his three "issues with change listeners" applies to Ember.js, because of our run loop.)

I think that this illustrates best the difference in philosophies between Ember.js and Angular. Ember.js and Angular both strive for simplicity and ease-of-use. But Ember is designed so you don't have to worry about whether or not you have 2000 bindings. If you're writing large-scale apps, you've got bigger things to worry about.

Angular is great for small- to intermediate-scale applications that will never run into the limitations of their architecture. With Ember, we sometimes ask you to do a little more work—like specifying the dependencies of your computed properties—in order to make the most common operations run at O(1) instead of O(n), or worse.

We're always looking to take advantage of new browser and language features to make things easier to use. For example, once proxies land in ES6 (http://wiki.ecmascript.org/doku....), we won't require you to use 

get()

 and 

set()

 any longer. But we're not willing to give you a little bit of rope if we think you'll just end up hanging yourself with it as your app grows.

So that's why I think, if you're building ambitious apps, you should pick Ember.js.

We're not afraid to borrow liberally from our predecessors that have already learned how best to build large apps.

We've got a fantastic community that has some of the smartest web developers working on the hardest problems, and they're doing it because they're hitting those hard problems in the real world and they want to solve it correctly.

We've thought very long and very hard about performance, how to make sure your applications don't hit pathological cases, and how to best take advantage of the features coming in the language. (Yehuda Katz, who works on Ember.js with me, is also on on TC39, the committee in charge of coming up with the next version of JavaScript.)

We've now locked down the 1.0 API, so you can start learning and not worry about the ground changing from under your feet.

To really get a feel for Ember, here's a screencast I put together of building an app from scratch:

There are also some great resources for learning:

• Ember.js Guides
• Rey Bango's Getting Into Ember.js tutorial
• Slides from Luke Melia's talk Introduction to Ember.js at the Ember NYC meetup

If you're building ambitious apps, you should definitely check out Ember.js.

Angular, Ember, And Backbone: Which JavaScript Framework Is Right For You?

http://readwrite.com/2014/02/06/angular-backbone-ember-best-javascript-framework-for-you


You've got the perfect idea for a JavaScript-based application or website. Now all you have to do is pick the right open source framework.

If you’re reading this, I’m assuming that you’re a beginner or novice developer, or else you’re hiring somebody else to develop your idea for you. But while you’ve probably heard the words Angular, Ember, and Backbone, you might not know what they are, or why they help web development.

Developers use JavaScript for lots of different Web applications because it can really make the client side—that is, the user’s side—look and work beautifully. But while it may not look old, the JavaScript language has been around for nearly 20 years, and it has the variety and vastness to prove it. If you keep adding more and more (see: redundant) code to make it work in multiple browsers and use cases, it can quickly become a big, confusing mess.

Enter JavaScript frameworks. Frameworks like Angular, Backbone, and Ember bring structure to your JavaScript code and keep it organized. They’re all open source, so they’re constantly being improved by the community. They also save you time because they’re each built on top of JQuery, a powerful library that makes some of JavaScript's tricker operations easier to perform and more readable.


See also: How To Build A WinJS App In 10 Easy Steps

Here's an example of how referencing JQuery might enhance the coding process: Instead of writing the tedious lines of code to generate a table, you could insert a reference to a JavaScript library that generates the table with just one line of code. Even better, these shortcuts don’t just help you work faster, they make your code work in multiple environments, too.

However, picking your JavaScript framework isn’t like picking between three different-colored T-shirts. In fact, it’s more like choosing between three completely different articles of clothing: Each piece helps to cover you, but they all function and look very differently. Carrying the metaphor even further, you wouldn’t wear a bathing suit in a cold climate, or a winter coat at the beach. Likewise, different JavaScript frameworks are better for different types of applications.
Advertisement — Continue reading below





Here is a rundown of each of the three hottest frameworks, and what they’re best for:
AngularJS



Initially released in 2009, AngularJSis the oldest of the three frameworks. Probably as a result, it also has the largest community.

In 2013, Angular had the fourth-largest number of contributors and third-largest number of stars (kind of like Facebook “Likes”) on GitHub. OnBuilt With AngularJS, you can check out all of the applications currently being developed with Angular.

Some of the most well-known companies that credit AngularJS as the JavaScript framework include Google and Nike. Beginning in August 2013, General Motors cars feature applications that were built in Angular. You’ll also notice a lot of news sites using AngularJS on their front pages, like theGuardian, the Huffington Post, and MSNBC.

According to Igor Minar, lead developer on AngularJS at Google, it’s more about Angular’s adaptability than anything to do with the news.

“I don't think that Angular is more suitable for news sites than for other sites and apps. But there definitely is a bunch of them,” Minar said. “I think it's just that these are high-visibility sites maintained by companies in highly-competitive market which means they keep their technology stack fresh in order to be efficient at making changes and providing great user experience.”

Why are sites that use Angular good at making quick changes? Probably because Angular, more aggressively than any other framework, nudges developers to create easily testable code and test it often. Though some developers might find this guidance annoying, it pays off in catching little coding errors before they have a chance to become big ones.

Another peculiarity of Angular is that it has a lot of its own terms and jargon. Minar thinks this is because the framework includes some features no other JavaScript solution does.

“Some terms we use commonly are specific to Angular and might come across as jargon or strange,” he said. “The good news is that the web standards are catching up and giving ‘official’ names to some of these concepts."

If you code with Angular, you’re coding on Angular’s rigid terms, but Google Trends points to that not being such a bad thing. You’ll have to use Angular’s jargon and it might take time to make your code more testable, but the result is adaptability later on.
Backbone.js



Backbone came out in June 2010, and its community is nearly as large as Angular’s.

Many popular applications use the Backbone framework, including Twitter, Foursquare, and LinkedIn Mobile. Also worth noting is that a number of music apps were built with Backbone, including Soundcloud, Pitchfork, and Pandora.

However, there’s something about Backbone that’s very, very small compared to other frameworks—and that’s its download size. Compressed and minified, AngularJS is about 36K; the Ember starter kit is even bigger, at 69K. But Backbone, compared to its contemporaries, is downright puny, at just 6.4K.

Backbone’s diminutive size is typically its biggest selling point, since it only depends on one JavaScript library instead of several. As a result, Backbone is extremely lightweight, which means it’s good for building fast and responsive applications—but it’s most effective if those web applications are themselves small and single-page, or better yet, only part of a page, like many of the music apps using Backbone right now.

Here's another characteristic that makes Backbone special: Its framework is remarkably hands-off, or as some developers put it, Backbone doesn’t “hold your hand.” This means experienced JavaScript developers can quickly get started, but less experienced developers might find themselves writing a lot of “boilerplate,” or repetitive code.

According to Backbone creator Jeremy Ashkenas, concerns about needless boilerplate coding are “a silly marketing campaign.”

“If you're writing a lot of ‘boilerplate’ code in Backbone, then you don't know how to use it,” Ashkenas said. “In general, in programming, if you're writing the same thing over and over again—you write a function to do it automatically for you.”
Advertisement — Continue reading below





If you’re having trouble, however, Backbone has an especially active community rife with free tutorials for getting started with the framework. Plenty of developers have taken to GitHub to upload useful examples and how-tos that take the place of other frameworks’ hand-holding.

If you’re working on a single-page application or widget—and you’re comfortable with being a self-starter—Backbone is likely the lightweight framework for you.
Ember.js



Ember is the newest kid on the block, but it’s already making waves. Initially released in 2011, Ember just hit version 1.0 last year. It also recently become Code School’s latest course, and given that Code School already offers courses for Angular and Backbone, it’s likely the newest course will grow to become equally popular.

LivingSocial, Groupon, Zendesk, Discourse, and Square are some of the most well-known applications that have adopted Ember. Ember creators Tom Dale and Yehuda Katz say it’s easy to see when a site is using Ember because of its loading speed.

“They feel like normal websites, they’re just far faster than what you’re used to,” Dale said. “It’s because all the rendering happens in the browser. It may look like a regular website, but under the hood, it’s architected like an iOS or Android app that isn’t being rendered by the server.”

At 69K minified and zipped, Ember is the largest framework of the three, but Katz points out that often medium-sized jpegs are just as large.

“The reason I feel confident that the features we’re baking in are things you need anyway is because I frequently look at the compiled size of Ember apps alongside other apps in the wild, and they’re all roughly the same size,” said Katz, implying that developers who use other frameworks often download additional libraries and tools during the building process.

Ember’s larger library size partly explains why it's the largest download of the three Javascript frameworks, but another reason is because Ember comes with a lot of built-in support for standard code features. If you’ve ever tried to click the “back” button on a website only to get no response, you know all about what happens when JavaScript applications break. Ember’s support features are there to keep small but annoying errors like those from happening.


See also: The Three Most Heated Debates In Git

Ember’s library size and support network are its two greatest strengths, but if you’re only trying to create a small widget or single-page app, it might be overkill for you. If you’re working on a multipage, navigational, long-term project, Ember might be your pick.

When developers discuss these three frameworks online among their contemporaries, the discussion often devolves into one of personal preference. But from a non-developer perspective, it's clear that different applications—and different needs—make each framework shine its brightest.

Images by Madeleine Weiss for ReadWrite
TAGS ANGULARBACKBONEJAVASCRIPTJAVASCRIPT FRAMEWORKSBEST JAVASCRIPT FRAMEWORKEMBERJQUERY

BY LAUREN ORSINI
Twitter Website

getting-to-know-flux-the-react-js-architecture

https://scotch.io/tutorials/getting-to-know-flux-the-react-js-architecture

Introduction

Welcome to the third installment of the Learning React series. Today we will be learning about how Facebook’s Flux Architecture works, and how to use it in your own projects!

If you haven’t already, I strongly recommend you check out the first two installments in this series, Getting Started & Concepts and Building a Real Time Twitter Stream with Node and React. They aren’t a hard prerequisite, but will certainly help you understand this article if you don’t already have familiarity with React.js.

What is Flux?

Flux is an architecture that Facebook uses internally when working with React. It isnot a framework or a library. It is simply a new kind of architecture that complements React and the concept of Unidirectional Data Flow.

That said, Facebook does provide a repo that includes a Dispatcher library. The dispatcher is a sort of global pub/sub handler that broadcasts payloads to registered callbacks.

A typical Flux architecture will leverage this Dispatcher library, along with NodeJS’s EventEmitter module in order to set up an event system that helps manage an applications state.

Flux is probably better explained by explaining its individual components:

• Actions – Helper methods that facilitate passing data to the Dispatcher
• Dispatcher – Receives actions and broadcasts payloads to registered callbacks
• Stores – Containers for application state & logic that have callbacks registered to the dispatcher
• Controller Views – React Components that grab the state from Stores and pass it down via props to child components.

Lets take a look at what this process looks like graphically:

How does the API relate to this?

When you are working with data that is coming from (or going to) the outside, I’ve found that using Actions to introduce the data into the Flux Flow, and subsequently Stores, is the most painless way to go about it.

The Dispatcher

So what’s this Dispatcher all about?

The Dispatcher is basically the manager of this entire process. It is the central hub for your application. The dispatcher receives actions and dispatches the actions and data to registered callbacks.

So it’s essentially pub/sub?

Not exactly. The dispatcher broadcasts the payload to ALL of its registered callbacks, and includes functionality that allows you to invoke the callbacks in a specific order, even waiting for updates before proceeding. There is only ever onedispatcher, and it acts as the central hub within your application.

Check out what one looks like below:

var Dispatcher = require('flux').Dispatcher;
var AppDispatcher = new Dispatcher();

AppDispatcher.handleViewAction = function(action) {
  this.dispatch({
    source: 'VIEW_ACTION',
    action: action
  });
}

module.exports = AppDispatcher;

In the above example, we create an instance of our Dispatcher and create a handleViewAction method. This abstraction is helpful if you are looking to distinguish between view triggered actions v.s. server/API triggered actions.

Our method calls the dispatch method, which will broadcast the action payload to all of its registered callbacks. This action can then be acted upon within Stores, and will result in a state update.

The diagram below illustrates this process:

Dependencies

One of the coolest parts of the provided Dispatcher module is the ability to define dependencies and marshall the callbacks on our Stores. So if one part of your application is dependent upon another part being updated first, in order to render properly, the Dispatcher’s waitFor method will be mighty useful.

In order to utilize this feature, we need to store the return value of the Dispatcher’s registration method on our Store as dispatcherIndex, as shown below:

ShoeStore.dispatcherIndex = AppDispatcher.register(function(payload) {

});

Then in our Store, when handling a dispatched action, we can use the Dispatcher’swaitFor method to ensure our ShoeStore has been updated:

case 'BUY_SHOES':
  AppDispatcher.waitFor([
    ShoeStore.dispatcherIndex
  ], function() {
    CheckoutStore.purchaseShoes(ShoeStore.getSelectedShoes());
  });
  break;

Stores

In Flux, Stores manage application state for a particular domain within your application. From a high level, this basically means that per app section, stores manage the data, data retrieval methods and dispatcher callbacks.

Lets take a look at a basic Store:

var AppDispatcher = require('../dispatcher/AppDispatcher');
var ShoeConstants = require('../constants/ShoeConstants');
var EventEmitter = require('events').EventEmitter;
var merge = require('react/lib/merge');

// Internal object of shoes
var _shoes = {};

// Method to load shoes from action data
function loadShoes(data) {
  _shoes = data.shoes;
}

// Merge our store with Node's Event Emitter
var ShoeStore = merge(EventEmitter.prototype, {

  // Returns all shoes
  getShoes: function() {
    return _shoes;
  },

  emitChange: function() {
    this.emit('change');
  },

  addChangeListener: function(callback) {
    this.on('change', callback);
  },

  removeChangeListener: function(callback) {
    this.removeListener('change', callback);
  }

});

// Register dispatcher callback
AppDispatcher.register(function(payload) {
  var action = payload.action;
  var text;
  // Define what to do for certain actions
  switch(action.actionType) {
    case ShoeConstants.LOAD_SHOES:
      // Call internal method based upon dispatched action
      loadShoes(action.data);
      break;

    default:
      return true;
  }
  
  // If action was acted upon, emit change event
  ShoeStore.emitChange();

  return true;

});

module.exports = ShoeStore;

The most important thing we did above is to extend our store with NodeJS’sEventEmitter. This allows our stores to listen/broadcast events. This allows our Views/Components to update based upon those events. Because our Controller View listens to our Stores, leveraging this to emit change events will let our Controller View know that our application state has changed and its time to retrieve the state to keep things fresh.

We also registered a callback with our AppDispatcher using its register method. This means that our Store is now listening to AppDispatcher broadcasts. Our switch statement determines whether, for a given broadcast, if there are any relevant actions to take. If a relevant action is taken, a change event is emitted, and views that are listening for this event update their states.

Our public method getShoes is used by our Controller View to retrieve all of the shoes in our _shoes object and use that data in our components state. While this is a simple example, complicated logic can be put here instead of our views and helps keep things tidy.

Action Creators & Actions

Action Creators are collections of methods that are called within views (or anywhere else for that matter) to send actions to the Dispatcher. Actions are the actual payloads that are delivered via the dispatcher.

The way Facebook uses them, action type constants are used to define what action should take place, and are sent along with action data. Inside of registered callbacks, these actions can now be handled according to their action type, and methods can be called with action data as the arguments.

Lets check out a constants definition:

var keyMirror = require('react/lib/keyMirror');

module.exports = keyMirror({
  LOAD_SHOES: null
});

Above we use React’s keyMirror library to, yup you guessed it, mirror our keys so that our value matches our key definition. Just by looking at this file, we can tell that our app loads shoes. The use of constants helps keep things organized, and helps give a high level view of what the app actually does.

Now lets take a look at the corresponding Action Creator definition:

var AppDispatcher = require('../dispatcher/AppDispatcher');
var ShoeStoreConstants = require('../constants/ShoeStoreConstants');

var ShoeStoreActions = {

  loadShoes: function(data) {
    AppDispatcher.handleAction({
      actionType: ShoeStoreConstants.LOAD_SHOES,
      data: data
    })
  }

};

module.exports = ShoeStoreActions;

In our example above, we created a method on our ShoeStoreActions object that calls our dispatcher with the data we provided. We can now import this actions file into our view or API, and call ShoeStoreActions.loadShoes(ourData) to send our payload to the Dispatcher, which will broadcast it. Then the ShoeStore will “hear” that event and call a method thats loads up some shoes!

Controller Views

Controller views are really just React components that listen to change events and retrieve Application state from Stores. They then pass that data down to their child components via props.

Here is what this looks like:

/** @jsx React.DOM */

var React = require('react');
var ShoesStore = require('../stores/ShoeStore');

// Method to retrieve application state from store
function getAppState() {
  return {
    shoes: ShoeStore.getShoes()
  };
}

// Create our component class
var ShoeStoreApp = React.createClass({

  // Use getAppState method to set initial state
  getInitialState: function() {
    return getAppState();
  },
  
  // Listen for changes
  componentDidMount: function() {
    ShoeStore.addChangeListener(this._onChange);
  },

  // Unbind change listener
  componentWillUnmount: function() {
    ShoesStore.removeChangeListener(this._onChange);
  },

  render: function() {
    return (
      <ShoeStore shoes={this.state.shoes} />
    );
  },
  
  // Update view state when change event is received
  _onChange: function() {
    this.setState(getAppState());
  }

});

module.exports = ShoeStoreApp;

In the example above, we listen for change events using addChangeListener, and update our application state when the event is received.

Our application state data is held in our Stores, so we use the public methods on the Stores to retrieve that data and then set our application state.

Putting It All Together

Now that we have gone through each individual part of the Flux architecture, we should have a much better idea of how this architecture actually works. Remember our graphical representation of this process from before? Lets have a look at a bit more granular view of this, now that we understand the function of each part of the flow:

Wrap Up

After reading this article, I hope that if you didn’t “get” Facebook’s Flux Architecture before, that now you can say you do. It wasn’t until building something with it that I understood how complimentary to React.js it actually is.

After you use Flux the first time, writing React without Flux feels like DOM traversal without jQuery. You can absolutely do it, but it feels less elegant and structured.

If you want to use the Flux architecture, but you don’t want to use React, check outDelorean, a Flux framework that you can use with Ractive.js or Flight. Another library worth looking at is Fluxxor, which takes a different approach to Flux architecture and provides a tighter coupling of Flux’s components into a central Flux instance.

Again, I believe that to truly understand Flux, you actually have to use it, so stay tuned for the 4th and final installment of Learning React where we will be building a shopping cart with React.js and Flux Architecture!

GETTING STARTED WITH FACEBOOK’S REACT.JS

1	Learning React.js: Getting Started and Concepts	Read
2	Getting To Know Flux, the React.js Architecture	Read
3	Creating A Simple Shopping Cart with React.js and Flux	Read
4	Build A Real-Time Twitter Stream with Node and React.js	Read
5	Make a Mobile App with ReactJS in 30 Minutes	Read