Hyperclay: a way to package up HTML files as portable, editable apps that contain their own editable UI. I'm using these simple apps to plan, edit emails, write blog posts, and a lot more. I edit them on my mac and they sync to the web live.
It feels like being able to design my own document format on the fly and display it however I want. It's making it painfully obvious how many editable primitives the web is missing, however.
I agree that all frameworks require learning framework-specific concepts, but I think there's a meaningful difference in what you need to know and how that knowledge transfers.
With Backbone, jQuery, or vanilla JavaScript, you're learning DOM APIs, event patterns, and explicit state management. These are things that are visible, inspectable, and fundamentally close to the platform. When something breaks, you can pop open devtools, see the actual DOM, trace the event handlers, and understand what's happening. The knowledge you gain is transferable. It's about how the web platform actually works.
With React, you're learning abstractions on top of abstractions: virtual DOM diffing, reconciliation algorithms, why objects in dependency arrays cause infinite loops, why your click handler sees stale state, why your input mysteriously cleared itself. This is React-specific magic that doesn't transfer. It's knowledge about how to work around React's mental model, not knowledge about how the web works.
You mention that batching and DOM reconciliation are solvable problems that justify React's complexity. But the article's point is that for most apps -- not Facebook-scale apps with 1,000 components on one page, but normal CRUD apps -- those problems can be solved with simpler patterns and conventions. We don't need a virtual DOM and a sophisticated reconciliation algorithm to build a form validator.
The real question isn't "does React solve problems?" It's "does React's complexity match the complexity of the problems most developers are actually solving?"
> The real question isn't "does React solve problems?" It's "does React's complexity match the complexity of the problems most developers are actually solving?"
Kind of disrespectful to reply to valid criticism of your AI slop article with more AI slop. Write like a human being man, what’s the point?
The "paleo influencer" comparison is interesting, but I think it actually works both ways here.
Yes, there's a temptation to romanticize the past and dismiss modern tools. But there's an equally strong tendency to assume that newer, more popular, and more widely-adopted automatically means better. React didn't just win on pure technical merit. It has Facebook's marketing muscle behind it, it became a hiring checkbox, and it created a self-reinforcing ecosystem where everyone learns it because everyone uses it.
The article isn't suggesting that a "huge global collective of the world's most talented engineers have been conned." It's asking a much more nuanced question: did all that effort actually move us forward, or did we just move sideways into different complexity?
Look at the two implementations in the article. They do the same thing. They're roughly the same length. After 15 years of React development, countless developer hours, and a massive ecosystem, we're not writing dramatically less code or solving the problem more elegantly. We're just solving it differently, with different tradeoffs.
Sometimes looking backward isn't about being a "retro-idealist," it's about questioning whether we added complexity without proportional benefit. The paleo diet people might be onto something when they point out that we over-engineered our food. Maybe we over-engineered our frameworks too.
> They do the same thing. They're roughly the same length
But they arent the same, the backbone code has raw HTML strings. These are opaque for code editors and not type safe. React code is using typed objects to construct the html (if you used typescript like is standard in 2025 for react projects). The backbone app is disconnected in the rendering flow. the space-y-2 selector is ambiguous and causes unnecessary searching. Just in this small example adds a level of indirection that just adds noise to what the component does. With everything setting raw html, what if you wanted the requirements blob to be a seperate component for instance. this is super easy and clean in react because html and custom components are treated the same.
It also cherry picks an extremely narrow use case of a single element on the page of a password element. This hides the realities of mature apps that you then need another parent component to check if the confirm password field matches, submits the form to backend and displays errors, checks if username is taken etc. Your example doesnt show calling another component from inside a component, etc.
Your purposefully slicing it in to a narrow use case and trying to show equivalence where there isn't
This is the equivalent of those "Primitive Technologies" Youtube videos of building a swimming pool out of mud. Yeah sure technically you accomplished some definition of a "swimming pool". Yes, in some lens you can stand back and look at your pool and a inground pool with filtration, etc and say that you accomplished the same. Yes, technically you proved if you want a swimming pool you don't need a bunch of other equipment. But if you are building a swimming pool to last and be usable for the next 10 years, you will find out why modern pools are not a dug out hole filled with muddy water.
Did you work on any big backbone apps professionally? We had a huge one at Airbnb where after a certain scale any change by anyone - from new grad to expert - could get stuck in 2 days of debugging pure incidental complexity. Change some ui dom structure? Oops you broke someone’s selector and their event won’t fire anymore. Send an update at the wrong time? Render loop.
Switching to React for that app (and everything else) was such a godsend. Once React landed in the codebase it spread like wildfire because of how eager everyone was to burn down the old way!
To me the “it succeeded because marketing” rings hollow because my experience at the time was:
- people loved their MVC ideas and “semantic makeup”, putting template in the JS was so WEIRD and ICKY. And no doubt the compile step for JSX still is annoying one-time complexity. Lots of resistance / thinking React was dumb.
- then you hear about someone on another team replacing a small but annoying feature with React and how relieved they are to be out of backbone hell
- you try yourself, it’s a weird new world and you struggle a bit with the new concepts. Hit a few sharp edges.
- after a week and a half you can’t go back.
- after 6 months (almost) everyone on every team wants to rewrite to React. (We had a few front end leads clinging to their Separation of Concerns as though changing class names on a node in backbone wouldn’t break a zillion event handlers)
If definitely became The Way and self reenforcing, but in my mind that happened primarily out of merit.
I appreciate the point about unidirectional data flow solving real problems, but I think we're trading one complexity for another rather than actually simplifying things.
Yes, cascading state changes with Backbone Store were frustrating to debug. But React's abstractions introduce their own set of equally frustrating problems: stale closures where your click handler sees old state, infinite useEffect loops because an object in the dependency array gets recreated every render, mysterious input clearing because a key changed from stable to index-based.
The difference is that Backbone's problems were explicit and visible. When something broke, you could trace the event handlers, see what fired when, and understand the flow. The complexity was in your face, which made it debuggable.
React's problems are hidden behind abstraction layers.
I'm not saying React doesn't solve problems. I'm questioning whether those solutions are appropriate for the 99% of apps that aren't Facebook-scale. Sometimes the explicit, verbose approach is actually easier to reason about in the long run.
Yes, applying compositional patterns and one-way data flow is most appropriate for all apps, independent of scale. Why? Because developer A (author of app x) leaves company. Developer B gets hired. Developer B is onboarded in an afternoon because things can be understood at a glance thanks to functional patterns and one-way data flow.
Having built many large-scale Backbone apps, anytime someone new came on board it was really very, very difficult, no matter how many design patterns one applied.
React's innovation was making FP mainstream. And then teaching the value of simplicity, as a principle. And yah, if something broke, it might be a little opaque, but at scale and in general, things broke _way less often_.
This is also the reason why most devs are full-stack now. Back in the day backend devs wouldn't dare touch FE code, and now its "not so bad", and pretty much anyone can work all over the stack.
This is a really cool approach! I checked out your Mockaton dashboard code and love what you're doing. Here's a simplified example of your pattern that really showcases its elegance:
// Using your minimal native DOM library (15 lines)
function TodoApp() {
return r('div', null,
r('h1', null, 'Todo List'),
r('ul', null,
store.todos.map(todo =>
r('li', {
className: todo.done ? 'done' : '',
onClick: () => store.toggleTodo(todo.id)
}, todo.text)
)
),
r('input', {
placeholder: 'Add todo...',
onKeyDown(e) {
if (e.key === 'Enter') {
store.addTodo(this.value)
this.value = ''
}
}
})
)
}
// Full re-render on any change - just replace everything!
store.render = () => document.body.replaceChildren(...TodoApp())
What I love about this:
- Zero build step - no JSX transpilation, no bundler needed
- Direct DOM access - `this.value` just works, no synthetic events
- Brutally simple - the entire "framework" is ~10 lines
You're absolutely right that a native DOM merge API would unlock this pattern completely. I just wish this could happen in the DOM instead of JS, so that we could get the power of the DOM as an intuitive model to think about instead of abstracting it into an amorphous data structure.
The fact that it has no build step and works directly on the DOM is fantastic — very similar to Backbone in terms of being able to understand what's happening under the hood! You can pop open devtools, see exactly what's happening, and modify it on the fly. No virtual DOM, no reconciliation mysteries, just functions returning DOM descriptions that get wholesale replaced.
You're cherry picking the tech titans that made it out of the Dot Com boom alive. The NASDAQ-100 had to replace 36 of its components between 2000-2002 due to bankruptcies and delistings - nobody knew in 1999 which companies would be the survivors.
The NASDAQ topped at 5,048.62 on March 10, 2000. It took 15 years for the NASDAQ to recover to its dot-com peak level. In those 15 years, you got an inflation-adjusted negative annualized ROI.
Annualized return of the NASDAQ from the 2000 peak to today is an inflation-adjusted 3.4%. Even "sure thing" blue chips like Cisco and Intel still haven't recovered their 2000 peaks in real terms, 25 years later.
Microsoft was the largest public tech company by far in 1999. So I wouldn't call that choice cherry picking. And wasn't Amazon with about $30B market cap the largest internet pureplay at that time?
nobody knew in 1999 which companies would be the survivors
The author (me) was strongly inspired by TiddlyWiki -- I love that software and wish it was allowed to proliferate more. If only browser vendors allowed their users to persist HTML files back to their own machines, we'd have a whole new ecosystem of personal applications!
I wish I could change the name from Hyperclay to TiddlyApp :)
Thank you for your kind words, much appreciated, speaking as the creator/maintainer of TiddlyWiki. I really like what you've done, and the way you've described it on the site. I hope you will enjoy success with it, and have as much fun with it as I have with TiddlyWiki.
> If only browser vendors allowed their users to persist HTML files back to their own machines, we'd have a whole new ecosystem of personal applications!
Hi Clemens, I'm a big admirer of yours and what you're doing with Webstrates. I first heard of you about a year ago, when I was first exploring the ideas that became Hyperclay.
I love the idea of a local-first Hyperclay. Offline editing is one of the pillars of personal software and I'd like to head in that direction.
Would you be open to hopping on a video call at some point? I'd love to compare notes.
1. Security: It operates under the same security model as most website builders (think SquareSpace), we completely trust the end user to modify their own site in their own best interest. If the end user violates this trust, they will lose access to their paid account and could be liable to damages from other users. Their actions, their consequences.
2. Who can modify: You can modify any app you create. You can also "enable signups", which allows other users to easily fork your app, but they all trace back to your source app. We're making a plan right now where you can ship updates to forked apps.
3. Difficult to maintain: Pieter Levels (of NomadList) famously codes his $60k/month apps in single index.php files, so I suppose it matter how you organize your code and what level of navigating-through-the-cruft you're comfortable with.
4. Other people can fork your app and track their own beers. We also want to integrate collaboration features, so 2 people can have control over the same page simultaneously, but for now it's best for single-user apps.
It feels like being able to design my own document format on the fly and display it however I want. It's making it painfully obvious how many editable primitives the web is missing, however.
https://hyperclay.com/