Blazor vs React : 이 .NET 아키텍트가 마침내 페이지를 선택한 이유

Blazor vs React는 모든 .NET 개발자가 궁극적으로 묻는 질문입니다.Blazor는 JavaScript 대신 C#로 대화형 웹 UI를 구축 할 수 있습니다.당신이 이미 .NET 개발자라면, 이것은 하나의 언어, 하나의 생태계, 그리고 어느 주 관리 라이브러리를 사용해야하는지에 대한 훨씬 적은 실존적 위기를 의미합니다. Blazor vs React는 모든 .NET 개발자가 궁극적으로 묻는 질문입니다.Blazor는 JavaScript 대신 C#로 대화형 웹 UI를 구축 할 수 있습니다.당신이 이미 .NET 개발자라면, 이것은 하나의 언어, 하나의 생태계, 그리고 어느 주 관리 라이브러리를 사용해야하는지에 대한 훨씬 적은 실존적 위기를 의미합니다. 컨텐츠 테이블 어쨌든 블라우스란 무엇인가요? The Case Against React에 대한 리뷰 보기 코드 비교: React vs Blazor Blazor가 나를 위해 일하는 이유 Blazor's Evolution : .NET 8, 9 및 10 When React Still Makes Sense Blazor로 시작하기 FAQ: Common Concerns Answered 최종 생각 나는 jQuery 1.3가 대량처럼 느껴졌을 때 2009 년부터 JavaScript를 쓰고있다.나는 프레임 워크가 제국처럼 상승하고 떨어지는 것을 보았습니다.Backbone, Angular, React, 그리고 이제 나는 신호에 대해 걱정해야합니까? 뜨거운 저녁 식사보다 더 뜨거운 저녁 식사 node_modules And somewhere around my third 800MB를 초과한 폴더, 나는 스스로에게 묻기 시작했다 : node_modules what if there was another way? 그것은 Blazor라고 불리고, 그것은 내가 생각하지 않는 언어를 사용하여 웹 응용 프로그램을 구축 할 수있게합니다. 받아들일 수 있는 행동이다. "2" + 2 = "22" 어쨌든 블라우스란 무엇인가요? Blazor는 JavaScript 대신 C#를 사용하여 대화형 웹 UI를 구축하는 마이크로소프트의 프레임 워크입니다.The name is a portmanteau of "Browser" and "Razor" (the .NET templating syntax), and it has been production-ready since 2020. 브라우저에서 실행되는 JavaScript를 작성하는 대신, 다음과 같은 C#를 작성합니다.Instead of writing JavaScript that runs in the browser, you write C# that either: 서버에서 실행 (Blazor Server): 서버에서 C#를 실행하고 실시간으로 SignalR WebSocket 연결을 통해 브라우저에 UI 업데이트를 흐릅니다. 브라우저에서 실행 (Blazor WebAssembly): .NET 실행 시간 자체는 WebAssembly를 통해 브라우저에서 실행됩니다. Both (Blazor United/.NET 8+): 각 구성 요소에 따라 렌더링 모드를 선택합니다.Server-side for initial load speed, WebAssembly for offline capability.Best of both worlds. // 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++; } } 웹 팩이 없습니다. 바벨이 없습니다. 17 개의 구성 파일이 없습니다. 컴파일하고 실행하는 C# 만 있습니다. The Case Against React (또는 내가 변화가 필요한 이유) React revolutionized how we think about component-based UIs. The Virtual DOM was genuinely clever. I'm not here to trash it. 그러나 React 생산 애플리케이션을 수년간 구축 한 후, 나는 내 삶의 선택에 의문을 제기 한 패턴을 발견하기 시작했습니다. 프레임 워크가 실제로 React 생태계는 다음과 같이 설명되었습니다.The React ecosystem has been described as 그것은 나의 문장이 아니지만, 나는 그것을 읽을 때 내 영혼에 느꼈다. "an ever-shifting maze of faddish churn"에 해당되는 글 1건 매년 새로운 "옳은 방법"을 가져옵니다 : 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 boilerplate가 우리를 죽이기 때문에 2020 컨텍스트 API(누가 도서관을 필요로 하는가?) 2021 Zustand, after Context caused re-render hell on a dashboard I built에 대한 리뷰 보기 2022 하나를 선택하십시오 : Jotai, Recoil, Valtio 또는 당신의 동료가 해커 뉴스에서 발견 한 것 2023 무엇이든 해고를 살아남았다. 2024 서버 구성 요소: 상태가 서버에서 지금 살아있는 것처럼 보입니다. DEV 커뮤니티의 하나의 개발자 "React에서 Vue로 Svelte로 Solid로 점프 한 지 수년이 지난 후 (그리고 다시) 나는 동일한 것을 약간 다른 방식으로 구축하는 방법을 끊임없이 다시 배우고 있다는 것을 깨달았습니다." 그것을 완벽하게 요약하십시오 결정의 피곤함은 피곤하다 2024 년에 새로운 React 프로젝트를 시작한 것은 단지 도구를 선택하는 데 2 일을 보냈다는 것을 의미했습니다. Bundler? Webpack는 이제 "유산"이지만 Vite는 기본입니다.하지만 Turbopack가 필요합니까? 상태 관리? 나는 비교 게시물을 읽은 3 시간 후 Zustand와 함께 갔습니다. 스타일링? Tailwind, 그러나 내 팀의 절반은 스타일링 된 구성 요소를 원했습니다. 양식? 반응 양식, 아마도 Formik이 더 나은 것을 필요로하지 않는 한. 그것은 내가 비즈니스 논리의 단일 줄을 썼기 전에이었다. The 그는 "생태계 옵션의 유연성과 다양성은 강점과 약점이기도 하다... 이것은 의사 결정 피로, 프로젝트 코드베이스의 변화, 일반적으로 사용되는 도구의 지속적인 변화로 이어집니다."라고 지적한다. React 2025의 상태 The Type Safety Theater 예, TypeScript가 존재합니다.예, 그것은 도움이됩니다.하지만 TypeScript는 역동적으로 인쇄 된 상처에 밴더입니다.당신은 기본적으로 하나가없는 언어로 인쇄 시스템을 삽입하고 있습니다. // 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 보안 악몽 자바스크립트 커뮤니티가 토론하는 것을 좋아하지 않는 것에 대해 이야기합시다. 폴더는 보안 책임입니다. node_modules September 2025: The Shai-Hulud Attack 위협된 18+ 패키지 with over 공격은 단일 유지 관리자에게 피싱 이메일로 시작되었으며, 며칠 안에 Zapier, PostHog, Postman의 패키지가 트로이에 의해 트로이 해킹되었습니다. One of the largest npm supply chain attacks in history 2.6 billion weekly downloads 그 키커? 다음은 2025년 11월, 25,000개가 넘는 GitHub 리포테리어에 영향을 미쳤다.이 버전에는 "지구가 망가진"패그백이 포함되었는데, 만약 악성 코드가 인증서를 제거할 수 없었다면 . 샤오미 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. 왼쪽 패드 2016 하나의 개발자는 11 라인 패키지를 공개하지 않았습니다.Babel, React, 그리고 수천 개의 프로젝트는 즉시 깨졌습니다. event-stream 2018 악의적 인 코드가 "쓸모있는"새로운 유지 관리자에 의해 주입되었습니다. 2.5 개월 동안 감지되지 않았습니다. 2021 8 million weekly downloads. Compromised to install cryptominers and password stealers. 모든 2024 모든 npm 패키지에 의존하는 "웃음"패키지. Shai-Hulud 2025 2.6B+ 주간 다운로드 영향. AI 지원 공격. 데이터 파괴 유용 부하. Why This Keeps Happening The npm ecosystem has structural problems: 대규모 중독 나무: 전형적인 React 앱에는 수백 가지의 과도한 중독이 있습니다. 자원봉사자 유지 보수자 : 소셜 엔지니어링, 화재 또는 소셜 엔지니어링을받을 수있는 무급 개인에 의해 유지되는 중요한 인프라. : npm installs whatever says. There's no compile-time check that the code is safe. No build-time verification package.json 사소한 패키지: JavaScript 생태계는 사소한 기능을 위해 패키지에 따라 정상화되었습니다. is-odd? is-even? is-number? These exist, and they have millions of downloads. # A real npm audit from a "simple" React project found 47 vulnerabilities (12 moderate, 28 high, 7 critical) Meanwhile, in .NET Land NuGet isn't perfect, but it's dramatically better: 서명된 패키지: 출판사는 암호화된 패키지를 서명할 수 있습니다. Curated Ecosystem: 덜 패키지 전체, 그러나 더 높은 평균 품질 : Core libraries maintained by a trillion-dollar company, not a solo developer Microsoft backing 컴파일 시간 보안: C# 컴파일러는 런타임 전에 많은 문제를 잡습니다. 소규모 의존도 차트: .NET의 포괄적 인 표준 라이브러리가 외부 의존도를 줄이는 것을 의미합니다. When I run 나의 Blazor 프로젝트에서, 나는 일반적으로 0 결과를 볼 수 있습니다. React 프로젝트에 대해, 나는 나의 오후를 청소합니다. dotnet list package --vulnerable npm audit Code Speak For Itself: React vs. Blazor에 대한 리뷰 보기 이론은 좋다. 코드는 더 좋다.이것은 두 프레임 워크에서 동일한 기능이 어떻게 보이는지입니다. 단순한 카운터 (The "Hello World" of Frameworks) 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; } 비슷한 라인 수 있지만 참고: 수입이 없음, 아니요 hook, no setter function. 단지 변수와 인센티브. useState 쌍방향 데이터 묶음 이곳에서 의식의 차이는 현실이 된다. 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 = ""; } handles both directions. No handler, no , no setter function. The binding just works. @bind onChange e.target.value Form Handling with Validation 여기서 물건이 맛있어집니다.Validation와 함께 사용자 등록 양식. 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 ); } That's three npm packages ( , , ), 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에 내장됩니다.The validation attributes are built into .NET. handles the submit flow. wires up validation automatically. The model class is reusable on your API too. EditForm DataAnnotationsValidator 데이터 픽업 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; } } } No cleanup needed. Blazor handles component lifecycle properly. No dependency array to forget. runs once when the component loads. OnInitializedAsync 구성 요소 커뮤니케이션 (부모에게 자녀, 부모에게 자녀) 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; } } 이 Syntax는 부모와 자녀 사이의 양방향 결합을 자동으로 연결합니다.Convention over configuration. @bind-SelectedItem The Ceremony Comparison 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 + 더 (모든 분야에서 단일) value onChange @bind Validation 형식 Pick a library, write a schema, pray 건설 DataAnnotationsValidator Data fetching + cleanup + deps array (좋은 행운) useEffect OnInitializedAsync State management This week's favorite: Redux? Zustand? Jotai? 클래스 필드 - Call when needed StateHasChanged() 다 Roll your own with Context or install a library (it just works) @inject Parent-child binding Props Down, Callbacks Up에 대한 리뷰 보기 @bind-PropertyName Blazor는 덜 코드와 덜 선택으로 똑같은 일을합니다. Why Blazor Actually Works for Me 하나의 언어가 그들 모두를 지배한다. 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은 의존성 주입 및 인터페이스 기반 프로그래밍을 염두에 두고 설계되었습니다.Implementing SOLID principles is not 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's debugger with Blazor is genuinely excellent. Breakpoints work. Step-through works. Watch expressions work. The call stack actually makes sense. I can set a breakpoint in my Blazor component, step through my business logic, and trace execution all the way to the database and back. Same debugger, same tools, same experience as any other C# application. 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 array. The symptom was silent infinite re-renders. Blazor's debugger would have caught that in seconds. useEffect The .NET Ecosystem is Stable (Boringly So) The .NET ecosystem moves slowly. Deliberately. I consider this a feature, not a bug. NuGet packages tend to have long-term support. When Newtonsoft.Json decided to stay on version 13, nobody panicked. It still works. Compare that to the npm ecosystem where "latest" is a lifestyle. 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 유효성 검증 논리를 가지고 있습니까? 공유 도서관에 한 번 쓸 수 있습니다. // 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: : Partial JIT compilation in the browser, replacing slow interpreter bytecodes with optimized WebAssembly Jiterpreter SIMD 기본: WebAssembly 단일 명령, 벡터화 계산을 위한 다중 데이터 AOT 컴파일: C#를 WebAssembly에 직접 컴파일하여 CPU 집중적인 작업에서 거의 네이티브 성능을 제공합니다.Compile C# directly to WebAssembly for near-native performance on CPU-intensive tasks .NET 9 added: WasmStripILAfterAOT: AOT 컴파일 후 IL를 제거하여 팩 크기를 크게 줄입니다. : Better assembly deferral for faster initial loads Improved lazy loading : Enabled by default for Interactive Server components WebSocket compression .NET 10 delivers: : Static assets preloaded via Link headers before the page renders Framework asset preloading : Browser downloads and caches critical assets earlier High-priority resource scheduling 성능 프로파일링 카운터: WebAssembly 앱을 위한 새로운 진단 도구 : Better memory management in long-running apps Automatic memory pool eviction 따라서: Static SSR는 초기 로드에 반응하기 때문에 제로 자바스크립트 히드레이션을 초과하는 HTML를 제공합니다. AOT 컴파일은 WebAssembly 앱을 거의 원래 속도로 만듭니다.당신은 각 페이지에 적합한 모드를 선택합니다. Blazor's Rapid Evolution: .NET 8, 9, and 10 One thing that impressed me about Blazor is how aggressively Microsoft has been improving it. This isn't a side project-it's a first-class citizen in the .NET ecosystem. .NET 8 : 블라조드 혁명 .NET 8은 Blazor의 작동 방식을 근본적으로 변화시켰습니다. .NET 8 이전에는 Blazor Server를 선택해야 했습니다. Blazor WebAssembly. Now you can mix and match per-component. Unified Rendering Modes에 대한 리뷰 보기 또는 모든 것이 변경되었습니다. 귀하의 구성 요소는 서버에서 단순한 HTML로 표시됩니다. SignalR 연결 없음, WebAssembly 다운로드 없음. 그냥 빠르고 SEO 친화적 인 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로 설정되며, 인터랙티브 기능은 Opt-in 향상으로 제공됩니다.이것은 철학의 근본적인 변화입니다.당신은 가장 빠르고 SEO 친화적 인 옵션으로 시작하고 필요한 경우에만 인터랙티브 기능을 추가합니다. .NET 9: Precision로 모드를 혼합 융통성에 대해 두 배로 줄어들었습니다.The new attribute lets you mark specific pages that use static SSR-useful for pages that depend on HTTP cookies or the request/response cycle. 네트워크 9 [ExcludeFromInteractiveRouting] 모스 @page "/privacy-settings" @attribute [ExcludeFromInteractiveRouting]

