Intentionally Unscalable

_hyperscript is intentionally unscalable. We make decisions that would be obviously inadvisable to anyone looking to make scalable software, and dismiss features like reactivity that seem to have proven themselves in this regard. To understand why, I examine and critique the concept of “scalable”.

Scalability refers to the ability of a system to handle more work given more resources. This definition matches both formal definitions and common use in application development circles. Given this definition, we can see that:

• Scalability is unidirectional — it only refers to scaling up, never scaling down. In fact, I never hear “scaling down” discussed at all. Declaring it out-of-scope to ascribe this to a wider culture of growth, I’ll just speculate that perhaps scaling down is assumed to be trivial, or not necessary as a system that handles a large amount of work can necessarily handle a small amount, adequately, without modification.
• When people talk about the scalability of a tool, they are usually employing metonymy^[1]. They are discussing the impact of the tool on other systems’ scalability (will _hyperscript hinder us as we get more users/our app gets more complex?) and not the scalability of the tool itself (can we get hyperscript to run N lines of code in T time with better hardware?)
• System, work, resources — a software development team consists of multiple systems using multiple kinds of resources to do multiple kinds of work. Which system is being discussed is usually clear through context, but we should be aware when “scalable” is used without such context.

System	More Work	Resources
Software	Serve more users.	Computers.
Team	Add complexity to the software and maintain it.	Time, money.

The two main systems in a software organization.

Why is scalability desired?

1. “As our app gets more complex, X will prevent us from growing and maintaining it”.

2. “As we get more users, the app we built with X will need rewriting”.

Write to rewrite

Expect that you might need to rewrite your code, and be considerate of your future self who is doing that. _hyperscript helps you do this in two ways:

• Readability over writability. The fact that _hyperscript code examples look like plain English is just as much an achievement of the author as it is _hyperscript’s. We do not do anything smart like Natural Language Processing; _hyperscript uses common and normal parsing techniques. C++, Perl, perhaps even Ruby have more complex grammars than _hyperscript. We give you tools like the prop of object and object's prop syntax. and theit variable that might seem magical but is actually little more than the accumulator register in an 8-bit processor. It is up to you the programmer to use these tools to create readable code. The burden you take upon your shoulders can include (but will not be limited to):

• Locality of behavior. Ever looked through a GitHub repo, not been able to find the code you were looking for, eventually clone the repo locally and start “Jump to Definition”-ing and “Peek References”-ing your way towards your target, only to find out it’s a wrapper for yet another function? If it is a Java project, I usually give up before reaching any source code files at all. Htmx “Carson” Org has written about Locality of Behaviorpreviously, so I’ll direct you there.

Conclusion

I recall what I now know to be an urban legend about the great architect Mimar Sinan. Supposedly, when the keystones of some arches in a mosque he built were yielding to old age, an engineer working on the restorations found a note in a bottle signed by Koca Mimar Sinan Ağa himself. It was a step-by-step guide on how to replace the keystone without disruption to the rest of the structure, complete with drawings.

Putting aside the implication that our modern architects don’t know how stone arches are built, and that Great Sinan Agha The Architect expected such architects to restore his works, this fictional Mimar Sinan clearly doesn’t know anything about scalability. If he did, he would predict when the Sultan would die and make the mosque last exactly that long.

When asked what their language is good for, many designers would say “everything” which really means “nothing”.

– Robert Nystrom, What I Learned at the Emerging Languages Camp

Nystrom said this in the context of choosing a niche for your language, but I believe it applies just as well to choosing a scale.

---

1. I was excited when looking up this word on Tureng, but “metonymy” doesn’t really have the barebones simplicity of the Turkish “ad aktarması” or the weight of the Arabic loan “mecaz-ı mürsel”. ↩︎

2. The way that the “we’ll need rewriting” argument assumes growth, but rejects relying on it reminds me of paying people in shares. If you can’t trust it enough to just pay me the money you’ll definitely make back, why should I? ↩︎

3. originally said this much more pithily: “if you are certain you’ll grow to 1 billion users, and you need an app that can handle that, why build it now on a startup budget when you’re going to have the budget of a 1B-user app soon” ↩︎

4. I’m aware that some people do programming purely as a job. I sometimes envy the indifference I imagine they have towards our petty squabbles. ↩︎