panphora

That simply isn't true. Progress toward a goal isn't the same as leading the field.

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.

The losses fall on bondholders now, but it does make it harder for SpaceX to raise money going forward. And if they actually slip into junk territory, some institutional investors will be forced to sell (mandates only allow investment-grade), pushing prices down and yields/spreads up even further.

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.

Anger about the 2008 bailout makes sense. Yen carry unwind deserves attention. However, the trading call to action fails on market structure.

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.

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/

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

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.

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.

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

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.

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

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

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.

This is a version that lets you easily update HTML apps locally. The hosted version is for when you want to share your apps or let other people fork them online.

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

Sorry about that, it's fixed now: MIT License

I added this word-for-word to the home page. Thank you!

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

Yes, I agree. My dream would be to one day work on a browser and integrate Hyperclay into it. I believe web apps have been around long enough as a core web technology that browsers should ship with a local web host, knowledge of what a user and user account is, and the ability to persist to disk whatever the user chooses.

There's two approaches Hyperclay takes.

1. Hosted: You get a bunch of "HTML Apps" that persist themselves by calling their own /save endpoint. We grab the HTML and overwrite their-app-name.html, making a backup/version along the way. (Each user can edit their own app only, but they can also enable signups so that other people can fork their app. We also have plans to allow them to ship optional updates to forked apps.)

2. Local: You download the open-source Hyperclay Local [0] and you can have your own personal, local HTML apps that also call the /save endpoint and make backups. You're also open to extracting the core code from this to host your own personally malleable apps on your own server (just implement some kind of auth)

[0] https://hyperclay.com/hyperclay-local

instead of storing JSON we store HTML with all its verbosity and all its tags that have nothing to do with the user edit

Yes. In exchange, we get a portable, malleable, self-contained application. That's the tradeoff.

What about if the webmaster then wants to change the HTML title

1. The webmaster owns my-app.hyperlay.com (or somecustomdomain.com). 2. The user forks their version and gets user-version.hyperclay.com (or user-version.somecustomdomain.com)

You need to fork before editing. In the future, we'll have support for shipping updates to forked applications that can be accepted or denied by the end users.

There is an open source, local app version by the same author (me) here: https://hyperclay.com/hyperclay-local

The idea is that two instances of overtype would be initialized inside those divs!

As someone who runs production services but isn't a full-time sysadmin, I evaluated this script before thinking about deploying it.

Here's what you should know:

The Good: It's a comprehensive monitoring solution that actually catches real threats. The YARA integration, eBPF monitoring, and honeypot features are impressive for a bash script.

Security Issues:

1. Command injection in process monitoring - Initially looked like a vulnerability because the code uses xargs basename on process names, which seemed dangerous. However, process names from ps output are already sanitized by the kernel (limited to 15 chars, no shell metacharacters executed).

2. Executing Python scripts from /tmp as root - Real privilege escalation vulnerability. Ghost Sentinel writes to world-writable /tmp then executes as root. Any local user can overwrite the file between write and execute to gain root. Trivial to exploit with inotify or loop, 100% reliable. Turns any compromised service account into root access. Fix: use root-owned directory instead of /tmp.

Email Configuration - Gmail will block direct server emails. Install msmtp and configure it with your Gmail app password (not regular password) to get theProtector to use msmtp's mail command:

  # Install
  sudo apt-get install msmtp msmtp-mta
  
  # Configure ~/.msmtprc (for root since script runs as root)
  sudo tee /root/.msmtprc << 'EOF'
  defaults
  auth           on
  tls            on
  tls_trust_file /etc/ssl/certs/ca-certificates.crt
  account        gmail
  host           smtp.gmail.com
  port           587
  from           your-email@gmail.com
  user           your-email@gmail.com
  password       your-app-password
  account default : gmail
  EOF
  
  sudo chmod 600 /root/.msmtprc

  # Remove cron job
  crontab -l | grep -v ghost_sentinel | crontab -
  
  # Remove systemd timer (if installed)
  sudo systemctl disable ghost-sentinel.timer 2>/dev/null
  
  # Remove logs and data
  sudo rm -rf /var/log/ghost-sentinel

Performance note: On resource-constrained VPS instances, set ENABLE_EBPF=false and MAX_FIND_DEPTH=1

I'm deploying a patched version this week. The creator spent a year on this and it shows - the eBPF/YARA integration is impressive. They should set up GitHub Sponsors or a donation link. It's better than many commercial solutions I've seen.

It's all bendable, always has been.

Yes, there's definitely philosophical alignment with the hypermedia approach: keeping things simple and leveraging HTML's native capabilities. In fact, I use hypermedia-oriented techniques on all the dashboard pages in the Hyperclay web app.

But in Hyperclay apps, the DOM is the source of truth -- there's nothing else. So there's no need for more than a single AJAX call (to save the page). HTMX is built to support a more traditional multi-page stack, whereas Hyperclay is built around single-file HTML apps.

The idea is that every HTML file is its own visual tool for modifying its own UI/data. For instance, you could build a page layout editor that lets users drag-and-drop components, and the editor itself would be part of the saved HTML file. An infinite variety of visual tools can (and will) be built on top of this structure.

As for essays about this vision, I'd recommend "Local-first software" [0] and "Malleable software" [1]

[0] https://www.inkandswitch.com/essay/local-first/

[1] https://www.inkandswitch.com/malleable-software/

No app installation needed, Hyperclay files are just HTML files, so they work like TiddlyWiki in that regard. You can download them and use them locally with any text editor, or even implement TiddlyWiki's saving mechanism if you prefer that workflow.

The key difference is when you want to share your creation on the web. With TiddlyWiki, you typically share a read-only version, requiring visitors to download and save their own copy. With Hyperclay, you can host that same HTML file on any server and live-edit it directly in your browser (if you're the owner). When people clone it, their clone is shareable and available on the web.

So you get the best of both worlds: the simplicity of a single HTML file that "just works" offline, plus the ability to publish it as a living document that you can edit directly in the browser.

Think of it as TiddlyWiki's philosophy extended to the shared web. Same single-file simplicity, but now your changes can be seen by others.

Yes, until we get it right.

I'm building a self-modifying HTML runtime inspired by TiddlyWiki [0]. It lets you build "HTML apps" in a single file with plain CSS/JS. These apps are shareable and hostable, but you can also download and use them locally as offline apps [1].

The cool thing is each HTML file is able to modify/overwrite itself, so users can use the app's own UI to modify it (e.g. a dashboard where users can add new fields by clicking a button to clone a DOM node, everything's persisted).

The key insight: collapsing the UI/state/logic layers into a single self-contained HTML file eliminates entire categories of complexity - no build steps, no deployment, no state synchronization. Everything you need is just right there.

[0] https://hyperclay.com/

[1] https://hyperclay.com/hyperclay-local

It's in his profile

You might find this optimal conversation path finder app of interest: https://x.com/eddybuild/status/1889908182501433669

An old YC blog platform Posthaven [0] does this.

If you pay $5/month for 1 year, your posts will be archived forever.

If we can't charge your card, your site goes into read only mode. Even if something catastrophic happens, your content will remain online.

[0] https://posthaven.com/pricing