26 ポイント 投稿者 GN⁺ 2025-08-19 | 7件のコメント | WhatsAppで共有
  • Hyperclay は、すべてのUI、ロジック、データが1つの HTMLファイル に統合される方式のウェブアプリ制作を支援する
  • ファイル自体を変更すると即座に その場で修正・リアルタイム共有 が可能で、アプリの見た目や挙動、編集方法まで直接制御できる
  • 別個のビルド・デプロイ工程、データベース、または複雑なバックエンドなしで 即時実行・保存 の構造を提供する
  • HTMLファイル1つだけで ブラウザ、サーバー、オフラインなどどこでも アプリを実行でき、すべての変更はバージョン管理および復元が可能
  • 現代のウェブ開発の複雑さ を減らし、リアルタイムに生きているインタラクティブなアプリを誰でも簡単に作れるよう設計されている

紹介: HTMLファイル1つで作る、生きたウェブアプリ Hyperclay

  • Hyperclayは、プログラマーが 複雑なインフラ管理なしに、1つの ポータブルなHTMLファイル で製品を形作るようにウェブアプリを作る体験を提供する
  • 従来のウェブ開発で必須だった 設定ファイル、ビルド、フレームワーク、デプロイパイプライン をなくし、ファイル1つで完結する構造を目指している

コアコンセプトと利点

  • アプリが 1つのHTMLファイルで構成 される
  • 視覚的UIを通じてファイル自体をリアルタイムに編集でき、その編集内容がそのまま アプリの状態として永続保存 される
  • UI、ロジック、データがすべて1つのファイル内に動的に含まれている
  • ユーザーは文書のようにアプリを 即座に修正し、変更をそのまま共有・ダウンロードしてオフライン利用 することもできる
  • 「interactive codeのためのGoogle Docs」という比喩のように、共有、修正、所有権の制御を自由に行える

主な機能の要約

  • 直接操作: アプリの実行中にそのまま編集できる。コンパイルやリロードなしで変更が即時反映される
  • What you see is what you build: UIを修正したりソースコードを直接編集したりすると、すぐにアプリが変わり、中間レイヤーがない
  • 真のポータビリティ: アプリをHTMLファイルとして書き出し、どこでも(サーバー・オフライン)同じように実行できる。保存のたびにバージョン管理が適用され、復元できる
  • これらすべてが 特別な技術なしに、標準のHTMLファイル1つだけで実現される

技術的な構造

  • Hyperclayは NodeJSサーバー とクライアント側の JSライブラリ で構成される
  • HTMLページが自らDOMを変更すると、変更後の document.body.outerHTML をサーバーへ送り、そのHTMLファイル自体が更新される
  • チェックボックスのchecked属性など、アプリ内での変更が永続的にHTMLコードへ保存され、次回アクセス時にも同じ状態を再現できる
  • バージョン管理読み取り/書き込み権限管理 をサポート

実際の例

  • 直接編集可能なブログ、勤務時間チェックリストなど、あらゆるアプリを1つのHTMLファイルで作成・保存できる
  • contenteditable 属性や、`` の形で、そのままアプリの状態を文書に記録する

背景と問題意識

  • 毎年数十のウェブサイトを制作する中で、ウェブアプリのコーディングが文章を書くことのように自然であってほしい というニーズがあった
  • 従来の静的ウェブサイトでは、変更が揮発的である(ユーザーの行為が保存されない)
  • データ永続性 をウェブ上で実現するには、データベース、API、テンプレート、アカウントシステムの構築など過剰な作業が必要になる
  • プロトタイプ、簡単なツール、個人開発ログ、ブログなど、素早く作ってリアルタイムに修正・共有したい需要 に対して非効率的だった

Hyperclayの解決方法

  • HTMLファイル1つにUI・状態・動作が統合される
  • まるでデスクトップアプリを開くように 簡単に開いてすぐ修正 し、結果をオンラインにそのまま反映できる
  • 永続的な(shared, cloneable, persistent)デジタルオブジェクトという概念を提示する
  • ウェブサイトビルダー、ドキュメント・図表・プレゼンテーションツール、ダッシュボード、ブログ、アンケート・クイズ作成、データ可視化など多様なツールに適用できる

全体コンセプトの要約

  • ほとんどのウェブアプリはすでにHTMLを使っている
  • 中間段階を省けば、HTMLファイルが 完全なデータベース / API / UI の役割を担い、スタックはわずか数行にまで単純化される
  • 開発者は複雑さを減らし、最小限のコード でも使いやすく保守しやすいアプリを作れる

Hyperclayの使用例

  • ブログ、チェックリストなど、どんなアプリでもたった1つのHTMLで作成・配布・共有・編集できる
  • `私のブログ!

` の形ですぐ使え、`` によって各状態が文書に永続記録される

