That's one small step for a developer, one giant leap for the web

Photo by Joey Csunyo on Unsplash

I want to talk about those brave JS developers who changed web-development forever.

JSON

JSON - born out of web platform limitation and a bit of creativity. There was XMLHttpRequest to do request to the server without the need to do full reload, but XML is "heavy" on the wire, so Douglas Crockford thought of clever trick - we can use JavaScript Object Notation and eval to pass data from the server to the client or vice versa in easy way. But it is not safe to execute arbitrary code (eval) especially if it comes from 3rd party source. So next step was to standardize it and implement a specific parser for it.

Later it becomes standard for all browsers and now we can use it as JSON.parse.

History note: Crockford says that JSON was in use at Netscape as early as 1996 he just rediscovered it and standardized it in 2001.

Document.querySelectorAll()

There were methods like Document.getElementById() and Document.getElementsByClassName(), but it was clumsy to use. John Resig created handy library to work with DOM - jQuery . The most handy part was universal query selector, which later wsa standardised as Document.querySelectorAll().

History note: jQuery created in 2006, it was partially inspired by Dean Edwards' cssQuery (appeared earlier). XPath have a similar idea (first appeared in 1999).

Side note: also jQuery got widespread because it has a lot of workarounds for browser quirks and inconsistencies, I guess we can say that jQuery made cross-browser development more accessible as well as AJAX.

CommonJS, AMD, Requirejs, Modules

Server-side story

Node.js was created by Ryan Dahl in 2009. There were server-side JavaScript environments before, like Netscape's LiveWire Pro Web, but they didn't get that much attention.

As soon as the server-side environment appeared, there was a clear need to create a standard to share modules. Kevin Dangoor in 2009 proposed CommonJS (initially named ServerJS) as a standard for specifying an ecosystem for JavaScript outside the browser.

Client-side story

jQuery had plugins, those plugins were based on IIFE pattern and script tag. Something like this

(function ( $ ) {
  $.fn.plugin = function() {
    //...
    return this;
  };
}( jQuery ));

Distribution of plugins happened via copy-pasting.

CommonJS originally was proposed for the server, but soon was ported for the client (Requirejs).

The main issue with CommonJS is that it is synchronous, which is not very comfortable for client-side, where you have to deal with network latency. Next step was Asynchronous Module Definition(AMD), which was asynchronous and allowed to specify dependency. CommonJS and AMD were equally popular, so people come up with UMD, which compatible with both.

One issue with asynchronous modules is that they can create a cascade of downloads, which can be pretty slow. In response to this developers invented JS bundlers, like Browserify and Webpack. It appears this is not a trivial task and it would be much easier if the module import process would be static. And this idea leads to ES6 harmony modules which were officialy accepted by TC39 on July 2014.

Webpack, Requirejs, and Promises lead to later dynamic import proposal.

Promises

In 2011, Promise concept was introduced as jQuery Deferred Objects.

In 2012 it was proposed as the spec for ES2015.

Other

• jQuery.ajax() and other AJAX libs inspired fetch
• anchor based (aka "hashbang") client-side routing inspired History API
• What else I forgot?

I see a pattern here

I do not want to minify value of contribution by people who stand behind browsers development and web standards. They all do hard work of creating APIs which will be used by millions of developers. It is pretty hard to nail it right from the first try. In this sense, JS developers have the opportunity to test API design in the field first and later when it is acknowledged and accepted it gets adopted by the web platform.

It seems like a good practice to test drive proposal first before it gets accepted, like what they do with TC39 proposals and babel plugins. But for sure it is not possible to test all proposal this way, some proposals require radical change and need to be driven by browser vendors first.

What's next?

I wonder what is the next thing pioneered in JS will be adopted by the platform.

Is it Virtual DOM with time slicing, deferred rendering and hydration popularised by React? It seems like it is next JSON - hacky enough (think about throwing Promises), creative enough, born out of limitation of the web platform.

Is it CSS-in-JS? It seems like next jQuery - what web platform offers is clumsy and hard to use, so people built tools around which are nice to use.

I don't know, this is just some food for thought 🤔. Let me know what do you think will be the next thing?

Follow me on twitter and github.