What is JavaScript ? What is modern JavaScript ?

JavaScript is a programming language that first appeared in 1995 [1] to give browsers their first type of smart functionality. At the time, web browsers were in dire need of some type of programming language, because without it, browsers acted as 'dumb' consoles that required to constantly communicate with remote web servers to change their workflow. With programming language support, it became possible for browsers to execute actions locally & dynamically -- on a user click, a mouse hover or key stroke -- without the need to constantly communicate with a remote web server. Thus the first JavaScript generation was born.

Web page events & DHTML

A distinguishing characteristic of this first JavaScript generation were events on web pages. At the dawn of the web, everything delivered to browsers was web pages structured with HTML (Hypertext Markup Language), leaving no way to perform further activity once the web page was delivered. JavaScript opened the door to a major breakthrough in dynamic behavior, because a web page could now be accompanied by programming logic that was executed on a user's browser.

With JavaScript, it became possible for a user loading a page...hovering over an image...clicking on a title to further trigger logic like presenting a message...changing the actual image...changing the underlying text all without the need to contact the origin server where the web page came from (i.e. everything was done locally). Take a look at the following web page example -- which is perfectly valid to this date -- illustrating the use of events.

If you download or directly open the web page on a separate tab, you'll notice the first thing the page does is present the pop-up message 'Welcome to the page'. This message is triggered by the JavaScript onload event -- associated with the loading of the page -- declared in the HTML <body> element. The onload event is linked to execute the built-in JavaScript alert method which is used to present pop-up messages.

Next, you'll see an HTML <img> element declared with both the JavaScript onmouseout and onmouseover events. The onmouseover event is triggered when a user passes his mouse pointer over the <img> element, while the onmouseout event is triggered when a user moves his mouse pointer away from the <img> element. In both cases the events are linked to custom JavaScript methods seen at the bottom of the page which change the <img> element src attribute. In summary, what these events and JavaScript logic do is change the image source when a user moves his mouse pointer over and away the HTML <img> element.

Finally, you can see an HTML <h1> element with the JavaScript onclick event which is triggered when a user clicks on an element. In this last case, the onclick event is linked to inline JavaScript which alters the element's innerHTML attribute which corresponds to the element's content (i.e. the one surrounded by <h1> and </h1>).

As you can sense with this example, this ability to mix and match events with JavaScript programming logic gave way to a rich mix of possibilities for web pages. It became possible to perform mathematical calculations, visual effects and deliver an overall better user experience, because it was no longer necessary to contact a web server to change a browser's state.

One of the first formal names these JavaScript techniques received was DHTML (Dynamic HTML). DHTML was classified as anything that combined HTML, JavaScript and CSS (Cascading Style Sheets) with the purpose of generating dynamic effects (e.g. animate text, rollover buttons, show/hide elements) based on a user's actions (e.g. mouse click, hovering or pointing the mouse over elements). In fact, to this day there are still sites that run and even distribute DHTML [2] and are perfectly compatible with the latest browser versions.

Although DHTML was a step forward over web pages without JavaScript, as web page expectations grew it became less than ideal. DHTML's biggest flaw was it required the entire web page payload (i.e. JavaScript programming logic & structured data) to be delivered in one step, with any additional payload requiring to get a newly generated web page from the origin web site yet again.

As the web grew -- with e-commerce, interactive content & video media -- the expectations on browsers also grew and with it those of JavaScript. Suddenly, that first generation of JavaScript that delivered 'modern' functionality for its time, started to appear a little rough. So JavaScript changed, the JavaScript language itself got a facelift like other web languages (e.g. HTML 5, CSS 3), a series of other techniques emerged to make JavaScript more powerful and JavaScript libraries were created to avoid having to reinvent the wheel for everyday JavaScript tasks.


Starting in 2004, JavaScript usage underwent a major shift with a technique called AJAX, an acronym for 'Asynchronous JavaScript and XML'. AJAX brought a new era of web pages capable of updating dynamically without any apparent communication with their origin web site. Of course, in the background a browser established communication with its origin web site again, except it was now done asynchronously via JavaScript. In this manner the origin server responded with new data -- in XML or JSON (JavaScript object notation) -- that was then integrated into the web page in a transparent way (i.e. without a full-page refresh).

AJAX became the norm for data intensive web pages (e.g. Maps and Email) where it was unfeasible to deliver the entire payload in one step or for web pages where constantly making full-page refreshes resulted in terrible user experiences. But the wide use of AJAX in all but the simplest web pages, brought to light a series of problems that affected web pages and JavaScript since their inception.

