3 JavaScript Libraries to Keep an Eye on in 2015

Enjoy creating incredible things with JavaScript? You might like our course on how to Build Your First Meteor Application on our learning platform, Learnable.

As developers, we all know that our industry evolves at a very fast pace. So fast, indeed, that it’s often hard to keep up with all the new libraries, frameworks and new versions of the tools we use on a daily basis. Still, it’s important to stay as up to date as possible. Doing so ensures that we remain productive and in line with the expectations of our bosses and clients.

The new year started more than a month ago and some trends have already started to take shape. In this article, I’ll cover three libraries and frameworks worth keeping an eye on in 2015.



React.js, sometimes referred to as simply React, is a JavaScript library for creating user interfaces, and was created by a collaboration between Facebook and Instagram. Currently, it’s maintained by these two companies with the help of other developers, and it’s used by companies like Yahoo, Airbnb, Sony and (of course) Facebook and Instagram.

React.js isn’t a complete framework, so it doesn’t provide all the components you’ll find in other projects like Ember or AngularJS. It encourages the creation of reusable UI components, which present data that changes over time. Many people like to refer to React as the V in MVC. An important difference with frameworks like AngularJS – which uses a two-way data binding model – is that React features a one-way data binding model.

One of the most important concepts of this project is the virtual DOM. You can think of it as a set of elements that you can modify with your data and which, in the end, will modify the page’s real DOM. The virtual DOM is used for efficient re-rendering of the DOM by using a diff algorithm that only re-renders the components changed. This in turn enables the library to be ultra fast.

Another great feature is that it can also render on the server using Node.js. Therefore, you can use the same knowledge you’ve gained both on the client and on the server. This has major performance and SEO benefits. Many developers are using React.js to render a first, static version of the page on the server, which is faster than doing so on the client and is also SEO-friendly. Then they enable fast user interactions and UI updates by using React.js on the client side.

This is just a brief introduction to this library, and I really encourage you to learn more by visiting the React.js website. It contains a lot of useful tutorials that will help you in the learning process.



Meteor is an open-source JavaScript framework written on top of Node.js, that focuses on real-time web applications. It’s not very new, as it has already reached a stable version (1.0), but lately I’ve been seeing more and more people discussing and adopting it to create their applications.

One of the main pros of Meteor is that it brings the famous Java motto of “Write once, run everywhere” into the JavaScript world. Using Meteor, you write code that runs both on the client and on the server, and you can even turn your web app into a mobile application by using Cordova behind the scenes. This kind of application is referred to as an isomorphic application – meaning an application that can run both client-side and server-side. The backend and frontend share the same code. If you love the fact that you can turn a Meteor application into a mobile app, you may want to read the article A Beginners Guide to Mobile Development with Meteor by David Turnbull.

When you install the framework, you get everything you need to develop both the client and server sides of your application, so it’s really fast to get up and running. Meteor comes with its own CLI that allows you to speed up your workflow. It also allows you to create a demo application on your local machine by typing the following command:

meteor create --example todos

One of my favorite features of this framework is that it’s reactive, meaning that any change to your data is automatically reflected everywhere throughout the app without the need for callbacks. Besides, as I mentioned before, Meteor focuses on real-time applications. So changes made by you or by other users are instantly reflected in the UI.

If this introduction seems appealing to you, I suggest to visit the official Meteor website, or read the articles 7 Reasons to Develop Your Next Web App with Meteor and What You Need To Know About Meteor 1.0, both published here on SitePoint.


rendr logo

In recent months, I’ve been reading a lot about isomorphic applications, and Rendr is another library that employs this concept. It’s a small library developed by Airbnb that allows you to run Backbone.js applications on both the client and the server. The advantages are the same as mentioned in the React.js section: serving static and SEO-friendly HTML pages fast.

Being light-weight is one of the goals of this project. As mentioned in this article:

In true Backbone style, Rendr strives to be a library as opposed to a framework.

Rendr also tries to be agnostic about the environment by minimizing code like if (server) {…} else {…}, which is what you’ll find in frameworks like Meteor.

Unfortunately, I’m not aware of real-world applications built using this framework (apart from the one mentioned in the linked Airbnb post), so I’m not sure it’s mature enough to be used in production.


In this article, I’ve described three very interesting projects that are attracting a lot of attention and that are joining the fascinating trend towards isomorphic applications.

In recent weeks I’ve been playing with React.js, and I must confess that I’m loving it. I’m still in the process of learning this library, so I don’t have strong opinions on it yet, and I need to use it in a major project to test it properly. But if it can serve the Instagram user base, I’m sure it can perform reliably in small to medium applications. I do find it funny that, while Google isn’t using its own AngularJS for applications like Gmail, Facebook is adopting React in production.

Have you ever used one or more of these libraries and frameworks? If so, what was your experience with them? And if you haven’t used them, are you willing to give them a try?


In React JS the JSX syntax is based upon XML and looks overly verbose to me. I hope it doesnt catch on.
I've used meteor and it is fantastic. I can see this blowing AngularJS out of the water when the backend is built on Node, even though Angular has been widely adopted by industry. Meteor fills the obvious void of allowing you to define one model that's shared between client and server, making maintenance much easier.


