The first thing anybody learns to program is the ubiquitous Hello World application. This simple application prints some variation of "hello world" to the screen. Depending on who you ask, the phrase hello world dates back to the early 1970s where it was used to demonstrate the B programming language or even to 1967 where it appears in a BCL programming guide. In such a simple application there is no need to worry about the structure of code. Indeed, in many programming languages, hello world needs no structure at all.

For Ruby, it is as follows:

#!/usr/bin/ruby
puts "hello world"

For JavaScript (via Node.js), it is as follows:

#!/usr/local/bin/node
console.log("Hello world")

Programming modern computers was originally done using brutally simplistic techniques. Many of the first computers had problems they were attempting to solve hard-wired into them. They were not general purpose computing machines like the ones we have today. Instead they were built to solve just one problem such as decoding encrypted texts. Stored program computers were first developed in the late 1940s.

The languages used to program these computers were complicated at first, usually very closely tied to the binary. Eventually higher and higher-level abstractions were created to make programming more accessible. As these languages started to take shape through the 50s and 60s it quickly became apparent that there needed to be some way to divide up large blocks of code.

In part this was simply to maintain the sanity of programmers who could not keep an entire, large program in their heads at any one time. However, creating reusable modules also allowed for code to be shared within an application and even between applications. The initial solution was to make use of statements, which jumped the flow control of the program from one place to another. For a number of years these GOTO statements were heavily relied upon. To a modern programmer who has been fed a continual stream of warnings about the use of GOTO statements this seems like insanity. However it was not until some years after the first programming languages emerged that structured programming grew to replace the GOTO syntax.

Structured programming is based on the Böhm-Jacopini theorem, which states that there is a rather large class of problems, the answer to which can be computed using three very simple constructs:

Astute readers will recognize these constructs as being the normal flow of execution, a branch or if statement, and a loop.

Fortran was one of the earliest languages and was initially built without support for structured programming. However structured programming was soon adopted as it helped to avoid spaghetti code.

Code in Fortran was organized into modules. Modules were loosely coupled collections of procedures. For those coming from a modern object oriented language, the closest concept might be that a module was like a class that contains only static methods.

Modules were useful for dividing code into logical groupings. However, it didn't provide for any sort of structure for the actual applications. The structure for object-oriented languages, that is classes and subclasses, can be traced to a 1967 paper written by Ole-Johan Dahl and Kristen Nygaard. This paper would go on to form the basis of Simula-67, the first language with support for object oriented programming.

While Simula-67 was the first language to have classes, the language most talked about in relation to early object oriented programming is Smalltalk. This language was developed behind closed doors at the famous Xerox Palo Alto Research Center (PARC) during the 1970s. it was released to the public in 1980 as Smalltalk-80 (it seems like all historically relevant programming languages where prefixed with the year of release as a version number). What Smalltalk brought was that everything in the language was an object, even literal numbers like 3 could have operations performed on them.

Almost every modern programming language has some concept of classes to organize code. Often these classes will fall into a higher-level structure commonly called a namespace or module. Through the use of these structures, even very large programs can be divided into manageable and understandable chunks.

Despite the rich history and obvious utility of classes and modules, JavaScript did not support them as first class constructs until just recently. To understand why, one has to simply look back at the history of JavaScript from Chapter 1, Designing For Fun and Profit, and realize that for its original purpose having such constructs would have been overkill. Classes were a part of the ill-fated ECMAScript 4 standard and they finally became part of the language with the release of the ECMAScript 2015 standard.

In this chapter we'll explore some of the ways to recreate the well worn class structure of other modern programming languages in JavaScript.