// This page always renders statically, even in an otherwise interactive app 다른 .NET 9 개선 사항: enabled by default for Interactive Server components WebSocket compression RenderInfo API를 통해 런타임에서 렌더 모드 탐지 for Blazor Server apps Improved reconnection handling .NET 10: Performance and Polish shipped with significant Blazor improvements: .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 특성은 사전 rendering 및 인터랙티브 render 사이의 데이터 공유를 단순화합니다.simplifies sharing data between pre-rendering and interactive renderers: 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 페이지 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는 모든 출시와 함께 더 빠르고, 더 유연하며, 더 많은 생산 준비가되고 있습니다. 반응이 여전히 의미가 있을 때 React가 나쁘다고 말하려고 여기 있지 않습니다. React를 선택하면 팀이 이미 JavaScript로 생각하고 아무도 C#를 배우고 싶지 않습니다. Blazor 생태계에 존재하지 않는 틈새 npm 구성 요소가 필요한 경우 선택하십시오 (아직도 틈새가 있습니다). 어쨌든 6 개월 안에 코드를 버릴 가능성이있는 빠른 시작 MVP를 위해 선택하십시오. React's ecosystem is massive. If you need an obscure charting library or a drag-and-drop grid that does exactly one weird thing, someone's probably built it. That's genuinely valuable. 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. Blazor로 시작하기 If you're curious, here's the quickest path to a running Blazor app: # 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 or 싸우기 위해서 npm install node_modules .babelrc webpack.config.js The is comprehensive and actually well-written. Microsoft's docs have come a long way since the MSDN days. Blazor 공식 문서 FAQ: Common Concerns About Blazor 나는 Blazor vs React 토론에서 모든 반발을 들었습니다. 일부는 유효합니다. Blazor WebAssembly 팩 크기가 너무 크나요? 2020 년에? 예, 그것은 거친이었다. 첫 번째 로드 2-3MB에 도달 할 수있다. 이제? .NET 8+는 수학을 변경했습니다 : AOT 컴파일은 런타임을 크게 단축합니다.AOT compilation reduces the runtime significantly 사용되지 않은 코드 링크 Lazy Loading Defers Non-Critical Assemblies에 대한 리뷰 보기 .NET 10 자동 압축 및 지문 추가 But honestly, the smarter answer is: don't ship WebAssembly to everyone. Use Static SSR for landing pages (zero WASM). Use Interactive Server for authenticated sections. Save WebAssembly for offline scenarios or heavy client-side computation. You pick per-page now. JavaScript 개발자를 Blazor 개발자보다 더 쉽게 고용할 수 있습니까? 당신이 실제로 고용하는 것에 따라 달라집니다. 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 hook, 그리고 팀이 선택한 메타 프레임워크. use The .NET talent pool is large, stable, and full-stack capable. Your backend developer can review frontend PRs without context-switching languages. Does React have more third-party components than Blazor? 완전한 멈추기 각 폴리된 React 구성 요소 라이브러리에는 보안 구멍, 호환되지 않는 동료 의존성 및 "모든 것: 문서를 추가"라고 말하는 READMEs가 포함 된 수십 개의 버려진 패키지가 있습니다. Blazor의 생태계는 작지만 당신이 발견 한 패키지는 여전히 유지되기를 희망하는 npm를 탐구하지 않습니다. 재료 디자인은 무료이며 유지 관리자는 실제로 문제에 응답합니다. and 둘 다 더 필요한 경우 무료 커뮤니티 라이선스를 제공합니다.Enterprise shops usually go 지원 계약에 대해서는 MudBlazor Radzen Syncfusion Telerik 그리고 언제 JavaScript 도서관이 절대적으로 필요합니까? 깨끗하게 삽입해 주세요: IJSRuntime @inject IJSRuntime JS

