Blazor vs React: なぜこの .NET アーキテクターがついにページを選んだのか

Blazor vs. React はすべての .NET 開発者が質問する質問です. Blazor では、JavaScript ではなく C# でインタラクティブな Web UI を構築できます. あなたがすでに .NET 開発者である場合、これは 1 つの言語、 1 つのエコシステム、そしてどの状態管理ライブラリをこの四半期に使用するかについて、より少ない実存的危機を意味します。 Blazor vs. React はすべての .NET 開発者が質問する質問です. Blazor では、JavaScript ではなく C# でインタラクティブな Web UI を構築できます. あなたがすでに .NET 開発者である場合、これは 1 つの言語、 1 つのエコシステム、そしてどの状態管理ライブラリをこの四半期に使用するかについて、より少ない実存的危機を意味します。 コンテンツテーブル とにかくブレイクって何? The Case Against React(反対反応) コード比較: React vs Blazor なぜBlazorが私に役立つのか Blazor's Evolution: .NET 8, 9, and 10 反応がまだ意味があるとき Blazor から始まる FAQ: Common Concerns Answered 最終思考 私は2009年からJavaScriptを書いていますが、jQuery 1.3はマスのように感じました。私はフレームワークが帝国のように上昇し、落ちるのを見ました。Backbone、Angular、React、そして今私はSignalsについて気にするべきですか?私はマス削除しました。 温かい夕食を食べたときよりも、 node_modules そして、私の周りで3 800MBを超えたフォルダで、私は自分自身に尋ね始めた: node_modules what if there was another way? それはBlazorと呼ばれ、私は考えない言語を使用してウェブアプリケーションを構築することができます。 受け入れられる行動です。 "2" + 2 = "22" とにかくブレイクって何? Blazor は、JavaScript の代わりに C# を使用してインタラクティブな Web UI を構築するためのマイクロソフトのフレームワークです。この名前は「Browser」と「Razor」(.NET テンプレートシンタクス)のポートマンテオであり、2020 年以来生産準備が整っています。 Instead of writing JavaScript that runs in the browser, you write C# that either: サーバー上で実行(Blazor Server):あなたのC#はサーバー上で実行し、リアルタイムでSignalR WebSocket接続を介してブラウザにUI更新を流します。 ブラウザ内で実行(Blazor WebAssembly): .NET ランタイム自体は WebAssembly 経由でブラウザ内で実行されます。 両方(Blazor United/.NET 8+):コンポーネントごとにレンダリングモードを選択し、初期ロード速度のためのサーバー側、オフライン機能のためのWebAssemblyを選択します。 // A Blazor component. Yes, that's C# in your UI. @page "/counter"

Counter Current count: @currentCount

Click me

