Make it have an initial count via attributes, sync it with the DOM so if the attribute changes the count resets, and make the JS property always match the attribute (and vice-versa) so it behaves sanely. You're in for a world of pain even for something as simple as this.

Plus they're not declarative: you will only make me use innerText-based updates by threatening me and my family.

Plus they only work with JS enabled, while I can use JSX in SSR.

I've worked extensively with Web Components. They suck.

I barely compact at work in a very complex monorepo (neither with Fable 5.1 nor Opus 5.5), and yet in my personal greenfield project Astra keeps compacting all the time, to the point of it being unusable.

2. Even in that case, people might just be demanding equal justice. If I make information free I might get jailed. Regardless of my moral framework.

It does not write code. It just calls my tool.

But I see your other points though.

I wish. https://modelcontextprotocol.io/specification/2026-07-28

If you often need timezone conversion, sounds like a `timezones` skill exposing a few lines in a Python script. Boom. No MCP needed. No server needed. It's just files, all the way down. If you find yourself operating with dates a lot maybe you need a `datetime` skill wrapping a bunch of tiny scripts. Fully deterministic, cheap on tokens, and you can even run them without an agent (shocking nowadays :P)

As I identify repetitive actions I add (Claude adds) new scripts to the Skill to save tokens in the future, whereas MCP I'm at the mercy of the server provider. E.g. I have a Magic the Gathering skill with a bunch of tools to retrieve card databases, simulate hands, get card images...

This article enlightened me: https://mariozechner.at/posts/2025-11-02-what-if-you-dont-ne...

This is why I don't feel Skills are orthogonal. They feel like MCP on steroids since the scripts can be composed with Bash et al (huge battle-tested ecosystem, plenty in the training set)... and you don't need crappy abstractions like "resources" (yes, that's a thing in MCP) when the agent has a shell and a filesystem.

I've used this pattern to great success. Nowadays I just share these `.skill` packages with my friends (I think they're just a fancy ZIP file?)

The only thing missing for me is credentials and sandboxing (see my GP post). I have my own ideas on how to solve this (and some of that Claude in cloud already solves for me), but it's not easy (which is how MCP won).

MCP is the wrong abstraction for all of that. Skills are better as pluggable interfaces, and I predict[0] chat and agentic loops will converge eventually (Anthropic already did this correctly; OpenAI, it's your turn) and skills marketplace will replace MCP in its current form.

I see value in MCP, but it feels like a stopgap/stepping stone.

[0] Where "predict" = "hope". The best solutions are often not the winners.

Computers used to have very little memory and processing power, and screens had very low pixel density so line width was not that big. Then you have to deal with the baggage 50 years later.

Modern Lisps have the luxury so they use head/tail or first/rest.

Not sure if you're just being polite but, in case you're doubting, functional languages make that distinction too.

Haskell has `Data.Vector.Vector` vs `Data.Vector.Mutable.MVector`.

Clojure has `transient`.

OP is just mistaken.

I feel like you're using "mutable" too narrowly, as it's used colloquially in some programming languages. E.g. in JS, MDN itself talks about "reassignment"[0] and not "mutability" even though people often use "mutability" as a word to refer to the distinction between `const` and `let`. The only mention of mutability there is:

> Others may prefer `let` for non-primitives that are mutated

I.e. explicitly using `let` for mutated arrays, even if not reassigned, to make the signal mutability (which JS cannot express).

Note that you used "reassignment" which is the specific word for "mutating a binding", but the article is not referring to bindings at all.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

The fact that you wrote this comment with Hindley-Milner-ish notation already makes your an outlier.

[0] https://tailwindcss.com/docs/styling-with-utility-classes#ma...

[1] https://github.com/tailwindlabs/tailwindcss/discussions/7651...

This leaves framework components as the only abstraction boundary, but that means if you're writing plain HTML without a framework there's literally no way to standardize your design system.

That and the huge soup of classes in DOM is (part of why) I don't like Tailwind... but that ship sailed a long time ago.

If I had to guess, this is pure Tailwind rot.

They don't know what n+1 problem is and they don't know about long-term maintainability.

My gripe with Claude is that while investigating how to do this it will report 200 other incidental findings which I overlooked and I realize those are broken too and need urgent fixing, derailing me, not it.