The Complete History of JavaScript, TypeScript, and Node.js
A Little Bit Of History
You already know what are the advantages of using JavaScript in the world of corporate software engineering, and what are the 5 reasons why Node.js is a great choice for start-ups. What you don’t know is how it all started.
The language itself has come an extremely long way from being used as only a facilitator of interactions on websites to a fully-fledged, universally useful programming language. We will take you on a journey from its creation to the TypeScript days.
JavaScript’s Infancy
In the very early days of the Internet, every website was static. Until 1995, there was no way of making websites dynamic; meaning that it was impossible to change the content of a webpage in response to different conditions. That’s why in 1995, JavaScript was created. Brendan Eich, the language’s creator, was given a simple task — to make interactivity possible. Eich’s creation had a clear goal, and as such fulfilled it. For a long time, that was it.
As the father of JavaScript said:
I was under marketing orders to make it [JavaScript] look like Java but not make it too big for its britches. It’s just this sort of silly little brother language, right? The sidekick to Java.
Asynchronous actions in the browser
At one point, people woke up, realizing that more can be done. Pages still had to completely reload to show new information, which resulted in a slow and inefficient process. There had to be a way to prevent websites from reloading to get and process new data, right?
The first widespread example of such an innovation was when Microsoft allowed Internet Explorer 5 to make HTTP requests. In 1999, they implemented an object called “XMLHttpRequest” which allowed for getting data from an external source without reloading the page.
Why was this functionality even implemented? Long story short, MSFT did that just so Outlook’s website fetched emails in the background. The long-term effects were much more than making one website run better.
According to Monika Mazurczak, Frontend Developer at ITMAGINATION:
“[Microsoft’s XMLHttpRequest] was one of the two most important developments in the world of JavaScript. Asynchronous actions allowed users to do more without having to reload the page which was a huge win in terms of UX.”
There was still an additional big problem to address. There were large differences in JavaScript engine implementations, and even there were different language flavors for each browser! Netscape had JavaScript, while IE had Jscript, for example. Even though MSFT’s implementation was to some degree compatible with JavaScript (as both were based on the ECMAScript specification), the implementation was fundamentally different.
jQuery — building for different browsers without a headache
In 2006, the world saw a solution that aimed to address the problem. Fourteen years ago, jQuery saw the light of day, abstracting the differences in implementations. The image you see above was how jQuery handled the differences in implementations between browsers. What you see below is just calling the “jQuery.ready()” function after a page finishes loading.
Do you know how it looks would it look like now? Thanks to the standardization of implementations, it is pretty straightforward. There are few ways to go about this, and this is one of them:
jQuery would become the most popular JavaScript library, and by a large margin. It still is the most popular library by market share to this day, where it is present on approximately 79.8% of the top 10k popular websites.
In comparison, React.js, which is widely regarded as a modern standard for front-end development, React is used on 43.7% of the top 10,000 most popular pages. When it comes to the front-end side, jQuery was the final important step to get the ball rolling. Consistency across browsers allowed developers to create the apps they wanted to, but previously couldn’t.
2009 — arguably the most important year for the ecosystem since the release
Three years later, in the arguably most important year for the whole JavaScript world, there were two events that changed the ecosystem.
One of these events was the initial release of Node.js, the other one being the first revision of the language — ECMAScript 2009 (better known as ES5) saw the light of day.
The First Event — ECMAScript 2009
ES5 brought many features that were absolutely necessary. Strict mode, essential operations on arrays such as filter, map, and reduce ( “The Holy Trinity of Functional Programming”), the JSON object, property getters & setters, and much much more that is outside of the scope of this article.
The Second Event — The Birth Of Node.js
The creation of Node.js made JavaScript a language that is relevant because the runtime enabled us to execute scripts outside of browsers in addition to in-browser execution. Interestingly, it was not the first attempt at allowing the execution of JavaScript on the server-side. Netscape’s Live Wire was the first one, but since it might be the first time you have heard about it; that says something about the solution’s popularity. While it does warrant an honorary mention, we won’t dedicate much more space to it.
Now that JavaScript was ready for serious use, there was one more aspect that needed to be fixed before the language could see some serious corporate adoption. The language is dynamic, without a type system.
You see, when you are thinking about writing an app that will get bigger than your standard beginning starter projects, you will run into problems sooner or later. Strongly typed languages, such as Java or C# give you a layer of safety — they will catch some bugs themselves, without having to involve you, the developer, in any way. That’s because they will ensure the correctness of the code themselves upon running it.
TypeScript Comes To The Rescue
There were some attempts at making JS more predictable, however, Microsoft might have proposed the best solution to date. Typescript, JavaScript’s superset, saw the light of day for the first time in 2012. Its purpose was to facilitate the development of large applications.
It has some features that made it extremely popular among the pros.
First of all, since C# and TypeScript were created by the same person, they share some similarities. Of course, don’t expect the two to be twins.
Second of all, migration from JavaScript to TypeScript is easy — you can migrate your codebase step by step.
Third of all, TypeScript integrates with e.g. React and Vue on the front-end seamlessly. On the backend, all major libraries work with TypeScript out of the box. Nest.js uses TS by default; while Express.js and Fastify have their additional type definitions for you to install and forget.
If whatever library you need is not on the TypeScript hype-train, you generally will still be able to use them while enjoying the enhanced design-time support. Users contribute type definitions for free for all the most popular libraries, and in the worst-case scenario, you can write your own declarations. In other words — if you’re using it — there are type definitions for it.
What does the future of JavaScript hold?
To end with, JavaScript has truly come a long way and assumed the role nobody dreamt it would. Even though many ridicule its type system, or its inconsistencies, the whole ecosystem proved itself as a solid contender more than once.
Throughout JavaScript’s history, there were two parties that made it perhaps the most dominating general-purpose programming language. Those two parties were open-source contributors and ECMA. The resilience and dedication of developers have lifted the language out of a big slump, bridging and fixing its gaps. ECMA gave them a solid foundation to build on, augmenting the language with requested features.
The future of JavaScript is not exactly clear. It seems as if the case for its popularity depends mostly on the WebAssembly project’s future. Long story short, it is possible for some time to compile languages, such as C++ or Rust to the code that browsers can use. Its use has some severe limitations, however, as e.g. you cannot access the DOM (page’s structure) and you are restricted to relatively new browsers only.
It might turn out, that JavaScript will stop being the only programming language being able to execute in browsers’ engines. If this happens, the superiority of Eich’s creation might be challenged, although there will be one aspect of it, that will remain true — the simplicity of the language.
PS: We are hiring Node.js developers. For all the Node.js pros we have good news — we are hiring. Whether you are a backend developer, React developer, React Native developer, or an Angular developer, we are waiting for you.
Originally published at https://www.itmagination.com.