@code { private int currentCount = 0;

private void IncrementCount() { currentCount++; } } No webpack. No babel. No seventeen configuration files. Just C# that compiles and runs. ウェブパックはありません。 The Case Against React (or: Why I Needed a Change) React は、コンポーネントベースの UI について考える方法に革命を起こしました。 Virtual DOM は本当にスマートでした。 しかし、 React の生産アプリケーションを何年も構築してから、人生の選択に疑問を投げかけたパターンに気付くようになりました。 The Framework Churn is Real Reactの生態系は、 それは私の言葉ではありませんが、それを読んだときに心の中で感じました。 「A EVER-SHIFTING LABE OF FADDISH CHURN」 毎年、新しい「正しいやり方」をもたらします: Year What We Were Told to Use 2016 Redux. Obviously. 2018 MobX because Redux boilerplate was killing us 2020 Context API (who needs libraries?) 2021 Zustand, after Context caused re-render hell on a dashboard I built 2022 Pick one: Jotai, Recoil, Valtio, or whatever your coworker found on Hacker News 2023 Whatever survived the layoffs 2024 Server Components. State lives on the server now, apparently? 2016 減って当然です。 2018 MobX なぜなら Redux ボイラープレートが私たちを殺していたからです。 2020 コンテキスト API (Who Needs Libraries?) 2021 Zustand, after Context caused re-render hell on a dashboard I built 2022 Pick one: Jotai, Recoil, Valtio, or whatever your coworker found on Hacker News 2023 何があっても解雇に生き残った。 2024 サーバーコンポーネント:State lives on the server now, apparently? DEV コミュニティの 1 人の開発者 「 React から Vue へ Svelte へ Solid へ(そして再び)ジャンプしてから、私は同じものを少し違った方法で構築する方法を常に学び直していることに気づきました。 完璧にまとめました♪ Decision Fatigue is Exhausting 2024年に新しいReactプロジェクトを開始したことは、私はツールを選択するだけで2日間を費やしたことを意味しました。Bundler? Webpackは現在「遺産」ですが、Viteはデフォルトですが、私はTurbopackが必要ですか? 州の管理ですか?私は3時間の比較投稿を読んだ後、Zustandと一緒に行きました。スタイリング? Tailwindですが、チームの半分はスタイリングコンポーネントを欲していました。 それは、ビジネス論理の1行を書く前にあった。 THE 「エコシステムの選択肢の柔軟性と多様性は強みと弱みの両方であり、意思決定の疲労、プロジェクトコードベースの変動、一般に使用されるツールの変化につながる」と述べています。 「React 2025」 セキュリティ・シアターの種類 Yes, TypeScript exists. Yes, it helps. But TypeScript is a bandage on a dynamically-typed wound. You're bolting a type system on a language that fundamentally doesn't have one. シームは表示します。 // TypeScript: Types are suggestions, really const user: User = JSON.parse(response); // No runtime validation! // user could be anything. TypeScript just trusts you.

// Meanwhile, in C#: var user = JsonSerializer.Deserialize (response); // Actual deserialization with type checking ラン 去年のクライアントプロジェクトで 847 インスタンス. その時点で、あなたは追加のステップで JavaScript を書いているだけです。 grep -r ': any' src/ | wc -l NPMセキュリティの悪夢 JavaScript コミュニティが話すのが嫌いなことについて話しましょう:あなたの フォルダーはセキュリティの責任です。 node_modules September 2025: The Shai-Hulud Attack 18+ 以上のパッケージ 攻撃は、単一のメンテナントへのフィッシングメールから始まったが、数日後には、Zapier、PostHog、Postmanからのパッケージがトロイア化された。 One of the largest npm supply chain attacks in history 2.6 billion weekly downloads キッカー? 25,000以上のGitHubリポジトリに影響を与え、このバージョンには、マルウェアが認証情報をエクスフィルタすることができなかった場合、このバージョンには「失われた地球」のパラバックが含まれていた。 . Shai-Hulud 2.0 destroy the victim's entire home directory これは古代の歴史ではない、これは . 今年は The Greatest Hits of npm Disasters Incident Year Impact left-pad 2016 One developer unpublished an 11-line package. Babel, React, and thousands of projects broke instantly. event-stream 2018 Malicious code injected by a "helpful" new maintainer. Went undetected for 2.5 months. Targeted Bitcoin wallets. ua-parser-js 2021 8 million weekly downloads. Compromised to install cryptominers and password stealers. everything 2024 A "joke" package that depended on every npm package. DOS'd anyone who installed it. Shai-Hulud 2025 2.6B+ weekly downloads affected. AI-assisted attacks. Data destruction payloads. left-pad 2016 ある開発者が11行パッケージを公開しなかったので、Babel、React、そして何千ものプロジェクトが即座に破綻した。 イベントストリーム 2018 悪意のあるコードは「役に立つ」新しいメンテナンダーによって注入されました。 2.5 ヶ月間検出されませんでした。ターゲット Bitcoin 財布。 パッケージJs 2021 毎週800万ダウンロード. 暗号通貨とパスワード盗賊のインストールを脅かす。 すべて 2024 すべてのnpmパッケージに依存する「ジョーク」パッケージ。 ハラハラ 2025 2.6B+ 毎週ダウンロードが影響を受けた. AI による攻撃. データ破壊のパイロード。 Why This Keeps Happening The npm ecosystem has structural problems: : A typical React app has hundreds of transitive dependencies. Each one is an attack surface. Massive dependency trees ボランティアメンテナンス:フィッシング、焼却、または社会エンジニアリングを受けることができる未払い個人によって維持される重要なインフラストラクチャ。 ビルドタイム検証はありません: npm は package.json が言っているすべてをインストールします。 trivial packages: The JavaScript ecosystem has normalized depending on packages for trivial functionality. is-odd? is-even? is-number? These exist, and they have millions of downloads. JavaScriptのエコシステムは、パッケージに依存して trivial機能性を正常化しました。 # A real npm audit from a "simple" React project found 47 vulnerabilities (12 moderate, 28 high, 7 critical) Meanwhile, in .NET Land NuGetは完璧ではありませんが、劇的に良くなっています。 署名パッケージ:発行者はパッケージを暗号化して署名できます。 : Fewer packages overall, but higher average quality Curated ecosystem : Core libraries maintained by a trillion-dollar company, not a solo developer Microsoft backing コンパイルタイムのセキュリティ:C#コンパイラはランタイム前に多くの問題を捕まえる 小さな依存グラフ: .NET の包括的な標準ライブラリにより、外部依存が減少します。 When I run 私のBlazorプロジェクトでは、私は通常ゼロの結果を見ます。 プロジェクトの後、私は午後をクリアします。 dotnet list package --vulnerable npm audit 『Let the Code Speak For Itself: React vs. Blazor』 Theory is nice. Code is better. Here's what the same functionality looks like in both frameworks. 理論は良いです。コードはより良いです. 両方のフレームワークで同じ機能がどのように見えますか。 A Simple Counter(フレームワークの「Hello World」) React (with hooks): import { useState } from 'react';

