Blazor vs React för affärsapplikationer: vilket kostar dig mindre?

Sökresultaten för ”Blazor vs React” är fulla av benchmarks och utvecklares åsikter. För ett företag som bygger en affärsapplikation är en annan fråga viktigare: vilket val innebär färre personer, mindre dubbelarbete och färre överraskningar de kommande fem åren?

Det korta svaret: om ditt team skriver C# och applikationen är intern eller bakom inloggning kostar Blazor oftast mindre. Om du bygger en publik produkt för många användare, med ett frontendteam och mycket interaktivitet, är React det bättre valet. Den största skillnaden ligger inte i tekniken, utan i vem som bygger skärmarna.

Samma skärm i båda

Enklast ser man skillnaden på en liten skärm: en lista med öppna order och en knapp för att uppdatera.

I React lever skärmen i JavaScript eller TypeScript och hämtar data från backend via ett API:

type Order = { number: string; customer: string; total: number };

export function OpenOrders() {
  const [orders, setOrders] = useState<Order[]>([]);

  const load = () =>
    fetch('/api/orders/open')
      .then((response) => response.json())
      .then(setOrders);

  useEffect(() => { load(); }, []);

  return (
    <>
      <h2>Open orders: {orders.length}</h2>
      <button onClick={load}>Refresh</button>
    </>
  );
}

För det behöver .NET-backend en endpoint, som måste skyddas, versionshanteras och dokumenteras som alla andra:

app.MapGet("/api/orders/open", (OrderService orders) => orders.GetOpenAsync())
   .RequireAuthorization();

I Blazor med rendering på servern är hela skärmen en C#-komponent som anropar samma tjänst direkt:

@inject OrderService Orders

<h2>Open orders: @openOrders.Count</h2>

<button @onclick="LoadAsync">Refresh</button>

@code {
    private List<Order> openOrders = [];

    protected override Task OnInitializedAsync() => LoadAsync();

    private async Task LoadAsync() => openOrders = await Orders.GetOpenAsync();
}

I React finns typen Order två gånger, en gång i C# och en gång i TypeScript, och ofta gäller det också valideringsreglerna. På en skärm är det en småsak. I en applikation med hundra skärmar är det ett lager arbete som växer med varje ändring.

För att vara rättvis: även en Blazor-applikation som körs i webbläsaren på WebAssembly behöver ett API. Skillnaden är att modeller och validering ändå kan delas, eftersom båda sidor är C#.

Jämfört efter det som spelar roll för verksamheten

	Blazor	React
Vem bygger skärmarna	Samma C#-utvecklare som bygger backend	Oftast en separat frontendutvecklare, eller fullstackutvecklare i två språk
Rekrytering	Från gruppen .NET-utvecklare	Från en mycket större grupp frontendutvecklare
Färdiga komponenter	Tillräckligt för affärsapplikationer: tabeller, formulär, diagram	Det största ekosystemet som finns
Första laddning	Snabb i serverläge, större första nedladdning på WebAssembly	Snabb, särskilt med ramverk som Next.js
Publika sidor och SEO	Möjligt, men inte dess styrka	Starkt, särskilt med Next.js
Gemensam kod med backend	Samma klasser, validering och regler	Ett andra språk, så typer och validering skrivs två gånger
Uppgraderingar under fem år	En .NET-uppgradering per cykel med långtidssupport	Många npm-paket som ändras i sin egen takt
Antal stackar att underhålla	En	Två: JavaScript och .NET

Ett typiskt scenario

Ta ett grossistföretag med tre C#-utvecklare som underhåller ERP-integrationerna. Företaget vill ha en ny portal där 200 anställda följer order och leveranser.

Med Blazor bygger samma tre personer portalen. Skärmarna använder de befintliga tjänsterna och valideringen, och varje ny skärm är en komponent.

Med React finns två vägar. Företaget anställer en frontendutvecklare, med all rekrytering, introduktion och samordning som det innebär. Eller så lär sig de tre C#-utvecklarna React och TypeScript, bygger en API-endpoint för varje skärm och håller typerna i synk på båda sidor.

Ingen av vägarna är fel. Men för den här typen av applikation kostar den andra mer för varje ny skärm, så länge applikationen lever.

Ärligt om prestanda och popularitet

• Prestanda. React laddar snabbt och körs helt i webbläsaren. Blazor i serverläge öppnas också snabbt, men varje klick går till servern, vilket ingen märker på en bra anslutning men känns på en dålig. Blazor på WebAssembly har en större första nedladdning, som sedan sparas i webbläsaren. För en intern applikation som öppnas varje dag avgör det sällan något. För en publik sida som måste öppnas på en sekund i mobilen gör det det.
• Popularitet. React är betydligt mer spritt, och Blazor är en nisch i jämförelse. Det spelar roll när du behöver anställa frontendspecialister. Det spelar mycket mindre roll när ditt team redan kan C#.

När React är det bättre valet

• en publik produkt för många användare som är beroende av trafik från Google
• mycket rik interaktivitet: redigerare, dra och släpp, mycket animation
• ett företag som redan har ett frontendteam som arbetar i JavaScript
• en mobilapp i React Native som ska dela kod med webben

Och React i frontend med .NET i backend är en fullt sund arkitektur som många företag använder. .NET-backend är densamma i båda fallen.

Fem frågor innan du bestämmer dig

1. Vem ska bygga och underhålla skärmarna: personer som kan C#, eller frontendutvecklare?
2. Är applikationen intern eller bakom inloggning, eller publik och beroende av Google?
3. Hur mycket av din affärslogik finns redan i .NET?
4. Behöver du mycket rik interaktivitet, eller mest formulär, tabeller och rapporter?
5. Vem kan du realistiskt anställa där du finns, om två år?

Pekar svaren mot ett C#-team, inloggning och logik som redan finns i .NET, välj Blazor. Pekar de mot ett frontendteam, en publik målgrupp och ett rikt gränssnitt, välj React, med .NET-backend.

Om Blazor i sig är ett säkert val de kommande åren tar vi upp i artikeln Har Blazor en framtid 2026?. Och om du redan har en Blazor-applikation som blivit långsam, läs om de sju vanligaste orsakerna.

Så arbetar vi

ProCoding är en .NET-studio från Split i Kroatien. Vi har levererat Blazor till produktion sedan 2020 och bygger också .NET-backends som React-frontends pratar med, så vi har ingen anledning att driva det ena eller det andra. Vi hjälper dig att välja, bygger nya Blazor-applikationer och flyttar äldre applikationer skärm för skärm. Första steget är ett kostnadsfritt samtal på 30 minuter.

Källor

• ASP.NET Core Blazor, Microsoft Learn
• ASP.NET Core Blazor render modes, Microsoft Learn
• React documentation, react.dev
• .NET and .NET Core support policy, Microsoft