17 ポイント 投稿者 GN⁺ 2025-05-16 | 7件のコメント | WhatsAppで共有
  • HTML、CSS、JavaScriptのWeb標準を中心としたUI言語で、既存フレームワークよりも簡潔で拡張しやすいインターフェース構成を目指す
  • Reactと異なりロジックとスタイルを分離し、CSS-in-JSの代わりに外部デザインシステムファイルを活用する方式で保守性を確保
  • 複雑なコンポーネント実装でもコードが単純でJSバンドルサイズが小さい。例: ソート/フィルタ機能付きテーブルが3.9KB
  • デザインテーマの切り替えもわずか32行のCSS変更だけで可能で、コンポーネント修正なしにデザインシステムを差し替え可能
  • Bunベースで動作し、高速なバンドリング、標準互換性、AIモデル向けUI生成の基盤などを備えた未来志向のフレームワーク

Introducing Hyper

  • HyperはHTML/CSS/JSのWeb標準をベースにUIを構成する新しいマークアップ言語
  • 複雑なUIもクリーンでシンプルな文法で表現可能
  • Reactと異なり表現・ロジック・スタイルを分離して構成する

Project goals

  1. Standards first: HTML、CSS、JS標準ベースの構成
  2. Simplicity: 複雑な抽象化なしのシンプルなコンポジション構造
  3. Design Systems: デザイナーと開発者の双方のための分離されたデザイン層
  4. Scalability: アプリケーションが大きくなっても単純さを維持

React vs Hyper 比較

  • Reactはロジック、構造、スタイルが混在したモノリシック構造であるのに対し、Hyperは純粋なビュー層に集中する
  • Simple components
    • 同じテーブルコンポーネントをModern ReactOld-school ReactHyperでそれぞれ実装した事例を提示
      • 現代的なReact: ShadCN、Material UI、Tailwind Catalyst などのコンポーネントライブラリでUIを構成し、AIツール支援が強み
      • 昔ながらのReact: スタイルとコンポーネントコードが分離されていた初期の方式
      • Hyper: Web標準に準拠した簡潔な例で、構造とスタイルを明確に分離
    • Hyperは不要なクラスや状態フックなしに、純粋なHTMLベースの構造とシンプルなメソッドだけで表現する
    • 単純な例では差は小さいが、複雑性が増すほどHyperとReactのアプローチ差は大きくなる
  • Complex components
    • ShadCNベースのReact: JSバンドル 91.3KB
    • Hyper: 3.9KB (1.2KB + 2.7KB)
    • Hyperは最小限のJSで動作し、保守しやすい
  • Design systems
    • Hyperでダッシュボードのスタイルを変更する際は、コンポーネントコードを変更せずCSSを32行追加するだけで全体テーマを差し替え可能
    • 一方、ReactベースのShadCNでは数千行のTSXコードがテーマごとに重複する
    • Hyperのデザインシステム哲学
      • CSS-in-JS、Tailwind、inline style などデザインとコンポーネントの結合を完全に排除
      • すべてのタイポグラフィとスタイル規則を外部CSSファイルに集約
      • 完全な再利用性中央集約型デザインシステムゼロボイラープレートを実現
  • Scalability
    • Hyper方式はプロジェクトが大きくなっても単純さを維持できる
    • 構造が単純で、コードサイズも小さい

よくある質問

  • Svelte、Vueとの違いは?
    • どちらもReactより軽量だが、依然として scoped CSS や Tailwind などデザインとコンポーネントの結合を促す
    • Hyperは完全に分離されたデザインシステムを強制する
  • What is Nue?
    • NueはNue JSテンプレートベースのWebサイト/Webアプリ生成器
    • HyperはNue JSの次世代進化版で、同じモノレポの下で管理されている
    • Hyperlink(予定)はルーターソリューションであり、Web標準との緊密な接続を意味する
  • 既存フレームワークとの違いは?
    • Hyperは新しい抽象化ツールの追加ではなく、標準への回帰と単純さの回復を中核目標とする
    • CSS、HTML、JSの知識だけでプロ向けアプリを構築可能
  • Web標準の重要性は?
    • タイムレスな技術: 数十年にわたり有効な技術基盤
    • 持続可能な製品: フレームワーク変更なしで長期間保守可能

今後の計画

  • Full-stack アプリケーション(3か月以内)
    • ルーティング、コンポーネント間通信、DB連携、クラウドデプロイ、デザインテーマ切り替え機能を搭載予定
  • Generative UIs(4〜5か月以内)
    • HTML/CSSの組み合わせをベースにしたAIが生成可能なUIフレームワーク
    • アクセシビリティ、レスポンシブ対応、ドキュメント化を自動で含む
  • どうやってReactに勝つのか?
    • 徐々にシェアを獲得することを目指す
    • 段階的に開発者の認識変化を促す
    • シンプルで保守しやすい構造を提供
    • 基礎技術の力を証明しながら成長する計画
  • 名前の重複問題は?
    • 既に同名を使うRust、Electronプロジェクトが存在するが、文脈が異なるため問題ない

究極的な目標

  • 破壊的にシンプルなWebスタックの構築が最終目標

7件のコメント

 
youngkwon 2025-05-17

典型的に歴史を無視して、昔の車輪を持ってきたようなものです。
いくつかのアイデアは悪くないように思いますが(Markdownの使い方)、他のツールと比べて大きな利点はないように思います。

Hacker Newsでの議論を見ると、
ひとまず開発者のReactに対する理解度があまりにも低いです。

 
aer0700 2025-05-17

近いうちに名前が変わりそうな気がしますね……本文にも書かれていますが、名前が重なる Electron のプロジェクトがありますし……あえてその名前を使う必要があったのかなと。

 
fastkoder 2025-05-16

コードを比較してみると、トークンをかなり節約できそうですね。

 
ng0301 2025-05-16

Svelte 最高

 
hyeonseok 2025-06-14

Svelte最高

 
sixmen 2025-05-16

人それぞれ好みは違うと思いますが、私は Angular や Vue など(このライブラリ? マークアップ? を含む)の <li for> よりも、vanilla JS で処理する JSX の .map((item) => <li>) のほうが好きなんですよね

 
schang124 2025-05-16

私も同感する部分です。HTML に追加されるロジックが vanilla ではなく独自の syntax である場合、それが大きなハードルになります。簡単な UI 実装は問題ありませんが、ロジックが複雑な場合は開発の柔軟性で差が出ますし、学習曲線も無視できません。