export default function Counter() { const [count, setCount] = useState(0);

return ( Counter Current count: {count}

setCount(count + 1)}> Click me ); } Blazor: @page "/counter"

Counter Current count: @count

count++">Click me

@code { private int count = 0; } Similar line count, but note: no imports, no hook, no setter function. 変数と増加のみ。 useState Two-Way Data Binding This is where the ceremony difference gets real. React: import { useState } from 'react';

export default function SearchBox() { const [query, setQuery] = useState(''); const [results, setResults] = useState([]);

const handleChange = (e) => { setQuery(e.target.value); };

return ( You typed: {query}

); } Blazor: You typed: @query

@code { private string query = ""; } 両方向に対応します いいえ handler, no , no setter function. The binding just works. @bind onChange e.target.value Form Handling with Validation ここは、物事がスパイスになる場所です. Validation with User Registration Form. React (with React Hook Form + Zod - the "modern" approach): import { useForm } from 'react-hook-form'; import { zodResolver } from '@hookform/resolvers/zod'; import { z } from 'zod';

const schema = z.object({ email: z.string().email('Invalid email'), password: z.string().min(8, 'Password must be at least 8 characters'), confirmPassword: z.string() }).refine(data => data.password === data.confirmPassword, { message: "Passwords don't match", path: ['confirmPassword'] });

export default function RegisterForm() { const { register, handleSubmit, formState: { errors, isSubmitting } } = useForm({ resolver: zodResolver(schema) });

const onSubmit = async (data) => { await fetch('/api/register', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(data) }); };

return ( {errors.email && {errors.email.message} } {errors.password && {errors.password.message} } {errors.confirmPassword && {errors.confirmPassword.message} } Register ); } NPMの3つのパッケージ( で、 で、 ), spread operators on inputs, and resolver configuration. It works, but there's a lot happening. react-hook-form @hookform/resolvers zod Blazor (with built-in DataAnnotations): @page "/register" @inject HttpClient Http

model.Email" /> model.Password" /> model.ConfirmPassword" />

Register

