To Grunt or to Gulp: the JavaScript Taskrunner Wars

Quoting Travis Maynard, “Task runners are small applications that are used to automate many of the time consuming, boring (but very important) tasks that you have to do while developing a project. These include tasks such as running tests, concatenating files, minification, and CSS preprocessing. By simply creating a task file, you can instruct the task runner to automatically take care of just about any development task you can think of as you make changes to your files. It’s a very simple idea that will save you a lot of time and allow you to stay focused on development.”

The rapid pace of tools development to simplify programming recently shifted to the build systems. Grunt, the trustworthy taskrunner, now has a challenger for the heart of web developers in the person of Gulp, the newest bride on the block.

Grunt is a configuration-based system which uses a Gruntfile in your document root to manage its configuration options. Most features are provided as addons using plugins. One of the major complaints about Grunt is the abundance of configuration required to achieve simple tasks.

Gulp on the other hand adopted the programmatic approach. It utilises a similar layout structure as Grunt (one Gulpfile and features added through plugins), but works based on the concept of Streams. In Gulp, your code as a set of files that require a series of operations performed on them. Once an operation is finished, a stream is used to pipe its result to the next operation to be executed.

Two main points favoring Gulp adoption today are Speed of Execution and Code over Configuration. Gulp has a noticeable execution speed over Grunt; it is expected that newer releases will narrow the gap. And for those who would rather write code than maintain configuration files, Gulp is also the way to go.

One advantage that Grunt currently has over Gulp is a much wider community support, with a lot more plugins available for it. This though is fickle, and can change as Gulp sees more adoption by developers.

“The most important question to ask yourself is which philosophy do you subscribe to more? Do you like a build system that prefers code over configuration? If so, then you may feel right at home with Gulp. Otherwise, stick with Grunt”.

Editor Smackdown: Sublime Vs Atom

              vs              

SublimeText has had a great reign; it is indeed a marvelous piece of software, hands-down one of the best cross-platform editors. But, like every good product is bound to have, there is a new contender making waves at the moment: GitHub’s Atom. The question then is: will Sublime continue to reign as the undisputed king of the editors?

Atom, promoted as “A hackable text editor for the 21st century”, is an all web based desktop app built on top of Chromium, Google’s open-source web browser. Written using Node.js, CoffeeScript, LESS and then wrapped in a WebKit wrapper, it currently runs on OS X, Windows and Linux.

Atom is an attempt to marry the beauty of Sublime with the ubiquity of JavaScript. The UI and functionality is basically a mirror of Sublime, the plugin system is cool, and a great community has already built up around it.

Sublime on the other hand went the native route as it’s core is written in C/C++ using a Python API for plug-ins. Though similar in UI and UX, its native nature accounts for why Sublime performs significantly better than Atom especially in “heavy lifting” like working with large files, as Atom still has a max of 2MB file load.

Sublime also outperforms Atom in terms of responsiveness. Be it typing within the document, switching tabs, or opening files, you will definitely notice the slight delays Atom’s web based foundation exhibits.

In this area of speed, the technology stack underlying Atom may yet be its greatest enemy. But with it’s open-source nature and the backing of Github, I believe there will be improvements as Atom matures.

Atom is beautiful, but it’s performance is being hobbled by platform choice. Sublime has raised the bar very high and I’m pretty sure for the time being, a non-native app will not be able to compete.

So till these issues are resolved, Sublime IMO ever so gingerly retains his crown as the King of the Editors.

Introducing Sails: the Realtime Node Framework

Sails is an MVC framework built on the simplicity of Node, the beauty of Express and the chattiness of Socket.IO. It’s like a Ruby on Rails for JavaScript and even comes with a pretty powerful commandline interface for issuing such commands as sails new myApp to create a new application.

Built on top of Express, Sails inherits its incredible performance and consistency and numerous modules, like the Express router, cookie parser, body parser. Thus developing routes / REST APIs is insanly quick.

Sails also provides realtime features with the integration of WebSockets and Socket.IO out of the box.

