What's Javascript?

The basics of web pages: HTML, CSS, and JavaScript

JavaScript was created back in 1995 as a language to add interactivity into web browsers. And if you would have asked a developer what it’s for prior to 2008, they’d probably give you a spiel like this.

JavaScript basics

Every URL that you load in your browser is made up of 3 things: HTML, CSS, and JavaScript.

HTML is all about order, shapes, and text – the structural elements of the webpage. HTML can’t pick what color your button is (you need CSS for this), or tell it to slowly fade out when someone hovers over it (you need CSS or JS for this). It’s like the architectural blueprint for the web page. It’s the starting point: you figure out how you want your page to be structured, then you worry about how it looks and how users interact with it.

The way I like to think about the relationship between HTML, CSS, and JavaScript is sort of like building a house, for those fabricators among us.

• The HTML is the structural elements of the house. The foundation, the floors, the walls. All the stuff that gets built first.
• The CSS is the aesthetic elements of the house. The paint on the wall, the moldings, the type of siding and roof shingles. All the stuff that goes on top of the structural elements.
• The JavaScript is the interactive elements of the house. The doors that open, the plumbing, the electrical, the window shades that go up and down. All the stuff that you use.

So what would you actually do on a web page with JavaScript? One classic example is handling form data. If you’ve ever filled out a form on a website, there’s probably some JavaScript behind the scenes taking the information you filled out and making sure it gets sent to a database somewhere.

But you also might use JS for something a little more fun, like animations, building interactive charts, or even something as simple as changing the color of a button once someone hovers over it.

JavaScript frontend libraries

There were (and still are) dedicated libraries in JavaScript for working with the browser. They make it easier to do things like change styling on the fly, move elements around the screen, and load scripts and data from external sources. One of the most popular was JQuery, which is less common today but still kicking.

A while down the road, we’d get React. It put JavaScript at the forefront of web dev, arguing that you should build your entire webpage in JS instead of just the interactivity. They even built a new extension to JavaScript (JSX) that lets you write HTML inside of it.

Suffice it to say that by the mid-2000s, JavaScript was pretty popular. But all of this that you see was restricted to the frontend. JavaScript physically couldn’t run on a server – the language wasn’t built for that. Server code was the purview of more “serious” languages like Java, C++, or if you’re more open minded, Python. JS, though, was something relegated to the 4 walls of the browser.

JavaScript on the backend via V8

Everything changed when Google released the V8 project back in 2008 alongside the shiny new Chrome browser. V8 is the engine that powers Chrome, and it was (from what I can tell) the fastest JS engine at the time. And though it wasn’t the first JS engine out there, it was the best, and people quickly realized that you could do more with it than just run JS in the browser.

Some of those people created Node.js, which (you may have heard of and) today powers many, many, many of your favorite websites. Node takes the V8 engine and uses it outside the browser to run and interpret JavaScript. When it came out a year after V8 was released in 2009, it was a huge deal. Now your whole app can be in Javascript, from your frontend to your server code on the backend.

You might be wondering what an engine is. The easiest way to think about it is to think of you (a developer) and your computer (or server) as speaking different languages. You speak Spanish, and your computer speaks English. How are you two going to communicate?

Simple. You write down what you want the computer to do in the language you know, which is Spanish. And then the computer has a language dictionary, translating what the Spanish writing means in its mother tongue.

This is exactly what a JavaScript engine does. You speak in higher level programming languages like JS, but your computer only speaks the lower level, scarcely-understood machine code. Engines like V8 translate your code into something a machine can understand, and then direct the machine to actually run the code.

TypeScript

JavaScript everywhere is awesome, but the JS language is not without its tradeoffs. Like Python, JS is an interpreted language, which means that it needs an extra layer between it and the machine to do some translation. Interpreted languages usually are easier to write (they look almost like English), and don’t require developers to think about lower level things like how much memory the code is using.

But the tradeoff is that interpreted languages are usually slower than compiled languages like C++, and much more prone to bugs related to data moving around. Historically, on the server, where time and cost was of the essence, developers wrote in these compiled, lower level languages. With so much JavaScript around now, codebases were messy and apps were getting slower.

TypeScript was released in 2012 to try and combat some of this stuff. It essentially takes JavaScript, and adds on some of the features of compiled languages that make them faster and more secure. It adds the ability for you to specify what type of data you expect a variable or a function in your code to be:

// creating the concept of a user, with a name that's a word and a cell that's a number

interface User { 

  name: string; cell: number;

}

// writing a function that only accepts a User, and no other kind of objects

function callUser(user: User) {

  // ...

}

Using TypeScript helps developers avoid some of the common bugs and performance issues you get when your language is too easy to write quickly. And since 2012, it has become incredibly popular (arguably as much as JS itself).

Today you can (and many do) build entire apps in JavaScript, from the frontend that your users see to the backend and data that power it. Though you hear about it less these days, for a while people were talking about the JAMStack – a philosophy for building full web apps in JavaScript that offload as much complexity as possible to services that take care of things for you, like Stripe.