The Ecma Natives Learning JS like a boss

Lab 0: The history of JavaScript and installation

Lab number zero. That sounds a bit weird right? In this lab we’re not going to do too much. Instead I’ll talk a bit about the history of the web, JavaScript, some of the politics that created the community we have today and then I’ll help you setup an environment so we can start developing stuff in Lab one.

JavaScript is an prototype-based object-based interpreted scripting language.

Now here are a few hard terms already.

Let’s start with the first one: “prototype based object-based”. Object-based means that a programming language stores states and operations. An object-based language becomes an object-oriented language when it also supports “inheritance” and “sub-typing”. If you want to know more about that, I’d advice you to just look for the words on Wikipedia.

The weird thing with older versions of JavaScript was that they did support some light forms of inheritance and sub-typing, yet older versions of JavaScript never had Classes. JavaScript did and does however support “prototypes”; the ability to inherit and re-use objects directly from “template objects”.

This has changed a bit however with the introduction of Classes a few years ago, but let’s not go into that rabbit-hole yet ;)

All of this might be a bit hard to understand now, and I do apologise for the bad explanation I’m doing here, but We’ll get back to this later in the course.

“interpreted” is the second weird thing here. Basically 4 major forms of code-executing exist today:

Machine, is a set of instructions that can be read and executed by the processor of your computer directly, Assembly is a type of code that the architecture on which your computer runs understands. Here we are in 1 and 0 land. Lots of machine and assembly type codes can’t be read by humans.

In many cases when you write code, it can’t be read by the computer directly. Instead before you execute your code, it needs to be turned into an other language. (preferably one, the processors in your computer understand):

When you use code that needs to compile, you need to turn that language into either machine or assembly code. You do it once, and then the “translated” result of your code can be executed and stored on the same or another computer. Some examples of compiled code are: Java, Go and Elixir.

When you use interpreted code, that code is translated on the fly. So you send your “untranslated” code to your server or computer and the translation happens as a line of code is picked up. The drawback here would be that before the processor of your computer can do anything, it first needs to translate code. When the code has been translated and executed it’s not (often) stored for later use. Some examples of interpreted code are: Ruby, Python and you guessed it: JavaScript.

So where did it begin?

JavaScript isn’t really that new. It has been around for quite some time. JavaScript started its life as “Netscape’s Mocha”. It was created by Brendan Eich in 1995. Brendan based the scripting language on Java, Scheme and Self. Netscape being pretty much the online big player for web-sites at the time strengthened its position quite firmly With the new-found ability to write small programs that could be run client-side on web-pages.

The first idea behind Mocha was to look a lot like Scheme, a dialect of Lisp. In talks to create a good standard fast (Netscape and Sun were in all kinds of weird deals) Sun pushed Brendan to make the language look more like Java in an attempt to make Mocha a Java-companion for the web. The script was renamed to LiveScript and then as Sun signed deals with Netscape the name JavaScript was adopted and would run small client-side scripts, while big brother Java would work with “Java applets” to take care of the heavier operations. If your computer is old enough, you probably still see those occasional pop-ups asking you to update Java.

Not today

In 1996 Microsoft joined in and tried to some extend take more control of the market by creating their own browser “Internet Explorer”, featuring their own implementation of JavaScript, called “JScript” because of trademark issues with the name JavaScript. Netscape reacted to this by making a bunch of standards and beginning to refactor its engine (which had been written in haste). The new interpretor was called SpiderMonkey. The name SpiderMonkey can still be found in Firefox, Netscape’s grandson.

You can still detect some of the haste JavaScript was written in today. A good example can be found on the “string” object

> typeof "hello world"
"string"

> typeof new String('hello world')
"object"

JScript and SpiderMonkey kept doing their own implementations, making surfing the web bit of a chaos. Internet Explorer had all kinds of quirks on the DOM, that Netscape would miss while Netscape would implement its own things.

Prototypes (the ability to re-use information, functions and other objects from template objects) was derived from the Self language and would work mostly the same between the two browsers.

