One of the most important lessons I've ever learned about Javascript is that no Javascript application is, by itself, actually a single program. Every Javascript application of even modest size is several different programs standing together in a trench coat and trying very hard to look like a single thing.

Let's look at the single most simple web application, the classic "push a button to increment a counter" that is the centerpiece of every "introduction to React / Vue / Angular / Lit / Svelte / etc." blogpost you've ever read. This application is just a button and a number, and every time you click the button the number increments. And let's talk about how it's very different from classical programming.

I've occasionally made reference, in the course of my blogging about Web Component development (and this applies to React as well), to "table driven development," and I had an opportunity to explain it in more detail this week. Table Driven Development is nothing more than identifying what is the minimum amount of syntax you need to express the data you use in your web page?

Let's start with a real-life example. This is a tab-based control from the Patternfly library, taken from a real project:

In my previous post, I talked about how using a CSS library cluttered the semantics of what a web component does, and after another week of living in this codebase I realized that there's a conversation to be had about the difference between abstraction and legibility. Because most of the time when we're talking about abstraction? We're actually talking about legibility. For example, I recently read the introduction to an OCaml textbook that said, "You will improve at abstraction, which is the practice of avoiding repetition by factoring out commonality."

That is absolutely not abstraction. That is legibility.

To quote James Koppel, an abstraction is an encapsulation of an idea, such as "sanitized" or "authorized" or "connected to a server," and locking the details behind an abstraction barrier so than not only don't you have to worry about the details, you shouldn't. That's not what my previous example did. Instead, it made the code's purpose and function legible.

So let's talk about legibility with another example.