@code { private RegisterModel model = new(); private bool isSubmitting = false;

private async Task HandleSubmit() { isSubmitting = true; await Http.PostAsJsonAsync("/api/register", model); isSubmitting = false; }

public class RegisterModel { [Required, EmailAddress] public string Email { get; set; } = "";

[Required, MinLength(8, ErrorMessage = "Password must be at least 8 characters")] public string Password { get; set; } = "";

[Required, Compare(nameof(Password), ErrorMessage = "Passwords don't match")] public string ConfirmPassword { get; set; } = ""; } } 追加パッケージゼロ. 検証属性は .NET に組み込まれています。 Submit flow を処理します。 wires up validation automatically. The model class is reusable on your API too. EditForm DataAnnotationsValidator Data Fetching React (with useEffect - the footgun everyone steps on): import { useState, useEffect } from 'react';

export default function UserList() { const [users, setUsers] = useState([]); const [loading, setLoading] = useState(true); const [error, setError] = useState(null);

useEffect(() => { let isMounted = true; // Cleanup flag to prevent state updates after unmount

fetchUsers();

return () => { isMounted = false; }; // Cleanup }, []);

if (loading) return Loading... ; if (error) return Error: {error} ;

return ( {users.map(user => ( {user.name} ))} ); } クリーニングパターンと共に . I spent two hours last year hunting down a memory leak because a junior dev forgot this pattern. The error message? "Can't perform a React state update on an unmounted component." Helpful. isMounted Blazor: @page "/users" @inject HttpClient Http

@if (users == null) { Loading... } else if (error != null) { Error: @error } else { @foreach (var user in users) { @user.Name } }

@code { private List ? users; private string? error;

protected override async Task OnInitializedAsync() { try { users = await Http.GetFromJsonAsync >("/api/users"); } catch (Exception ex) { error = ex.Message; } } } Blazor はコンポーネントのライフサイクルを適切に処理します. No dependence array to forget. runs once when the component loads. OnInitializedAsync Component Communication (Parent to Child, Child to Parent) React: // Parent function Parent() { const [selectedItem, setSelectedItem] = useState(null);

return ( {selectedItem && } ); }

// Child function ItemList({ onItemSelected, highlightedId }) { const items = [...];

return ( {items.map(item => ( onItemSelected(item)} > {item.name} ))} ); } Blazor: @* Parent *@

@if (selectedItem != null) { }