Features like regular expressions, JSON and the ability to raise exceptions were not there yet. JavaScript would undergo some big changes in the years that followed, only slowed by the development of Flash with ActionScript, a spin-off from JavaScript, as well as the continued interest in Java on the web.

One big change had to happen however: ECMA standardization. ECMA is an organisation formed in 1961 (long before most people were able to get their own computer at home) with the sole purpose to create standardization of information and communications systems. Making sets of rules if you will on how languages should function when multiple people and companies had different ideas.

So a team called TC-39 set off creating a standard for JavaScript called ECMA-262. The ECMA committee could however not use the name JavaScript for the same trademark reasons Internet Explorer had to go with JScript, so they decided to go with the name ECMAScript. While we call the language JavaScript today, it’s technically still called ECMAScript.

In ECMA 1 & 2 the main focus was to create some standards. Features from different browsers were brought together. Version one was released in June 1997 with NetScape 4. Later ECMA 2 mostly just updated small inconsistencies.

Netscape 4

ECMAScript 3 introduced some big changes. Suddenly developers were able to perform Regular expressions, do and while, exceptions (and the ability to catch them), formatting on numeric output, in and instanceof operators, more built-in functions on strings and arrays and much much better error handling. The iteration was released in 1999 and became the bread and butter for JavaScript development in the years to follow. Even today a lot of websites still transpile new fancy JavaScript code to this old standard.

ECMA ran into some bumps as well. Two factions started to rise within TC-39. One faction wanted to develop the language further to allow running more heavy code client-wise; while another group thought it wouldn’t be the good course for JavaScript. The release of ECMAScript 4 was pushed further and further away.

Some big wrinkles popped up when browsers started to support AJAX – asynchronous JavaScript and XML – allowing code to send requests to servers without having to reload web-pages. Most browsers at the time implemented it natively, but Internet Explorer didn’t join the party. When it eventually did one had to go through some weird loops to get it to work. The AJAX discussion did however re-kindle the development light for ECMAScript 4. In the peak of its development the new version 4 implementation had features like:

The committee developing ECMAScript 4 at the time was formed by Adobe, Mozilla, Opera and Microsoft. Yahoo entered later when most of the features were already decided. Douglas Crockford was the person sent by Yahoo. He voiced concerns for many of the proposed features and got a lot of support from Microsoft. Microsoft didn’t want any of ECMAScript 4’s features in their browsers and even threatened legal actions. ECMAScript 4 development stopped again.

Douglas pushed the idea to push out a simpler, reduced set of features for the new standard, the things most of the committee could agree on. So no new syntax, just some improvements from the experience of using version 3. This iteration should be called ECMAScript 3.1

ECMAScript 4 was a problem still. In the end Brendan Eigh ripped the band-aid and posted a mail after a meeting in Oslo in 2008 outlining the following details:

  1. Work should be focused on ECMAScript 3.1 aka ES3.1, and should be implemented by browsers.
  2. Collaboration should be continued for the next steps beyond ES3.1, which should include some new syntax, but should be more modest than the many ideas from ECMAScript 4 aka ES4.
  3. Some of the ideas for ES4 were so unsound for the web. Packages, Namespaces and early binding were off the table.
  4. Some of the ideas from ES4 should be rephrased and redefined (like Classes).

ECMAScript took 8 years of development and was scrapped in the end.

Brendan used the word “Harmony” a few times in the conclusions of his mail. This harmony would become the name for the future place of new JavaScript ideas. “ECMAScript Harmony” was born.

Adobe decided to implement a big bunch of features from ES4 into ActionScript 3 and kept maintaining it for a while for its own (from Macromedia acquired) “Flash”.

Before the end of ES4, a small spin-off was created called E4X. It featured some nice patches for XML parsing, was introduced into SpiderMonkey, but removed not long after for lack of use.

So the book on ES4 was closed. TC-39 wasn’t sitting still however. The ECMAScript Harmony project started coming up with some good ideas! The result, ECMAScript 5 became the long sought rebirth of JavaScript. It included:

ES5 was released in all different browsers between 2011 and 2012. It became the standard for Internet Explorer 10 and Safari 6, of which the first is still being used by a good chunk of users world-wide today. ECMAScript 5 got a 5.1 iteration in 2011, which fixed some ambiguities.

With the development back on track TC-39 and ECMAScript Harmony steamed on with some fundamental new features in ECMAScript 6, 7 and 8 which would get the respective names ECMAScript 2015, 2016 and 2017. EcmaScript 2015 featured some ideas from ECMAScript 4 and a range of new improvements to the languages like:

In the course We’ll touch on a good bunch of these.

Thanks to not taking features like namespacing and optional typing along in EcmaScript 2015 as well as the rephrasing of some of the features (like classes) all of these features made it past the standardization process. It did take almost 6 years to implement everything however. The fact that the committee as well as the community were able to pull something like this off gave a further boost to the development of ECMAScript. Short after the release of the ECMAScript 2015 spec some further small changes were made like Array.prototype.includes (which would be pushed to ECMAScript 2017 later), the exponention operator and some small corrections.

At this point, most of the features from the ECMAScript 2015 spec are implemented in modern browsers.

With that behind us we are now in the realm of ECMAScript 2017 and 2018. Some of the features you are going to use from that in the rest of this course include:

There is however a catch.

And this is and has been the bane of JavaScript developers for quite some time now. We need to care about browsers. Sure, there is a standard and browser makers do their best to develop new features as soon as possible, but the end-users of those browsers need to update their computers. 3 browsers that have been a problem for a very long time to that regard are:

There are still a lot of people out there using Windows 7 with Internet Explorer 10. This version of Internet explorer still runs on ECMAScript 5 and doesn’t support all the new fancy features yet. Safari fixed most of the issues by continuing to update their browser through Apple update and Android fixed the problem of old phones when it pulled its interpretor out of the browser into a separate (system) app called webkit, This app would then receive updates directly from the Google Play Store (and still does today).

But when developing sites and web-apps we do need to consider the stuff we can use or not. “Can I Use” is a website that lists new features in Javascript, CSS and HTML and tells us where we can use what. Let’s take a look at Async.

Here we see that (as of writing) Internet Explorer and Opera Mini don’t give any support at all yet. So here we can do two things:

The last can be achieved in two ways:

In our future lessons we’re going to play with the last of those. Having to polyfill stuff only applies when we deal with a browser. When we write backend-server Apps or react-native Apps we can often use all the new tools we want as we are in control of what ECMAScript version we use.

There are also some JavaScript features that exist in one browser only, but not in others. These differences are created when the creators of browsers don’t agree with each other or if they want to try out new features that are being researched by TC-39 or ECMAScript Harmony. One good example of this is the forEach() function on a node-list. Normally when you have an array you can use forEach() like this:

[1, 2, 3].forEach(number => {
  console.log(number);
});

In Chrome, Firefox and Safari you could do:

document.querySelectorAll('p').forEach(node => {
  console.log(node.id);
});

This will fetch all the paragraph objects from a page and put them in a node-list. This node-list then has the prototype function forEach (like the list above). In Internet explorer however, that forEach doesn’t exist forcing you to either Polyfill it or write an old fashioned for-loop:

nodes = document.querySelectorAll('p');
for (let i = 0; i < nodes.length; i += 1) {
  const node = nodes[i];
  console.log(node);
}

Browsers have also started to support other things than just Javascript. Some browsers are starting to dip their toes into Web Assembly and some browsers have started to venue into the native support of a new language called TypeScript. We’ll eventually venture into the latter in a later stage of this course.

Installation

With the history and some of the weird quirks now behind us, let’s focus on that computer of yours! We’re going to install a program called NodeJS. It’s basically Javascript, but not in a browser. Just like Python, Ruby and other languages we can use NodeJS as a REPL interface and execute files.

Looking at the fact that we’ll eventually start making either IOS or Android apps with JavaScript, it’s best if you follow this course on a computer with Ubuntu 19.04 or Mac OSX. Any laptop or desktop from the past five years will do.

