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 inspiredfetch - 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?
Top comments (12)
Thanks for sharing, this post is remarkable 👊 👊
Most of the environment we know as web developers are quite recently and yet most people ignore where does it comes from and why it changes so fast.
With WASM, service workers and web components 2018, is a great time for web development.
So glad you didn't mention npm! That one has been a right mess from the start and has only recently started to learn from other package systems that solved these problems years ago. It's a shame, because with a decent package system the whole js ecosystem could be a lit further along than we currently are.
Stream based processing popularized by RXJS might become part of the standard.
Do you have a link to the proposal or a draft? I'm intrigued
here you go, github.com/tc39/proposal-observable
Sorry for the wording. It was wishful thinking. This is not going to happen anytime soon. :(
Very good post. Kudos, but you missed a few innovations that made a real radical change as well like RxJS and innovations in JavaScript runtimes.
To be fair I don't see radical changes from RxJS. Maybe I use it wrong or I miss something, but in reality I haven't need anything more than
debouncefrom reactive/stream libraries on the client-side. On the other side streams on the server-side is a real deal - you can use streams for things like Gulp, stream response from the server, for queues etc.There is also interesting story about ability to cancel request with RxJS+Redux, which I haven't tried.
What do I miss here?
Yes on the server side it brings an amazing set of functionality. Treating stuff as stream has performance advantages on certain applications. Regarding the story of cancelling promises it's not just promises any even can be cancelled. That was one of the powerful functionalities. I felt it to be extremely useful as I had some unorthodox usecases at work to implement streams in existing javascript app.
So many people are praising this. I want to start by saying thanks for the history, but the writing was Helter skelter, it didn't feel researched or thought through. When I finished reading, I felt the article was different from where it began.
Kudos for the thoughts, and thank you for explaining.
I will mostly agree with this (with small "but").
I'm doing basic fact-checking and if I'm not sure about something I will add something like "I think" or "I guess" etc. I'm trying to be intellectually honest (first of all with myself).
If you refer to the fullness of research, for sure I believe I missed other interesting things. I focused on things that I know. I also agree that it lacks some links to the sources. And I can explain why. This post took me about half a day (not exact number). I have limited time and a limited amount of energy to accomplish the post. If I will iron-out post I can lose interest and never publish it, so I choose to finish it as soon as it "good enough".
If writing blogs would be my job, I would spend more time on it. I would do more thorough research. I would ask friends to edit it for me. But as of now, this is a hobby. I'm doing it in between work, attempts to learn something new and personal time.
My intent is to share some ideas I have, to show perspective.
It is not a rewarding experience so far - I do not get much response to my posts (I get likes and followers), but not sure if people understood what I tried to say, do they agree or not, do they have a similar experience or not.
This is why it is what it is.
In addition to basic fact-checking, I also do basic grammatical check and if I use somebody's else material (code snippets, photos) I place a link to the author.
RxJS observables