React Framework Comparisons: Svelte, Preact, Blazor, Flutter, and Htmx
React vs Svelte, Preact, Blazor, Flutter, and Htmx, compared. Real bundle sizes and tradeoffs, plus which one fits your next build.
Svelte and Preact cut bundle size, Htmx skips the client framework, and Blazor and Flutter each render through a different runtime entirely. None change how content gets fetched behind them.
Svelte, Preact, Blazor, Flutter, and Htmx all get compared to React for the same reason. Each one skips a piece of React's runtime cost. Svelte and Preact cut bundle size. Blazor swaps JavaScript for C#. Flutter renders its own UI instead of native components. Htmx skips the client-side framework entirely. None of them beat React on ecosystem size, but each wins on one specific tradeoff.
This roundup covers all five head to head, not five separate pages. For the wider framework landscape beyond just React's rivals, see the full framework selection guide. Picking a content layer to sit behind any of them? Draftbase's delivery API ships REST and GraphQL to any frontend. This comparison is about UI rendering, not data fetching.
React, Briefly
React renders to the DOM through a virtual DOM diff. It ships as a JavaScript library, not a full framework. It pairs with Next.js or Remix for routing and server rendering. It's the default most teams reach for first, which is exactly why every alternative below gets measured against it.
Svelte vs React: Compiler Output vs Runtime
Svelte compiles your components at build time into direct DOM-update instructions. There's no virtual DOM to diff at runtime, and close to no runtime at all. Svelte 5 ships at roughly 2 to 5KB gzipped for a minimal app. React 19 ships at 42KB, per Strapi's 2026 comparison.
That gap shows up in raw numbers. It's not just a marketing claim. The same benchmark clocked Svelte at about 8ms rendering a 1,000-item list. React took 47ms, and used roughly double the memory.
<script>
let count = $state(0);
</script>
<button onclick={() => count++}>{count}</button>
React's newer Server Components claw some of that back. They move work off the client entirely. For a typical business dashboard, that gap narrows further. Most users wouldn't notice it at all. Svelte's edge stays sharpest on bandwidth-constrained builds, animation-heavy screens, or embedded widgets. Every kilobyte there ships to every visitor.
Preact vs React: Same API, Smaller Runtime
Preact is a 3 to 4KB alternative to the React API. It's not a compiler, unlike Svelte. Most React components run in Preact with zero changes. preact/compat maps React's API onto Preact's runtime.
That makes Preact the lower-risk swap of the five. You keep JSX, hooks, and most of your existing code. You lose part of React's ecosystem, though. A library that reaches into React internals, not just the public API, can break under Preact's compat layer.
When Preact makes sense over Svelte
Pick Preact when an existing React codebase needs a smaller bundle without a rewrite. Pick Svelte when you're starting fresh and want compiler-level performance, not just a lighter runtime under the same API.
Blazor vs React: C# Instead of JavaScript
Blazor is Microsoft's answer to one question. What if the frontend ran C# instead of JavaScript? Blazor WebAssembly ships a full .NET runtime to the browser. It runs your C# there, at near-native speed once it loads.
That WebAssembly runtime is the real cost. Initial load runs heavier than a typical React bundle. The browser downloads a runtime before it downloads your actual app. Blazor fits an enterprise .NET shop that wants one language across backend and frontend. It fits a fast-loading public marketing site far less. See how to choose a web framework for the same tradeoff outside this specific comparison.
Flutter vs React: A Different Rendering Model Entirely
Flutter isn't really React's alternative at all. It's React Native's. Flutter paints every pixel itself, through its own Skia/Impeller rendering engine. It works the same way on iOS, Android, and web. React, the library covered in this post, renders to a browser's DOM. Flutter renders to a canvas it fully controls instead.
That distinction matters for how people search this. Someone comparing "Flutter vs React" for a mobile app almost always means Flutter vs React Native. The fuller React vs React Native breakdown covers that split. Flutter's web target exists, but it trails React badly on SEO and initial load for an actual web page. It ships a rendering engine most content sites don't need.
Htmx vs React: HTML Over the Wire vs JSON Plus Client Rendering
Htmx flips React's model. React sends JSON, and the client builds HTML from it. Htmx flips that: the server sends ready-made HTML fragments. Htmx swaps them into the page on a click or form submit.
<button hx-get="/api/like" hx-target="#count" hx-swap="innerHTML">
Like
</button>
No hydration step exists here. There's no client-side render to reconcile against server output. The page turns interactive the moment the HTML lands. Htmx ships at roughly 14KB gzipped. A typical production React app ships 200 to 500KB of JavaScript, per Builder.io's comparison.
When Htmx is the wrong pick
A rich client-side state machine has no natural home in Htmx's request-response model. Neither does drag-and-drop, or an app that must work fully offline. That's React's actual strength: managing state that never touches the server at all.
Bundle Size and Rendering Model, Side by Side
| Framework | Min bundle (gzipped) | Rendering model |
|---|---|---|
| React 19 | ~42KB | Virtual DOM, client or server |
| Svelte 5 | ~2 to 5KB | Compiled, no virtual DOM |
| Preact | ~3 to 4KB | Virtual DOM, React-compatible API |
| Htmx | ~14KB | Server-rendered HTML fragments |
| Blazor WASM | Multi-MB (.NET runtime) | WebAssembly, C# |
| Flutter | N/A (native/canvas) | Custom Skia/Impeller engine |
The Real Filter: What's Actually Being Optimized
Most "X vs React" comparisons frame the choice as pure speed. The more useful question is which cost you're moving. Svelte and Preact move cost out of the runtime. It lands in the build step instead. Htmx moves it out of the client and onto the server. It trades JavaScript for round trips. Blazor and Flutter move it into a runtime. The browser downloads that runtime before anything works.
None of these frameworks touch how content gets fetched. A site built in any of the five still needs a content API behind it. Picking the rendering layer first, then the data layer, is backwards for most teams.
What Breaks When a Team Switches Frameworks Mid-Project?
The rewrite risk isn't evenly spread across these five. Swapping React for Preact is often a one-line change: point the bundler alias at preact/compat, and most components keep working. The risk sits in the exceptions, not the rule.
Swapping to Svelte, Htmx, or Blazor is a different project entirely, not a migration. Components, state management, and routing all use a different mental model. Teams that try to port React components line by line usually end up rewriting most of them anyway. JSX and Svelte's template syntax don't map cleanly onto each other.
The safer path splits the decision in two. Pick the rendering framework for a new project, greenfield, with no legacy code pulling against the choice. For an existing React app, treat a full framework swap as a last resort, not a refactor. Leaving React costs you component libraries, hiring pool depth, and years of Stack Overflow answers. That cost usually outweighs the bundle-size win, unless the bundle is the actual bottleneck a real user hits.
Which Should You Actually Pick?
Pick React when the ecosystem, hiring pool, and Next.js's server story matter more than raw bundle size. That covers most content sites and product apps. Pick Svelte for a bandwidth-sensitive or animation-heavy build starting from scratch. Pick Preact to shrink an existing React app's bundle. The rewrite risk stays low. Pick Htmx for a server-rendered app that needs light interactivity without a JS build pipeline. Reach for Blazor only inside a .NET shop. Reach for Flutter only when the real target is a native mobile app, not a web page.
Conclusion
Each alternative to React solves one specific cost: bundle size, C#-only teams, native rendering, or skipping the client framework altogether. None of them replace the need for a typed, framework-agnostic content layer behind the UI. Draftbase's delivery API ships REST and GraphQL from one schema, so switching rendering frameworks later doesn't mean rebuilding how content gets fetched.
Ship content that's built to be found
Draftbase generates schema, structured data, and a fast MDX editor for every post.
Frequently asked questions
Is Svelte faster than React?
Yes, on raw benchmarks. Svelte ships a smaller bundle and skips the virtual DOM, so it renders large lists faster and uses less memory.
Can I use React components in Preact?
Mostly, yes. Preact's compat layer maps React's own API onto its runtime, so most parts run with no change. A rare library can still break.
Is Flutter a replacement for React?
No. Flutter competes with React Native for mobile apps, not with React for the web. Flutter renders its own canvas; React renders to the browser DOM.
Does Htmx need a build step like React?
No. Htmx is a single script tag with no compiler or bundler required. React usually needs a build pipeline for JSX and bundling.
Should I pick Blazor over React for a new web app?
Only inside a .NET shop that wants one language across the stack. Blazor WebAssembly ships a larger initial payload than React, so it costs more on first load.
Samer is a software engineer and entrepreneur, founder of Draftbase and Ezi Home Services, building technology that simplifies home services. Passionate about software, APIs, automation, and creating products that solve real-world problems.