@code { private Item? selectedItem; } @* ItemList.razor *@ @foreach (var item in items) { SelectedItem = item"> @item.Name }

@code { private List items = [...];

[Parameter] public Item? SelectedItem { get; set; }

[Parameter] public EventCallback SelectedItemChanged { get; set; } } The syntax automatically wires up two-way binding between parent and child. Convention over configuration. @bind-SelectedItem 式典比較 Task React Blazor Two-way binding + (every. single. field.) value onChange @bind Form validation Pick a library, write a schema, pray Built-in DataAnnotationsValidator Data fetching + cleanup + deps array (good luck) useEffect OnInitializedAsync State management This week's favorite: Redux? Zustand? Jotai? Class fields. Call when needed StateHasChanged() DI Roll your own with Context or install a library (it just works) @inject Parent-child binding Props down, callbacks up @bind-PropertyName Two-way binding + より (every. single. field.) value onChange @bind Form validation 図書館を選び、スケジュールを書き、祈りなさい。 Built-in DataAnnotationsValidator データキャッチ + cleanup + deps array(おめでとう) useEffect OnInitializedAsync State management This week's favorite: Redux? Zustand? Jotai? Class fields. Call 必要時 StateHasChanged() DI Context で独自のロールまたはライブラリをインストールする (it just works) @inject 親子義務化 トップ > Props Down, Callbacks Up @bind-PropertyName See the pattern? Blazor does the same thing with less code and fewer choices to agonize over. なぜBlazorは実際に私のために働くのか One Language to Rule Them All This is the killer feature. With Blazor, I write C# on the frontend and C# on the backend. Same language. Same type system. Same patterns. // Shared model used by both frontend and backend public record CreateOrderRequest( string CustomerId, List Items, ShippingAddress Address );

// API endpoint [HttpPost] public async Task > CreateOrder(CreateOrderRequest request) { // Validate, process, return }

// Blazor component calling the API var order = await Http.PostAsJsonAsync ("api/orders", request); 「APIを更新しましたが、TypeScript タイプを更新するのを忘れました」 コンパイラはすべてをキャプチャします。 セキュリティの種類 実際に意味するもの C# is statically typed. Not "we added types later and hope you use them" typed. The compiler is your friend, and it will tell you about problems your users find them. before // This won't compile. Period. int count = "five"; // Error CS0029

// Pattern matching catches nulls at compile time if (user is { Email: var email }) { SendWelcomeEmail(email); // email is guaranteed non-null here } As , "combining these tools with the type safety of the language allows developers to write code with a lot more confidence up-front, not having to worry about runtime errors like unexpected nulls." Emergent Software notes SOLID Principles Are First-Class Citizens .NET was designed with dependency injection and interface-based programming in mind. Implementing SOLID principles isn't fighting the framework-it's using it as intended. // Program.cs - Clean DI registration builder.Services.AddScoped (); builder.Services.AddScoped (); builder.Services.AddScoped ();

// Component receives dependencies automatically @inject OrderService Orders @inject NavigationManager Navigation

@code { private async Task SubmitOrder() { var result = await Orders.CreateAsync(currentOrder); if (result.IsSuccess) { Navigation.NavigateTo($"/orders/{result.Value.Id}"); } } } Try achieving this level of clean dependency injection in React without a third-party library and a configuration ceremony. 「Debugging That Doesn't Make You Cry」 Visual StudioのBlazorのデバッグは本当に素晴らしいです Breakpoints work. Step-through works. Watch expressions work. The call stack actually makes sense. Visual Studioのデバッグは本当に素晴らしいです Breakpoints work. Step-through works. Watch expressions work. The call stack actually makes sense. 私はBlazorコンポーネントで分断点を設定し、ビジネスロジックを踏み出し、データベースに至るまで実行を追跡することができます。 private async Task LoadOrders() { // Set a breakpoint here var orders = await OrderService.GetRecentAsync(customerId);

// Inspect 'orders' in the debugger // See the actual types, not 'object Object'

this.orders = orders; } Compare this to debugging React where you're juggling browser DevTools, React DevTools, and Redux DevTools all at once. Last year I spent 45 minutes on a bug that turned out to be a missing dependency in a 症状は静かな無限のリレンダーだったBlazorのデバッガーは、それを数秒で捕らえただろう。 useEffect The .NET Ecosystem is Stable (Boringly So) .NET エコシステムはゆっくりと動きます. 意図的に. これはバグではなく機能だと思います。 NuGet パッケージには長期的なサポートがある傾向があります。Newtonsoft.Json がバージョン 13 に留まることを決めたとき、誰もパニックに陥りませんでした。 それはまだ機能しています。これを「最後」がライフスタイルである npm エコシステムに比較してください。 When I upgraded from .NET 7.0.14 to .NET 8.0.0 last November, I got a documented list of breaking changes. Took me an afternoon to migrate a medium-sized app. When React moved from class components to hooks, the community spent months rewriting tutorials and arguing on Twitter. Real-World Advantages コードシェアはTrivial Got validation logic? 共有図書館に一度書き込む。 // Shared.Validation/OrderValidator.cs public class OrderValidator : AbstractValidator { public OrderValidator() { RuleFor(x => x.Items).NotEmpty(); RuleFor(x => x.Total).GreaterThan(0); RuleFor(x => x.ShippingAddress).NotNull(); } }

// Use in Blazor component // Use in API controller // Use in background service // Same validation, everywhere コンポーネントモデルは、よく知られている。 MVC または Razor Pages から Razor シンタクスを知っている場合、Blazor コンポーネントは自然な感じになります。 .NET 開発者の学習曲線は、数ヶ月ではなく数日で測定されます。 // Component with parameters - looks like any other C# class @code { [Parameter] public Order Order { get; set; } = default!;

[Parameter] public EventCallback OnOrderUpdated { get; set; }

