Where are we?

We've come a very long way! When you started this book, you very likely thought we'd be talking about JavaScript running inside your users' browsers before Chapter 18! At this point in your web development journey, you've mastered how web servers create web content, manage state, and execute business logic. You've learned HTML as a mechanism for structuring the pages the web server generates, and you just learned how to use CSS to make complex and rich user interfaces.

There is a lot to be gained by learning all of these things before client-side JavaScript. Well designed applications that use modern HTML and CSS not only limit the necessity of client-side JavaScript, but they also are easier to improve using a more limited amount of JavaScript. This was not always the case - 10 years ago you needed JavaScript for much more. You'd also be surprised how many people's computers and phones are slow, and memory constrained - making running JavaScript on their machines a poor experience. Finally, you might also be surprised how many people turn off JavaScript, mainly because they don't want your code running on their machine!

As a developer, you likely have a very different perspective on computing, and the computer you use. It's easy to forget that most people view computers as a commodity, do not think much about their performance, and certainly don't keep their browses up to date unless they are forced to. The average person doesn't know which browser they use.

All this is to say... I recommend you use JavaScript on the client, but I also recommend you opt for HTML/CSS based solutions when available.

Nevertheless - client-side JavaScript is a huge part of web development. It's the final piece of the puzzle is adding interactivity! In this chapter, we'll take a look at the basics. In the next chapter, we'll learn how JavaScript can "phone home" and interact with your web server, and in the following chapter we'll see JavaScript take over the entire application design - introducing reactive single page applications.

The browser as the execution engine

The JavaScript we've seen so far runs on the server. It's the code that receives requests, executes, and generates responses. The JavaScript we've written never runs on the client's computer - it's simply generating HTML to send to their browser. Everything we've learned so far in JavaScript could have just as easily been written in Java, C#, Python, Ruby, Rust, or just about any other general purpose language. This changes when we talk about client-side.

JavaScript is not like C, C++, or Rust - it isn't compiled into machine code. It doesn't run directly - it is run by an execution engine, or runtime/interpreter. We learned early on that on the server, that runtime is Node.js, which leverages Google's V8 JavaScript engine to do most of the heavy lifting. Node.js, running on a computer without being part of a web browser was a fairly new concept in the early 2010's. Before that, JavaScript was typically only found running inside web browsers - which continue in fact to be the most common place JavaScript is run. Nearly every web browser you can think of is a JavaScript runtime, in addition to an HTML parser, CSS render, etc. Much like Node.js embeds V8 to execute Javascript, the Google Chrome (and open source Chromium) browser does the same! Microsoft Edge, Brave, Opera, and Vivaldi browsers also use V8 to run JavaScript. V8 isn't the only engine in use though, Firefox uses SpiderMonkey, and Apple's Safari browsers use JavaScriptCore.

Node.js exposes interfaces (C++ function calls) to the V8 Engine that allow your JavaScript to access your computer, by interacting with the operating system. In Node.js, these interfaces provide you with access to the file system, sockets, and other I/O devices. Web browsers do not typically provide their JavaScript engine access to such things (we'll talk about why in a moment), but they do create different interfaces for many other things - like your device's GPS subsystem! Far more important however: the web browser gives JavaScript access to the HTML loaded in on the current page!. In fact, client-side JavaScript's main purpose is to manipulate the HTML interactively, without the need to reload HTML from the server.

This brings us to our final big point: JavaScript is always running somewhere, and you MUST be clear on where. We are going to continue to write JavaScript server side. That code can't access anything on the user's device, and it can't access HTML "loaded" on their screen - it's job is still going to be running on the server, generating HTML to send. Now however, we are also going to use JavaScript in the browser. That code doesn't have access to anything on the server. It can't access the file system. It can't access the database. It can't access the session! It's running only on the end-user's machine, in their browser.

Pro Tip💡 The paragraph you just read is one of the most important in this entire book. Too many students - whether they learn web development in the order we've learned it in this book (server side first) or not, get confused about where their code is running. Make sure, at all times, you are clear. JavaScript on the server is about receiving HTTP request, using code and the database to generate a response, and sending the HTML over HTTP. JavaScript on the browser interacts with the end-user, manipulates the HTML, and adds interactivity.

So what?

So what do we actually do with JavaScript?

The "CLICK ME" above is HTML, and when you click it it will start to change colors. Randomly. You can click it again to make it mercifully stop. That's JavaScript doing that. There's JavaScript code manipulating the CSS attached to a single div element on this page. It's doing that via a timer, that is started when it detects the click event on the div. The timer is disabled when you click again.

You might be wondering - why would you want to do this... it's a fair question. This isn't all you can do though, and that's why JavaScript is important. The example above performs some really essential things, that you couldn't easily do before:

1. You can do something when the user clicks something, other than travel to a new URL.
2. You can do something at regular intervals of time.
3. You can change the HTML and CSS loaded in the browser, without reloading the page.

For now, we can think of JavaScript (in the browser) as code that operates on the HTML and CSS loaded, and is invoked on (1) page load, (2) time intervals, or (3) user events - like click or scroll.

That's pretty general. It means you can show and hide things when the user clicks, scrolls, presses a button, etc. It means you can move elements around the screen, to follow the mouse, smoothly animate, or pop up out of nowhere to annoy someone with a sign-up form.

Let's start looking at how this is all done, first by learning how to add JavaScript to our pages and how to use some basic I/O.