本文へスキップ
【Ver1.0到達🎉】ReactネイティブエンジンJsxCoreが正式版をリリース!同時にAstroにC#を持ち込むAstroSharpを発表のアイキャッチ画像
Architecture

【Ver1.0到達🎉】ReactネイティブエンジンJsxCoreが正式版をリリース!同時にAstroにC#を持ち込むAstroSharpを発表

公開: 更新: 約7分で読めます

先日、ASP.NET Core のビューを JSX/TSX で書き、React/Preact でレンダリングするビューエンジン JsxCore を 前回の記事で紹介しました。「リリース間近」としていたその JsxCore が、ついに 1.0.0 として正式リリースされました。さらに作者の David Whitney 氏は、同じ発想を Astro に C# を持ち込む「AstroSharp」へと広げる PoC も公開しています。本記事はその続報として、1.0 で何が確定したのか、そして次に何が起きているのかを整理します。

JsxCore 1.0.0 が正式リリース

David Whitney 氏は 2026 年 8 月 4 日、「JsxCore 1.0.0 is out.」と発表しました。要点は前回紹介した内容がそのまま「安定版」になったことです。.tsx を書いてコントローラーから返すと、サーバーレンダリング・ハイドレーション・その両方を、レスポンスごとに選べます。ビューモデルの型は C# から自動生成され、導入は dotnet add package JsxCore だけ。前回記事の執筆時にスター数は数十でしたが、本記事時点で約 200へと伸び、注目の高まりがうかがえます。

README でも JsxCore は 「Next.js・Remix・Astro のような Node ベースのフレームワークに匹敵し、競合しうる」存在として、Node ランタイムや npm を必要とせずに位置づけられています。ASP.NET Core の MVC・WebAPI・Minimal API に対して、JSX/React/Preact/TypeScript をネイティブに載せる——それが 1.0 で一区切りついた形です。

次の一手 — Astro に C# を持ち込む「AstroSharp」

さらに興味深いのが、David Whitney 氏が同じ発想を Astro(astro.build)へ広げていることです。C# を Astro のソースツリーで、まるで TypeScript のように使う PoC「AstroSharp」の作業中の動画を公開しました。下の動画では、.razor のコンポーネントを Astro のプロジェクト内に置き、C# でレンダリングされたカードやブログ一覧が表示され、ターミナルには [astrosharp] using .NET SDK 10.0.102 や astro v5.18.2 ready が並んでいます。

Astro に C# を持ち込む「AstroSharp」の作業中デモ。.razor コンポーネントを Astro で C# レンダリングしている(出典: @david_whitney / X)。

仕組みのポイントは、インストール経路は素の npm パッケージでありながら、その裏で Roslyn を積んだサイドカーの .NET プロセスが動くことです。これにより、ホットリロードや静的な開発体験を .NET 側でそのまま提供します。作者は PoC の構成をこう整理しています。

整理すると、Astro プラグインが管理するサイドカー .NET プロセスが開発時の Roslyn ホットリロードを担い、コンテンツは .razor ファイルに C# の @{ ... } フロントマターで書けます。SSR はサイドカー経由、または実験的な WASM(オプトイン)で行えるとのこと。ビルド時に .NET ランタイムを要する点は前提ですが、利用者から見た入口は npm のまま、という設計が特徴です。全体像を図にすると次のとおりです。

