2ality – JavaScript and more

Node.js is a program that lets us run JavaScript code outside browsers – which we can use for a variety of things.

A shell provides a text-based way of interacting with the operating system. In this chapter, we explore how shells work and why we need them for web development.

CSS provides a variety of services for web content:

• In the previous chapter, we used it to format content: to change colors, typefaces, etc.
• In this chapter, we will use it to lay out content: to place HTML elements on a page.

In the previous chapter, we used HTML to create unformatted content. In this chapter, we use CSS to configure the style of that content: We can change the color of the background, use various fonts, add vertical spacing, etc.

This chapter covers a lot of ground relatively quickly: It’ll be fun to explore how HTML can be styled and you’ll have a solid foundation after reading it.

I was looking for a way to create images (think screenshots) of CSS layouts that I can use in HTML, EPUB and PDF files. This blog post describes my solution – which produces SVG images.

In this blog post, I’d like to talk about CSS: I wish it supported inner breakpoints – breakpoints not for viewports or containers but for HTML elements inside viewports or containers.

In this chapter, we learn how to create web pages via HTML.

In this chapter, we perform a few steps to prepare us for web development.

In this chapter, we learn how to use the version control system Git and a useful companion website, GitHub. Both are important tools when programming in teams but even help programmers who work on their own.

In this chapter, we explore Markdown, a lightweight markup language that’s easy to learn and used a lot when writing about programming: documentation, comments, etc. We’ll need it in the next chapter. Learning it may seem like a detour but it’s easy to pick up and you’ll come across it often if you are interested in web development.

In this chapter, we install a package manager. That gives us access to all kinds of software.

In this chapter, we learn how to write a server that lets users log in via passwords. That process is called authentication.

In this chapter, we’ll write our own web server: It will serve files and manage the data for a browser app.

In this chapter, we’ll take a look at frontend frameworks – libraries that help with programming web user interfaces (“frontend” means “browser”, “backend” means “server”). We’ll use the frontend framework Preact to implement the frontend part of a todo list app – whose backend part we’ll implement in a future chapter.

In this chapter we develop a small web app in the same way that large professional web apps are developed:

• We use libraries that we install via npm.
• We write tests for some of the functionality.
• We combine all JavaScript code into a single file before we serve the web app. That is called bundling. (Why we do that it explained later.)

In this chapter, we learn how to handle tasks that take a long time to complete – think downloading a file. The mechanisms for doing that, Promises and async functions are an important foundation of JavaScript and enable us to do a variety of interesting things.

In this chapter, we explore the popular data format JSON. And we implement shell commands via Node.js that read and write files.

In this chapter, we’ll explore the data structure Map (a class) which lets us translate (“map”) from an input value to an output value. We’ll use a Map to display text upside-down in a terminal!

In this blog post, we discuss Oracle’s trademark of the word “JavaScript”:

• What are the problems caused by that trademark?
• How can we fix those problems?

In this chapter, we look at exceptions in JavaScript. They are a way of handling errors. We’ll need them for the next chapter.

In this chapter, we learn how to create plain objects with properties. We use them to create a simple flash card app.

So far, all of our JavaScript code resided in a single file – be it an .html file or a .js file. In this chapter, we learn how to split it up into multiple files. And how to automatically test if the code we write is correct.

In this chapter, we run a web server on our own computer and use it to serve a web app.

In this chapter, we learn how to do things repeatedly in JavaScript.

In this chapter, we learn about tools for only running a piece of code if a condition is met: truth values (booleans), comparisons and if statements.

In this chapter we look at one way of storing more than one value in a variable: arrays.

In the last chapter, we worked with numbers. In this chapter, we’ll work with text and write our first applications.

In this chapter, we take the very first steps with JavaScript and learn about numbers, variables and functions.

This blog post provides an overview of my new series of blog posts called “Web development for beginners”.

On 25 June 2025, the 129th Ecma General Assembly approved the ECMAScript 2025 language specification (press release, GitHub release), which means that it’s officially a standard now.

This blog post explains what’s new.

In this blog post, we explore ways in which we can make regular expressions easier to use.

JavaScript has two common patterns:

• Maps: We check the existence of a key via .has() before retrieving the associated value via .get().
• Arrays: We check the length of an Array before performing an indexed access.

These patterns don’t work as well in TypeScript. This blog post explains why and presents alternatives.

In ECMAScript 2025, JavaScript gets a class Iterator with iterator helper methods. This class conflicts with TypeScript’s existing types for iterators. In this blog post, we explore why that is and how TypeScript solves that conflict.

In this blog post, we explore how we can style text that we log to the console in Node.js.

Some of the examples use a Unix shell but most of the code should also work on Windows.

Converting values to strings in JavaScript is more complicated than it might seem:

• Most approaches have values they can’t handle.
• We don’t always see all of the data.

In this blog post we look at:

• The current best practice for deploying library packages: .js, .js.map, .d.ts, .d.ts.map, .ts
• Recent new developments in compiling and deploying TypeScript: type stripping, isolated declarations, JSR, etc.
• What the future of deploying TypeScript might look like: type stripping in browsers, etc.

In this blog post, we examine how we can test types in TypeScript:

• First, we look at the library asserttt and the CLI tool ts-expect-error.
• Then, we consider which functionality could be built into TypeScript.

In JavaScript, code has color: It is either synchronous or asynchronous. In this blog post, we explore:

• The problems caused by that
• How to fix them via synchronous await
• The two downsides that prevent synchronous await from being practical

Today’s announcement by Microsoft:

[...] we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by 10×, and substantially reduce memory usage.