The first was JavaScript as a language was severely fragmented, mainly due to the browser wars [3]. The browser wars was a time of fierce competition between browser creators to dominate the market through 'bigger & better' browser features. This in turn led to half-baked or innovative JavaScript features that only worked with certain browsers. This fragmentation meant the same JavaScript logic didn't necessarily work as expected across all browsers, leading to increasingly complex JavaScript designs needed to make web pages work equally across multiple browsers.

The second issue was JavaScript relied on the DOM (Document Object Model) to access and navigate the structure of web pages. There's really no quick way to explain the DOM [4], but suffice to say you already saw a little bit of the DOM in the initial web page events example. All web page events (onload,onclick) are technically known as DOM events and a web page's HTML elements (<img>, <h1>) are technically known to a browser as DOM nodes which have DOM methods & properties (innerHTML). So writing JavaScript logic required a deep understanding of the complex scheme of conventions and methods used by the DOM. With AJAX becoming all the more common for web pages, the DOM simply represented another adoption hurdle on top of JavaScript fragmentation.

To alleviate these last problems, web pages making heavy use of JavaScript relied on libraries to both standardize JavaScript behavior across browsers and make it easier to update web pages without direct use of the DOM. In this area, the jQuery JavaScript library -- created in 2006 -- established itself as the most popular choice for this purpose, which to this date is among the most used JavaScript libraries.


The jQuery JavaScript library hit critical mass because it solved a major JavaScript pain point. It guaranteed the same JavaScript logic could work across all major browsers and it also provided a more natural way to access and navigate the structure of web pages compared to the DOM. In addition, with jQuery's wide adoption, it also led to a flourishing ecosystem of plug-ins and sub-projects (e.g. jQuery-UI) based on jQuery which made its value proposition even more attractive.

But as explosive as jQuery's usage has been to date, jQuery is still rooted on foundations from early web page design practices. The following example illustrates a web page with jQuery's main functionalities.

The first important aspect of this jQuery example lies in the HTML elements (e.g. <h4>,<button>, <div>) being declared separately from any DOM events or JavaScript logical actions -- notice, there are no inline events (onload,onclick) or JavaScript methods declared directly on the HTML elements like in the previous web page events example.

This design is underpinned on the fact that HTML elements were originally conceived for presentation purposes (i.e. how to display a web page) and not on how to react to dynamic actions (i.e. a user clicking or hovering over an element), hence both HTML and JavaScript are separate. This separation requires the use of references to interconnect HTML elements with their JavaScript logic. As you can see in the example, the various HTML elements all contain either an id attribute or a CSS class inside the class attribute, which are used for identification purposes.

Once HTML elements have identifiers, it's possible to access them for the purpose of manipulation. Toward the bottom of the example and wrapped in JavaScript's <script> element, you can see the jQuery syntax $("#...") and $("<element_type>.<css_class>") used to access HTML elements. Once jQuery references are established for HTML elements, it's possible to associate events (e.g. click, toggle) to elements that further trigger logical actions (e.g. update text, make an AJAX call).

Notice how all the JavaScript actions in the example update the <div id="banner-message"> element when something happens in other HTML elements. In addition, look at the last JavaScript declaration which is an AJAX call -- provided by the jQuery built-in $.ajax method -- that also lives separately from its HTML element and relies on many references to do its work.

Now let's take a step back and look at the good, the bad and the ugly of this design. The good part is the design is simpler and cleaner than using the DOM. With jQuery, event handlers and logic are no longer sprinkled around with HTML elements, but instead are clearly separated. Another positive aspect of jQuery is how it accesses HTML elements. Instead of having to work directly with DOM methods and properties (e.g. getElementById(), parentNode(), childNodes) that are difficult to master, jQuery supports simpler and more powerful methods to access HTML elements (e.g. by HTML element type, by id attribute value, by CSS class attribute value).

The bad part of jQuery's approach is that it can become overly complex to decipher and debug web pages with dozens or hundreds of elements & actions. So for example, it isn't the use of one or two AJAX calls in this format that presents a problem, but rather it's the use in web pages that require dozens or hundreds of AJAX interactions, where the management of references, data updates and error handling in this manner can quickly become difficult to understand.

The ugly part of jQuery's approach comes from the difficulty to express relationships between HTML elements and their actions. Notice how the example creates a reference to the <div id="banner-message"> element which is then used across the various JavaScript event handlers. The ugliness here stems from the fact that each of the JavaScript event handlers needs to be associated with a reference to the HTML element, instead of the HTML element being associated with JavaScript event handlers and related HTML elements that influence it -- in other words, all the actions associated with <div id="banner-message"> are spread out, instead of being grouped in a single location.