AstroSharp の仕組みの図。①Astro プロジェクト(.razor でコンテンツを記述・C# の @{ } フロントマター、npm でインストール、C# を TS のように src で使う)→②サイドカー .NET(Roslyn)(Astro プラグインが管理、Roslyn でホットリロード、.NET SDK 10 を利用)→③出力(SSR)(サイドカー経由で SSR、実験的 WASM オプトイン、Astro の中で C# が動く)。ビルド時に .NET ランタイムは必要だが利用者の入口は npm のまま。
AstroSharp の仕組み。入口は npm パッケージ、その裏で Roslyn を積んだサイドカー .NET が動く(本記事執筆時点では作業中の PoC)。

ここまでのまとめと、率直な感想

短い期間で一気に動きました。ASP.NET Core に React/TSX を載せる JsxCore が「近日公開」から 1.0 の正式版へ到達し、スターも数十から約 200 へと伸びています。そして作者はその勢いのまま、Astro に C# を持ち込む AstroSharp の PoC まで見せてきました。1 つのプロジェクトを安定版に届けると同時に、次のフロンティアへ手を伸ばしている——この推進力そのものが強く印象に残ります。

率直な感想として、これは 「.NET を、他と同じように"普通に"モダンな Web 開発ができる場所にしたい」という作者の一貫した意志の表れだと感じます。Node ランタイムを前提とせず、既存の C# の資産・型・ツールをフロントへ地続きで持ち込める設計は、.NET を主戦場にするチームにとって現実的で、率直に魅力的です。一方で温度感は分けて捉えたいところで、JsxCore は 1.0 として実プロジェクトで試す価値が十分、AstroSharp はまだ PoC として動向を追う——というのが正直な線引きです。次に何が"C# 化"されるのか、続報が楽しみな領域だと感じています。

開発者の声(X より)

JsxCore 1.0.0 のリリースと AstroSharp の PoC 公開に、.NET コミュニティからは実務的な反応が寄せられています。長年 ASP.NET Core を使うコンサルタントの Spencer Schneidenbach 氏は、「フロントは React があるので必ずしも要らない。ただ、.NET プロジェクトの中に置ける JSX はかなり美味しそうだ」と、既存の React 資産を持つ立場からの率直な魅力を語ります。

また Davor Pihač 氏は、Blazor SSR と HTMX を比較検討していたが、これこそ求めていたものかもしれないと反応。既存の .NET のサーバーサイド描画の選択肢と並べて評価されている点が印象的です。

何が起きているのか — .NET 開発者の視点

一連の動きに共通するのは、「JS フレームワークの書き味を、.NET のまま手に入れる」という一貫したテーマです。JsxCore は ASP.NET Core に React/TSX を、AstroSharp は Astro に C#/Razor を持ち込みます。いずれも Node ランタイムを前提にせず、サイドカーやインプロセスで .NET を動かす点が共通しており、既存の C# 資産・型・ツールをフロントに地続きで使えるのが魅力です。Blazor SSR や HTMX と並ぶ、サーバーサイド描画のもう一つの現実解として評価が始まっています。

一方で温度感は見極めが必要です。JsxCore は 1.0 に到達して安定版の目安がついた一方、AstroSharp は作業中の PoCであり、SSR の WASM 経路は実験的です。まずは JsxCore を実プロジェクトの一部で試し、AstroSharp は動向を追う、という温度差のある付き合い方が現実的でしょう。

よくある質問

JsxCore 1.0 は本番で使えますか?

1.0.0 として正式リリースされ、ASP.NET Core の MVC・WebAPI・Minimal API に対応します。導入は dotnet add package JsxCore のみで、Node.js は不要です。とはいえ登場から日が浅いので、まずは小さな画面から採用し、更新に追随できる範囲で広げるのが安全です。基本的な仕組みは 前回の JsxCore 入門記事で解説しています。

AstroSharp はもう使えますか?

現時点では作業中の PoCです。C# を Astro のソースに置き、.razor でコンテンツを書き、サイドカーの .NET プロセスが Roslyn ホットリロードを担う——という構成が動いている段階で、SSR の WASM 経路は実験的(オプトイン)とされています。本番採用よりも、方向性を知る材料として追うのが適切です。

Blazor とは競合しますか?

競合というより選択肢の追加です。Blazor は C# 完結、JsxCore は React/TSX の書き味を .NET に持ち込む方式です。開発者の声でも Blazor SSR や HTMX と並べて比較されており、チームのスキルセットと求める表現で選び分けるのが実態に近いでしょう。

参照元

この記事をシェア

コピーしました

関連記事