@code { private async Task InitializeChart() { await JS.InvokeVoidAsync("Chart.bindings.init", chartElement, chartData); } } 당신은 JavaScript 생태계에서 잠겨 있지 않습니다. 그것을 위하여 의존 Is Blazor good for SEO? Static SSR renders pure HTML. Google sees it, indexes it, done. Same as Next.js SSR but in C#. This objection made sense in 2020 when Blazor was WebAssembly-only. It hasn't been true for years. Blazor는 모바일 앱에 사용할 수 있습니까? 블라조르 하이브리드가 존재합니다.부품을 한 번 쓰고 MAUI (iOS/Android/Windows/macOS), WPF 또는 Windows Forms에서 실행하십시오. 동일한 C# 구성 요소, native app shell. Not quite "writ once, run anywhere" but close enough for most use cases. Blazor 도구는 React와 VS Code만큼이나 좋습니까? I'd argue it's better, but that's subjective. Visual Studio with Blazor: breakpoints와 step-through로 실제 디버깅, 전체 코드베이스를 이해하는 IntelliSense, 구성 요소 및 서비스에 걸쳐 작동하는 refactoring, 대부분 작동하는 Hot Reload, 통합 테스트 및 프로파일링. VS Code with React: syntax highlighting, IntelliSense that works if TypeScript is configured right, hoping your is correct, browser extensions that may or may not conflict with each other. launch.json 디버깅만으로도 나를 팔았습니다.Blazor 구성 요소에 분해점을 설정하고 데이터베이스로, 하나의 IDE, 하나의 언어로 이동? Blazor는 Microsoft 판매자 잠금을 만듭니까? .NET is open source (MIT license). Blazor is open source. You can run it on Linux, in Docker, on AWS, on Azure, wherever. Is there ecosystem gravity toward Azure? Sure. But I've deployed Blazor apps to AWS, DigitalOcean, and bare metal servers without issue. 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. 최소한 Microsoft는 도로지도를 발표합니다. Blazor Hot Reload가 제대로 작동합니까? 그것은 .NET 5. by .NET 8 그것은 사용할 수 있었다. 에디터 A file, save, see changes. Method bodies, Razor markup, CSS, all instant. .NET 10 finally made it good .razor Is it as fast as Vite? No. Is it fast enough that I don't think about it? Yes. Final Thoughts Blazor로 전환하면 모든 문제를 해결하지 못했습니다.나는 여전히 버그를 쓴다.나는 여전히 아키텍처 오류를 저지른다.나는 여전히 때때로 타이포로 밝혀지는 무언가를 디버깅하는 데 너무 오랜 시간을 보냅니다. But I've stopped spending mental energy on which state management library is "correct" this month. I don't wonder whether my TypeScript types match runtime data anymore (spoiler: they often didn't). I'm not updating seventeen npm packages every time Dependabot yells at me. 하나의 언어, 하나의 생태계. .NET 작업의 10 년 동안 내가 정교하게 한 패턴.그것은 거래이며, 나에게 그것은 가치가 있습니다. Your mileage may vary. But if you're a .NET developer who's ever looked at your with existential dread-Blazor might be worth an afternoon of your time. package.json 다음은 무엇인가요? If you want to try it: . That's the whole setup. dotnet new blazor -o MyFirstBlazorApp && cd MyFirstBlazorApp && dotnet run Microsoft의 튼튼하고, 그리고 내가 찾은 가장 친절한 기술 subreddits 중 하나입니다. Blazor tutorials r/Blazor 질문을 던지거나 소셜 네트워크에서 나를 찾으십시오.나는이 것에 대해 이야기하는 것을 좋아합니다. Sources: 출처 : The State of React and the Community in 2025 If Not React, Then What? 최신 JavaScript 프레임 워크가 시간 낭비되는 이유 Is Blazor Better Than JavaScript? Blazor vs React: A Comprehensive Comparison ASP.NET Core Blazor Apps 디버그 - Microsoft Learn .NET 8의 Blazor : 서버 측 및 스트리밍 렌더링 Blazor에서 Static Server-Side Rendering의 장점 .NET 10의 새로운 기능 - Microsoft Learn What's New in ASP.NET Core in .NET 10 - 마이크로소프트 배우기 npm Supply Chain Attack - Palo Alto Networks Shai-Hulud 2.0 Supply Chain Attack - Wiz npm left-pad Incident - Wikipedia 이벤트 스트림 Malicious Package - Snyk The "Everything" Package Chaos - 소켓 About the Author I'm a Systems Architect who is passionate about distributed systems, .NET clean code, logging, performance, and production debugging. I've mass-deleted 내가 인정하고 싶은 것보다 더 많은 폴더를 받았습니다. node_modules Linkedin: 나와 연결하기 GitHub: mashrulhaque Twitter/X: @mashrulthunder