This blog post looks at some of the details behind the news.

In this blog post, we explore what unions and intersections of object types can be used for in TypeScript.

Roughly, TypeScript is JavaScript plus type information. The latter is removed before TypeScript code is executed by JavaScript engines. Therefore, writing and deploying TypeScript is more work. Is that added work worth it? In this blog post, I’m going to argue that yes, it is. Read it if you are skeptical about TypeScript but interested in giving it a chance.

Read this blog post if you are a JavaScript programmer and want to get a rough idea of what using TypeScript is like (think first step before learning more details). You’ll get answers to the following questions:

• How is TypeScript code different from JavaScript code?
• How is TypeScript code run?
• How does TypeScript help during editing in an IDE?
• Etc.

Note: This blog post does not explain why TypeScript is useful. If you want to know more about that, you can read my TypeScript sales pitch.

Now that Node.js has built-in support for TypeScript, we can use it as the foundation of simple playgrounds that let us interactively explore TypeScript code.

In this blog post, we explore how we can test that complicated TypeScript types work as expected. To do that, we need assertions at the type level and other tools.

The TypeScript handbook makes an interesting statement: “Often, the checks in a conditional type will provide us with some new information. Just like narrowing with type guards can give us a more specific type, the true branch of a conditional type will further constrain generics by the type we check against.”

In this blog post, we’ll see that this goes further than you may think.

In this blog post, we look at the special TypeScript type never which, roughly, is the type of things that never happen. As we’ll see, it has a surprising number of applications.

In this blog post, we examine how TypeScript handles JavaScript symbols at the type level.

If you want to refresh your knowledge of JavaScript symbols, you can check out chapter “Symbols” of “Exploring JavaScript”.

In this blog post, we explore two equivalent notations for Arrays in TypeScript: T[] and Array<T>. I prefer the latter and will explain why.

A conditional type in TypeScript is an if-then-else expression: Its result is either one of two branches – which one depends on a condition. That is especially useful in generic types. Conditional types are also an essential tool for working with union types because they let us “loop” over them. Read on if you want to know how all of that works.

A mapped type is a loop over keys that produces an object or tuple type and looks as follows:

{[PropKey in PropKeyUnion]: PropValue}

In this blog post, we examine how mapped types work and see examples of using them. Their most importing use cases are transforming objects and mapping tuples.

In this blog post, we explore how we can extract parts of compound types via the infer keyword.

It helps if you are loosely familiar with conditional types. You can check out chapter “Conditional types” in “Exploring TypeScript” to read up on them.

TypeDoc now lets us refer to parts of other files via {@includeCode}. In this blog post, I explain how that works and why it’s useful.

TypeScript’s satisfies operator lets us check the type of a value (mostly) without influencing it. In this blog post, we examine how exactly it works and where it’s useful.

In this blog post, we look at how can make things “read-only” in TypeScript – mainly via the keyword readonly.

During the last two years, ESM support in TypeScript, Node.js and browsers has made a lot of progress. In this blog post, I explain my modern setup that is relatively simple – compared to what we had to do in the past:

JavaScript’s Arrays are so flexible that TypeScript provides two different kinds of types for handling them:

• Array types for arbitrary-length sequences of values that all have the same type – e.g.: Array<string>
• Tuple types for fixed-length sequences of values where each one may have a different type – e.g.: [number, string, boolean]

In this blog post, we look at the latter – especially how to compute with tuples at the type level.

In this blog post, we take a closer look at template literal types in TypeScript: While their syntax is similar to JavaScript’s template literals, they operate at the type level. Their use cases include:

• Static syntax checking for string literals
• Transforming the casing of property names (e.g. from hyphen case to camel case)
• Concisely specifying large string literal union types

The ECMAScript proposal “RegExp escaping” (by Jordan Harband and Kevin Gibbons) specifies a function RegExp.escape() that, given a string text, creates an escaped version that matches text – if interpreted as a regular expression.

This proposal reached stage 4 on 2025-02-18.

In this blog post, we take a closer look at TypeScript enums:

• How do they work?
• What are their use cases?
• What are the alternatives if we don’t want to use them?

The blog post concludes with recommendations for what to use when.

I never felt confident about my tsconfig.json. To change that, I went through the official documentation, collected all common options, and documented them in this blog post:

• This knowledge will enable you to write a tsconfig.json that is cleaner and that you’ll fully understand.

• If you don’t have the time to read the post, you can jump to the summary at the end where I show the tsconfig.json that I use now – along with recommendations for adapting it to different use cases (npm package, app, etc.).

• I also link to the tsconfig.json recommendations by several well-known TypeScript programmers. (I went through them when I researched this post.)

I’m curious what your experiences with tsconfig.json are: Do you agree with my choices?

Traditionally, we could only apply regular expression flags such as i (for ignoring case) to all of a regular expression. The ECMAScript feature “Regular Expression Pattern Modifiers” (by Ron Buckton) enables us to apply them to only part of a regular expression. In this blog post we examine how they work and what their use cases are.

This proposal reached stage 4 on 2024-10-08.

The ECMAScript feature “Import Attributes” (by Sven Sauleau, Daniel Ehrenberg, Myles Borins, Dan Clark and Nicolò Ribaudo) helps with importing artifacts other than JavaScript modules. In this blog post, we examine what that looks like and why it’s useful.

Import attributes reached stage 4 in October 2024 and will probably be part of ECMAScript 2025.

Starting with v23.6.0, Node.js supports TypeScript without any flags. This blog post explains how it works and what to look out for.

In this blog post, we look at how WebAssembly has become an ecosystem for many programming languages and what technologies enable that.