Show HN: Nectar、WebAssemblyにコンパイルされるRustライクなReact

ひどいギグの経験の後、私は自分が漠然と有能な開発者であることを思い出したいと思いました。 最近Rustの列車に飛び乗ったばかりで、ReactのRust版で、よりパフォーマンスが高く、扱いやすいものを探していました。 JavaScriptを効果的に削除できるかどうかも疑問に思いました。 このプロジェクトはそこから生まれました... Nectarは、あなたのアプリ全体、ロジック、状態、レンダリングをWebAssemblyにコンパイルするプログラミング言語です。 JavaScriptは、WASMとDOMをブリッジする約10KBのシステムコールレイヤーに削減されます。 <p>起源： Reactスタイルのエルゴノミクスをより良いパフォーマンスで実現しようとしましたが、途中でブラウザのDOM（Blink/C++）と差分検出ステップを経由して可能なことの天井に達したことに気づきました。 そこで、それに逆らうのをやめ、WASMにコンパイルされ、変更されたDOMノードのみをO(1)で更新する独自のシグナル駆動レンダリングレイヤーを構築しました。仮想DOMもガベージコレクタもありません。 <p>現在の状態： - 1つのバイナリ。 同じコンパイラがフォーマット、リンティング、テスト、開発サーバー、LSP、SSR（SSRは未開発ですが）を行います。 - きめ細やかなシグナル。 各バインディングは独自に更新されるため、差分検出パスはありません。 - コンパイル時の安全性を提供するRustにインスパイアされた借用チェッカー。 - Webで頻繁に使用されるパターン（コンポーネント、ストア、ルーター、フォーム、認証、支払い）のための言語レベルのキーワード。 - SEOとスクリーンリーダー。 同じソースから2つのDOMにコンパイルされるため、アプリはスクリーンリーダーやクローラーに対して表示されたままになります。 <p>正直な状況、これは初期段階であり、ほとんどが1人の人物によるものです： - 「JavaScriptなし」というラインにはアスタリスクが付いています。 WASMはDOMに直接触れることができないため、小さなJSブリッジ（約10KB）がありますが、現時点では主要ブラウザでは克服できません。 - サイトの数値（カウンターは約10KB対ReactとJSの約387KB）は実際の小さな例ですが、フルアプリの比較ではありません。 それらが示す以上のものとして読むべきではありません。 それらは、大規模なスループットを測定するために意図的に貧弱にアーキテクトされています。（こじつけです） - ライセンスはBSL 1.1なので、実際のものを構築する前に読んでください。 <p>ライブデモ、キャンバスレンダリングエンジンを使用した10,000製品、およびSvelte 5とのサイドバイサイド比較： <a href="https://buildnectar.com/app/canvas" rel="nofollow">https://buildnectar.com/app/canvas</a> <p>サイト： <a href="https://buildnectar.com" rel="nofollow">https://buildnectar.com</a> コード： <a href="https://github.com/HibiscusConsulting/nectar-lang" rel="nofollow">https://github.com/HibiscusConsulting/nectar-lang</a> <p>私は本当にそれが徹底的に批判されることを望んでいます。 コアとなる賭けが間違っているなら、私の夢を打ち砕いてください。しかし、どうすれば改善できるか教えてください。 私はまだこれが良いアイデアであると完全に確信していません。 これがこれほど構築が難しいとは思っていませんでした。 もし最初から知っていたら、決して構築しなかったでしょうが、現実はこうです。