結論

  • Hyperclayは、ウェブ開発の煩雑さなしに、誰でも軽量でポータビリティに優れたインタラクティブなウェブアプリを制作し、リアルタイムで共有・保存・復元できる新しい方法を提示する
  • 開発者やデザイナーだけでなく誰でも簡単に使える 次世代のウェブアプリプラットフォーム である

7件のコメント

 
bobross0 2025-09-03

興味深いですね

 
aobamisaki 2025-08-21

これは、以前あちこちにあったWebエディタと動作原理は似ていますが、HTMLファイル1つだけで成立するという点が興味深いですね。個人的には、これも一種のProof-of-Conceptのようにも思えますが、正直これをうまく活用したらどうなるのか気になるところでもあります。

 
ifmkl 2025-08-20

これの動作方式って、単に https://ja.news.hada.io/topic?id=19611 に以前上がっていたエディタの動作方式と同じでは? ここに私も、サーバーでのセルフホスティングのために Node.js で簡単なバックエンドを付けて、エディタで作成した post を保存できるようにし、index.html に一覧を読み込んで表示する機能の2つを付けて、簡単なブログ掲示板として使っていますが、見て回ると同じような感じですね。

 
reagea0 2025-08-19

面白いですね!
セキュリティがどうなのか気になります。

 
m00nlygreat 2025-08-19

面白いアイデアですね。tiddlyWikiも面白かったですが

 
developerjhp 2025-08-19

