An intro to JavaScript

JavaScript is the language/format for adding interactivity to a web page—based on actions or events from the user. Where do we even start with JS? (Everyone calls it JS.) It is so massive and often seems unapproachable. So we’ll go through a bit of background, and then start with some very practical examples you might want in your work.

JavaScript basics
There are literally millions of sites about JS, but let’s start with MDN.
JavaScript | MDN
More MDN.
Newest ‘javascript’ questions - Stack Overflow
Great resource for many things, but especially/famously for JS. It’s like Reddit for code!
The Modern Javascript Tutorial
This reference goes very advanced/in-depth.
Eloquent JavaScript
Also goes deep.

Going back to a very early analogy, JavaScript is the muscles of the web. Like HTML (the bones) and CSS (the skin), it is ultimately still just text that is parsed by our browsers. Like CSS, it can live within HTML documents, but is usually saved separately with the extension .js

JavaScript was first created by Brendan Eich over just 10 days in 1995, and has been through a myriad of evolutions, paths, missteps, and enhancements since then. It has nothing formally to do with Java, confusingly—other than being contemporaries and sort-of competitors (thus the name). (Coffee-culture was really big in the 90s!) JavaScript won the race, by every measure, and is ubiquitous on the modern web.

The idea was to make something that Web designers, people who may or may not have much programming training, could use to add a little bit of animation or a little bit of smarts to their Web forms and their Web pages.

Brendan Eich

Like HTML/CSS, JavaScript was a malleable, interpreted (not compiled) language running in the browser—meaning the source code could be seen by anyone, and anyone could borrow or modify it for their needs. And so as our computers—and thus our browsers—became faster and cheaper, JS was used for more and more things. Remember that now the tendrils of JavaScript are almost everywhere—running headless on servers, rendering whole sites, talking to hardware, processing NASA images, and so on. It’s web technologies, all the way down.

Libraries/frameworks vs. plain/vanilla JS

You’ll often hear folks talk about libraries or frameworks in the context of JavaScript—one of the ways it is so malleable. These are collections of Javascript code with their own specific ideas, paradigms, and syntax, that expand upon what the language can do (or can do quickly or easily) on its own, out of the box.

Things like jQuery (old-school, now), Node, React, Vue, Angular, D3, and p5 (to name some popular ones) are all written in and are interfaced with (controlled by) JavaScript as well. They are often created to do something JavaScript doesn’t yet support on its own (in/famously, jQuery) or with a niche use/focus (like data-visualization, with D3). There are many, many frameworks and libraries.

When you write JS without libraries, it is usually called plain or vanilla JavaScript. The language has evolved so much that we can do a lot, here, and this is where we’ll start. And while JS does many things, we’ll first just use it in the most simple way—to make our web pages more interactive.

Where does JS live?

Very much like CSS, JavaScript code can live in several places:

Inline as attributes
Inside <script> elements within HTML documents
As separate/external .js files (the right way), via src attributes

1. Inline event handlers

JS was first added directly in attributes in HTML tags, just like CSS—but attached/listening for specific events:

<button onclick="alert('The button was clicked!');">Click here!</button>

Note the single quotes when nested/inside doubles!

This works for very, very simple things, but—for many of the same reasons as inline CSS—is brittle and doesn’t scale with complexity, or across multiple pages. Try writing a whole, elaborate function in there! No good.

2. Wrapped in `<script>` tags

So again like CSS, JavaScript can be enclosed in its own special tag, the <script> element. (These are also, somewhat confusingly, called inline scripts.) Anything inside the tag should be written in JavaScript syntax and will be executed right away, in the order/position of the tag within the HTML document.

Since this script isn’t directly on an element anymore (as above), we then have to identify the target element with a querySelector, and then attach the onclick event to it:

Note the different // comment syntax for JS! And we had to add cursor: pointer; for the button in our CSS, to indicate it is actionable. Mind your affordances.

Here the onclick is a shorthand for using addEventListener. We also store (declare) the element here as a variable, to keep our code readable and reusable. These are a bit like their CSS counterparts. Ergonomics!

Oh also, `<noscript>`

Some folks block/disable JavaScript—for performance or accessibility reasons, or to hide advertising/annoyances, and so on. This is less and less common these days, since so many sites completely rely on JS. It isn’t always feasible to replicate your site behavior entirely without JS, but you can use a special <noscript> tag to show content only when scripting is turned off:

<noscript class="warning">
	Our site uses JavaScript for some of its functionality, which is disabled in your browser.
</noscript>

You can test these by disabling JavaScript in your DevTools.

3. Separate/external `.js` files

By far the most common, flexible way to include JavaScript is externally—again, like CSS. The difference here is that instead of a <link> element, we still use a (now empty) <script> tag, with the addition of a src="filename.js" attribute:

<script defer src="script.js"></script>

I’ve never liked this empty-tag syntax, what can you do.

This will still run when the document gets to the <script> (and in its place/order) as before, and the defer attribute allows it to “see” the HTML (not yet loaded) below it.

We can then move the script up into our <head>, along with our other external files:

Stays readable/clean with long documents and lots of files. Where there is one JS file, there are often many.

It’s the same JavaScript and behavior as the inline example above—but now moved over into a nice, separate, JS-syntax-highlighted file that can be re-used across pages.

Adding/removing a class

Okay, time for a more practical example: probably the most common thing you will use JS for—especially as we’re starting out—is simply to add or remove (toggle) a class from something when the user interacts with your page (such as clicking on a menu).

Like with our transition examples, the element needs two states in your CSS: without the class and then with the class. The JavaScript interaction/event will switch between them, and our CSS transition will smooth out the… transition.

We’ll again use addEventListener and querySelector to listen for clicks, but then modify the classList of a different element:

Note the camelCase variable names, which is the JavaScript convention. Longer, more-descriptive names will help as your code gets more complex.

The class can be toggled on any element in your HTML (or sometimes, even just on document.body itself)! querySelector takes any CSS selector, even other classes. Also you an specifically use classList.add and classList.remove, if you don’t want the on-and-off behavior from classList.toggle.

You can do many, many things with this basic “add a class” JS! It’s the basis for much of the interactivity you see online.

Watching for scrolling

Another very common use for JavaScript is to do something when an element enters or exits the viewport (scrolling into or out of view)—like fading or moving something in.

Again we’ll need two states in our CSS—defined with/without a class. But now we’ll make use of the user’s scrolling, instead of a click, to toggle the between them.

This used to be unnecessarily hard in JavaScript, and was one of the things jQuery was created to help with. But now we can easily use IntersectionObserver to watch the element:

Note the if / else statement, an example of conditional logic!

You will often want to use this on multiple elements—and remember, when in code, don’t repeat yourself! So we can use querySelectorAll to select multiple elements, and then a forEach loop to run the same class for each of them:

Here we’ve also adjusted the rootMargin from the viewport/default, so the elements don’t transition immediately.

Some miscellaneous JS tips

Alright, that is a lot. Like we’ve been saying—JavaScript is a whole thing. Here are some other tips, as you start to explore:

Using alert(yourVariable) for telemetry/debugging can quickly be pretty annoying—instead, you can use console.log(yourVariable) to show messages in the DevTools console. A quick console.log('Hello world!') can check if things are plugged in right. The console will also show any JavaScript errors!

In other languages, these functions are often, ironically, called print.
Search on Stack Overflow! Someone has likely had your problem, before. Many people don’t really know JS (myself included)… so much as they really know SO.
This brings us to LLMs, large language models (“artificial intelligence”)—tools like ChatGPT or GitHub Copilot. These can be useful; we use them ourselves. But much like Stack Overflow, you have to know what to look for, and need a level of understanding to do this to and to discern the value from the noise.

We don’t want you to treat code from anywhere as a “black box”—we want you to understand it. And copying wholesale from these—or any other source—does not demonstrate understanding. We’ll remind you of our syllabus discussion on this.
Ignore any examples that have lots of dollar signs, like $("something").else—it means this is jQuery, and so is pretty outdated! (Eric really, really doesn’t like jQuery.)
To quickly get recent/modern, vanilla JavaScript results, instead include “ES6 ” in your search—this refers to a more recent, easier-to-use syntax.
Relatedly, if you see arrow functions => it is a pretty good sign the answer recent.
Like HTML/CSS, JS does not care about whitespace or tabbing. But it is case-sensitive!
You’ll also see a lot of semicolons ; but secretly you (almost never) actually need them!

Any application that can be written in JavaScript, will eventually be written in JavaScript.

Jeff Atwood