In this chapter we will learn a little of historical context about JavaScript and NodeJS.

Historical context is very important in software, because we're often using tools built by other people, and we're therefore influenced by decisions taken in the past by them.

Understanding the reason for those decisions, and how the tools we use came to be the way they are, will help us feel a little less confused about what we're doing.

JavaScript started as a simple language designed to make web pages interactive.

In the 1990s, web browsers like Netscape Navigator added JavaScript so that developers could write code that runs directly in the browser.

The original idea was to have Java as the core language for making websites (with the so called "Java applets"), and JavaScript just for minor stuff.

The core design was done by Brendan Eich, who at the time was an employee at Netscape, in less than 2 weeks.

But most people preferred using JavaScript to Java, and also Java applets had some security issues at the time, so eventually Java was dropped as an option and JavaScript became the de facto standard for web development.

JavaScript is an interpreted language, as opposed to compiled languages like C.

Code written in a compiled language gets turned into a binary, and the binary gets fed directly to the CPU of the computer.

Interpred languages, on the other hand, tend to be more user-friendly, and are closer to how humans think ("high level") rather than to how machines work ("low level"); so they usually have a virtual machine built to run their code.

A virtual machine is a special program that sits between the code you write and the CPU, and executes your code (because the CPU cannot understand it).

This allows you to program without knowing too much about the underlying machine, but it also has a cost in terms of performance, because the computer is not running just your program; it's running a program (the virtual machine) that runs your program.

As web applications became more and more complex, there was demand to improve the performance of JavaScript. The V8 engine is the interpreter that powers JavaScript in Google Chrome. It was developed at Google and released in 2008.

While the older JavaScript engines were mostly traditional virtual machines, the V8 engine is a JIT (just-in-time) compiler.

The JavaScript code gets fed to the V8 engine, and the engine tries to compile parts of it as native binaries on the fly. This allows you to have the experience of a high level language, with performance that it's a little closer to low level languages. This has made JavaScript the fastest high level language in the world, bit of a "best of both worlds" thing.

While being easy to use and quite fast to execute, after the release of the V8 JavaScript kept having a huge limitation: it could only run inside a browser.

Why is that a problem?

Well, since browsers execute code fetched from millions of different sources on the internet, they can easily incur into malware, so they're "sandboxed" from the rest of the operating system.

JavaScript could not access the file system and other local resources on your computer (at least not easily like other languages could), so that was a significant limitation on what kind of applications you could build with it.

In 2009, Ryan Dahl published NodeJS, which is a runtime that allows you to use the V8 engine outside the browser, directly on the native operating system of your computer. It also adds many features that are useful for writing server-side and command-line programs. For example, you can use NodeJS to create a web server, read and write files, or build tools that automate tasks.

In this course so far, we've explored the JavaScript features that are present in both the browser and in NodeJS. Those features allowed us to define data and manipulate it in abstract ways. In the next few lessons, we'll explore the features that are specific to NodeJS and allow us to interact with the operating system.