The idea is simple: store state you'd normally store in a separate database in the document itself.

Then, also give the the document a bunch of powerful APIs granted to it by its host:

(1) Sync changes to the document with live collaborators

(2) Extract data from the document using a simple JSON map config

(3) Boot up a full content CMS from the same simple JSON map config

(4) More features added every month

I'm really excited with even the tiny bit of early traction I've gotten. About a dozen paying users so far.

Long term, I'd love to have this file type (vanilla HTML file + some extra features granted by the host) become a file type other companies offer tools and their own hosting for (like Wordpress).

Hosted platform: https://hyperclay.com

Native offline apps (source available, almost MIT license):

- https://htmlclay.com

- https://hyperclaylocal.com

Autonomous driving is the clearest counterexample: by March 2026 Waymo had logged over 220 million rider-only miles with nobody in the driver's seat, and was doing 400,000+ rides per week across six US metros. Tesla's consumer product is still officially "Full Self-Driving (Supervised)," and Tesla itself says it does not make the car autonomous. Mercedes has Level 3 certification. Tesla has none.

Optimus missed the stated 5,000 robots in 2025. As of July 2026, Tesla still isn't selling it and is only preparing manufacturing capacity. Meanwhile Agility's Digit is in commercial warehouse deployment today. Solar Roof is worse: Musk targeted 1,000 installations per week, and Wood Mackenzie estimated Tesla averaged about 21 in 2022. Tesla's disputed the number but offered no replacement count.

SpaceX is the real exception. It genuinely leads, and the engineering is remarkable. But it's still a decade overdue on "crewed Mars by 2024." That's the point: on the one venture where "more progress than anyone else" is actually true, the promise is still failing by over a decade.

The criticism isn't that nothing comes to pass. It's that concrete near term promises repeatedly fail and get replaced by bigger ones. When a valuation depends on being uniquely far ahead, competitors catching up erases that premium fast.

That can snowball: wider spreads → higher borrowing costs → more stress → wider spreads. The existing bonds' coupons are fixed, so the real bite is on future issuance and refinancing.

Lots of capital-intensive companies (SpaceX is definitely in this category) lean heavily on debt markets to fund ongoing investment and roll over maturing debt, so losing cheap access is a big deal.

Comments URL: https://news.ycombinator.com/item?id=47779309

Points: 8

# Comments: 1

Key counterpoints:

- Global FX turnover runs near $9.6T per day (BIS, April 2025). A retail wave of calls will not move USD/JPY in a durable way at that scale.

- /6J options settle on /6J futures. When you buy calls, you mostly push dealer delta hedging into futures, then dealers unwind as exposure changes. No sustained spot yen demand comes from that flow.

- FXY calls track an ETF wrapper, not spot.

- “Widowmaker trade” most often refers to repeated losses from shorting Japanese government bonds, not a long-yen crowd squeeze.

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/

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

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.

  // 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())

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.

Comments URL: https://news.ycombinator.com/item?id=45677968

Points: 4

# Comments: 2

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.

I wish I could change the name from Hyperclay to TiddlyApp :)

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.

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.

But the ultimate goal is to have an ecosystem of where you can host/deploy/use HTML apps, including other competing services.

Note: we are working on a way for a developer to push "DOM-based schema migrations" to all forked apps.