To ease development, Sails uses the Waterline ORM to abstract data access to SQL and NoSQL databases. The data-agnostic nature of the ORM makes it easy to mix and match datastores, so you can have some models stored in MySQL and others in Redis. It provides validation and some level of association between joins. It is easy to write custom methods on your models to extract “higher-order” data from them. But most importantly, creating a model gives you a ton of routes (CRUD blueprints and REST endpionts) out of the box (and they all work with Websockets!).

Sails also encourages using consistent conventions for structuring files across applications. This ideally enhances productivity, especially when working in a team. It’s better for stakeholders because it means you do less inventing and more practical work, it’s easier to get new programmers up to speed on how existing codebases work, and it allows a team to encourage/enforce coding best-practices.

In all, with its beautiful mix of technologies and some stronger conventions for app development, Sails is indeed a Node framework to look into.

Why MEAN: the rise of JavaScript

The era of Web 2.0 is gradually drawing to a close. Pockmarked by the reign of Ruby on Rails, PHP (and its many frameworks), Web 2.0 apps had a clear delineation in roles between the server and client portions.

Today, we are seeing a rise in the demand for apps that provide instant, real-time features previously found only in desktop applications. Most interactivity on the web were restricted to Java applets, Flash and the bad-child of the web, JavaScript.

In it’s early days, JavaScript took a lot of bashing, and was relegated to the “me-too” status by a lot of developers, the writer included. It was looked down on, but as is oft the case, today it has the last laugh.

The creation of the the V8 JavaScript engine by Google sparked a maddening surge in the current renaissance of JavaScript. With the invention of Node.js by Ryan Dahl based on the V8 engine, all hell was literally let loose. Suddenly, the rejected stone became the chief cornerstone.

Since server-side programming was possible in JavaScript, what about the data-layer? The march of NoSQL began, with heavyweights like MongoDB, Couch etc spawned and created to ride the wave.

On the client-side, an avalanche of frameworks were born. From the grand-old king (jQuery), newer contenders came forth – Backbone, Ember, Angular, Knockout etc

Ubiquity was within reach, as a developer just needed to learn 1 language: JavaScript.

Not done with his victory, JavaScript turned his eye to one of the companies who started it all: Microsoft. Windows 8 soon came, and with it, a native API for developing in JavaScript. Oh, the sweet smell of victory.

One final frontier: the mobile. Predictions placed mobile as the next big thing, and JavaScript loved the sound of it. He tuned in to the challenge and viola we had a slew of technologies enabling mobile development in JavaScript. PhoneGap/Cordova, Ratchet, Crosswalk et al are all off-springs of the JS/Mobile union.

Then GIS and mapping, game engines, visualization libraries, telephony API’s, the list becomes endless.

A web developer going into the 21^st century then has a dilemma: what do I learn? Short answer, Go MEAN. Mongo for your database, Express and Node for server-side and Angular for the client-side. It is amazing the productivity gains you get from focusing on one language and not having to switch context regularly.

Like Julius Caesar, JavaScript can finally boast “I came, I saw, I conquered”. We are all at his mercy.

Understanding Backbone Events System

Backbone uses a pub/sub event system to manage notifications for actions. A pub-sub system has 3 main components:

• A place to store the things that happen when we trigger the event – internal implementaion
• The method that broadcasts the event – Publish (trigger)
• A system that allows us to register (for/to that) interest on that event – Subscribe (on)

A pub-sub system is an implementation of the Observer pattern and it helps in code decoupling; it makes it possible for components to publish or subscribe to different events based on the state of the system.

“The general idea behind the Observer pattern is the promotion of loose coupling (or decoupling as it’s also referred as). Rather than single objects calling on the methods of other objects, an object instead subscribes to a specific task or activity of another object and is notified when it occurs. Observers are also called Subscribers and we refer to the object being observed as the Publisher (or the subject). Publishers notify subscribers when events occur.” …Addy Osmani

Backbone.Events Overview

The Backbone.Events object contains methods that facilitate the Observer design pattern and a variation of the observer pattern called pub/sub. These functions permit plain vanilla JavaScript objects or the various objects created by Backbone to communicate with each other in a decoupled manner.
To achieve this, the prototypes of the high-level constructor functions provided by Backbone are all extended with the functions contained in Backbone.Events (using the ubiquitous _.extend(Model.prototype, Backbone.Events) of Underscore fame). The affected constructors include:

