Meteor.js – Meteor and Reactivity


Real-time Features

A lot of Meteor’s strengths hail from its reactivity and real-time capabilities. We will look in to how these work while explaining how these real-time features can integrated with an API.

Reactive Templating

Reactive or declarative templating is a style of UI construction that contrasts the imperative approach in other words declarative templating communicates to and tells the computer how to do something and as a result what you want to happen will happen. The declarative approach however tells the computer what you want to happen and lets the computer figure out how to do it. Declarative templating separates the UI state, the underlying logical situation of what the user can see, from the layout being viewed (DOM). The user declares how the rendering technology should translate the state into the visual elements of the DOM. The state is then updated and the DOM adjusts accordingly.

Declarative Template Diagram
Declarative Template Diagram

A declarative rendering framework manages its complexity with an internal model of the core state of the page and this automatically changes the UI to reflect this model. To simplify this, what you see in your user interface or HTML markup will update itself automatically when our data is changed or edited.

Instead of waiting for a hard refresh our UI will reflect what has changed. The endless possibilities and ideas for real-time applications really become apparent once the functionality of declarative template is understood. Imagine all the possible data that we can extract from from an API. For example the Twitter Stream API.

Twitter Stream API

To install this open up your cmd window with Node.js installed

The Twitter Stream API returns a JSON object full of various different components of specified user’s Twitter timeline. Each different entity is stored in its own separate array.

Each additional object key in an entity is also stored in a nested array. The application has to iterate through various layers of nested arrays to retrieve the specified key of information that is to be displayed.

Twitter Stream API JSON object
Twitter Stream API JSON object

This depicts a sample Twitter Object that would typically contain keys holding different variables of a tweet own. In the next post I will be covering more detailed methods showing how to use the Twitter Stream API.

Asynchronous Tasks

A typical Meteor.js application’s sync design is based on a singular JavaScript framework. JavaScript is usually single threaded and can only handle one event handler at a time. In a single-threaded environment, only one section of code can be running at any one time.

Single threading incurs blocking or synchronous tasks which means the system has to await a particular task to be finished and is unable to perform other tasks while waiting for it.

An asynchronous task can be initiated and then put aside while another task is executed. This is the concept behind Meteor’s synchronizing and event design.

In an application the Twitter Stream API can be used to retrieve information from Twitter timelines.

For a typical JavaScript framework the request would be made to the API and then the system would have to wait until it made a callback. This is not the case with Meteor, due to asynchronous use of the event loops. When the API makes a callback , that task can be concentrated on again. In order for this to happen JavaScript generates an additional background thread which takes care of managing the tasks of the event loop in order to prioritize the API tasks only when it has made a callback to the server.

Here is sample diagram of a the realtime sync by Toptal

Toptal sync diagram
Toptal sync diagram
Live refresh

Since Meteor is based on the Node.js framework , the server at runtime is single threaded. As a whole,  Node.js usually has more asynchronous operations, calling APIs and reading and writing files. So a basic callback can consist of up to three nested functions while more complicated operations can contain even more levels and sub-levels of other callbacks.

This may initially sound complicated., However, Meteor simplifies this by using a fiber package to deal with the way callbacks are made in this regard. The fiber package solves the issue of excess callback functions by abstracting away the asynchronicity using the Fiber sub-library called Future.

Meteor’s server automatically detects changes to any applications codebase, so pushing the new code to the clients prompts the client to reload. Even after an application has been deployed changes can occur and automatically update the applications client via hot-code pushes.


This post contains key fundamentals that will be used in the implementation of a typical Meteor.js application. Its good to know some of these concepts about reactivity that work under the hood of the Meteor.js architecture.

This post also reflects how a typical application will be implemented using Meteor.js and its unique isomorphic API.  It is used to structure the code and provide a dynamic reactive coding environment, giving any application that you make fluid real-time capabilities.

It will also make it easier to maintain and enhance in any future phases of an application that you have created where additional functionality might be considered. The Mongo vs Minimongo relationship that a typical Meteor.js application contains, provides a foundation to easily store any retrieved object or entity from an API. While the reactive environment allows any changes to these objects to be reflected back into the user interface instantaneously.