As the web continued its evolution, newer and larger demands were placed on web pages, browsers and its now staple language called JavaScript. Single page applications (SPA) became a common theme with every functionality under the sun packaged into one page, smartphones took over as the most popular device to access the web and real-time web functionality became an almost default expectation. So once again, that 'modern' JavaScript of yesteryear started to appear dated. JavaScript components made their appearance to ease the creation of more complex JavaScript user interfaces (UI), JavaScript libraries soon became full-fledged JavaScript frameworks and the JavaScript language became so limited for certain functionalities, that entirely new languages came into existence that were later converted into what else, JavaScript!

JavaScript components

Components are an old concept in software engineering based on the premise of reusable pieces of software that encapsulate logic and data. If you've done or read about OOP (Object-Orientated Programming) then you should be fairly familiar with the concept of components, as both concepts share common design features (e.g. reusability, encapsulation). While it was possible to create JavaScript components since the early years of the language -- via its OOP facilities [5] -- the practice never really took off until a series of frameworks made the use of JavaScript components easy and commonplace.

The main benefit of JavaScript components is they allow HTML and JavaScript to be rolled into the same unit and not live separately, unlike the process illustrated in the previous jQuery example. With JavaScript components it also becomes possible to re-use the same unit multiple times in the same application or across projects. In addition, JavaScript components also offer the possibility to create parent-child relationships between components so actions and data are shared. And finally, with JavaScript components it becomes easier to test UI behavior, since presentation and logic are encapsulated into the same unit.

Though the purpose of JavaScript components is clear, implementation wise JavaScript components vary -- sometimes widely -- depending on the underlying library or framework where they come from. Much like the selection of other web technologies, JavaScript components require you invest time learning subtleties that only work in the context of certain libraries or frameworks. The most popular JavaScript component approaches -- of which I'll go into greater detail later -- include:

JavaScript MVC

With the surge of AJAX, many designers realized it was possible to deliver a single web page and simulate the functionality of dozens of web pages via AJAX, giving the end user a cleaner experience rather than him jumping from web page to web page. This paved the way for Single Page Applications or as their also known by their acronym: SPA.

Like other demands before it, SPA really pushed the boundaries of what was possible with JavaScript. Let's start this discussion from the previous jQuery example which is a 'toy' web page that uses a couple of JavaScript event handlers. Now envision a real-life web page to display a product catalog, conservatively this type of web page should have a dozen or more JavaScript actions, given a toy web page has a couple of actions. Managing this amount of JavaScript actions is pretty doable with jQuery, even though you're likely to feel some of the design strains I already mentioned (e.g. difficulty debugging, managing error handling).

But let's not forget you're now doing a SPA. That single product catalog web page with a dozen JavaScript actions will now be lumped together with a sales web page that also has a dozen or more JavaScript related actions, as well as a checkout web page with a dozen or more JavaScript related actions and many more pages like that. At the end, you're likely to have the scenario I forewarned when I talked about jQuery's limitations: hundreds of elements & actions all lumped together in a single page.

So how can you realistically manage hundreds of elements & actions all lumped together in a single page with JavaScript ? Easy, you organize everything with a tried and proven approach. As it turns out, since the dawn of the Internet web sites had relied on server side stacks in languages like PHP, Java & Python, to design software as interconnected parts that favor maintenance & reusability.

These design patterns consisting of things like web page routing (i.e. what page sequence to follow for a given task), business logic execution and data validation, are known by the broader name Model–View–Controller (MVC) architecture [6].

So faced with the complexities of SPA, JavaScript went ahead and adopted functionalities -- such as routing and dependency injection -- that were once reserved for server-side languages like PHP, Java & Python. And just like that, JavaScript libraries soon became full-fledged JavaScript frameworks that were able to deal with MVC architecture entirely on the browser.

The most popular JavaScript MVC frameworks -- of which I'll go into greater detail later -- include:

JavaScript on the server

Of all the potential JavaScript novelties, the one that can be the most surprising for web development veterans is the idea of running JavaScript on a server. Even if you don't agree with the idea of JavaScript components or JavaScript MVC, you can't deny both are still bound to the browser where JavaScript has always lived and dominated.

So why would anyone want to run JavaScript on the server with so many solid server language choices like PHP, Java and Python ? It turns out someone encountered an unresponsive UI while uploading a file and ended up using JavaScript on the server to get real-time updates [7]. Several years after this experiment, JavaScript on the server is now commonplace.