• Backbone.Model()
• Backbone.Collection()
• Backbone.View()
• Backbone.Router()
• Backbone.History()

To facilitate the pub/sub pattern, the Backbone.Events object contains the following functions which provide the functionality needed to create events, trigger events, and create listening relationships between objects based on events.

• on(event, callback, context) aka bind()
• off(event, callback, context) aka unbind()
• trigger(event, arguments)
• once(event, callback, context)
• listenTo(other object, event, callback)
• stopListening(other object, event, callback)
• listenToOnce(other object, event, callback)

Binding Events to Objects using on()
The on() method will bind a callback function to an object, and that callback will be invoked whenever the event is triggered. The on() also accepts a string event parameter which can contain multiple events separated by a space. on() takes 3 arguments (the 3rd is optional): the name of the event(s), the callback function to execute when the event is triggered and the this context for the callback function.

 var ourObject = {};
 // Mixin
 _.extend(ourObject, Backbone.Events);

 // Add a custom event
 ourObject.on('dance', function(msg){
    console.log('We triggered ' + msg);
 });

 // Trigger the custom event
 ourObject.trigger('dance', 'our event');

on() provides the Subscribe mechanism.

Triggering And Passing Values To A Callback Function Using trigger()
The trigger() method is used to invoke named (i.e. events) callback functions. Its takes 2 parameters: the first is the name of the event(s) as a string; while the second parameter gives the option of passing values to the callback function.

 var ourObject = {};
 // Mixin
 _.extend(ourObject, Backbone.Events);

 function doAction (msg) { console.log("We are " + msg); }

 // Add event listeners
 ourObject.on("dance", doAction);
 ourObject.on("jump", doAction);

 // Single event
 ourObject.trigger("dance", 'just dancing.');

 // Multiple events
 ourObject.trigger("dance jump", 'very tired from so much action.');

trigger() provides the Publish mechanism.

Removing Events and Callback Functions with off()
The off() method can be used to remove previously bound events and callback functions from an object. The basic syntax takes the name of the event and the callback to remove as parameters; but calling off() with no parameters on a Backbone model, collection, view, or router object will remove everything including the built in BackBone events and callbacks.

var ourObject = {};
 // Mixin
 _.extend(ourObject, Backbone.Events);

 function dancing (msg) { console.log("We " + msg); }

 // Add namespaced custom events
 ourObject.on("dance:tap", dancing);

 // Trigger the custom events. Each will be caught and acted upon.
 ourObject.trigger("dance:tap", "started tap dancing. Yeah!");

 // Removes event bound to the object
 ourObject.off("dance:tap");

 // Trigger the custom events again
 // won't be logged as it's not listened for
 ourObject.trigger("dance:tap", "stopped tap dancing.");

Have an object listen for events on another object using listenTo()
The listenTo() method gives the ability for one object to listen for an event on another object, and when that event occurs provide a callback function that is invoked. listenTo() is called on the subscribing object (i.e the object to be notified when an event occurs) and it takes 3 parameters: the source object or publisher, the event type to listen for (as a string) and a callback function to execute when the event is triggered.

Stop listening for events on another object using stopListening()
The stopListening() method can be used on objects that are listening to other objects to terminate the notifications. Depending on the parameter passed in when the function is called, stopListening() can stop listening to a specific event, all events or all/specific events associated with an object.

 var a = _.extend({}, Backbone.Events);
 var b = _.extend({}, Backbone.Events);
 var c = _.extend({}, Backbone.Events);

// add listeners to A for events on B and C
 a.listenTo(b, 'anything', function(event){ console.log("anything happened"); });
 a.listenTo(c, 'everything', function(event){ console.log("everything happened"); });

// trigger an event
 b.trigger('anything'); // logs: anything happened

// stop listening
 a.stopListening();

// A does not receive these events
 b.trigger('anything');
 c.trigger('everything');

For a more comprehensive look at Backbone and Events, see the excellent article by Cody Lindley at http://tech.pro/tutorial/1367/part-1-backbonejs-deconstructed

The Art of Learning::The HackReactor Edge

Learning is an art of adapting and applying yesterday skills, experiences and knowledge to today’s circumstances.