興味深いですね..

 
GN⁺ 2025-08-19
Hacker Newsの意見
  • Hyperclayでは、NodeJSサーバーとフロントエンドJSライブラリによって、HTMLページがDOMを更新し、変更された .html ソースを置き換えることで、ページを継続的に最新状態に保てる
    たとえばチェックボックスをクリックすると checked 属性が追加され、この状態の document.body.outerHTML をHyperclayでグローバルに保存しておけば、次回の訪問時にもそのまま反映される
    自動バージョン管理と読み書き権限の管理にも対応している
    開発者とコンテンツ編集者の役割が同一である場合に最も有用だと思うが、複数の編集者が同時に使うと変更を互いに上書きしてしまう可能性があるので
  • もしNodeJSサーバーが必須なら、完全にself-containedなHTMLファイルだけでは成り立たないように思えて混乱する
  • この内容をそのままホームページに追加した
    ちなみに、開発者がforkしたすべてのアプリに「DOMベースのスキーママイグレーション」をpushできる仕組みを実装中とのこと
  • TiddlyWikiに着想を得たと聞いたが、TiddlyWikiの本質はサーバー不要の構造ではなかったのか気になる
    実際、簡単なWebアプリを作っていると結局サーバーが必要になる場面は出てくるが、サーバーレスなアプローチとサーバー結合はやや矛盾しているようにも感じる
    それでも利点としてはクロスデバイスでのアクセス性向上があり、オンライン編集はしやすそうだ
    私の場合はテキストエディタでスマホから編集し、同期アプリでラップトップへ同期している
  • Web標準が file:// プロトコルで実行されるローカルファイルのページをもっと手厚くサポートしてほしい
    シンプルなHTML/Vueミニアプリを作るたびにいろいろ問題が起き、いつも回避策を探さなければならなかった
    たとえばローカルHTMLファイルではローカルJSモジュールをimportできなかったり、別のローカルファイル(オーディオなど)を開けなかったりする
    無制限なアクセスを防ぐために制限が必要なのは理解できるが、特定の拡張子やディレクトリを明示して許可するような方式があるとうれしい
    毎回Webサーバーを立ち上げるのは面倒すぎて大げさに感じるので、URLを入力するだけでそのままアプリが動くのが理想だ
    • ジェネレーター型Webアプリで大きな制約になるのは、HTTPSで読み込まれたページだけがClipboard APIを使えることで、file:/// ではコピー機能が動かない
      ビルドも依存関係もない完全オフラインアプリでも、この制限のせいでボタンの代わりにテキストエリアへ置き換えなければならず面倒だ
      ローカルサーバーの起動にはVS Code devcontainerを使えば自動でサーバーが立ち上がり、コマンドを追加すればローカルでもHTTPS化できる
    • 昔のWindowsにはHTAという方式があり、拡張子の異なるHTMLファイルとして、ブラウザメニューなしでファイルシステムへのアクセス権を持っていた
      セキュリティ的には脆弱だったが、今ならElectronベースでフォルダやsqlite db程度にアクセスできる現代版があっても使い道はありそうだ
      OrcaのようにブラウザやDOMなしでキャンバスだけを提供するwasmアプリビルダーも代案になる
    • ローカルHTMLファイルの危険性は理解しているが、ブラウザに「オフライン専用」モードができて、ローカルファイルシステムと外部ページを分離してアクセスできるようになるといい
      完全な解決にはならないとしても、シンプルで直感的な形でブラウザを制限付きローカルサーバーとして使えるので、十分有用だと思う
    • HTMLがローカルプラットフォームとして閉じられていくことにはある程度不満があった
      それでもオーディオやJavaScriptなどはある程度動くし、Webサーバーを立ち上げるのも python / node ですぐ実行できるので、それほど難しくはない
      ターミナルに webserver_here コマンドを追加するか常駐させておけば解決する
      むしろローカルHTMLの危険性が高まっているので、より厳格な境界を求めるようになった
    • 最近 ここここ でも似た悩みをしていた
      今のところ代替手段は localStorage と手動のエクスポート/インポートしかない
      Hyperclayから着想を得て、Electron Fiddle のように1回だけインストールして複数のミニアプリを読み込むElectronアプリの構想に関心がある
  • Hyperclayの技術的な実装方法が気になった
    単に localStorage の話なのか、それともFileSystemAPIでファイルを直接上書きするのかなど、詳しい動作原理の説明が不足していた
    ユーザーが保存するときに、「名前を付けて保存」ダイアログなしで自動反映されるのかも気になる
    • Hyperclayには2つの方式がある
      1. ホスティング: 複数のHTMLアプリが自分の /save エンドポイントを呼び出してHTMLを保存・上書きする(バックアップ・バージョン管理あり)
      2. ローカル: オープンソースのHyperclay Local(リンク)をダウンロードして個人的に運用する方式で、こちらも /save エンドポイントを呼び出してバックアップでき、サーバーを自分でカスタマイズしてホストすることも可能(authだけ実装すればよい)
    • うーん、これをさらに一歩進めると、サーバー用構文を追加したPHPやWordPressと本質的に似てこないだろうか?
      システムが多層化してどんどん複雑になり、実質的な改善というより負担が増える循環のようにも感じた
    • 「モダンWeb開発のノイズを無視して自分の望む体験を作る」というメッセージが、短いテキストとミーム画像の間に混ざっている演出は少し奇妙に感じた
      私が望む体験は、核となる説明と、流れのある背景説明、そして本当に必要な部分だけのダイアグラムだ
    • サーバーにDBがあり、HTMLを保存する構造だ
      つまりJSONで変更分だけを別保存するのではなく、HTML全体を各時点ごとに保存するイメージだ
    • 理解した限りではHTMLファイルそのものが更新される
      フォーム、属性、タグなどの変更履歴がHTMLソースへ直接反映される構造だ
  • WWWの本来のビジョンに再び近づいている感じがする
    初期のWebブラウザ(NeXT向けのTim Berners-Leeのアプリ)にもエディタ機能が含まれていた
    初期のHTML編集がWebから消えていった理由は、
    1. HTTP PUT メソッドがなく、編集したHTMLをWebへ保存できずローカルにしか保存できなかったこと
    2. Mosaicなどのブラウザが、複雑さなどの理由から編集機能を外した状態で配布され、大衆化の方向が変わったこと
    • 読み取り/注釈/書き込みが可能なWebこそ、ずっと以前から望んでいたWebの姿だ
      Hyperclayのように各ページごとに独自ツールキットを作るのも素晴らしいが、本当に望ましいのは、ブラウザ(ユーザーエージェント)レベルでどこでも使える標準ツールが提供されることだと思う
    • W3CはAmayaというWebエディタを10年以上維持していた
      良いアイデアだったし、テストベッドとしての役割も十分に果たしていたと思う
      なくなってしまって残念だが、初期ビジョンには明確に合致していた
    • TBL(ティム・バーナーズ=リー)の初期文脈では、ローカル保存=Web保存だった
      大学のワークステーションでNFSなどのネットワーク共有を使い、実質的にファイルが公開保存され、同じマシンのアドレスでアクセスできた
      SGIワークステーションではネットワーク設定さえすれば完全にそのまま動作した
      さらにWebの焦点は情報を構造化することにあり、見た目より内容のほうが重要だった
      時が経つにつれてWYSIWYGモデルやテーブル/divの乱用など、見た目への執着が強まり、初心が薄れていった
      誰にでも理解できるシンプルな設計をするのは本当に難しいが、今では少数の専門家集団しか理解できないかなり複雑な構造になってしまった
      HTMLは今でも簡単に使えるのに、現代の開発では複雑な専門技術になってしまったことが惜しい
      元々TBLが志向していた文脈を本当に理解している人は、ごく少数しか残っていないように思える
    • 「Webブラウザもエディタだ」という点について
      今のブラウザはどれも開発者ツールでHTML/JS/CSSをライブ編集できるので、みんなエディタではないかとも思う
      みんなdevtoolsを使わないのか、それともvanilla JS/HTMLではなくReactやTSだけを使っているのか気になる
      Chrome・Firefox・Safari系はどれもブラウザ内蔵IDEと言えるレベルの機能を提供しており、直接コーディングも可能だ
  • Hyperclayを見てみると、DOM(仮想DOM)を活用する構造のようだ
    Shopify風のポリシーや法的案内も少し追加されるとさらによいと思う
    私のHNプロフィールを見れば、なぜこれがクールだと思う一方で法的な部分も必要だと感じるのか分かるはずだ
  • ゲームのセーブファイルでも似た方法を試したことがある
    1行目は <!DOCTYPE html><html><head><script>const rawData = のような形で、2行目に全状態を入れる
    保存ボタンを押すと document.documentElement.outerHTML を取得し、最新状態で2行目を書き換えてダウンロードする
    サーバーなしでも動作する
    関連コード
    • Chromeで以下の data: URLブックマークを作っておくと、1つのタブにメモ帳風エディタを開いて、タブを閉じない限りstateが維持される
      data:text/html,<html><head><title>Notepad</title><style>html,body{margin:0;padding:0;}textarea{padding:10px;font-family:Courier;font-size:16px;height:100%;width:100%;border:none;outline:none;}</style></head><body><textarea style="height:100%;width:100%;font-size:16px;padding:10px;"></textarea><script>document.getElementsByTagName('textarea')[0].focus()</script></body></html>  
      
    • 私も同じように、単一のHTMLファイルで動くゲームを作った
      テキストを編集したあと、新しいローカル版として保存できる
      Android+Braveブラウザでは問題なく動くが、iOS+Safariではサポートされていない
  • TiddlyWikiもこの分野で20年以上の歴史を持つツールだ
    Hyperclayは、マルチユーザー/マルチテナンシーとDBベースの永続性により重点を置く構造に見える
    TiddlyWiki も参考になる
  • 誰かがWindows 98のHTAアーカイブを再発見したようなプロジェクトだ
    HTA wiki
    • HTAは元祖Electronっぽい感じだった
      ただし昔のIE環境ではデバッグが地獄だった
    • HTAは時代を先取りした、良くもあり(同時にひどくもある)技術だった
      見た目はただのWebページだが、IE専用でローカルプロセス実行権限まで持っていた
      永続性の管理が問題で、類似性もかなり限定的だ
    • その前にはOutlook Web Accessが似た役割を果たしていた気もする
      Outlook on the web
    • まったく同じことを考えていて、コメントしようとしていた
  • 面白いアイデアだと思うので、いつかぜひ試してみたい
    サイトも見てみたが全体的に気に入った一方で、現実的にどこで限界が見えてくるのか気になる
    セキュリティ面では、自分がページを変えられるなら他人も可能なのか? 権限はどう管理するのか?
    コード量やロジックが増えたとき、どの時点で管理が難しくなるのか? データ量が増えるとどうなるのか?
    たとえば私がビール管理アプリを作った場合、他のユーザーは私のデータ抜きでアプリだけを複製して別個に使えるのか気になる
    • セキュリティ: SquareSpaceなど、ほぼすべてのWebサイトビルダーと同じ信頼モデルだ
      ユーザーは自分のサイトを自由に変更できる
      もしユーザーが信頼を裏切れば、有料アカウントへのアクセス権や、他人に損害を与えた場合の責任が伴う
    • 編集権限: アプリを作った人なら誰でも編集できる
      signups 機能を有効にすると、他のユーザーもそのアプリを簡単にforkでき、元のアプリへ追跡できる
      forkしたアプリへのアップデートpush機能も実装中だ
    • 保守の難しさ: NomadListのPieter Levelsも単一の index.php だけで月額 $60k のアプリを運営しているのだから、結局はコードをどう整理するか、不要な部分をどう受け入れるか次第だと思う
    • 他の人がアプリをforkして、自分のデータだけを保存する形で運用できる
      将来的にはコラボレーション機能も入れる予定だが、現時点では1人ユーザーに最も向いている
  • このアイデアは新鮮に感じる
    Webstrates プロジェクトでも似たことを試している
    DOMを永続化レイヤーとして使い、小規模グループ向けの協働ソフトウェアを作っているが、Hyperclayはこの仕組みを従来型のWebページにそのまま適用している点が違う
    最近では MyWebstrates のようにローカルファースト方式も試みている
    Webworkerを使ってHyperclayでもオフライン編集をサポートできるのか気になる
    • Clemensです。Webstratesに深く感銘を受けた一人です
      去年Hyperclayを構想していたときに初めて知った
      Hyperclayのローカルファースト版はぜひやってみたいし、オフライン編集はパーソナルソフトウェアの柱だと考えている
      もしよければビデオ通話で意見交換できないだろうか