JavaScript on the server is dominated by Node.js, a platform based on the same V8 engine used by Google's Chrome browser. What's interesting about Node.js isn't its ability to run JavaScript on the server per se, but rather its ability to provide asynchronous & non-blocking behavior, making it an ideal choice for real-time web applications (e.g. chats, live event publishing).

I can't emphasize enough how Node.js is a platform, which makes it many things. Node.js is a run-time environment for JavaScript server applications, this means it's like a regular web server, it just uses an event loop design which makes it different and ideal for real-time applications. Node.js also has it own API for things like HTTP operations, processing buffers and DNS queries, among other things, this means it's also framework. And in addition, Node.js also comes with a package manager called npm, which means a lot of modules/libraries/frameworks -- 250,000 worth as of last count -- get written for Node.js.

It's also important to note Node.js doesn't preclude using any of the JavaScript topics I already mentioned, in fact, Node.js actually complements them. For example, you can use both a JavaScript MVC framework like Angular and React JavaScript components -- or one individually -- with Node.js. However, be aware Node.js supports thousands of other JavaScript packages which can be confusing at first. For example, you'll find Node.js packages like Sails and Express that are also JavaScript MVC frameworks, just be aware these last packages are JavaScript MVC server side frameworks, not to be confused with JavaScript MVC client side frameworks like Angular or Ember. So it's possible to end up using many frameworks in the same application (e.g. React for JavaScript components, Angular for JavaScript MVC on the client, Node.js as the JavaScript server run-time and Express for JavaScript MVC on the server.)

I advise you to take your time learning about Node.js and server side JavaScript development, it's one of the most intimidating pieces of JavaScript technology due to its wide scope and amount options. However, it should be worth the effort, since JavaScript on the server will unequivocally require you to navigate the Node.js ecosystem.

Languages that produce JavaScript: JSX and Typescript

Did you know the JavaScript language was put together in 10 days[8] ? That's not a typo, it was ten days! Can you imagine trying to create a solid software application in 10 days, let alone creating a programming language in the same time frame ? The reality is JavaScript at inception was never conceived for such a wide range of purposes like it's used today.

JavaScript's syntax and functionality shortcomings are pretty glaring compared to other programming languages, how bad ? Pretty bad, as in 'break the Internet' bad. This is a true story about how JavaScript broke the Internet [9] which is why I find it so interesting. Let's do a quick exercise to show why and how this happened with JavaScript.

How do you left-pad a string in your favorite programming language ? In Java you can use the language's String.format method, in Python you can use the language's str.rjust method, in PHP you can use the language's str_pad method, but how about JavaScript ? Well you won't find a built-in method for this, you would need to use JavaScript's String object and create your own implementation -- like this simple left-pad method. And this is the crux of the problem with JavaScript, for something as simple as left-padding a string -- a feature that's covered out-of-the-box by most programming languages -- you have to write your own implementation.

In this true story, it took a couple of lawyers alleging copyright claims on an apparent innocuous name, to force a developer to unpublish a JavaScript library that offered a left-pad method. As it turns out, this simple JavaScript library with the functionality to left-pad strings was used by thousands of other JavaScript projects, which in turn broke thousands of Internet sites that relied on it. All legal issues and availability assumptions aside, this really shows the functionality holes in JavaScript. You can blame the lawyers all you want, but it's more telling that thousands depended on a third-party JavaScript library for functionality that's standard in most programming languages.

To alleviate some of these shortcomings and in the face of more demanding JavaScript functionalities required by JavaScript components, JavaScript MVC frameworks and JavaScript on the server, various initiatives have emerged to supplement JavaScript and make the language more flexible and powerful. Among the most important initiatives are:

So what is modern JavaScript ?

After this walkthrough of JavaScript's facets throughout the years, you might be left puzzled pondering "WTF is modern anyways ?" Well in 1995 modern was JavaScript events, in 2004 modern was AJAX, in 2006 modern was jQuery, in 2010 modern was Angular 1, in 2012 modern was Node.js, in 2014 modern was React and in 2016 modern was Angular 2. But don't be fooled, even Angular 2 from 2016 has some traces of the earliest JavaScript events from 1995, just as React from 2014 has some influence from AJAX created 10 years earlier.

So modern JavaScript is really a wide and moving target. You may have learned JavaScript five years ago and some of those techniques may be considered old by today's standards, just as you may know JavaScript techniques from 20+ years ago that are still considered modern best practices. My intent is to take you on a guide through JavaScript's various ins and outs to learn modern JavaScript as it's known today.