You could probably do major parts of this course in contraptions like Bash for Windows, but as we’ll start diving into sending development apps over the wire to phones, You’ll notice that connecting physical phones to vitalisation is painful. Ping me if you need help setting up dual-boot and I’ll join you on a call and help you get it done!!

If you really need to keep Windows on your laptop, then drop a message in our WhatsApp group and someone will help you set up VirtualBox with Ubuntu 19.

I’m going to assume that you’ve been part of Global Code and know some Terminal Lingo already.

Whenever I prefix a command with $ You should run the command after (excluding the $) in your terminal. Whenever I prefix with >, you should execute the command in a NodeJS REPL. If something goes wrong, open an issue on Github and mention the line in the markdown source of this file where things started to go wrong. You can find the source of this page here

For Mac OSX users

First things first, that standard terminal app of yours is ugly and useless. Let’s install something better called Iterm2, lets download and install the latest stable release

With that done, let’s fire up Iterm and install some basics. For the next steps we’re going to need 2 components:

Xcode platform tools (git, some compilers, readLine for REPL, etc.) you can install them like this:

$ xcode-select --install

When that is done, let’s install and update HomeBrew, an app-store for developer goodies. run brew --version. If it doesn’t return the version of homebrew and throws you a “command not found” error run the following step:

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Now let’s update our package manager and upgrade installed software:

$ brew update
$ brew upgrade

Now that that works, lets install Nodenv with node-build. 2 programs that will help us keep multiple versions of NodeJS on our computer so we can switch between them depending on what project we work on later.

$ brew install nodenv
$ nodenv -v # Should output a version
$ nodenv init

Follow the instructions that are returned. The instruction will most likely be that you need to add a small line of code to ~/.bash_profile. You can do this by opening an editor like pico and pasting it in.

$ pico ~/.bash_profile

After this you will need to close your existing terminal screen and open a new one. (since you edited basic instructions for the terminal)

For Ubuntu Users

Your terminal application should be on par already. If you want to have something more advanced, you could check out Terminator

To make sure you have all the necesairy side-plugins, we’ll install an older version of nodeJS from the Ubuntu apt-get store.

$ sudo apt update
$ sudo apt install nodejs npm curl git

With that done let’s use the nodenv installer to install nodenv, the NodeJS version manager allowing you to easily switch between different versions of NodeJS later

$ curl -fsSL https://github.com/nodenv/nodenv-installer/raw/master/bin/nodenv-installer | bash

At the end of the installation a doctor script will run and determine that you haven’t got nodenv in your PATH. let’s fix that real quick!

$ echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.bash_profile
$ echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.bashrc
$ echo 'eval "$(nodenv init -)"' >> ~/.bash_profile
$ echo 'eval "$(nodenv init -)"' >> ~/.bashrc

Exit your terminal and open a new one. The command nodenv -v should now return more info!

For OSX and Ubuntu

Now that we have a node version manager, lets install the latest version of node (you can find the latest stable version by executing nodenv install --list). In our case we’ll go for:

$ nodenv install 12.7.0
$ nodenv global 12.7.0
$ nodenv rehash
$ node -v # Should return v12.7.0

The global bit here tells our system that when we don’t ask for a specific node version, it should use 12.7.0 instead. The rehash bit, tells the system to reload all NodeJS related things.

And that’s it, Let’s boot it up and try some things!

$ node
> console.log('hello world!')
hello world!
undefined
> new Date()
2019-08-09T10:51:50.247Z

Final remarks

That’s it for now! Today you learned a bit about the history of ECMA, a bit about how the community for JavaScript came to be and you managed to install NodeJS!

In the next lab we’ll dive into the most common functions and features of JavaScript. We’ll also set you up with a smarter code-editor, that checks your programming- spelling (Through small javascript-plugins called ESLint and prettier) and slaps you on the wrist when you happen to write ugly code accidentally.

Can’t wait? Check out one of these 3 editors today:

Written on August 8th, 2019 by Peter van der Meulen
Feel free to share!

You may also enjoy: