Introduction – JavaScript

We have arrived at a place where most of the work in the browser is now handled on at the client-side, and the back-end now serves as a data endpoint (JSON/XML). We have routers, databases, templates, and all the other jazz, working in the browser. Everything is fast and interactive. We are moving towards Single Page Applications that persist state, via the URI or in data storages (local or on server). This is all thanks to the world’s most loved (and hated) language, JavaScript. Even with a fair share of “Bad Parts”, JavaScript has prevailed. There have been several additions in the current stable version EcmaScript 5 which added a lot of syntactic sugar, and with the upcoming EcmaScript 6 release JavaScript has become a full-fledged Object Oriented language which until now was taunted as a Prototypal language acting as a faux OO language.

We have seen the release of hundreds of client-side frameworks – Angular, Ember, and Backbone being the popular ones. Backbone has even made into the Drupal 8 core, which speaks volumes about the requirements and use-cases of these frameworks. Thanks to the efforts of JavaScript overlord Ryan Dahl, JavaScript has been available as a server side language for a few years now. Going by the sheer number of contributions per quarter, Node.js has seen the fastest growth in the Open-Source community, as compared to the other big players like Ruby, Python, PHP or Java, a figure that is exponentially larger than any other.

The Front-end community has also witnessed a boom in the tooling landscape, something that was almost negligible until the arrival of Node.js. Now, we have build tools, dependency managers, scaffold generators and a lot more, resulting in a huge productivity boost for developers. A lot more can now be worked upon and achieved, without having to lose sanity over mundane and repetitive tasks like compiling, minifying, linting, or analyzing. Unlike other languages and stacks, JavaScript can be run on all fronts: Browser, Server and Database, thus lowering the entry barrier by several folds – there is no shift in context, as you will be writing JavaScript everywhere. Additionally, JavaScript can work with any server-side language or database.


One of the most unique and exciting frameworks out there on the web right now, Meteor is built on top of Node.js. Everything, right from the templates to the database is reactive, so any change at the client-side, or in the database is synchronized instantaneously, requiring no other measures. Meteor has quickly amassed a strong and extremely helpful community, creating a platform that you would love to build on, and give back to. Unlike other frameworks, there are no concepts of MVC or middleware (although you can implement them if it suits you). Everything is based on seven principles that act as guiding principles for the core, and the apps built upon it. One of them is close to my heart:

Embrace the Ecosystem
Meteor is open source and thus integrates, rather than replacing existing open source tools and frameworks.

One can use Meteor with build tools like Grunt, Gulp or Broccoli for various tasks, but the upside to Meteor is that it compiles, minifies and concatenates all assets into a single file on its own. Dependencies are managed, depending on the directory structure. For example, content inside the /lib directory is loaded first and files named ‘main.*’ are loaded last. Another important feature of Meteor is that you can share libraries between the server and client, so if a date-time formatting library like Moment.js is present, it can be used to convert UNIX epoch date-time stamps to human readable formats in the browser, rendering them from view-templates, or on the server before it gets stored in the database.

Case Study

Following Write Code Every Day, I ended up working on an application to create markdown files last weekend. In the beginning, I used a MEAN stack, but later ended up switching to Meteor. The project was something that I created for personal use but ended up opening it for everyone. Similar to every other Meteor project that I have worked on, I was able to scaffold a prototype in a couple of hours, and was able to invest the rest of the time into refining the user experience, and adding features here and there.

Introducing Writ

JavaScript And Future Development Landscape - 1 - Introducing Writ Javascript - Axelerant

Introducing Writ Javascript

Writ is an application to create notes in Markdown, with live previews on the side. You can store your notes in the databases and access from anywhere. Changes are reactive, and if you update a note on one device the same note, open on a different device, is updated without making any requests. Writ is built upon several packages that Meteor ships with, along with a few third party ones via Atmosphere.js, a few custom helper modules, and Handlebars helpers.

JavaScript And Future Development Landscape - 2 - JavaScript : Meteor - Axelerant

JavaScript : Meteor

This post was written in Writ. Dogfooding.

As with any other single page application, there was a slight delay in the initial page load for Writ. When a SPA site loads for the first time, templates are rendered at the client side, subscribing to database collection, parsing, and running scripts and styles. This a lot of work, leading to a slow application boot. However thanks to some awesome work on part of the Meteor community, two packages – Fast Render & Iron-Router – come in handy in reducing the page load time exponentially.

Fast Render by @arunoda sends just the data that you need for initial load, thus significantly improving performance. Just drop this into your application, and you are good to go. Note that you will need Meteorite to install the Fast Render package.

Iron Router is a routing package for Meteor – an extremely powerful and extensible one. It ships with some handy predefined functions like layoutTemplate, loadingTemplate, onBeforeAction, onAfterAction, and a whole lot more. A powerful one among these is waitOn, that helps improve performance by subscribing to a collection only when you are on a defined route.

Tests for Writ are written in Mocha, a BDD/TDD testing library. It has support for asynchronous function calls and a handy CLI tool that runs every time you make changes in the source files. There are other Meteor-specific testing frameworks available, like Laika. I chose Mocha simply because I was already familiar with it.

Arunoda released Kadira the same day that I released Writ. I had already signed up for it some time back, and gone through the documentation, and I was able to quickly integrate it with Writ. Kadira is a New Relic-esque app to help you monitor your Meteor application. You get a live feed of data and how your users are using it. It helped me track issues that people were facing with OAuth and redirect-loop.

JavaScript And Future Development Landscape - 3 - Kadira – JavaScript - Axelerant

Kadira – JavaScript


JavaScript has come a long way, from generating snowflakes, to a full stack language. We see native support for reactive features like Object.Observe and DOM Mutation Observers popping up everywhere. Promises have landed in all the stable versions of Safari, Chrome, Firefox and Internet Explorer, so goodbye Callback Hell. We even have Generators out in ES6. JavaScript is a part of our daily lives, right from the toaster to the smartphone, and JavaScript is here to stay. The choice is yours – embrace JavaScript or perish.

And on a lighter note: