JavaScript can run both client- and server-side, which inherently means that the use cases for using JavaScript versus Python will vary. From humble beginnings, JavaScript, with its quirks, strengths, and limitations, is now one of the main pillars of the interactive web as we know it, from powering rich frontend interactions, to web servers. How did it become one of the most important ubiquitous technologies of the web? In order to grasp JavaScript's powerful ability to add functionality to both the front- and backends, we first need an understanding of what the frontend is—and what it isn't. Having an understanding of JavaScript's origins helps to clarify the "why" of JavaScript, so let's take a look.

The following topics will be covered in this chapter:

• The National Center for Supercomputing Applications (NCSA) and the need for interactivity
• Early web browsers and a 10-day prototype
• Enter Ecma International
• HTML, CSS, and JavaScript—the best friends of the frontend
• How JavaScript fits into the frontend ecosystem

You can find the code files present in this chapter on GitHub at https://github.com/PacktPublishing/Hands-on-JavaScript-for-Python-Developers.

The early internet was a fairly boring place compared with the rich medium we now have in the 21st century. Without graphical browsers and only fairly rudimentary (and esoteric) commands, early adopters were able to do only certain academic tasks for a period of time. Starting from ARPANET (the Advanced Research Projects Agency Network), it was designed to facilitate basic communication and file transfers by being one of the first packet-switching networks. Additionally, it was the first network to implement the Transmission Control Protocol/Internet Protocol (TCP/IP) suite, which we now take for granted as it runs behind the scenes of all modern web applications.

Why is this significant? The early internet was designed for fundamental and simple purposes, but it has grown since then. As a Python developer, you already understand the power of the modern web, so a full history of the web isn't needed. Let's skip to the origins of what we now know as the frontend.

Enter Tim Berners-Lee in 1990: the invention of the World Wide Web. By building the first web browser himself and with the European Organization for Nuclear Research (known as CERN) creating the first website, the floodgates opened and the world was never the same. What started as academic tinkering has now become a global necessity, with millions of people around the globe relying on the web. It goes without saying that today, in the 21st century, we use the web and multiple forms of digital communication to go about our everyday lives.

One of the projects that Berners-Lee created was HTML—Hypertext Markup Language. As the backbone of a website, this basic markup language spawned significant growth and development in the computing community. It only took a few years (the year was 1993, to be precise) for Mosaic, the first iteration of what we now call a browser, to be released. It was developed by the NCSA at the University of Illinois at Urbana-Champaign and was a vital part of the web's development.

So, why JavaScript? Obviously, the web needed more than just static data to be useful, so, in 1995, Brendan Eich at Netscape Communications came along. Originally, the idea wasn't to create a whole new language but rather to incorporate Scheme into Netscape. That idea was superseded by the work Sun Microsystems did with Java. It was decided that this language that Eich was creating would be somewhat Java-like, and not Scheme at all. The genesis of the idea came from Marc Andreessen, the founder of Netscape Communications. He felt there needed to be a language to combine HTML with a "glue language" that helped with images, plugins, and—yes—interactivity.

Eich created a prototype of JavaScript (originally called Mocha, and then LiveScript) in 10 days. It's hard to believe that a 10-day prototype has become such a crucial part of the web, but those are the facts as history records them. Once Netscape developed a production-ready version, JavaScript shipped with Netscape Navigator in 1995. Shortly after JavaScript was released, Microsoft created its own version of JavaScript, called (unceremoniously) JScript. JScript shipped with Microsoft's Internet Explorer 3.0 in 1996.

Now, there were two technologies competing for the same space. JScript was reverse-engineered from Netscape's JavaScript, but since the two flavors of the language had their own quirks, the browser wars began, leading sites to often have a label "Best viewed in Netscape Navigator" or "Best viewed in Internet Explorer", due to the technological complexities involved in supporting both technologies on one site. A portent of things to come, the differences in the early versions only increased. Some websites would work flawlessly in one browser and break horrifically in the other—not to mention the complications caused by other competitors to both Netscape's and Microsoft's browsers! Early developers also found the differences between the two technologies only fueled the arms race. If you experienced such degradation of performance (or, even worse, you were working with JavaScript in the early days, like me), you definitely felt the pain of the competing versions. Each company, as well as other third parties, raced to create the next best JavaScript release. At its core, JavaScript has to be interpreted client-side, and the differences between the browsers led to bedlam. Something had to be done, and Netscape had a solution, though it wouldn't be perfect.

We'll learn about this solution in the next section.

The European Computer Manufacturers Association (ECMA) changed its name in 1994, becoming Ecma International, to reflect its refined purpose. As a standards organization, its purpose is to facilitate modernization and consistency for various technologies. Partly in response to Microsoft's work, Netscape approached Ecma International in 1996 to standardize the language.

JavaScript became documented in the ECMA-262 specification. You may have seen the term ECMAScript or "ECMAScript-based languages". There are more ECMAScript languages than just JavaScript! ActionScript is another ECMAScript-based language that follows similar conventions to JavaScript. With the downfall of Flash as a web technology, we don't see ActionScript much in practice anymore save for a few discrete uses, but the fact remains: Ecma International created standards and they have been used to create different technologies, which helped ease the browser wars—for a time.

Perhaps the most interesting part of Ecma International with regard to JavaScript is the various versions that have been codified. To date, there are nine versions, all with varying differences. We will be using ECMAScript 2015 (also known as ES6) throughout this book, as it is the most stable baseline for web development work today. Features of the 2016-2018 versions can be used by some browsers and will be introduced.

Powering every modern website or web application are, at a minimum, three technologies: HTML, Cascading Style Sheets (CSS), and JavaScript. They are the "best friends" of the frontend, and are illustrated in the following screenshot:

At the intersection of the three technologies is where our modern website lives. Let's take a look at these in the following sections.

HTML, the overlooked hero

When we think about the web, the basic structure of a site—the skeleton, if you will—is HTML. However, with its (purposeful) simplicity, it's often ignored as being a simple technology. One way to think about a website is thinking about a body: HTML is the skeleton; CSS is the skin; our friend JavaScript is the muscle.

HTML's history is inextricably tied to that of the web itself, as it continues to evolve with advancing specifications, features, and syntax as the web itself grows. But what is HTML? It's not a full-fledged programming language: it can't do logic or manipulate data. However, as a markup language, it's incredibly important to our use of the web. We won't spend too much time talking about HTML, but some basics will get us on the right track.

The HTML specification is controlled by the World Wide Web Consortium (W3C), and its current version is HTML5. HTML's grammar consists of elements, called tags, that have specific definitions and are surrounded by angle brackets. When used in JavaScript, these tags describe nodes of data that JavaScript can read and manipulate.

Why is HTML important to us in JavaScript? JavaScript can touch HTML using the browser's internal Application Programming Interface (API) called the Document Object Model (DOM). The DOM is the programmatic representation of all the HTML on the page, and it dictates how JavaScript can manipulate elements on a rendered page. Unlike Python, JavaScript can react to user inputs without communicating back to the server; its execution logic can happen on the frontend. Think about when you enter information in a form on a website. Sometimes, there are required fields, and if you attempt to submit the form, JavaScript can halt the submission to the server and give visual cues—such as red outlines on required boxes and a warning message—and convey to the user that information is missing. This is an example of JavaScript using the DOM for interactivity. We'll dive further into this later on, in Chapter 7, Events, Event-Driven Design, and APIs.

Here's an example of a simple HTML5 boilerplate:

<!doctype html>

<html lang="en">
<head>
  <meta charset="utf-8">

  <title>My Page</title>

</head>

<body>
  <h1>Welcome to my page!</h1>
  <p>Here’s where you can learn all about me</p>
</body>
</html>

It's pretty legible in and of itself: contained within tags titled title is a string containing a simple title for this page. In the meta tag, we have one more element besides the name of the tag: the charset attribute. HTML5 also introduced semantic tags, which not only provide a visual structure to the page but also describe the purpose of the tag. For example, nav and footer are used to denote navigation and footer sections on a page. If you'd like to experiment with HTML, CSS, and JavaScript as we progress, you can use a tool such as Codepen.io or JSFiddle.net. Since we're so far only working with client-side work, you don't need a compiler or any other software on your computer. You can also work locally with your favorite text editor and then load your HTML in a browser.

One more set of attributes that are important to our needs with JavaScript are class and id. These attributes provide an efficient conduit by which JavaScript can access HTML. Let's take a look in the following code block at a more fleshed-out example of HTML:

<!doctype html>

<html lang="en">
<head>
  <meta charset="utf-8">

  <title>My Page</title>

</head>

<body>
  <h1 id="header">Welcome to my page!</h1>
  <label for="name">Please enter your name:</label>
  <form>
    <input type="text" placeholder="Name here" name="name" id="name" />
    <p class="error hidden" id="error">Please enter your name.</p>
    <button type="submit" id="submit">Submit</button>
  </form>
</body>
</html>

The output of this will give us a very simple page, as follows:

Very basic, right? Why is Please enter your name repeated? If you notice the second p tag on the page, one of its classes is hidden. However, we can still see it. We'll need CSS to help us out here.

CSS

If HTML is the bone structure of our page, then CSS is the skin of it, giving it a look and feel. Working with JavaScript on the frontend inherently takes into consideration CSS as well. In the example of our website form, the red outlines and warning messages are often triggered by toggling CSS classes. Here's a short example of CSS:

.error {
  color: red;
  font-weight: bold;
}

In this example, we have one CSS declaration (the error class, denoted as a class by the period preceding its name), and two CSS rules inside the curly braces for font color and font weight. It won't be important for now to be fully versed in CSS structure and rules, but as a JavaScript developer for the frontend, you will likely interact with CSS. For example, toggling our error class to make the text in our form red and bold is one way that JavaScript can trigger a message to the user, informing them that there's a problem with the form submission.

Let's add the preceding CSS into our previous HTML work. We can see this results in the following change:

Now, we can see that the rules of red and bold are being reflected, but we can still see the paragraph. Our next two CSS rules are the following ones:

.hidden {
  display: none;
}

.show {
  display: block;
}

This is a little closer to what we expect to see. But why make a paragraph just to hide it with CSS?

JavaScript

Enter our friend, JavaScript. If JavaScript is going to be the muscles of the body, it's then responsible for manipulating the bones (HTML) and the skin (CSS). Our human muscles can't do all that much to change our physical appearance, but they can certainly put us in different positions, expanding and contracting our elastic skin and manipulating the positions of our bones. With JavaScript, it's possible to rearrange content on a page, change colors, create animations, and much more. We'll be diving deeply into how JavaScript interacts with HTML and CSS because, after all, JavaScript is why we're here now, reading this book!

One of the most notable points to make about JavaScript versus Python is that, in order to make changes to a page, a Pythonic program would have to respond to input from the client side from the server, and then the browser would re-render the HTML. JavaScript avoids this by executing in the browser.

For example, in our page shown previously, if the user tries to submit the form without entering a name, JavaScript can remove the hidden class and add the show class, at which point the error message shows. This is a very simple example, but it underscores the idea that JavaScript can execute changes in the browser without calling back to the server. Let's put the pieces together.

The HTML is shown in the following example:

<!doctype html>

<html lang="en">
<head>
  <meta charset="utf-8">

  <title>My Page</title>

</head>

<body>
  <h1 id="header">Welcome to my page!</h1>
  <form>
    <label for="name">Please enter your name:</label>
    <input type="text" placeholder="Name here" name="name" id="name" />
    <p class="error hidden" id="error">Please enter your name.</p>
    <button type="submit" id="submit">Submit</button>
 </form>
</body>
</html>

The CSS is shown in the following example:

.error {
  color: red;
  font-weight: bold;
}

.hidden {
  display: none;
}

.show {
  display: block;
}

Now, let's write some JavaScript. This likely won't make sense yet, but if you're working along in an editor such as JSFiddle, try to place the following JavaScript in the JS pane and hit Run:

document.getElementById('submit').onclick = e => {
  e.preventDefault()
  if (document.getElementById('name').value === '') {
    document.getElementById('error').classList.toggle('hidden')
    document.getElementById('error').classList.toggle('show')
  }
}

Now, if you run this and click Submit without entering any data into the box, our error message will display. Very simple so far, but congratulations! You just wrote some JavaScript! Now, how would we do this with Python? We'd have to submit the form to our backend, evaluate the inputs provided, and re-render the page with our error message.

Instead, welcome to working with the frontend.

As you can imagine, there's more to JavaScript than simply hiding and showing elements. A powerful application is more than just a collection of script tags—JavaScript fits into an overall lifecycle and ecosystem, creating rich user experiences. We'll be diving into single-page applications (SPAs) using React in a Chapter 8, Working with Frameworks and Libraries, so, for now, let's set the stage.

If you're not familiar with the term SPA don't worry—you've already used at least a few without realizing that that's what they were. Perhaps you use Google's Gmail service. If you do, poke around at it a little bit and notice that the page doesn't appear to do hard refreshes to get information from the server. Instead, it communicates asynchronously with the server and dynamically renders content. There may be periods of waiting for content to load from the server that is often filled with a little spinning icon. The name for this underlying paradigm of loading content asynchronously from a server and sending data back is called Ajax.

Ajax, short for Asynchronous JavaScript and XML, is simply a collection of technologies and techniques used on the client side to streamline the user experience by allowing data to be fetched and sent in the background. We'll be discussing calling APIs from the frontend with Ajax a bit later, but for now, let's try a small example.

Our first Ajax application

First, we'll create a very simple Python script, using Flask. If you're not familiar with Flask yet, don't worry—we won't get into it in detail here.

Here's an example of an app.py script:

from flask import Flask
import os

app = Flask(__name__, static_folder=os.getcwd())


@app.route('/')
def root():
    return app.send_static_file('index.html')


@app.route('/data')
def query():
    return 'Todo...'

Here's our HTML with JavaScript (index.html):

<!doctype html>

<html lang="en">
<head>
  <meta charset="utf-8">
 
  <title>My Page</title>

</head>

<body>
 <h1 id="header">Welcome to my page!</h1>
 <form>
   <label for="name">Please enter your name:</label>
   <input type="text" placeholder="Name here" name="name" id="name" />
   <button type="submit" id="submit">Submit</button>
 </form>
 <script>
   document.getElementById('submit').onclick = event => {
     event.preventDefault()
     fetch('/data')
       .then(res => res.text())
       .then(response => alert(response))
       .catch(err => console.error(err))
   }
 </script>
</body>
</html>

Before we break this down, let's try to run it, by executing the following code:

$ pip install flask
$ export FLASK_APP=my_application
$ export FLASK_DEBUG=1
$ flask run

We should see the following screen:

Let's click Submit, and the following screen should appear:

We successfully displayed the text Todo… from Python in JavaScript! Let's take a quick look at how we did that.

Our base route (the / route) will serve our static index.html file. Great—now, we can see our HTML. But what about the second route, /data? It's simply going to return text. So far, it's not very different from any bare-bones Flask application.

