CS 347: Lecture 12 – JavaScript
Dear students:
It was 1995. The web was becoming the Un-desktop, a place where we shared things that didn’t need a particular operating system or architecture. The web was rising fast and so was its vehicle Netscape. Microsoft feared missing out and was triggered into developing Internet Explorer. Meanwhile, Sun had just abandoned the world of smart appliances and decided to make Java a language for applications served out on the web. The same Java bytecode could run on any computer with a Java virtual machine, which fit nicely into the idea of the web as the neutral platform. To combat the looming Microsoft, Netscape and Sun decided to join forces.
Netscape started building a lightweight scripting language that they viewed and marketed as a companion language to Java. While in development, it was named Mocha. But it was released under the name JavaScript, a name chosen expressly for its marketing benefit. The language has very little in common with Java. Rather, JavaScript has more in common with functional languages. It took ideas from these languages, namely first-class functions, and squeezed them into a Java-like syntax.
JavaScript was originally meant to be a client language and a server language. Netscape used it in their Live Server product, which did not take off. JavaScript took on an identity as a client language, run by the web browser on the computer of the end user. This role made it an object of scorn for the first decade of its life. It had limited power: it could manipulate the DOM and handle events. But the web grew, and JavaScript gained the power to talk to servers. This meant that web developers could respond to an event by firing off a database query in the background, collecting up the results, and dynamically updating portions of the document—all without reloading the page.
Today Java is one of the three core languages of the web. Many other languages compile down to it, making it the “assembly language of the web.” JavaScript has also become a popular language on the server and as a scripting language for desktop applications. One very popular JavaScript interpreter is Google’s V8, which is used by Chrome. Firefox has SpiderMonkey, and Safari has JavaScript Core.
Some folks took V8 and integrated it into an environment for running JavaScript outside the browser. That environment is Node.js. When you run JavaScript using Node.js, you don’t have things like the DOM or the event loop. You don’t use Node.js to render HTML or listen for mouse clicks.
If you want to build desktop JavaScript apps that do use HTML and interface events, you can use Electron, which uses Node.js and Chromium to run your app in stripped-down instance of a web browser.
Exercise
To motivate some of the ideas of JavaScript, we’ll write a little code together. We will make a page with three RGB sliders in the middle of the page. Each slider will be linked to a number input. When either the slider or its associated inpout is changed, we’ll update the background color of the page. Furthermore, the slider and the input will be linked views, meaning that when one is changed, the other is automatically updated.
Here’s our HTML:
<!DOCTYPE html>
<html>
<head>
<title>...</title>
<link rel="stylesheet" href="style.css">
<script defer src="main.js"></script>
</head>
<body>
<div class="slider-grid">
<span>red</span>
<input type="range" min="0" max="255" id="r-slider">
<input type="number" min="0" max="255" id="r-box">
<span>green</span>
<input type="range" min="0" max="255" id="g-slider">
<input type="number" min="0" max="255" id="g-box">
<span>blue</span>
<input type="range" min="0" max="255" id="b-slider">
<input type="number" min="0" max="255" id="b-box">
</div>
</body>
</html>
We assemble this into a grid with the following CSS:
.slider-grid {
display: grid;
min-height: 100vh;
grid-template-columns: auto auto auto;
justify-items: center;
align-items: center;
justify-content: center;
align-content: center;
grid-gap: 10px 5px;
}
.slider-grid > span {
justify-self: end;
}
The role of JavaScript is to tie the elements to each other and to the user. We start by grabbing references to the elements:
const sliders = [
document.getElementById('r-slider'),
document.getElementById('g-slider'),
document.getElementById('b-slider'),
];
const boxes = [
document.getElementById('r-box'),
document.getElementById('g-box'),
document.getElementById('b-box'),
];
Let’s write a function that updates the body’s background-color property to value currently reflected in the form elements. Which elements do we use given that they are linked? Let’s consider the sliders to be the single source of truth.
function changeBackground() {
const r = parseInt(sliders[0].value);
const g = parseInt(sliders[1].value);
const b = parseInt(sliders[2].value);
document.body.style['background-color'] = `rgb(${r}, ${g}, ${b})`;
}
changeBackground();
If we change the sliders, we can call this function in the developer console. That’s something we always need to be aware of. The client can run our JavaScript, inspect it, disable it, and who knows what. In particular, client-side form validation is not reliable. The client may have bypassed your checks.
Now let’s hook up our event listeners. A change in the slider needs to update its associated number input, and vice versa. Changes in either need to update the background. Our first draft might look something like this:
for (var i = 0; i < 3; ++i) {
boxes[i].value = sliders[i].value;
sliders[i].addEventListener('input', () => {
boxes[i].value = sliders[i].value;
changeBackground();
});
boxes[i].addEventListener('input', () => {
sliders[i].value = boxes[i].value;
changeBackground();
});
}
But this fails. If we throw in a console.log(i) in the event handlers, we see that i is 3, which is not a valid index. What is happening? In JavaScript, functions form what are called closures. A closure is a marriage between an unevaluated chunk of code and the variables that are sitting around at the time the code is stored for later invocation. When the code is eventually run, it can draw from those variables, even if they’re no longer in scope. We say the function closes around those variables.
In this case, that var i declares a global variable. Variables declared with var are hoisted outside of their braces to the top-level of their nearest surrounding function. Outside of a function, they become global. This often means that var-variables have a much wider scope than we intend. All 6 functions close around this global variable. By the time the callbacks run, the loop has altered this global variable to be 3. This is bad; we don’t want such sharing.
These days, we can fix our probably by using let instead of var. The let scope gives us the block scoping that we are familiar with in other languages. In the case of a loop, each iteration will have an independent binding. As a general rule, never use var.
for (let i = 0; i < 3; ++i) {
boxes[i].value = sliders[i].value;
sliders[i].addEventListener('input', () => {
changeBackground();
boxes[i].value = sliders[i].value;
});
boxes[i].addEventListener('input', () => {
changeBackground();
sliders[i].value = boxes[i].value;
});
}
Now our sliders work beautifully. See you next time.
P.S. It’s time for a haiku:
One language for love
The same one for hate and jokes
Sorry for laughing