Occasionally, I get stuck wondering what I should use to iterate over a list/collection of items in Javascript. There seem to be a hundred ways of achieving it. To tackle that and have a handy little reference, I’m writing this guide touching all the common ways of iterating that I use and the kind of data they are a good fit for.

for

1
2
3
4
5
6
7
8



const arr = ['apple', 'ball', 'cat'
for(let i = 0 i < arr.length i++) {
  console.log(arr[i
}
// Output:
// apple
// ball
// cat

The regular for loop (with a loop variable that iterates from some number to some other number with user supplied increments) is the most common form of for loop. I try to use as little of this one as possible as there’s usually a better suited loop available for the job. But if nothing else fits, know that the ‘regular for’ has your back.

for..in

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19



const obj = {
  firstName: 'John',
  lastName: 'Doe'
}
for(const prop in obj) {
  console.log(prop

// Output:
// firstName
// lastName

const arr = [3, 2, 1
for(const prop in obj) {
  console.log(prop

// Output:
// 0
// 1
// 2

for..in loop can be used to iterate over properties of an object. Supplying an array to for..in will give the index in the loop variable. In either case, doing a obj[prop] or arr[prop] should enable looping over the object’s key values or array items.

for..of

1
2
3
4
5
6
7
8



const arr = [3, 2, 1
for(const prop in obj) {
  console.log(prop

// Output:
// 3
// 2
// 1

for..of loop is useful for linearly looping over iterables like strings and arrays from the first to last item. I often mistake the for..in loop for this, but adding a new loop was how ES6 prevented breaking all the legacy code that depended on for..in to give array indices and not array items.

Array.prototype.forEach

1
2
3
4
5
6
7
8



const arr = ['World', 'Alice', 'Bob'
arr.forEach(word => {
  console.log('Hello', word

// Output:
// Hello World
// Hello Alice
// Hello Bob

Array.prototype.forEach will accept a callback function (say (item [, index, array]) => {}) and call it with each item in that array. An optional second argument will carry the current item’s index. Optional third argument passes the reference of the original array if you wish to operate on it inside the callback.

Note that Array.prototype.forEach simply means that you can invoke this method directly on an array, like [3, 2, 1].forEach(...)

Array.prototype.map

1
2
3
4
5
6
7



const arr = [10, 20, 30
const arr10x = arr.map(item => {
  return item * 10
})
console.log(arr10x
// Output:
// [100, 200, 300]

Map maps over the items in the array, calls a callback with each item and returns a new array created from the values returned from callback functions.

Array.prototype.filter

1
2
3
4
5
6
7



const arr = [1, 2, 3, 4, 5, 6, 7, 8
const onlyEvens = arr.filter(item => {
  return item % 2 == 0
})
console.log(onlyEvens
// Output:
// [2, 4, 6, 7]

Filter calls a callback function with each item in the array and returns a new array with only the elements for which the callback returns true. In general, the callback function implements the logic to determine if a given element should be present in the resultant filtered array (returns truthy if it should).

Array.prototype.reduce

1
2
3
4
5
6
7



const arr = [1, 2, 3, 4, 5, 6
const sum = arr.reduce((accumulator, item) => {
  return accumulator + item
}, 0
console.log(sum
// Output:
// 21

It took my a long time to get used to Array.prototype.reduce, most likely because I don’t use it often. But it shows up quite often when you’re working on functional code, or functional programming languages like Haskell.

The Array.prototype.reduce method takes two arguments, a reducer function (of the signature (accumulator, curr) => return newAccumulator) and an initial accumulator value. In the first iteration, the accumulator takes the initial value. In the next iterator, the return value of the previous iteration becomes the new accumulator value. After the last iteration, the accumulator value is returned from the Array.prototype.reduce method.

Object.keys() and Object.values()

1
2
3
4
5
6
7
8
9
10



const obj = {'a': 1, 'b': 2
const keys = Object.keys(obj
console.log(keys
// Output:
// ['a', 'b']

const values = Object.keys(obj
console.log(values
// Output:
// [1, 2]

Object.keys() and Object.values() take in an object and return an array of all the keys and values of that object in an array respectively which can then be used with the looping methods discussed above.

Object.entries()

1
2
3
4
5



const obj = {'a': 1, 'b': 2
const entries = Object.entries(obj
console.log(entries
// Output:
// [ ['a', 1], ['b', 2] ]

Object.entries takes in an object and returns a multidimensional array with each item a pair of key-value pair from the object.

while and do..while

1
2
3
4
5
6
7
8
9



const arr = [1, 2, 3, 4, 5
const index = 0
while(arr[index] < 4) {
  console.log(arr[index
}
// Output:
// 1
// 2
// 3

while and do..while are the other classics apart from the good ‘ol for loop. I don’t use while and do..while loops for iteration. They’re generally useful when you’re repeating a task without knowing in advance the number of times you’ll be repeating (for..in and for..of do that) or you’d want to only run the loop until a specific condition holds true (for can do that).

An interesting use case where while loops shine is when we need to iterate indefinitely (until the given condition is true), which isn’t really iteration and hence I have put this section at the end, just as good to stuff.

In closing

That’s it. I hope that simplifies iteration for you a bit. It certainly did for me. Did I miss any way of looping over iterables? Do let me know! I hope you learned something from this article. Thank you for reading!

This isn’t going to be a shameless ripoff of Douglas Crockford’s work in the book Javascript – The Good Parts, which used to be a highly recommended book in the Javascript community before ES6 took off. Rather, I’m going to write what are, according to me, the good parts of the Javascript programming language. I’m not keen on making this sound like an endorsement or otherwise. I am more interested in exploring the reasons that make Javascript such a popular language even if not the most loved. Why is it that the language you find at most programming bootcamps is Javascript? In this little post, let’s try to reason that.

The motivation for writing this post came from my company, which is launching a new course that will teach people with no programming experience full stack web development. The course will teach a student all they need to know to write a complete web application, in Javascript. That made me wonder, why teach (just) Javascript? Why not Python, or Ruby, or something even fancier? Following are some of my ideas.

Because ease of learning

Javascript is a high level language, and the learning curve is somewhat flat until you get to the last 20% or so of the language. You don’t need to know a lot of computer science and computer organization to pick something like Javascript or Python. On the contrary, the typical first languages that are taught in colleges (in India), C and C++, require you to understand memory, stacks and heaps, platform that you write code for and so on.

Also, given the event driven nature of the web, Javascript makes a lot of sense when you’re interacting with user actions (Javascript supports event-driven style of programming). It is easy to express intentions in Javascript, and given that it has been around for some time now, most problems that you’d face are already solved somewhere by someone.

Because community and support

Javascript has a huge user base, and I’m not talking about the end users. I’m talking about developers. Many people I know started their careers in software technology with Javascript. There’s good reason for that. One that there’s no shortage of resources on learning Javascript, debugging, utility libraries, UI libraries, testing and frontend frameworks. It is easy for people to pick something up and stay motivated when they have their questions answered easily with google searches, and they find people with whom they can relate the learning process.

Because jobs

It is easy to find jobs that require Javascript, which is something that definitely matters if you’re learning how to write code for getting employed (which many of us are). The salary might not be as high as for some other languages and frameworks, but it would in general be high enough. Also, it is always possible, and much easier, to move in between different tech roles than getting into one in the first place.

Because frontend and backend

If you’ve been programming for some time now, picking a new language isn’t at all difficult, and that’s part of what is expected of us programmers. But for someone who’s just starting out, being able to program an entire application in a single language is a huge plus, as compared to spending a lot more time learning their second language for backend specifically. You can always learn a new language later on specifically for backend or anything else, once you are a decent Javascript developer.

Because JSON

JSON, or Javascript Object Notation, is a format for representing data as key value pairs in a text document (Douglas Crockford, mentioned earlier, is the creator of JSON). As the name suggests, it is the same format that you’d use to represent an Object in Javascript. While JSON is not exclusive to Javascript (since it is a file format), it is well integrated into the Javascript-verse and accepted as the de-facto format of data exchange.

To make things simpler, many NoSQL databases use the same key-value representation which means all of your data, from the database, to backend and eventually the frontend, is in one format. It makes things easy to understand. It shouldn’t then be surprising that many of the bootcamps choose such a NoSQL database to go along with their full stack development course.

Because time-to-productive

If you’ve written code in Java or C++, you know that it takes an awful lot of time to go from a complete programming novice to someone whose software might be useful to others. Compare that with Javascript (or Python). You can start learning it today, and within a week, you’ll have your very own sign up forms and what not. In a couple of months, you’ll be pushing out code of the quality you find in production at most startups (if you’re not sure whether to be happy or sad at that line, be neither. You’ll discover one way or the other).

Because it works (..for now)

And because we do not have an alternative. Javascript is installed universally. You don’t have to ship it with your app. I think that’s a huge point in its favour, and enough reason to learn some Javascript even if one doesn’t plan on writing a lot of it. It is the language of the application layer of the internet. It is far from elegant. But remember this

There are only two kinds of languages: the ones people complain about and the ones nobody uses. – Bjarne Stroustrup

That quote is particularly appealing to me, and not just because I had a mini-crush on Stroustrup ever since I missed his talk back in 2015.

In closing

Javascript can be a very good language to start with. It makes all the more sense if you’re learning to get employed as a developer. I must say that the ecosystem is not the best at this point. There are new libraries and frameworks popping up and fading out every other day, and there are way too many best practices for anything to be seen as a standard. But if you do get started with Javascript, spend some time later in your career figuring out how computers and the internet work. Javascript isn’t going to force you to, but it comes in handy.

If you liked this post, check out 17 tips after a year in Javascript development for exactly what the link title says. Thank you for reading!

Long time no see, Javascript. Where had you been, my old friend?

Well, not really. I have been writing Javascript more than ever since my last post about the language on this blog, some 26 months ago. As some of you already know, writing Javascript has become my day job and it is honestly one of the better things that could’ve happened to me. I’ve learned a lot of the nitty-gritties of the language and surrounding environments (and the web) and gained invaluable insights about software development in general.

In this post, I aim to cover some of things I wish I knew as a Javascript newbie (no offense to anyone. I’m a newbie myself in most ways). These aren’t supposed to be comprehensive or even correct, for that matter. No particular order is followed. These are just things I feel I could’ve helped myself with while learning the language and building some initial projects and wish to share with you guys here.

It will be most helpful if you’re just finishing learning the core language and want to find out what exists in the world of web development. Feel free to contradict and correct me.

1. All Theory And No Practice

Get over with that college student attitude of reading chapter upon chapter of dull text and not writing a single line of code. And by code, I don’t mean the example code snippets. Go out there on Github and Reddit and search for beginner problems statements. Creating a simple TODO list or displaying the top posts on Reddit frontpage via their API doesn’t require any deep knowledge.

The essential skill to learn here is to be able to use a search engine, find relevant documentation, getting passive help from online communities (See stackoverflow or Reddit; r/javascript, r/webdev, r/frontend are good places to start looking). You cannot learn cycling by just reading about cycling. You learn cycling by riding a bicycle, by talking to your friends about the dangerous stunt you pulled off, by going offroad on the weekends, by watching the pros ride and then trying those things. That’s what makes it fun. Don’t make it a job. More often than not, you’ll suck at the end of it.

2. Build Tools

I made the mistake of assuming I knew everything about the language once I finished my guidebook. The reality was far from it. Language is just one little part of the puzzle of mastering any programming stack. There are many support tools that I didn’t care to explore back then. For example, there’s something called as a build tool.

In an organizational setting, you don’t start a project by creating an index.html and then linking it with your main.js. Instead, you make use of build tools (See Webpack or Grunt) to compile your code into a form understood by new and old browsers alike, bundle all of your code together and make it production ready. A basic understanding of build tools will go a long way and come in handy when making your next hobby project shine.

3. Modularization

Modularization, in simple English, means separating parts of your code that work similarly. Just like we sleep in our bedroom, bath in our bathroom and cook food in the kitchen, code the does similar things should be separated into different files and functions/classes. fetch() API calls in one file, little utility functions/hacks in another, DOM manipulation functions in another and event listeners separately. This is one of the many ways of doing it. See what works best for you. Remember that your frustration level two weeks later while finding a bug in your code is inversely proportional to the number of files and functions you separated your source code in.

The importance of modularization strikes only when you feel the pain in your back scrolling up and down and sideways finding a particular section of a function responsible for something. You’ll have to take a leap of faith here to learn this lesson the easy way.

4. Consistency

You don’t have to be collaborating with other humans to follow this. Just pick up a code style and stick to it religiously (see Airbnb’s Javascript style guideline for a starting point). You’d hate yourself if you open your code editor and find things like varNames and var_names mixed all over the place. This is not limited to just syntax or micro stuff. On a broader level, follow the same style for everything. If you return a Promise from an API service function, then stick to that style. Don’t interchangeably return promises and data, for example. And don’t mix imperative, object-oriented and functional coding styles randomly. Make conscious calls on what is right for the situation, and document appropriately.

The less you think about the language semantics, the more you can think about the problem you’re trying to solve. And consistency will definitely reduce a lot of the unnecessary load of deciphering your own code.

5. Documentation

Another task deserted of any love in the realms of software engineering. No one likes to document code, take it from me. But the difference between a rookie and a master is knowing when and why something must be done irrespective of his affection towards the job. Write comments, doc strings. Decorate your projects with nice READMEs and fancy “build passing” and “codecov” badges. No, you’re not doing it for others. You’re doing for yourself because you know it is right. You want to know your thought process two months later when you read the code to make some changes. It is like an “enable time machine access to this point in time?” button in your code, which you reply with a “deny” if you decide to not document your code.

6. Think, Think, Think And Then Write Code

This is one of my personal favorites. I’ll start coding 0.006 seconds (number might be slightly inaccurate) after hearing the problem statement. Don’t do this mistake. Don’t fall for your heart saying it has understood it all. Your heart is wrong. Think about the problem. Confirm that you have understood the requirements correctly. Formalize the requirements in your mind, or better yet, in a Github issue or something. Come up with a naive approach to do it. See if you can optimize the code, think about space-time tradeoffs, think if you can use something like a hashmap etc. You’ll be surprised how many better solutions you’ll come up with after thinking about it for 10 minutes as opposed to jumping right into the code.

7. Tracking Your Project’s Progress & Version Control

Use git, Github (or any other Git hosting). Use issues to write down what you plan to do for the next iteration. Use PR (pull request) feature to fix that issue. Write down if there were any caveats in the comments below the PR requests. Yes, do it even if you’re the only person working on the project. It might seem unnecessary and tedious, but once you get the hang of it, your time will be much better utilized and progress much better tracked.

8. Automate Your Deployment

I remember my workflow before starting work. Keep committing to the master branch and testing things out locally. And when things look decent enough, spin up a digital ocean droplet, clone the repository and start the development server there. That was my ‘deployment’. If any changes need to be done, commit to master and push from local. Pull them on the server and restart development server.

Now that I know better, I not only make separate branches for each feature, I set up auto deployment on Heroku on particular branches (mostly master and staging/development). It’s a one-click affair (assuming you followed the build tools part) and takes away a lot of hassles (and is free as well). Knowing the right tools can make a huge difference, as you just saw.

9. Unit Tests

If you’ve ever worked on a non-trivial project (say around a thousand lines of code), you will recognize the tragedy when you modify your code while adding a new feature and accidentally break a lot of the old code which you realize later when things start going south at which point a lot of git-fu is required to get back to a safe point and not lose any newer work. Let me tell you something. It is all avoidable with simple unit and integration tests. Think of tests as employing a bunch of robots to look over your old code and point out when you’re about to break your own (or someone else’s) code.

It is very hard to convince yourself to write tests even after knowing the pluses, let alone without knowing them. But again, you’ll have to take a leap of faith here. Or you can wait until someday while casually refactoring some code you mess something up which you realize only after three days with hours of debugging which could’ve been avoided by writing a simple test.

10. Use ES6

This might be a no-brainer to most of you, but I still find people writing older Javascript syntax even though they know and understand the newer spec. With modern build tools and polyfills, most of the times not writing the latest spec syntax is just laziness. If you find yourself writing things the old way, force yourself to use the newer ways. They are there for a reason.

Let’s be honest guys, Javascript is not the most elegant language. The older versions are riddled with bugs in the spec itself (see function scoping of var, the this keyword, double equals (==) comparison and automatic type coercion). The newer versions of the language are an attempt at fixing things and we should respect that, even if that means going out of your way to follow the newer semantics.

12. Understand What JS Is And What It Isn’t

Javascript, the core language, is actually a subset of the things we’re used to of using in our everyday development on the frontend. The core language is relatively small and simple, but add DOM APIs to it, and suddenly it becomes something slightly bigger and a bit more complex. Javascript is single threaded but DOM APIs like fetch (or xhr) and setTimeout are asynchronous because of the browser’s magic. Learn to consciously differentiate between them as that will come in handy. As a general rule, DOM is very slow as compared to the Javascript language engine.

13. You Probably Don’t Need That Framework

This has been repeated enough that I could’ve skipped it, but I’ll still put it out here. If you find yourself importing Lodash or Underscore for simple things like mapping, iterating over objects, filtering objects and things like that, consider looking for equivalent core Javascript alternatives. The latest ECMA spec adds a lot of helpful data structures and utility functions that make writing functional code very easy and pleasant.

Similarly, if you are planning to use ReactJS or Vue just because everyone seems to be talking about it, don’t. Go read up their introduction and documentation and judge if your project fits the use case that particular framework is build for and the problem it is trying to solve. For learning purposes, you can consider using the frameworks for trivial apps, but for anything else, make decisions on a strictly use case basis.

14. Learn Basics Of CSS

While the popular opinion still says that CSS is a pain in the back to master, I’d suggest learning almost 60-80% of it with maybe 20% of the efforts. No need to remember which browser supports what niche attribute. Just the important very-handy-in-real-life parts like flexbox, grids, box model, margins, paddings, positioning related, display related, floating related and so on. You will cover a lot with just these, and they come in super handy for personal projects. (Again) trust me.

15. Explore Web Workers/Service Workers

What if I tell you, you can hijack API requests from your webapp and service them without making a roundtrip to the server? You’ll say, if the request is serviceable on the frontend itself, why bother making an API call in the first place, and I make a poker face to that. Jokes aside, service workers enable you to handle network connectivity drops and provide a much smoother experience. You can save the data that a client wanted to send the server in the browser while offline and then replay those requests again when network connectivity is recovered.

Web workers allow your code to delegate work to another processing thread. This can be any type of work that you would want to unload off the main thread like heavy calculations etc.

16. Explore Browser-Side Databases

There’s localstorage, there’s cache, there’s indexDB. This is apart from the cookies and session headers. Basically, there is no shortage of storage options on the client side. Try and use these to cache and store data that need not be sent to the server, or maybe cache in case of uncertain network availability. With service workers and Cache, you can fine tune what gets cached and the behavior when a cache is hit or miss. You can even set up caching strategies with plain Javascript code logic.

There are wrappers such as PouchDB that can sync with the server side CouchDB and provide nice real-time syncing capabilities. Speaking of real-time, you might also want to check out Firebase by Google. I used to use it in the past and it was very easy to set up and work with.

17. Explore Progressive Web Apps

Now you can make your website work offline too. Ever seen that “Add to homescreen” button on certain websites? When you add those websites to your homescreen, you can then open them like regular Android apps and if they’re built that way, even use them offline (further reading: developers.google.com/web/progressive-web-apps).

In Closing

I hope this article was useful. If you’re a beginner with web engineering and have just finished learning the Javascript language, you might want to explore some of the above points in detail. I’m sure you’ll have fun building your next awesome project using these guidelines.

Thank you for reading.

If you’re like me, then you must have gone nuts on hearing about WebSockets for the first time. We now have a totally independent protocol that will not terminate connection after a request-response cycle, which means all hacks to keep a persistent connection from the browser (long polling, I’m looking at you) would now be part of the history. Welcome to the world of WebSockets.

Let’s start with the Wikipedian and Mozillian definition of WebSockets, to get some initial traction.

Wikipedia says that..

WebSocket is a protocol providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011, and the WebSocket API in Web IDL is being standardized by the W3C.

Mozilla Developer Network says that..

WebSockets is an advanced technology that makes it possible to open an interactive communication session between the user’s browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.

To begin with, let us all make sure we have websocket support by clicking here. Assuming you do, let’s begin. Web browsers provide us with the WebSocket class. To create a websocket, we simply need to

let ws = new WebSocket('ws://server.com/endpoint');

This gives us a websocket object which supports methods like send() and close() and event listeners like onmessage and onerror.

Creating a nodejs instance running a websocket server is easy with modules. I did try to do it natively, but it went too tedious. Finally I settled for ws module from npm. The server side code looks trival.

On the browser, things are even simpler.

// call the object constructor
var ws = new WebSocket('ws://nagekar-ws.herokuapp.com/'
// attach a message listener
ws.onmessage = function(msg) {
	console.log(msg
}
// send some message
ws.send('hello server!'

Once we call the constructor, an HTTP GET request is generated to initiate the transaction. You’ll find that these headers are sent by your browser.

GET / HTTP/1.1
Host: nagekar-ws.herokuapp.com
Connection:Upgrade
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits
Sec-WebSocket-Key:ut0NjBQxxBnmtUStHfMUDw==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.108 Safari/537.36

The ones to notice are the URL, which begins with ws:// protocol. Cross domain requests are allowed. This initial step requires the use of HTTP(S) or web, hence the name ‘web’ sockets. The ‘Connection:Upgrade’ and ‘Upgrade:websocket’ and what requests the server to change this connection to a socket one. The Sec-WebSocket-Key header is what client sends to the server. The server crafts another key with this and returns it back in the response header. A response header looks like this.

HTTP/1.1 101 Switching Protocols
Connection:Upgrade
Sec-Websocket-Accept:7CAJHdL7QMG4ceqd0M1O8SDbM2Q=
Sec-Websocket-Extensions:permessage-deflate
Upgrade:websocket
Via:1.1 vegur

On receiving the Sec-Websocket-Accept header, the handshake is completed, and now the client and server are connected via persistent sockets, ready to perform both way message delivery.

Click ‘Connect’ button to initiate WebSocket handshake. The server will respond with a timestamp every 2500 milliseconds. Also, the server will echo back everything to send at it. The close button will call the WebSocket.close() method which will terminate the connection.

Message Box

Pretty interesting, isn’t it. Things get even more interesting when you use a readymade library built on top of WebSockets, such as Socket.io. It supports all browsers (through fallback to XHR/polling), has better looking APIs, is easy to use and allows you to broadcast without having to worry much about raw connections. If you’re going to use these WebSockets in production, there’s no reason not to use Socket.io. Using native websockets is not recommended if you’re planning to support some legacy browsers. Even Mozilla terms it as an ‘experimental technology’. Check out the compatibility table for more information.

I hope this post was informative. I did learn a lot while researching on this topic, and I’m glad I did. As always, thank you for reading. Please drop a comment in case of feedback or correction.

I remember starting to learn Javascript. It was all a nightmare. Functions used to execute out of order and seemed very random. There was chaos all around, and I was usually left wondering, ‘what is the order of execution here?’. Of course, that question never got answered, because that wasn’t the right question. The right question would’ve been, what drives these functions in this code.

Fortunately, I asked it at an early stage. The things that make Javascript tick are called events. Without these, your browser window is just a dead canvas. Not just the browser, but other Javascript environments as well, work because of events. And when you understand it, events and event driven programming are probably the most intuitive form of developing applications. Events are not difficult to visualize, once you start to relate them to the real world events.

Suppose you’re alone at your home. You’ll need to make sure you open the door in case someone arrives. There are two ways of doing it. First way is to periodically keep checking if someone is outside the door, say every 5 minutes. In the best case, someone will arrive the moment you open the door, but in the worst case, a visitor has to wait for about 5 minutes before you make your next visit. This is just ridiculous. It is inefficient (visitors have to wait for you) and waste of time (when you check but no one has arrived). Who does this? Well, most procedural languages work this way. And it works, for their use cases. But when you’re dealing with real life scenarios, like checking doors or handling HTML form responses in browsers, where the time of completion of an action or arrival of a visitor is unknown, a better approach has to be used, especially when time, muscle and browser resources are so scarce. Here comes event driven programming.

Suppose, you’re alone again, in the same house. But this time, you decide to make use of events. You install a doorbell. Now, whenever someone arrives and rings the bell, you know you have to go open the door. That’s simple. That’s event driven. It doesn’t matter if the next visitor comes after a minute or after an hour. You’ll open the door instantaneously, without waste of your own time. And the fact that most homes have doorbells and this is our natural workflow when dealing with similar situations, is the proof of how intuitive this programming paradigm is.

Okay, that was cool, so far. But I know that I have to listen to a doorbell and then on hearing it, walk to the door to open it. How do I make the machine do that. The answer is callbacks. If you are not quite sure what they are or how they work, do check out my other article on how callbacks and event loop work. So essentially, we attach a ‘callback’ to an event. The callback, as the name suggests, calls back when the event occurs, and lets us control the aftereffect. Such a callback is also called an event listener, which infact is what you attach to the element.addEventListener('event', callback); when working in the DOM. In Nodejs environment, you get a custom EventEmitter class that you can use to emit and listen to events. If you haven’t heard of it, socket.io is all about custom events and the data transfer between the client and the server. It makes use of websockets along with XHRs. If you are into creating sockets and data interexchange between remote hosts like I am, socket.io is for you.

Finally, I hope to have given you some insights of event driven programming with Javascript. Not a lot of code, but that is something you’ll find everywhere. I always like to emphasis on the concepts rather than implementation. It makes for a better implementation.

I have been a part of numerous web projects, and after these many applications using multiple languages and frameworks, when my friend Kunal suggested that we should develop an Android application that would make use of a backend and stuff like that, I couldn’t help but desperately show my excitement. I told my friends, family and even seniors about the thing I am working on. After all, it was my first time going full stack mobile.

For clarifying things, I am still doing the backend. It is my little team that has gone full stack. On mobile. The application, called the moodShare will enable a user to do few simple tasks like registering, logging in, adding friends, sharing statuses, reading statuses and stuff like that. Each task is made possible with a simple API that is made without much thought to future scaling. I know, that is really bad from my side. But then, I was too desperate to get an application up and running that I neglected a lot of issues that arose when we were developing.

The application’s backend was Mongo, Express and Node. We deployed it to Modulus.io but then this happened and we had to shift it to Heroku.

Too poor to get a proper server… Crashing in 3..2..1 #javascript #nodejs

A photo posted by Abhishek Nagekar (@abhisheknagekar) on Mar 4, 2016 at 9:06am PST

And this was when we had around 4 live users. The code quality was poor, very poor. Trust me when I say it. 4 users were hitting the database around 7 times a second.

Beautiful sight of requests hitting the API server #javascript #nodejs

A video posted by Abhishek Nagekar (@abhisheknagekar) on Mar 4, 2016 at 7:43am PST

Then there were many other issues as well. For example, if you added a friend who had 400 status updates in his or her name before you added, your phone would notify you, well, 400 times. Literally. That was awful. Push notification was implemented in a way you write an infinite for loop to check if something has changed.

But hey, this was our first time. We did enjoy each and every second of the development (around 4 days), the bugs just as much. We did learn a lot from it. Before this project, messaging queue was just a name, Google Cloud Messaging was just another service that I knew nothing about, three or four HTTP status codes that I knew. The satisfaction of knowing more about these was worth it all. Lastly, we did not abandon the project. Our alpha version was pretty stiff and unusable. Hopefully, with better APIs, better hosting and material design on the frontend, we plan to rock with the beta version. Stay tuned.

Screenshots

Links

• The initail release of moodShare
• Backend code on Github
• Live API on Heroku

Callbacks are the things that make writing Javascript fun. If you think you are better off writing Javascript the way you wrote C and Java, then you are not really feeling the essence of this beautiful language. I found it rather hard to get used to this style of programming, called affectionately as the non-blocking style. What is this difficult sounding technique, and how can you make use of it to write better code is what we’re going to see in this little essay.

Starting with the most basic explanation of what a callback is. Suppose I have two functions A and B. Although I can execute both of them myself, what I can do is execute A and ask A to execute B for me. Yes, that is all there is to the callbacks thing. I have two functions, I execute one and then ask it to execute the other one for me. Simple.

But, you might ask, why I would ever want to do such a thing. Well, think about it this way. Computer processing is way, way faster than any I/O in question, especially when the I/O is on the other side of the network (or globe, for that matter) which is usual in the case of most web applications. Now, if you write code such that it queries a remote (or local) database and uses those results to carry on further processing, it results in a bottleneck. The processor executes instructions in the order of nanoseconds. An I/O request to the disk or network takes a few milliseconds at best, or a million times more time than what a processor needs to do a single atomic task. So essentially writing code that waits for results from I/O is simply wastage of the precious CPU cycles that could’ve been put to better use in the meantime.

A callback is also of great use when you want to make a function, say A, do things according to the context by supplying a specialized function B at the runtime. For example,

So let’s get into some (pseudo) code. We will first see what it is like to write code without callbacks and blocking IO and then examine some issues. Then we will write the same code using callbacks and non-blocking IO and see if we have rectified (or at least mitigated) those issues.

Now this code is blocked when the Javascript engine is waiting for the Mongodb query to execute and return. It may take a few milliseconds, and only after that does the control of the program moves to the next lines. If the database hangs up for any reason, then the response will never reach the end user, regardless of whether the login credentials were correct or not (or let the user know something went wrong). It may also happen that the Javascript engine continues the execution with ‘undefined’ returned, resulting in falsy block being executed each time. Having addressed these problems, let us now write the asynchronous version of the same (pseudo) code.

The callback function in a way keeps waiting for the response from the database in the background white the flow of program is not interrupted. As soon as the reply comes, the code in the callback function is executed. That sounds neat. Wait a second. Didn’t we all learn that Javascript is single threaded and does a single job at a time and what not? Then how is the callback supposed to listen when the browser is already executing the code below it?

To understand that, you’ll have to stop believing every thing you write in Javascript is Javascript. Yes, I mean it. Javascript is single threaded, but there is much more to Javascript than just a single call stack. Ok first, what is a call stack. Whenever a javascript file is executed, the engine creates a context for the code to run. This is the global execution context. It sits at the bottom of the call stack. Whenever a new function is invoked (or ‘called’), a new execution context is pushed on top of the stack. After the execution completes, the execution context is popped off the stack. After the last line of code is interpreted, the global context is popped off the stack.

Well and good. But what about that setTimeout function that you set for the next 10 seconds? And our own mongodb query. Where did those go? The setTimeout is actually a webAPI provided to us, the Javascript developers, by the browser. Similarly, our mongodb query command was not a Javascript thingy, but a C++ API from the Nodejs bag of goodies. These events are handled by their respective environment, and when they finish execution, they enter what is called the callback queue. There, they wait until the call stack is completely empty. Once the call stack in empty (all Javascript code is done running), the event loop kicks in, pushes the callback functions waiting in the call back queue on top of the stack, one by one. A great way to visualize what the above paragraph just said is to try it out yourself at loupe by Philip Roberts. He’s an amazing guy and you should totally check out his talks.

So that was it for this little article. Hope to have helped you. Keep digging.

Edit: The section below this has some major issues, that I only found out after pushing into github. Read edit section.

I always admired the sites which did not reload upon clicking links here and there, but simple gave me whatever I requested for, with grace. Sites like Facebook, Twitter and Youtube extensively use it, and the application hardly reloads after the initial reload. Here’s my attempt on making something similar.

Firstly, I downloaded a free HTML template from Online Casinos. The links had to be edited. The pattern I used was to replace, for example, any (internal) link pointing to example.html to #/example.html. What it did was 1.) prevent the page from reloading, and 2.) putting the requested location to some place from where I can extract it with Javascript.

Next, grab that location of the hash. The Javascript’s built in method window.location.hash provides the page’s current hash. We drop the first char from the returned hash as it is the hash (#) character itself. The hash value is essentially the location to be navigated to, hence, we use some string manipulation to craft a new URL from it, and make an AJAX request to fetch the contents of the page requested, and insert it into the div specified through Javascript.

For example, suppose we are on about.html page. Now if I click ‘contact’ link, the link would change to /about.html#/contact.html, the hash value would be grabbed by the window.location.hash method, a GET request is fired to get that location with a XMLHttpRequest object, the response is inserted with innerHTML method on the div, and using the window.history.pushState() method, we update the URL to /contact.html, to ease sharing. All this, in the blink of an eye. Cool.

I could do it in two different ways. One was to just place the text in those files and inserting them into the template. The drawback of this was that if a user directly visits that page, he/she would just see plain text. For example, check this link out. The Javascript code for that was,

The separate callback function for getHash was necessary because onclick() event fires before the hash is changed, and it would result in the script grabbing the previous hash. As already mentioned, the navigation is smooth if one visits index.html and then other links, but try getting the about.html page first. All you’ll see are a few lines of text.

A sloppy solution to the above problem was to replicate the entire index page with varying content for each of the page, and then replace entire DOM on anchor click. You can imagine this is not at all smart, and would destroy the point of this site. Not to mention the extra bandwidth to reload the same resources on every request. Here is the implementation for this method.

What would be the smarter way? Perhaps, making sure the first page to load always downloads the entire html every time, and subsequent requests to be made to download the changed content. I will be implementing this solution shortly. Drop in your ideas too, and share if you enjoyed reading this.

Edit

So, the above code seemed to work on my localhost, but there were some serious (cross origins and some logical ones) issues with it, so much that I considered to learn relative and absolute links all over again. Anyways, I also happened to redesign my blog during this time (redesign in the sense changing the template), and I am working to implement AJAX loading on all links here on my blog. So far, all links on the home page seemed to work as expected (AJAXified). I am using the document.write() method, so judge me on that. You can check them out here. The code snippet is following.

What do you think about it? It feels a little buggy at times, and sadly, Internet Explorer isn’t supported yet. But for most of it, chrome and firefox are working like a charm. Hope to get all links covered under this thing, which would be nice. Sadly though, the browser tab shows loading for all the third party resources on the page which kill the purpose of this thing. Anyways, feel free to correct or improve this in the comments below.