panphora (u/panphora)

panphora commented on Ask HN: What Are You Working On? (December 2025) · Posted by u/david927

panphora · 4 days ago

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.

https://hyperclay.com/

panphora commented on React vs. Backbone in 2025 backbonenotbad.hyperclay.... · Posted by u/mjsu

Jcampuzano2 · 2 months ago

Its hilarious reading this article and then the code because despite sometimes being a React hater - the React code is entirely more readable and followable.

Yes there are good frameworks that I'd argue beat React in multiple facets, but Backbone is not it having written it in the past.

- Two way data flow with stores is terrible for predictability

- Batching is not built in by default so you get layout thrashing as your app scales unless you're very careful

- You can easily blow away entire DOM trees if you aren't careful since it does not do any sort of reconciling differences.

- And more.

And the argument about needing to know stuff about the framework is entirely worthless. There are frameworks all over every single programming language ecosystem and ALL of them come with something you have to know about the framework itself, thats the tradeoff you make by picking a framework at all. Can we stop using this as an argument that there is magic or not? Yes React does tend to have a bit more in certain areas but they things they mentioned aren't even close to the worst offendors and have legitimate use cases.

The number of quality of life improvements, performance considerations, warning/DX improvements, etc. Its just not comparable for a small toy example.

Go build a full app with Backbone and React and tell me React wasn't miles easier to reason about and continue adding features.

panphora · 2 months ago

Author here.

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?"

panphora commented on React vs. Backbone in 2025 backbonenotbad.hyperclay.... · Posted by u/mjsu

ZvG_Bonjwa · 2 months ago

There is, I think, a sort of innocent arrogance that comes with people who boldly claim that renowned, well-adopted frameworks or technologies are straight up bad or a non-improvement over yesterday’s tech.

That’s not to say popularity guarantees quality, that progress is always positive, or that there’s not plenty to criticise. But I do think authors of articles like this sometimes get a big hit from being subversive by playing into retro-idealist tropes. The engineering equivalent of paleo influencers.

Such proposals would suggest a huge global collective of the world’s most talented engineers have been conned into fundamentally bad tech, which is a little amusing.

panphora · 2 months ago

Author here.

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.

panphora commented on React vs. Backbone in 2025 backbonenotbad.hyperclay.... · Posted by u/mjsu

picardo · 2 months ago

> For massive apps with 1,000 components on the same page, maybe React's complexity is justified. But what the other 99% of apps?

The number of components is not the only yardstick of complexity. Most of the complexity in building a UI comes from state management and how state changes are propagated across the store and the UI.

I worked with Backbone for many years, and I can distinctly recall the hours of frustration I had debugging a UI because it was freezing due to cascading state changes. That was because we were using Backbone Store, which had bidirectional data flow, and when one updated the store, it would trigger a change to the UI, which would change the state store, which would change the UI, etc.

You could argue that the real innovation of React was "unidirectional data flow," but React team made Flux architecture central to the framework, making it easier to adopt good practices, whereas Backbone remained store agnostic and even encouraged Backbone Store which used the observer pattern for many years. I think you should choose a framework that allows you to fall into the Pit of Success, and React was that framework at the time, and for my money, it still is.

panphora · 2 months ago

Author here.

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.

panphora commented on React vs. Backbone in 2025 backbonenotbad.hyperclay.... · Posted by u/panphora

efortis · 2 months ago

> Something hackable like …

I've been thinking and experimenting with re-rendering the whole DOM[1]. I'm aware there are libraries for merging DOM trees, but I'm limiting the project to native APIs. I'm following React's declarative model with a 10 LoC React.createElement implementation. Since there's no native DOM merge API, I'm mutating the DOM in two places, but reusing the components.

So far, I believe that given a merge DOM function or native API, we can get the benefits of React with a few utilities.

[1] https://github.com/ericfortis/mockaton/blob/main/src/Dashboa...

---

> Is there a better model?

IMO, React class components with something like Meteor’s ReactiveVar for state. Here’s an implementation for that standalone state:

https://github.com/uxtely/js-utils/tree/main/reactive-state

panphora · 2 months ago

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.

panphora commented on Shiller PE Ratio multpl.com/shiller-pe... · Posted by u/justin66

ArtTimeInvestor · 3 months ago

The all time high of the Shiller PE was in December 1999.

If your hypothesis at that time was that the internet would benefit tech companies, it was not a bad time to invest:

Microsoft shares were $58. Now they are $510.

=> 9% annualized ROI.

Amazon was at $4. Now it is at $220.

=> 17% annualized ROI.

QQQ was at $89 and is now at $592

=> 8% annualized ROI.

panphora · 3 months ago

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.

panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u

sydbarrett74 · 4 months ago

I'm getting a 404 for most of the pages. Not confidence inspiring.

panphora · 4 months ago

I wasn't planning to launch today hehe. The changelog and pricing links are fixed!

panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u

phantomathkg · 4 months ago

At first I thought it is tiddlywiki but it is not.

panphora · 4 months ago

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 :)

panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u

clemensnk · 4 months ago

This is really neat! It echoes many of the ideas we've been exploring with the Webstrates project (https://webstrates.net). We've been using the DOM as persistence layer for building malleable collaborative software for smaller groups, whereas hyperclay focuses on using the same mechanisms for traditional webpages. Recently, I have been experimenting with a local-first approach to Webstrates (https://github.com/Webstrates/MyWebstrates). Might be interesting to explore if a Webworker-based approach like in MyWebstrates could be used for offline editing in hyperclay.

panphora · 4 months ago

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.