Asynchronicity in JavaScript, a Short History
Tags: javascript
Published: 2019-10-07 13:39:22

#Asynchronous City!

If you work in web development, I'm sure you've dealt(probably with plenty growing pains) with asynchronous actions. Adding time as an element of coding adds to an already complex task. There's no point in lamenting it though, because asynchronous behavior is absolutely vital to any modern web(especially) app. There was a time, though that this wasn't the case! Let's take a look at where we were and where we are now.
<br><br>


#Back in the day...
<br>

Early in the internet days, when browsers were first becoming widespread, most web pages were served as complete HTML pages. Every time a user performed an action, a completely new page was rendered according to the user's input. Even if only one piece of information on a page changed, an entire 'new' page had to be sent from server to client. This led to the same information being sent over and over. Yikes...Fortunately for us, that didn't last. 
<br><br>


#Early Asynchronicity
<br>


In '96, Microsoft introduced the iframe tag in Internet Explorer(yeah, the browser we all love so much). It could load or fetch data asynchronously. A few years later, their Outlook Web Access team conceptualized a scripting object that contained methods responsible for asynchronously transferring data between web browsers and web servers. The Outlook Web Access team's idea came to fruition as part of the second version of the MSXML(Microsoft XML Core Services)library in the form of XMLHttp(Extensible Markup Language HyperText Transfer Protocol). The MSXML library shipped with Internet Explorer in '99. 

<img src="https://thepracticaldev.s3.amazonaws.com/i/q4k1kbai78kxys9usgvl.jpg"/>
<br>
#XMLHttpRequest(XMR)
<br>

Shortly after Microsoft's efforts to create XMLHttp, Mozilla created a JavaScript wrapper for Microsoft's XMLHttp interface. This wrapper(XMR object) as a JavaScript object later became the defacto standard in all major web clients. It become so ubiquitous that the World Wide Web Consortium(W3C) published a Working Draft specification for the XHR object in 2006. The standardization that came along with this led to cross-browser JavaScript libraries that allowed developers to use the XHR object indirectly and more succinctly. The most popular of these libraries was(is) jQuery. According to builtwith.com, jQuery is used on more websites than any other JavaScript library(<a href="https://trends.builtwith.com/javascript/javascript-library/traffic/Entire-Internet">by far</a>).
<br><br>
<img src="https://thepracticaldev.s3.amazonaws.com/i/wpzysz5kstobismfv1oq.png"/>
#jQuery and further asynch development
<br>
jQuery and libraries like it made asynchronous web development more accessible and because of that, it became more common. One drawback in this time period, though, was the manner in which responses from asynch requests were dealt with. In order to handle action after action, many callbacks would have to be nested inside of each other, possibly creating what is affectionately referred to as <a href="https://en.wiktionary.org/wiki/callback_hell">callback hell</a>. Of course APIs were written to deal with this, but as a part of ECMAscript 2015, a newer, more efficient approach became native to JavaScript:
<br><br>
#Promises
<br>
<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promises</a> are a modern way to deal with asynchronous actions in a clear and concise manner, and since they are native to JavaScript, they are widely available in cross-browser support! If you are unfamiliar with Promises, they are definitely worth incorporating into your knowledge base.




while (life.left.length > 0) {
life.do = coding();
}