Now, let's take a look at our JavaScript. There's one thing to note first and foremost: in our HTML file, we can wrap our JavaScript with <script> tags. While storing JavaScript in a separate file brought in with its own script tag (we'll get to that), it's convenient to include code directly in your HTML for small, quick, and non-production debugging purposes. There are times when you will insert code directly in your HTML file, but this does not happen often. For now, we'll break our best practices and play with the following snippet:

document.getElementById('submit').onclick = event => {

Hm. What is this cryptic line? It's the beginning of an ES6 arrow function. We'll dive into functions in more depth later, but for now, let's see what we can glean from this line, as follows:

• document.getElementById('submit'): By looking at our HTML, we can see there is an element with the ID attribute of 'submit': the button. So, first, we're looking for our button.
• .onclick: Here's an action verb for us. If you guessed that this function is designed to take action when a user clicks the button, you're correct.

As for the rest of the contents of the function, we can guess that we're doing something with an event—something regarding fetching data and then doing something with it. So, what's that something?

alert(response) is what we’re doing with it! An alert is just one of those annoying little pop-up messages you see in your browser, and, with the data from Flask, we displayed it in one of those! Again, not quite practical, but hopefully you can see where we're going: the frontend doesn't exist in a vacuum—we can communicate back and forth between the client-side and the server-side with just a few lines of code on either side.

We'll take a look at the fetch function in closer detail when discussing APIs, but for now, let's take a minute to look at what we've done so far with this exercise, as follows:

1. We created a small web application using Python and Flask to serve a simple HTML page.
2. This application also had an endpoint to serve a very simple message as its output: Todo….
3. Using JavaScript, we took action when the user clicked the Submit button.
4. Upon clicking the Submit button, JavaScript communicated with the Python application to request data.
5. The returned data was displayed to the user in an alert window.

And that's it! We made our first successful Ajax call.

JavaScript in practice

Now that we've seen a hands-on example of how JavaScript can be used with Python, let's discuss its uses across the frontend spectrum. Spoiler alert: we'll be using JavaScript on the server side, starting in the next chapter. We encountered some cryptic commands in our Ajax example, so while it may be easy to overlook the use of and need for JavaScript, we see it's a real language with real applications.

Part of the beauty of JavaScript is its nearly universal adoption in browsers. Over time, JavaScript syntax and features have slowly evolved, but support for the different features, which were at one time wildly different between browsers, is now standardizing. Some differences still remain, however, but there are useful tools on the web that are kept up to date on the various features that browsers may or may not support. One of these sites is caniuse.com, and this is illustrated in the following screenshot:

The various methods and properties of JavaScript are broken out in this site by various popular browsers in a matrix to show which are (and which are not) supported by each browser. In general, however, you won't need to worry too much about whether or not your code will run on a given browser unless you're using cutting-edge features.

Now, we've shown an example of JavaScript interacting with Python as our backend using Flask, but we can use practically any backend system, as long as it's prepared to accept inbound HTTP traffic. Python, PHP, Ruby, Java—the possibilities are all there, as long as the backend expects to be working with a frontend.

A note about libraries such as jQuery: we won't be using jQuery in this book. While useful for shortcuts and simplification of some methods, one of its major draws (at least for many developers such as myself) was its under-the-hood standardization of JavaScript between browsers. Remember that Ajax fetch call we made? It used to be the case that an Ajax call had to be written in two different ways, one for each main type of JavaScript interpreter. However, browser standardization has eased most of the cross-browser nightmares. jQuery still provides many tools that are useful, especially for the user interface (UI), such as plugins that make it unnecessary to write components from scratch. Whether or not you use jQuery or similar libraries is up to you or will be dictated by the project's needs. Libraries such as React, which we will be discussing, are designed to fill a very different need than libraries such as jQuery.

JavaScript has a large, respected place in the modern web. From simple beginnings at NCSA, it's now an integral part of modern web applications, whether for UI, Ajax, or other needs. It has official specifications and is constantly evolving, making working with JavaScript ever more exciting. Working in concert with HTML and CSS, it can do much more than simple interactivity, and it can easily communicate with (almost) any backend system. Its purpose is to give us more than static pages—we want pages that do work. If you coded along, we made a simple Ajax application, and while right now the commands are probably nonsensical to you, you can hopefully see that JavaScript is fairly legible. We'll be taking a deep dive into JavaScript's grammar and construction later on.

We haven't spent time discussing the backend use of JavaScript yet, but don't worry—that's next.

Try your hand at answering the following questions to test your knowledge:

1. Which international group maintains the official specification for JavaScript?
   1. W3C
   2. Ecma International
   3. Netscape
   4. Sun
2. Which backends can communicate with JavaScript?
   1. PHP
   2. Python
   3. Java
   4. All of the above
3. Who was the original author of JavaScript?
   1. Tim Berners-Lee
   2. Brendan Eich
   3. Linus Torvalds
   4. Bill Gates

4. What is the DOM?
   1. JavaScript's representation of HTML in memory
   2. An API to allow JavaScript to modify the page
   3. Both of the above
   4. None of the above
5. What is the primary use of Ajax?
   1. Communicating with the DOM
   2. Manipulating the DOM
   3. Listening for user input
   4. Communicating with a backend

Here are a few resources for you to peruse:

• Thoriq Firdaus, Ben Frain, and Benjamin LaGrone. HTML5 and CSS3: Building Responsive Websites. Birmingham: Packt Publishing, 2016.
• Browser wars: https://en.wikipedia.org/wiki/Browser_wars
• W3C: https://www.w3.org/