Another library that should be put on the list is Vue.js. http://vuejs.org/

It is similar to AngularJS but much lighter and syntax is so simplified that makes AngularJS over complicated, but yet it is powerful enough to build any rich application very quickly.


Change.org actively uses and contributes to Rendr. I know this because I work there smile We get a lot of traffic and Rendr performs admirably. Its definitely faster than our Rails framework in serving the front-end. A newer version of Rendr just came out as well (v1.01) here https://github.com/rendrjs/rendr/ with full documentation.



until ES6 babel well be popular framework.


Is it possible integrate ZK with ReactJS?


IMO another interesting framework: http://neft.io .
It's sth different, because neft.io is a framework for a truly native apps (no webview) with a new language for styles in place of the CSS.


I've never heard of it but if a couple of really interesting frameworks to create native apps using JavaScript are React Native and NativeScript.


React it's really fast, but i hate the idea to mix the view with the logic of my app. We have been worked on the MVC pattern for years and React breaks this. For me doesn't make sense.

Let's see what AngularJS2 have to say on this fight.



I have the same feeling and that's why I'm not 100% sure React is a good thing.


Even though I'm a great fan of Meteor.js, I'm surprised as to how much focus there still is relatively low-level client libraries like React.js or Rendr, or even Ember.

You still have to create your own UI components with each of those, and bootstrapping a simple app is a pain.

I'm curious why there is so little coverage of UI components like Webix, which offer so much more out of the box. If you can build in 20 seconds the kind of UI the demo at http://webix.com shows, then why not?

BTW @AurelioDeRosa: Webix is surprisingly cool and would get you quite a bit of readership if you wrote about it. I've developed an integration between Meteor.js and Webix, and was surprised to see it get 160 stars on GitHub.


Hi Dan.

If you think that Webix is a topic people might be interested in and you're keen to write an article about it, we can discuss this possibility. What do you think?


React.js seems to break major principles that we all though was good. I though the same at first, and then I tried it. When you stick with the small re-usable components, it makes absolutely more sense to have the business logic with the view. It is so easy to work with React.js component. If you don't give it a shot just because it doesn't "feel right", you are missing on something great.


I collect technology product feature information and create trade-offs from it. Below is one such set of trade-offs between React and Meteor. Please take a moment and consider that the hapinstance of the dated blog posts one chooses to read and their ensuing threads may not be the most efficient way of bringing her to an adequate awareness of the differences between products.

My collection of technology feature information currently contains 27 frameworks, 46 tools, and 119 application starters for a total of (n1^2 + n2^2 + n3^2)/2 = 273,003 sets of trade-offs and it is constantly being updated. Under the current blog-post product informing system, that would be a whole lot of dated articles and ensuing comments to read and re-read.

It takes a community to keep this accurate. I do this in my free time and with the help of other volunteers. Please contribute your knowledge at the following link. If you understand Vue, ZK, Webix or any others feel free to complete questionnaires for them too. It will only take you a couple minutes and will save the development community years of research time and regret at making poor choices.

Meteor offers: 17% that ReactJS doesn't
* 0.7% Client-side queryable database
* 0.7% Supports IE8
* 0.7% Compatible with JQuery UI
* 0.7% Modules
* 0.7% CSS class renaming
* 0.7% State and state-modifying code in same place
* 0.7% Use multiple apps on the same page
* 0.7% Automatic js inclusion
* 0.7% Built-in package manager
* 0.7% Has no dependencies
* 0.7% Routing
* 0.7% Routing, convention-over-configuration
* 0.7% Object instance reusability, instances are passed automatically (doesn't need)
* 0.7% Object instance reusability, instances are saved to a common $scope
* 0.7% Auth integrated into routing
* 0.7% Observables for databinding a.k.a. KVO
* 0.7% Two-way data binding
* 0.7% Real time
* 0.7% Local data persistence
* 0.7% Computed properties
* 0.7% Prevents AJAX calls within controllers (doesn't need)
* 0.7% Safe from stored cross-site scripting (xss) attacks
* 0.7% Hotcode pushes
* 0.7% Bulit-in webserver
* 0.7% Command-line Interface
* 0.7% Automated deployment to app store


ReactJS offers: 5% that Meteor doesn't
* 0.7% Reusable components, using mixins
* 0.7% Hierarchical components
* 0.7% Uses inheritance
* 0.7% Virtual, shadow DOM
* 0.7% Single source of truth
* 0.7% Only changed list items are updated
* 0.7% Statically analyzable
* 0.7% Not too opinionated
* 0.7% Easy to test, html templates


webix == dhtmlx

I'm too use dhtmlx + meteor smile


Meteor has http://components.meteor.com.

No. Webix started out as fork of DHTMLX, but continued development under XB Software. See more in the Wikipedia page I created for it.


I would never consider using something like Ember / AngularJS. However React.js has def sparked interest. Being bound to a framework is less that ideal but having a modular libary with regards to UI is a neat idea.

Not ready to move over however I have started to use 'states' and restructure how we handle these plugins based on what they do in react.js Alexander Schepanovski explains the idea pretty well in this post:


AurelioDeRosa, Thanks for sharing this.

Really a great work !!!