In the next post we will look at a more detailed implementation of the Twitter Stream API.

Meteor.js Getting Started & Basic Principles


Previous Encounters

I first encountered Meteor.js before it had reached version 1.0. It’s site at the time looked like this.

Meteor website look before 1.0
Meteor before 1.0

Its growth in the last 2 years has been staggering. After the release of version 1.0 the site got a complete overhaul and turned into the red colored behemoth that it looks like now.

Metoer.js Installer Homepage
Metoer.js Installer Homepage
Meteor.js Community
Meteor.js Community
Why use Meteor.js
Why Meteor.js?

As jsdiaries is a similar red colored behemoth (not really) I thought I’d take time to look at Meteor.js now and highlight its key principles and foundations that it still adheres to. I hope to follow this post with a look at current state of Meteor and some of its newly added features.

Meteor.js’s seven principles

Data on the wire

Meteor doesn’t send HTML over the network. The server sends data and lets the client render it.

One Language

Only one language is used throughout the API so throughout the client and server side only

JavaScript is used everywhere. Even HTML and CSS files are translated into JavaScript for the client and server to read. This is significant when it comes to debugging an application.

Databases Everywhere

The same methods to access a database are used on the client and server side. This results in instantaneous call-backs to the data base from the client.

Latency Compensation

On the client Meteor preemptively fetches data and simulates models to appear that the server methods call return instantly.

Full Stack Reactivity

Real-time is the default in Meteor.js. All layers from the database to the template update themselves automatically when necessary.

Embrace the Ecosystem

Meteor is open source and integrates with existing open sources tools and frameworks. Additionally anything Meteor lacks can be a installed using Node.js. So instead of replacing tools and frameworks it integrates them.

Simplicity Equals Productivity

Meteor’s main functionality has clean, classically beautiful APIs. In other words the Client, Server and Database run on the one JavaScript API.

These seven principles give an element of structure to the Meteor platform. Its implementation of reactive programming enables the use of less code used overall. The platform itself is also a very initiative paradigm to create user interfaces due to its simplicity of its reactive update features.

So what exactly can we take from these principles? Well the most important thing to know is that Meteor reacts in real time because the Client and Server are in the same state and that they both only use JavaScript.

Installing Meteor.js

For Mac users open up your terminal and type:

This command single-handedly installs all of the following on a Meteor platform.


Neccesary NPM packages


For Windows users simply navigate to

And download the installer.

Among these features Meteor’s own reactive virtual DOM engine , Blaze, gets installed too. All these features being installed as well as a reactive template system already give the project some initial structure. Meteor adheres to no official files structure system. However a general consensus from Meteor users is to separate your JavaScript files into client and
server folders where each folder contains specific operations that should occur on the client or server side. At the time I began development using Meteor was not available to use on Windows machines. As of time of this writing Meteor 1.1 now fully supports Windows and MongoDB 3.0.


When I first started developing with Meteor.js I used a third party IDE called Nitrous. It was used for a project in order to work in an envi-environment that supports Meteor through a deployment box.  At the time Meteor did not support Windows and Nitrous was a cloud-based back end development platform. It contained an environment that replicates a Meteor directory running off a machine. It also has a web IDE and its own CMD alongside its directory.

At the time Nitrous proved to be a beneficial tool for building a Meteor.js application as it allowed the use of the applications directory across multiple platforms. However, Nitrous is now discontinued so your better off just downloading and install Meteor.js yourself through the command window or by downloading the installer for Windows but if you want to subscribe to any of their future open source projects they allow you to do so here:

Text Editors and IDE’s

There are also quite a few text editors that support Meteor.js intellisense. A developer looking for a development environment like this would be recommended to use some of the following.


It also comes down to personal taste such as styles of syntax highlighting, using the navigation, supported plugins etc. If you looking for an even more detailed introduction to this exciting framework you could check out either of these starter books.

In my next post we will dive into some of the more interesting parts of this framework.

Excellent Overviews of Meteor.js

Back in May of this year a post was realeased that informed of a compatibility update for Meteor 1.3 and associated study plan has been linked in one of Sascha Greif’s latest posts:

Latest blog updates