DEV Community: Matthew Dean

Web components failed. We can fix them.

Matthew Dean — Wed, 07 Oct 2026 12:48:03 +0000

In 2004, the W3C was betting HTML's future on XHTML 2: a stricter, XML-based language that wasn't backward compatible with the web people had actually built. Apple, Mozilla, and Opera disagreed, and formed the WHATWG to keep evolving HTML instead. That work became HTML5.

And for a while, it was thrilling. HTML5 wasn't just a spec; it was a movement. We got <video> and <audio> (goodbye, Flash), <canvas>, new form input types, semantic elements like <article> and <nav>, and a parsing algorithm that finally made every browser read broken markup the same way. There was a logo. HTML had a logo. There were whole conferences about it. The message was clear: HTML was alive again, and it was going to grow up into an application platform.

HTML5 became a W3C Recommendation in 2014. And then the energy mostly went somewhere else.

Look at what happened to the other two languages over the next decade:

JavaScript went from a language people apologized for to one that ships a new edition every year. ES2015 alone gave us classes, modules, promises, arrow functions, and destructuring. TC39 built a stage process so public that you can watch a feature grow from a napkin sketch into a shipped standard.

CSS may have had the best decade any language has ever had. Grid. Custom properties. Container queries. :has(), the parent selector we were told for years was impossible. Native nesting. Cascade layers. @scope. Describe 2024's CSS to a developer in 2014, and they'd assume you were describing a preprocessor. (I should know. I've been maintaining Less.js for over 10 years.)

And HTML? HTML got crumbs.

A <dialog> element that took until 2022 to work in every major browser. A popover attribute. A <search> element for marking up search forms. Invoker commands, so a button can open a dialog without a line of JavaScript. Every one of these is welcome. But every one of them is a widget: a single, pre-built behavior handed down by the spec. None of them is a primitive: something you can build your own things out of.

HTML is now a "Living Standard," which is a lovely name. But living isn't the same as growing. JavaScript and CSS got new capabilities; HTML got new nouns. A decade on, markup still has no way to say "repeat this," "show this only if," "this value comes from over there," or "this is a component, and here's its contract." For any of that, you leave HTML and go write JavaScript.

Web Components were supposed to fill that gap. And to be fair, they shipped. They work. GitHub, YouTube, and Salesforce all use custom elements in production, and some of them use them well.

But they were meant to be more than that. They were meant to be the web's component model: write a component once, use it anywhere, no framework required. More than a decade later, ask HTML for a reusable, typed component with conditionals, loops, and reactive state, and the answer is the same as it was in 2013: "install a framework." That's the sense in which they failed.

Some context: I've been a professional web developer for over 20 years. I've written plenty of custom elements. I've written a lot more React, Vue, and Svelte components. And I've watched a lot of teams (including mine) try to build a "framework-agnostic" component library on Web Components and quietly give up.

Here's how that played out.

The promise, and the retreat

Web Components were first pitched in 2011, and Google's Polymer library became their flagship: the platform as the framework. Polymer eventually went into maintenance mode in 2018 and was superseded by Lit.

Lit is genuinely good. But the transition tells you something. The people most invested in Web Components concluded that the raw custom-element API needed a rendering library on top of it. That was a reasonable call; it was also an admission that the platform alone wasn't enough.

Framework authors looked elsewhere

Meanwhile, the people building component models for a living were reaching their own conclusions. In 2019, Rich Harris wrote "Why I don't use web components". If you haven't read it, the short version:

Shadow DOM pushes your CSS into JavaScript.
The property/attribute split forces boilerplate.
Slotted content renders eagerly, whether you want it or not.
There's one global registry, so naming collisions are your problem.
The DOM is, in his words, "an awkward interface for building interactive applications."

You can debate any one of those points. The outcome is harder to debate: React, Vue, Svelte, and Solid each built their own component model rather than building on this one. The people who design component models for a living chose not to use the platform's.

A button you can't extend

Even if you skip the frameworks and go all in on the platform, you hit walls quickly. The one that surprises people most: Say you want a button with some extra behavior. The spec has an answer for this! It's called a customized built-in:

<button is="fancy-button">Save</button>

class FancyButton extends HTMLButtonElement {
  // extra behavior here
}
customElements.define('fancy-button', FancyButton, { extends: 'button' });

Great! It's still a real <button>. It submits forms, it's focusable, it has the right role, Enter and Space work. Ship it!

Welp, not so fast. That works in Chromium and Firefox. WebKit's formal standards position is to oppose customized built-ins and not implement them. So in Safari, you get a plain button that ignores your class entirely.

"Fine," you say, "I'll use an autonomous custom element."

<fancy-button>Save</fancy-button>

That works. But now you have an element that doesn't submit forms, isn't focusable, has no button role, and doesn't respond to the keyboard. So you add tabindex, role="button", a keydown handler for Enter and Space, ElementInternals for form association, disabled-state handling...

At this point you've reimplemented <button>, and you'll be maintaining that reimplementation for as long as the component lives. The browser already had a perfectly good one; the platform just didn't give you a way to use it.

The only spec-sanctioned way to reuse native semantics has no cross-browser path. That's not an edge case; that's the core use case.

Ten years to catch up

Interop was the other half of the promise, and for about a decade, the relationship status between React and custom elements was "it's complicated." React couldn't pass an object or array to one as a property, and couldn't listen to its custom events without manual ref wiring. The gap was tracked publicly on Custom Elements Everywhere for years.

Full support landed in React 19, in December 2024. That's more than ten years after custom elements were proposed. "Use it anywhere" didn't include the most popular UI library for most of that time.

The platform's own basics took nearly as long:

Form participation via ElementInternals only became stable cross-browser with Safari 16.4, in March 2023.
Declarative Shadow DOM (i.e. server rendering a shadow root without JavaScript) reached Safari in 16.4 and Firefox in 123, in 2024.

Forms and SSR. The two things every real app needs. Roughly a decade to get there.

So what actually went wrong?

Honestly, I don't think it matters whether Web Components failed by design or just because they were never fully leveraged. If you're picking a component model today, the outcome is the same: in their shipped form, they didn't become the web's component layer.

But I do think there's a single root cause, and it's this:

Web Components solved packaging. They never solved authoring.

They gave us a place to put a component (a tag name, a lifecycle, a shadow root). They never gave us a way to write one in markup. Look at what an app author reaches for every day, and what HTML gives you natively:

What you need	What HTML gives you	What everyone does instead
A reusable component with a typed API	Custom Elements (untyped, imperative, string-only attributes)	React / Vue / Svelte components
Conditional and repeated markup	Nothing	`v-if`, `{#each}`, `.map()`
Reactive state	Nothing	hooks, refs, runes, signals
Bind an input to state	Nothing	controlled inputs, `v-model`, `bind:value`
Declare a data dependency	Nothing	fetch-in-effect, loaders, resources

Every cell in that last column solves the same problem with different syntax: a loop is v-for in Vue, {#each} in Svelte, and .map() in React. Same idea, three syntaxes, and none of them carry over. That's why your component library gets rewritten every time your company changes frameworks. Web Components didn't fix that, because they never tried to.

This is the HTML5 story again. JavaScript and CSS each got a sustained, decade-long investment in the language itself. HTML's component model, by contrast, was built from the JavaScript side: a class you register, with HTML as the place it gets mounted. The markup never learned anything new.

Shadow DOM added a subtler problem. Most of us wanted scoping: my component's styles shouldn't leak out. What we got was isolation: nothing gets in either, so theming, shared design tokens, forms, and focus all have to negotiate with the boundary. We asked for scoping and got isolation along with it.

We can fix them

Here's the part where I stop complaining. If you take the record above seriously, the fix has a pretty clear shape:

Write components as markup, not as imperative JavaScript classes. Templates, conditionals, loops, bindings: in HTML.
A component should lower to a real native element. If it's a button, the browser should see a <button>. No wrapper, no rebuilt semantics.
Scope styles without a shadow boundary. CSS @scope exists now. Encapsulation without isolation; real isolation becomes opt-in, not a tax.
Reactivity should be a declarative dependency graph that tools can read, type, and analyze. No eval, no new Function, CSP-clean.
It should be portable. Compile the same source to React, Vue, or Svelte, so it isn't Yet Another Walled Garden.
Graduate into the platform one piece at a time. That's how Declarative Shadow DOM and invoker commands went from userland shims to shipped syntax.

None of these ideas are new on their own. Vue and Svelte proved markup-first components and scoped styles. Mitosis proved one source, many targets. The missing piece is putting them together as HTML, with the explicit goal of getting them into the platform.

Enter HTML Next

HTML Next is a component format, plus open source (MIT) tooling, built on a public Declarative HTML Components proposal. Here's a complete component:

<template component="x-counter">

  <defs>
    <state name="count" type="number" value="0"></state>
    <handler name="increment">
      <set name="count" expr:value="$count + 1"></set>
    </handler>
    <handler name="reset">
      <set name="count" expr:value="0"></set>
    </handler>
  </defs>

  <div>
    <button type="button" on:click="increment">
      Count: {$count}
    </button>
    <button type="button" on:click="reset">Reset</button>
  </div>

</template>

That's it. Markup, typed state, and event handlers in one HTML file. No class, no connectedCallback, no attributeChangedCallback, no shadow root.

And remember the button problem? Here's what happens to a component invocation:

<!-- You write -->
<x-button variant="solid">Save</x-button>

<!-- Replaced with a real button at runtime -->
<button data-component="x-button">Save</button>

The component doesn't pretend to be a button and hope every browser plays along. It gets replaced with an actual <button>. No customized built-ins, so no waiting on Safari, from the people who make iPhones (who are famously against buttons). Form submission, focus, role, and keyboard behavior stay the browser's job, where they belong.

You can use that same source file:

natively, with a small browser runtime (or with Vite), or
in Vue, React, or Svelte, imported alongside your existing components through Vite adapters, or
as generated framework source, via the converter, if you'd rather ship plain React/Vue/Svelte code.

That last part is the bit I care most about. A component library shouldn't need a rewrite every time an app changes frameworks. Write it once in HTML, and let the consuming project decide.

This is a dev.to article, so it's probably not going to surprise you that I'm the editor of this proposal, and you should weigh my enthusiasm accordingly.

The proposal is at Stage 0. The tooling is early, and syntax and output may change. It is not a W3C or WHATWG deliverable, and browsers don't understand this syntax on their own; the tools run or compile it for you. The goal is to prove features in userland and then upstream the ones that earn it, feature by feature. Some things a compiler simply can't fix (like native element extension across browsers), and those belong in later proposals to the actual standards bodies.

The proposal behind it

The tooling is the part you can use today. The part I'd most like your eyes on is the spec it implements: Declarative HTML Components Level 1.

It's written the way platform specs are written, because the end goal is to become one. It covers templating ($each, $if, $match), a small type system, a pure expression language with Intl formatting, bindings and events, slots and composition, server-rendered markup that hydrates into the same instance, reactivity and data, validation, style scoping, and a security chapter (no eval, static resolution).

A few design decisions I think are worth calling out:

Conformance is observable equivalence. A compiler and a browser polyfill are both valid implementations, and they must produce the same native DOM, state, events, accessibility, and errors for the same source.
It versions like the platform does. Levels like CSS (this is Level 1), stages like TC39 (this is Stage 0), and dated snapshots in between. No big-bang "1.0."
It's purely additive. A plain HTML file is already valid. You adopt one feature, one tag at a time.
It names what it can't fix. Native element extension and a better Declarative Shadow DOM are explicitly marked as upstream work for the real standards bodies.

There's also an honest list of open questions: data fetching and caching semantics, SSR serialization, whether expressions should use and/or or &&/||, scheduling, and parser edge cases like tables and SVG. If you have opinions on any of those (and if you've read this far, you probably do), open an issue on the specs repo. That feedback shapes what Level 1 becomes.

Moving forward

I don't want to bury Web Components. A lot of smart people put a decade into them, and pieces of that work (custom element registration, ElementInternals, Declarative Shadow DOM) are genuinely useful. I want to finish them: give the platform the authoring layer it skipped.

If that sounds interesting, read the proposal, build your first component, poke at the source, and file issues when something breaks. Something will. That's what Stage 0 is for.

In 2004, a few people at three browser companies decided HTML deserved a better future than the one it was being handed, and they went and built it. The whole web got better for it, quickly. JavaScript and CSS have had that kind of energy for ten years straight. I think it's HTML's turn again, and this time, anyone can help write it.

CSS: the language with no syntax

Matthew Dean — Fri, 08 Aug 2025 18:13:43 +0000

Congratulations! You have fallen prey to my clever click-bait-y title, but before you dismiss this topic out-of-hand ("Because," you say, "of course CSS has syntax"), or leave a smarmy comment, allow me to walk you through what CSS is, and how it's defined.

Some context: I've been a maintainer of Less.js (the CSS pre-processor) for about 10 years, and the lead maintainer for most of that time. When I started contributing, I knew very little about not just CSS parsing, but about parsing in general.

In the last 5 years, I've worked on not just Less but other CSS-related parsing projects, including one that re-imagines both Less and Sass parsing for the modern era (which has yet to be released). I've used a variety of parsing approaches, parsing generators, and parsing libraries.

In some cases, I had to abandon the use of certain parsers or parsing approaches because they just weren't flexible for CSS, and the reason is that CSS has no single syntax.

What do I mean by "single syntax"?

You can think of CSS as kind of a collection of "micro-syntaxes". CSS has kind of a top-level syntax for how things are organized (okay, okay, yes you can say that at the top level, there is a syntax), and then the way it works is that individual specifications have their own micro-syntax that defines the syntax within that location. On the whole, each micro-syntax has generally tried to mostly look consistent with other micro-syntaxes before it, but that doesn't mean that they actually are consistent or that the same syntax has the same semantics, as you might find in other languages.

You might be scratching your head at this, because, if you've never had to parse it, or have that parser actually understand all its component pieces (as it does in a system like Less), CSS syntax looks the same everywhere.

So, let's illustrate this with some examples.

Assignment or selector?

What does the colon : mean in CSS? You might be tempted to say assignment, because of this:

.box {
  /* Look! There's an assignment `:` operator! */
  color: red;
}

Okay, then, what does this mean?

/* Look! There's... oh... */
div:hover {}

"Not a problem!" you say. This is at the start of a ruleset (also called a qualified rule), and we know that pseudo-classes and pseudo-elements start with : followed by an identifier. Easy peasy.

Alright, so a pseudo-selector looks like :ident, cool. Okay, how do we parse this?

.box {
  /* Look There's a pseudo-... oh... */
  color:red;
}

Okay, never mind that, we say. We can just have two modes! When we're at the "top-level" where we're expecting rulesets, we can have : mean one thing, and then inside it, we can have it mean another.

Welp, not so fast. One of the reasons Less and Sass were so popular for so long was the convenience of nesting rulesets and at-rules inside each other, and both engines support this:

.box {
  button:hover {}
}

CSS Nesting has now been adopted by the core CSS language itself, and as of 2024, is now supported in browsers. So this form is valid in CSS now too.

If you know anything about parsing, you may now start to recognize that we're looking at an example of "infinite lookahead" and backtracking. Some engines either don't support infinite lookahead, or don't support it without major performance penalties. The reason it's "infinite" is because of cases like:

.box {
  foo:red blue green yellow purple brown black grey...

As we parse this, we have to ask:

is this a property called "foo" with a value of red blue green yellow purple brown black grey etc? or
is this a selector selecting an element called "foo" with a pseudo-class of :red and descendant elements of blue green yellow purple brown black grey etc?

There are ways to avoid infinite lookahead, of course, such as having a list of all known CSS properties, and/or having a list of all known valid HTML elements, but this is already a little too deep into parsing, so let's get back on track to syntax and how CSS is defined.

How CSS syntax is actually defined

The way that CSS syntax is defined is that you can think of it as having a basic outer structure with "slots" where syntax definitions can go.

These "slots" are:

An at-rule's "prelude" (everything before outer ; or its {} block)
An at-rule's block ({}) contents
A property's value
A pseudo-selector's () block, if it exists
A CSS function's () block

Example 1: at-rules

Instead of having general parsing rules, parsing is specified by the at-rule specification itself. For example: the @supports at-rule parses (or can parse) property/value pairs, like:

@supports (transform-origin: 5% 5%) {
}

...whereas the @scope rule expects to be parsing selectors e.g.

@scope (.card) {}

Example 2: :nth-child() and dimensions

In general, CSS considers units like -1 to be distinct tokens. If you have this, for example, this will be parsed as two values: 1 and -1:

/* This has a value of 1 -1 */
padding: 1-1;

However, :nth- functions define their own micro-syntax: An+B. Instead of the argument to :nth-child(n-1) being interpreted as two tokens, n and -1, it's interpreted as "n minus 1", which, confusingly, is different from the calc() function because, again, calc() has its own micro-syntax!

CSS: What's a "list"?

One of the most frustrating and inconsistent parts of CSS syntax is that it has no formal definition for "lists". Or, rather, it has a collection of syntaxes which all can represent lists, but not all of them are consistent in describing what's in the list and what isn't.

That said, probably the most consistent right now in CSS syntax and micro-syntaxes is comma-separated and semi-colon-separated lists, which is generally defined like:

// List members are ['1', '2', '3']
1, 2, 3

// List members are ['1 1', '2 2', '3 3']
1 1, 2 2, 3 3

// List members are ['a: 1', 'b: 2', 'c: 3']
a: 1; b: 2; c: 3;

That is, in general:

Each comma splits the value into distinct members of the list i.e. if you have two commas, you have 3 members of the list.
A semi-colon-separated list "groups" other values that, themselves, can have comma-separated lists.

You may be scratching your head and saying, "What do you mean, 'in general'? Isn't this always true in CSS?"

Sorry, but nope. Where this concept begins to fall apart is in CSS function calls. The reason it begins to fall apart is because of these ambiguities in CSS syntax:

CSS functions can receive arguments. Those arguments are CSS values.
CSS function arguments are a comma-separated list, BUT (importantly),
CSS values can also be a comma-separated list.

With early CSS functions, this wasn't an issue. All functions received values that didn't themselves have commas. Eventually, though, use cases and CSS proposals emerged for functions that could receive commas. And not just functions. There emerged use cases where other CSS values, which could be comma-separated, might themselves need sub-lists as individual parts of the value.

So, now what were proposal authors to do? If your guess is, "Hopefully, something consistent?" then prepare to be horribly disappointed.

The Many Failed Attempts at Lists-of-Lists Syntax in CSS

1. The `/` separator

You'll probably recognize this. In some CSS values, the list separator is a slash (/) character. But it would be a mistake to consider it a list separator like , or ;. I'll explain.

Let's take border-radius as an example:

border-radius: 10px 20px / 30px 40px;

In the border-radius syntax, this syntax is used to figure out "radius pairs" for corners. I don't want to get into the minutia of the border-radius syntax, but suffice to say that the / separates a set of values preceding it from a set of values following it. In this case, it's a list like: ['10px 20px', '30px 40px'].

You might be tempted, then, to think of the / as just another list separator. But, of course, that isn't the case.

When calc() was introduced, it recognized that almost all programming languages use / as a "division operator". It wasn't going to re-invent the wheel, so the calc() micro-syntax uses it for division and not as a list separator:

/** This means "20px divided by 2" and not
 * "a list containing '20px' and '2' */
calc(20px / 2);

Some property sets, like background-* for example, use comma-separated lists for individual properties, and slash-separated lists for other properties. So, when they get put together, you may get a value like this:

background: url(a.png) left top / cover, url(b.png) right / contain;

From a syntax perspective, what does this value mean? If you're familiar with the background property(s), you may instinctively be able to read this unambiguously. But let's look at this from purely a syntax perspective.

Can you tell me what the "lists" or "lists of lists" are from these CSS values?

unknown: one two / three four;
unknown: one / two three, four;
unknown: one, two three / four;

If your brain says, "The comma splits the value into list pairs, and the slash further splits THOSE values into list pairs," it's a good guess, but, in CSS, that's just not true. It's entirely dependent on the micro-syntax of the given property. You have to know the property name to know how to understand the syntax that follows.

In the case of background, this is how these lists are actually grouped semantically:

background: url(a.png) left top / cover, url(b.png) right / contain;

/**
  background: [
    [
      'url(a.png)',
      'left top'
      'cover'
    ],
    [
      'url(b.png)',
      'right',
      'contain'
    ]
  ]
*/

If the / divided lists consistently across CSS, then the semantic division of this value would be:

background: [
    [
      'url(a.png) left top',
      'cover'
    ],
    [
      'url(b.png) right',
      'contain'
    ]
  ]

Even url(a.png) left top requires you to understand the micro-syntax of background to know that url(a.png) is the background-image and left top represents a single property background-position and not two distinct properties. ✨ Micro-syntaxes! ✨

2. Lists of lists in function (or "function-like") calls

One of the first functions that needed a list of lists was var(). You might think of it as having two values, and it does: the custom property name and the fallback value:

color: var(--theme-color, red);

However, CSS authors had to resolve something: what about values that have commas? The solution, in this case? Just treat everything after the first comma as being absorbed into a single value.

font-family: var(--theme-font, 'Helvetica', sans-serif);

Is the comma consistent here? Again, take the var() out of this and just think of CSS functions as a general syntax. What does this mean?

unknown: new-css-function(one, two, three);

Is that a function that is taking 3 value arguments? Or is it taking one comma-separated value argument?

Well, in the case of var(), delightfully, it's neither. It's taking 2 arguments, the second of which can be a comma-separated argument.

From a language syntax perspective, that's kind of insane, but it gets better!

A note about Less / Sass's handling of lists of lists

Since both Less and Sass (the SCSS variant) are supersets of CSS, there are cases where each had to solve lists-of-lists from a wholistic syntax perspective since CSS offers no consistent guidance in this regard.
Sass let's you wrap values in parentheses to pass lists to functions and mixins:
value: sass-function((1, 2, 3), 4, 5);
Less prefers that you be more explicit, because parentheses may be part of a valid value (think media query syntax), so it asks you to use Less's escape ~ character to more clearly denote that you want the final value to be without the parentheses:
value: less-function(~(1, 2, 3), 4, 5);

3. The CSS Functions and Mixins Module

Probably the most bizarre and perverse twist on trying to come up with a solution for lists of lists is the new CSS functions and mixins module proposal.

It uses NONE of the prior solutions, including Sass / Less prior art, to define lists of lists and comes up with yet another. So, if you're counting, CSS and CSS preprocessor syntax now have:

comma-separated lists
semi-colon separated lists
slash-separated lists (inconsistent)
parentheses-grouped lists (Less and Sass)
...a brand new one defined by this module: curly-brace-grouped lists

This syntax ends up looking like this:

 width: --max-plus-x({ 1px, 7px, 2px }, 3px);

Let me be clear: it's not that I think this syntax is bad, necessarily; it's just that it's Yet Another Micro-syntax. IMO it has these two flaws:

Flaw 1

Until now, curly braces in CSS has actually been a mostly-consistent syntax, denoting a group of rules, like:

/* We thought we understood curly braces in CSS... */
.box {
  color: red;
  background: black;
}

The authors of this module proposal have decided to break that syntax convention, entirely, such that one of the few syntax "rules" will now be, again, removed from "reliable" syntax. (Not that CSS ever specified that curly braces should / would always contain rules; it's just been a consistent syntax convention until now.)

Flaw 2

Instead of CSS authors saying, "You know what? Maybe we should make a formal 'list of lists' standard in CSS and start using it," the use of this format for this module has no general applicability, and there are no plans to migrate it anywhere else.

In other words, if CSS were a single syntax, a syntax proposal with this would come with certain expectations to update other syntaxes for function calls or values to be able to use it, such as:

/* Supporting this moving forward: */
font-family: var(--theme-font, { 'Helvetica', sans-serif });
/* Instead of the inconsistent `rgb(100 100 100 / 0.5)` syntax */
color: rgb({ 100, 100, 100 }, 0.5);

There's no such proposal here. It's just Yet Another Micro-syntax.

CSS - not one syntax, but a smorgasbord of micro-syntaxes

Listen: I love CSS! Sure, from a language syntax perspective, it resembles something like Howl's Moving Castle. But, from a beginner perspective, its relatively-lean syntax means that it's easy to write and quite forgiving. In some ways, its weaknesses are also its strengths.

Just... don't ever try to build a CSS parser. Become a tomato farmer instead.

Addendum: despite knowing better, I've currently building a new CSS parsing & processing framework anyway, to replace Less / Sass / CSS modules / Tailwind / Styled Components / other styling systems, so follow me on here and/or leave a comment if you want to hear about it!

Why, after 20 years as a JavaScript developer, I switched to semicolons

Matthew Dean — Sun, 13 Jul 2025 20:07:46 +0000

This is a first of a series I thought I'd start writing (and hopefully continue writing) about my experiences over 36 years as a programmer, and 20+ years as a professional web developer. (Am I old now? I think I'm old.)

First, what are we talking about? If you're new to JavaScript, you may know that JavaScript is rather forgiving of statement terminations. JavaScript isn't alone in this. Go, Swift, Kotlin, Ruby, Python, Lua... they all make semicolons optional at the end of statements.

In JavaScript, the spec calls this Automatic Semicolon Insertion or ASI. The simplified explanation is that if JS sees what would be a syntax error, and it thinks a semicolon might fix it, it inserts one automatically.

Here's an example:

let one = 1
let two = 2

Early in the culture of JavaScript development, almost all code examples you would find online, though, always had semicolon terminators, like:

let one = 1;
let two = 2;

The semicolon-less era

In the early 2010s, this started to shift. Web development, as a culture, was getting more and more sophisticated, which led to more subject-matter experts with in-depth knowledge, including of esoteric concepts like ASI.

Many JavaScript developers began to say, "Look, semicolons are optional 99% of the time. Why not just omit them, as a standard?" For many, because semicolons seemed unnecessary, then they were just a form of visual noise.

Around the same time, teams were promoting coding with the same style, for easier maintenance and for making fewer decisions. So this new "standard" began to be incorporated in linting tools so that semicolon terminators were now not just optional, they were actually forbidden in a given codebase.

Anyway, this is a lot of probably unnecessary history, which many readers may already know. The point is, why did I, after adopting semicolon-less JavaScript for over ten years, decide to abandon this as of this year (2025)?

99% is not 100%

JavaScript doesn't require semicolons most of the time, but when it does, errors can suddenly become very unintuitive. Let's take this code example (demonstrating variable swapping via array destructuring), which I borrowed from this Medium post:

let varOne = 'Hello'
let varTwo = 'World'

[varOne, varTwo] = [varTwo, varOne]

JavaScript will actually parse that second statement as:

let varTwo = 'World'[varOne, varTwo] = [varTwo, varOne]

If I paste the above code example in VSCode, and let TypeScript try to explain the error to me, I don't get something like "semicolon missing between line two..." blah blah blah, instead I get these errors:

'varTwo' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer
Type 'any[]' is not assignable to type 'string'
Index signature in type 'String' only permits reading.
Left side of comma operator is unused and has no side effects.

Sure, if you know ASI rules, after a bit of head-scratching, you may eventually realize a semicolon is necessary here. The reason is that JavaScript will not insert a semicolon before ( or [ at the start of a line,

You can, of course, just add in one of two ways: either the end of the second statement or the start of the third, like:

// Option 1
let varOne = 'Hello'
let varTwo = 'World';

[varOne, varTwo] = [varTwo, varOne]

// Option 2
let varOne = 'Hello'
let varTwo = 'World'

;[varOne, varTwo] = [varTwo, varOne]

Interestingly most "Ditch your Semicolon" advocates have recommended Option 2, because you're not altering the second statement in order to resolve the third.

Code can start to look weird fast

Despite many advocates insisting that the above example was rare, as I said, it can make errors unintuitive, but, also, if you're working in a team where someone needs to review your code and isn't as familiar with ASI quirks, the above solutions can easily look like a typo.

Additionally, in the 2010s, destructuring patterns, including re-assignment via destructuring, were not as prevalent, as it only began to be supported in middle of 2016.

For these reasons, over time, I found myself needing to pepper in semicolons, because:

I began to use destructuring more in my own code, including re-assignment via destructuring.
I began to use TypeScript almost exclusively.

TypeScript: adding additional problems for ASI

Why would TypeScript make this issue worse? Let's take the following code, in JS:

let input = document.querySelector('input.url')
input.focus()

This works fine! But let's take this into TypeScript:

let input = document.querySelector('input.url')
input.focus()
// - errors: 'input' is possibly null
//           Property 'focus' does not exist on type 'Element'

Okay, let's fix that by casting this to what we know this element actually is.

let input = document.querySelector('input.url')
(input as HTMLInputElement).focus()

All of the sudden, both these lines are reporting errors, even though we only changed the second line. Why? Because TypeScript imports all the same ASI quirks as JavaScript, meaning a line that starts with ( continues the statement.

This began to increasingly happen to me. I would fix a type problem, which would then require me to wrap something in parentheses, which then would create new errors, which then I'd grumble and insert an awkward-looking semicolon there at the start of the statement.

What was the issue with semicolons in the first place?

Eventually, I began to wonder what I was really gaining by leaning on ASI. As software developers, we're used to looking at semicolons at the end of statements. In fact, if you're a web developer, you're used to putting them at the end of CSS declarations. They just aren't a big deal.

And as to visual noise? Because they are so ubiquitous, they start to visually disappear anyway.

They don't even arguably require more typing. I have both ESLint and "Fix on save" enabled in VSCode, meaning every save will just quietly fix any missing semicolons.

As a result, I've discovered that I actually think about semicolons less by using them than by not using them. There's just less cognitive overhead. Statements end with semicolons, full stop. Same-line statements are separated with semicolons. (Almost) all statements have semicolon companions. I no longer have to think about semicolons while destructuring or fixing type problems. My code is no longer confusing my C# colleagues who may be reviewing it.

Moving forward;

Anyway, for me, while this is arguably not the largest issue or problem to have, I thought it would be an interesting dive into code style decisions. And I would imagine some of the same logic may apply to other code that uses optional semicolons, and I'd be interested to hear about that!

Photo by Sudharshan TK on Unsplash

Simplicity as a Feature

Matthew Dean — Fri, 26 Nov 2021 23:55:06 +0000

I recently came across the article "Complexity is killing software developers," and I've been thinking about it ever since.

The article covers a broad spectrum around software development in general, but I've been thinking specifically around the domain of front-end web development, and the multiple layers of abstraction we often buy into as being zero-cost--essentially: all feature benefits, with no significant drawbacks.

We write our components in JavaScript. Except it isn't. It's TypeScript. We write a function call to update the DOM. Except it isn't a function call. It's JSX (TSX). It'll be a function call later. The JSX contains markup of what HTML elements it will render. Except it doesn't. They're "styled components", all of which are abstracted from both the elements they render and the CSS that will eventually be read by a browser. We include this component in our HTML document, except we don't. Someone wrote a 200-line Webpack config file that will magically split this component and others, along with other assets and resources, and render a linked document, based on an abstracted template. Maybe Webpack itself is abstracted, behind a tool like Next.js or Vite.

At my company, I started working on a site and just mentally tallying the layers of abstraction: styled components, TypeScript, React, Redux, route strings as typed enums, content as JSON...and I started to wonder: was all this necessary? Is it worth it?

Or another way to ask it: what is this costing us?

First of all, I have to acknowledge that this question is ironic coming from someone who's been one of the maintainers of Less (the CSS pre-processor) for the last few years. So, it should be said that I'm not against any of these abstractions on their face. I may have strong opinions about this or that tool, but there's no question (to me) that the rise of reactive libraries were a net benefit to web development, or the adoption of component-based design. I've often advocated strongly for tools like TypeScript.

That said, in the past little while, I've started to feel differently, and I've been thinking about this problem from a different perspective. What I've started to see is that, where we used to add these tools to solve a particular pain point where we had before, as a culture, we in web development have acclimated to complexity regardless of the costs. Why wouldn't we use Webpack? We used it before. Why wouldn't we use TypeScript? It's what we're comfortable with.

I think what we've failed to recognize--and I will include myself in this--is that for each benefit it may provide, there is a maintenance and cognitive overhead cost (among other costs) in each additional abstraction that we add into our workflow.

Our monorepo takes forever to run yarn install, and no one knows exactly why. The complex nest of dependencies is not something we've been able to really dig into yet, as we're plowing through each sprint. Each app takes mountains of time to compile, and to run tests, and bundles seem unnecessarily large, but to decipher that just takes more time with each layer of abstraction.

Recently, I switched our dev build compiler of some of our shared packages to SWC from TypeScript (along with removing other abstractions), which, on the one hand, is great! You definitely should explore doing that.

But... on the other hand, I was solving a problem that we ourselves had created, and this sacrilegious thought also occurred to me: what if we weren't compiling / transpiling our code at all? How much faster would that be?

Immediately after I had that thought, I looked around me to make sure the web development gods were not about to smite me. After all, we've lived in a world of, if not TypeScript, surely at least Babel-ified JavaScript, but there's a question if that's needed anymore.

I'm not the first one to have this thought. Rich Harris, a prominent figure in web development, having developed Ractive, Rollup, and Svelte, had this to say about moving from TypeScript back to JavaScript (with JSDoc type annotations): "Among other things, the resulting code is generally smaller than transpiled code. Building, testing etc all become much less finicky. And .d.ts files are still generated from source code."

I don't want to make this entirely about TypeScript; for many teams, TypeScript may be the best option! But I think there's an overlooked value in sincerely asking the question of just how complex any project needs to be, and recognizing that each layer of abstraction is not zero-cost. It may increase development time, even as it decreases it in other areas. It may increase build time or deploy time. It may increase tech debt. It can increase cognitive overhead, or the time to onboard a new developer.

Do you need React, or will Svelte do? Or maybe something even lighter?

Do you need Less / Sass, or styled components, or is your design system simple enough that regular ol' CSS will work?

Do you need Webpack? Or is there something simpler, maybe with fewer options, but with less cognitive overhead?

Do you need Redux, or can you use Zustand? Do you even need a global state library?

Do you need JSX? Do you need TypeScript?

I've begun to think about this as Simplicity as a Feature. Just in the way that we may optimize for performance, and build for Performance as a Feature, I'm starting to think we should optimize our tools and codebases for simplicity. Not to use the simplest tools but to simply use only the tools with only the features that we really need. And if we start to need that next abstraction, that's okay! Sometimes there are things that are trade-offs for performance, just like there are things that are trade-offs for simplicity.

But the leaner you keep your tools and your code, in theory, the faster you and your team can iterate, build, and deploy.

So stop using giant boilerplate-y project templates with every conceivable feature and tool you might ever need. If you use TypeScript, it's okay to not use it on some things! Heck, it's okay to manually write an .html file! It doesn't make you a bad developer, I promise!

And if you're new to web development, don't buy into web sites and apps needing to be necessarily complex, and you needing to learn and use myriad layers of abstraction.

It's okay for things to be simple. That might even be best.