[CascadingParameter] public UserContext? User { get; set; } } Performance Has Improved Dramatically Early Blazor WebAssembly had legitimate performance concerns. Those days are largely behind us-each .NET release has brought major improvements. .NET 8 introduced: Jiterpreter: ブラウザ内の部分的な JIT コンパイルで、最適化された WebAssembly で slow interpreter bytecodes を置き換える SIMD デフォルト: WebAssembly Single Instruction, Multiple Data for vectorized calculations AOT コンパイル: C# を WebAssembly に直接コンパイルし、CPU 集中のタスクでほぼネイティブなパフォーマンスを実現 .NET 9 added: : Removes IL after AOT compilation, significantly reducing bundle size WasmStripILAfterAOT 改善された怠慢な充電:より速い初期充電のためのより良い組み立て延期 : Enabled by default for Interactive Server components WebSocket compression .NET 10 delivers: Framework asset preloading: Static assets preloaded via Link headers before the page render : Browser downloads and caches critical assets earlier High-priority resource scheduling パフォーマンスプロファイリングカウンター:WebAssemblyアプリの新しい診断ツール Automatic memory pool eviction: Better memory management in long-running apps (自動メモリプールの排除:長期間実行中のアプリでメモリの管理を改善) So: Static SSR outperforms React on initial load because you're serving pre-rendered HTML with zero JavaScript hydration overhead. AOT compilation gets WebAssembly apps to near-native speed. You pick the right mode for each page. Blazor's Rapid Evolution: .NET 8, 9, and 10 Blazorについて私に印象を与えたのは、マイクロソフトがどのように積極的にそれを改善しているかです. これは副プロジェクトではありません - これは .NET エコシステムの一流の市民です。 .NET 8: 「Blazor United」革命 .NET 8 fundamentally changed how Blazor works with the introduction of . Before .NET 8, you had to choose: Blazor Server Blazor WebAssembly. Now you can mix and match per-component. Unified Rendering Modes(ユニバーサル・レンダリング・モード) または changed everything. Your components render as plain HTML on the server. No SignalR connection, no WebAssembly download. Just fast, SEO-friendly HTML. Static Server-Side Rendering (SSR) // A static SSR page - renders as pure HTML @page "/about" @attribute [StreamRendering]

About Us

About Our Company This renders as static HTML. Search engines love it.

新しい Blazor Web App テンプレートは SSR にデフォルトで、オプトインの強化としてのインタラクティビティーです。これは哲学の根本的な転換です - あなたは最も速く、最もSEO フレンドリーなオプションから始め、必要なときにだけインタラクティビティを追加します。 .NET 9: Mixing Modes with Precision 柔軟性が2倍に増え、新しい attribute は、特定のページをマークすることを可能にします。 use static SSR-useful for pages that depend on HTTP cookies or the request/response cycle. .NET 9 [ExcludeFromInteractiveRouting] must @page "/privacy-settings" @attribute [ExcludeFromInteractiveRouting]

// This page always renders statically, even in an otherwise interactive app Other .NET 9 improvements: enabled by default for Interactive Server components WebSocket compression at runtime via the new RendererInfo API Render mode detection Blazor Server アプリケーションの再接続処理を改善 .NET 10: Performance and Polish BLAZORの大幅な改善に伴い、 .NET 10 : The Blazor script is now served as a static web asset with automatic compression and fingerprinting, significantly reducing payload size and improving caching. Blazor script optimization : The new 属性は、プレーレンダリングとインタラクティブレンダリング間のデータ共有を簡素化します。 Persistent component state [PersistentState] @code { [PersistentState] public List ? Movies { get; set; }