The changing and evolving world of the 21st century requires new sets of skills, and Education is the medium by which we can learn and teach them. Adapting is necessary because the world is in constant flux – Change happens; research has shown that what the world knows doubles every 18 months.

The Change-Makers, the leaders of tomorrow, are those who have the foresight to see the next curve of change and then commit to helping not just themselves but others to prepare for and harness this change.

Utilizing education and learning, they communicate their thoughts and beliefs and experiences and knowledge with the aim of educating and enhancing.

Most times, these ones go against the norm, they strive to change the status-quo. Sometimes they are branded radicals and mavericks by those too afraid to change. But courage and strong faith in the value they are creating keeps driving them forward.

The Change-Makers move the world forward, and Teachers are the greatest of them all. By educating others, they help prepare them to initiate, meet and face the challenges of change. Teachers enlighten, guide, encourage, inspire, motivate and challenge us to rise to the full capacity of who we can be.

And this is the HackReactor Edge. Having looked at the status quo; the numerous degrees in Computer Science, they have re-defined what VALUE means for and to a software engineer in the 21st century. And in 12 intense weeks of focus, they drill these concepts into you. It can be a terrifying ride, but it is at once both enjoyable and exhilarating; challenging you to stretch yourself beyond your mental boundaries.

What is the HackReactor Edge? It is, in my understanding, summarized by the 4 points below:

• Code-First, Code-Always: there is no better way to learn but by doing; and that is the first principle you learn at HR. As one who loves to read, I have discovered that “Knowledge acquired not applied soon disappears”. HR throws you into the deep-end of practicals: you can learn coding only by coding. Practice cements and solidifies Theory. Do more, get better… This principle gives birth to the next one, which is…

• Toy Problems: these are a series of daily challenges you are required to solve at the beginning of each day. When you think you know a subject, toy problems redefine your assumptions. They stretch your understanding of the subject matter till you grasp all the minutest details of it, leaving you gasping with the satisfaction only true mastery gives. Sometimes they give you nightmares in the daytime, but what marvelous brain-churning nightmares they are. “Challenges make a man, and he who from them shrink denies himself of the opportunities to grow”; toy problems are the ultimate test of your mettle.

• Accelerated Learning: Whew!!! Strap on your seatbelts, the jet is about to take off!!! Your learning and assimilation skills are ramped to the max; you have to work on your capacity to absorb multiple concepts at amazing speed. You realize that you have been your own greatest enemy in your past learning experience: by limiting what you can learn at any given time. By exposing you to multiple cutting edge technologies simultaneously, HR helps your mental capacity grow.

• Pairing and Accountability: as a melancholy, I love to be on my own and do on my own. But HR has challeged me to re-assess my prioities. True learning is social; true mastery can never be achieved in isolation. Pairing helps you see the world of code from another set of brilliant eyes; it makes you stay accountable and focused on the task at hand. It gives you feedback on your present skill level and highlights areas where you need to work on. You learn the truth in the axiom: “There is no growth without accountability”.

In the supersonic pace, it is sometimes easy to yield to the human nature of plaguing feelings of inferiority. You may at times feel overwhelmed, may be tempted to give up and throw in the towel, may look around and see yourself surrounded and outclassed by peers who seem to do so much better than you are doing.

This is where you appreciate the excellence that HackReactor represents: their TEAM. This group of exceptional, brilliant maestros pre-empt your fears; their personal touch seems like magic; they seem to sense what you are going through and like a mother helping her toddler take the first steps, they lovingly guide you back from the precipice and through your challenges. They are one call (or Google Hangout) away, with amazing resources to meet your needs. They bring you back into the community and help you realise that “heck, its one big family”…

It’s just 2 weeks in 12, and it has been one jolly ride. I am glad I am in the HR family, maybe you should come along too.

If you are a software engineer, a web developer, a computer science under/postgrad or you are aspiring to be one of the above, my challenge to you then is this:

Are you tired of the status quo? Do you desire to take your skills and knowledge to the next level?

Then Try the HackReactor challenge; Get the HackReactor Edge!!!

You’d be glad you did…

Let me end with a dedication to the HR Team from another great maverick, Steve Jobs…