protected override async Task OnInitializedAsync() { // State is automatically restored from prerendering Movies ??= await MovieService.GetMoviesAsync(); } } : : now works seamlessly across all render modes. New project templates include a default page. Better 404 handling NavigationManager.NotFound() NotFound.razor : Server circuits now expose traces as top-level activities, making observability in Application Insights much cleaner. Improved diagnostics 軌道は明確である:Blazorは、リリースごとにより速くなり、より柔軟になり、より多くの生産準備ができています。 When React Still Makes Sense I'm not here to tell you React is bad. It's not. Pick React if your team already thinks in JavaScript and nobody wants to learn C#. Pick it if you need some niche npm component that doesn't exist in the Blazor ecosystem (there are still gaps). Pick it for a quick startup MVP where you'll probably throw away the code in six months anyway. Reactの生態系は巨大です. もしあなたが不明瞭なグラフライブラリや、奇妙なことをするドラグ・アンド・ドロップ・グリッドを必要とするなら、誰かが作ったかもしれません. それは本当に貴重です。 But if you're a .NET shop building internal tools, line-of-business apps, or anything that needs to run for more than three years? Blazor is worth a serious look. Getting Started with Blazor もしあなたが好奇心を持っているなら、Blazorアプリケーションを実行するための最も迅速な方法は以下の通りです。 # Create a new Blazor Web App (.NET 8+) dotnet new blazor -o MyBlazorApp cd MyBlazorApp dotnet run That's it. No that spins for three minutes downloading half the internet. No folder larger than your actual code. No または to fight with. npm install node_modules .babelrc webpack.config.js The マイクロソフトのドキュメントは、MSDNの時代以来、長い道のりを歩んでいます。 Blazor 公式ドキュメンタリー FAQ: Common Concerns About Blazor 私はBlazor vs Reactの議論のすべての異議を聞きました. いくつかは有効です. ほとんどはそうではありません。 Blazor WebAssembly バンドルサイズが大きすぎますか? 2020年? はい、それは粗大でした. 最初のロードは2〜3MBに達する可能性があります。 では? .NET 8+ は数学を変更しました: AOT コンパイルはランタイムを大幅に縮小 IL trimming strips unused code (未使用のコード) Lazy loading defers non-critical assemblies .NET 10 自動圧縮と指紋の追加 しかし、正直に言えば、より賢い答えは、すべての人にWebAssemblyを配信しないでください。ターンページのためのスタティックSSR(ゼロWASM)を使用してください。認証されたセクションのためのインタラクティブサーバーを使用してください。WebAssemblyをオフラインシナリオや重いクライアント側の計算のために保存してください。今すぐページごとに選択してください。 Are JavaScript developers easier to hire than Blazor developers? Depends what you're actually hiring for. A senior C# developer picks up Blazor in a week. The component model clicks immediately, the syntax is just Razor, and they already know the language. Compare that to hiring a "React developer" who learned it three years ago and now needs to catch up on Server Components, the ハック、そしてあなたのチームが選んだメタフレームワークに関係なく。 use .NET 才能プールは広く、安定しており、完全なバックエンド能力を備えています. Your backend developer can review frontend PRs without context-switching languages. React には Blazor より多くの第三者コンポーネントがありますか? いやいやいや、完全停止。 それぞれのリラックスした React コンポーネント ライブラリには、セキュリティの漏れ、互換性のないピアア依存性、および「TODO: add documentation」と書かれる READMEs が数十個あります。 Blazorの生態系は小さいが、あなたが発見したパッケージが依然として維持されていることを願って、npmを掘り下げていない。 is the one I reach for first. Material Design, free, and the maintainers actually respond to issues. そして どちらも無料のコミュニティライセンスを提供します. Enterprise shops usually go for the support contracts. MudBlazor Radzen Syncfusion Telerik And when you absolutely need a JavaScript library? きれいにインタラクティブにしましょう: IJSRuntime @inject IJSRuntime JS

@code { private async Task InitializeChart() { await JS.InvokeVoidAsync("Chart.bindings.init", chartElement, chartData); } } You are not locked out of the JavaScript ecosystem. You just don't それに。 depend BlazorはSEOに良いですか? Static SSR は純粋な HTML を表示します。Google はそれを見て、インデックスし、実行します。Next.js SSR と同じですが、C# でこの異議は、Blazor が WebAssembly のみだった 2020 年に意味がありました。 Blazorはモバイルアプリで使用できますか? Blazor Hybrid exists. Write your components once, run them in MAUI (iOS/Android/Windows/macOS), WPF, or even Windows Forms. 同じ C# コンポーネント、ネイティブ アプリ シェル 全く「一度書き込み、どこでも実行する」のではなく、ほとんどの用例に十分に近い。 Is Blazor tooling as good as VS Code with React? もっと良かったと思うけど、主観的だ。 Visual Studio with Blazor: actual debugging with breakpoints and step-through, IntelliSense that understands your whole codebase, refactoring that works across components and services, Hot Reload that mostly works, integrated testing and profiling. VS Code with React: syntax highlighting, IntelliSense that works if TypeScript is configured right, hoping your 正しい、互いに矛盾する可能性のあるまたは存在しないブラウザの拡張子。 launch.json Blazor コンポーネントでブレイクポイントを設定し、データベースに一つの IDE で、一つの言語で進みますか? それは楽しいだけです。 BlazorはMicrosoftのベンダーロックインを作成しますか? .NET はオープンソース(MIT ライセンス)。Blazor はオープンソースで、Linux、Docker、AWS、Azure、どこでも実行できます。 Azure に対するエコシステムの重力はありますか? もちろんですが、私は問題なく Blazor アプリを AWS、DigitalOcean、および裸のメタルサーバーに展開しました。 Compare this to React, which is technically open source but practically controlled by Meta's priorities. When Facebook decided class components were out, the entire ecosystem pivoted. When they pushed Server Components, everyone scrambled. マイクロソフトがロードマップを発表。 Does Blazor Hot Reload work properly? .NET 5. By .NET 8 it was usable. .NET 8 で使えるようになりました。 EDIT A file, save, see changes. Method bodies, Razor markup, CSS, all instant. .NET 10がようやく良くなりました。 .razor Is it as fast as Vite? No. Is it fast enough that I don't think about it? Yes. 最終思考 Switching to Blazor hasn't solved all my problems. I still write bugs. I still make architecture mistakes. I still occasionally spend too long debugging something that turns out to be a typo. しかし、私は今月、どの州の管理ライブラリが「正しい」かについて精神的なエネルギーを費やすのをやめました。TypeScriptのタイプがもはやランタイムデータに匹敵するかどうかは不思議ではありません(スポイラー:彼らはしばしばそうではありません)。 One language. One ecosystem. Patterns I’ve refined over a decade of .NET work. That’s the trade-off, and for me it’s worth it. 1つの言語. 1つのエコシステム. .NETの仕事の10年以上にわたって精進してきたパターン。 マイレージは異なる場合がありますが、あなたが .NET 開発者である場合、あなたのマイレージを調べたことがあります。 現実的な恐怖とBlazorはあなたの時間の午後の価値があるかもしれません。 package.json 次は何? If you want to try it: それが全体のセットアップです。 dotnet new blazor -o MyFirstBlazorApp && cd MyFirstBlazorApp && dotnet run Microsoft's 堅固で、そして 私が見つけたテクノロジーのサブレッドの1つです。 BLAZOR チュートリアル r/Blazor Questions? Drop a comment or find me on social. I like talking about this stuff. Sources: ソース: 反応状態と2025年のコミュニティ If Not React, Then What? なぜ最新のJavaScriptフレームワークは時間の無駄なのか Is Blazor Better Than JavaScript? Blazor vs React: A Comprehensive Comparison Debug ASP.NET Core Blazor Apps - Microsoft Learn Blazor in .NET 8: Server-side and Streaming Rendering Blazor で Static Server-Side Rendering の利点 What's New in .NET 10 - Microsoft Learn What's New in ASP.NET Core in .NET 10 - Microsoft Learn npm サプライチェーン攻撃 - Palo Alto Networks Shai-Hulud 2.0 サプライチェーン攻撃 - WIZ npm left-pad Incident - Wikipedia マリシウス・パッケージ Malicious Package - Snyk The "Everything" Package Chaos - Socket About the Author 私は、分散型システム、 .NET クリーンコード、ログ、パフォーマンス、および生産デバッグに情熱を持っているシステムアーキテクターです。 私が認めたい以上に何度も書いています。 node_modules Linkedin: つながる GitHub : マシュルハック Twitter/X: @mashrulthunder