VSATutorialSeptember 2026 · 10 min read

VSA Todo App — Part 10: Blazor Server vs MVC Frontend Comparison in VSA

TL;DR

Part 10 closes the core tutorial by comparing two production frontends for the same VSA Todo backend. The Blazor CRM uses Blazor Server with MudBlazor — a state machine pattern, MudDataGrid, MudDialog for child items, and SignalR real-time connection. The MVC Project Manager uses ASP.NET Core MVC with Vue.js — DataTables.js for server-side grids, modal dialogs, drag-and-drop file upload, and print support. Both call the same VSA CQRS handlers. Learn when to choose each.

Part 10 of 20 in the VSA Todo App Tutorial Series|← Previous: Part 9|Next: Part 11 →

Help Us Grow

Love this tutorial? Explore our ready-to-use enterprise starter kits built with VSA in .NET 10.

The same VSA backend can serve radically different frontends. The Blazor CRM Todo feature uses Blazor Server with MudBlazor — a stateful, component-based UI with real-time SignalR connections. The MVC Project Manager Todo feature uses ASP.NET Core MVC with Vue.js — a traditional request-response model enhanced with reactive JavaScript. Both call the same CQRS handlers, both follow the same VSA folder structure, and both deliver the same functionality. This part compares them side-by-side so you can choose the right frontend for your VSA application.

The fundamental difference is state management. Blazor Server maintains UI state on the server via SignalR — every button click, dropdown change, and form submission is a server event. MVC with Vue.js maintains state in the browser — the server sends HTML, and Vue.js manages form state, validation, and API calls client-side. Neither is better; they solve different problems.

Blazor Server: State Machine Pattern

The Blazor CRM's TodoPage.razor uses a state machine pattern with an enum to manage view transitions. The component renders different sub-components based on the current state — Table, Create, Update, or View. The component's state is entirely captured by _currentView and _selectedData. No URL routing, no query parameters, no JavaScript. The MudBlazor components handle the UI: MudTable for the data grid with built-in sorting and pagination, MudForm with FluentValidation for forms, MudDialog for child item CRUD and delete confirmation. Child items are managed in separate dialogs that call dedicated API endpoints — the parent page doesn't reload.

MVC + Vue.js: Reactive Server-Rendered Pages

The MVC Project Manager serves Razor views enhanced with Vue.js. Each page has a corresponding .cshtml.js file that mounts a Vue 3 app. The index page uses DataTables.js for the list, the create/edit pages use reactive forms with Tom Select dropdowns and flatpickr date pickers. File uploads use drag-and-drop with base64 encoding — the user drops a file, Vue.js reads it as a base64 string, and includes it in the JSON payload. Image attachments display as thumbnails with a gallery modal. The DataTable on the index page calls /api/todo with server-side parameters — the table is searchable, sortable, and pageable without reloading the page.

Validation UX: Server-Side vs Client-Side

The Blazor CRM validates client-side using MudBlazor's MudForm with FluentValidation — errors appear instantly as the user types. The MVC Project Manager validates server-side in the handler and returns field-level errors that Vue.js displays next to each field. The Blazor approach provides faster feedback but requires duplicating validation rules (once in the validator class, once in the MudForm binding). The MVC approach has a single source of truth (the handler's validator) but requires a server round-trip for validation feedback.

When to Choose Each

Choose Blazor Server when: you want a rich, desktop-like UI without writing JavaScript, your users have reliable internet connections (SignalR dependency), you prefer C# end-to-end, and you need real-time updates across users. The state machine pattern with MudBlazor components produces polished UIs with less code than equivalent JavaScript.

Choose MVC + Vue.js when: you need server-rendered pages for SEO, your users have unreliable connections (each page is a standalone request), you want progressive enhancement (pages work without JavaScript), or your team has strong HTML/CSS/JS skills. The MVC approach also works better for public-facing pages where search engines need to index content.

Both patterns share the same VSA backend. The handlers, validators, entities, and endpoints are identical. The frontend choice is independent of the architecture. You could even mix both in the same application — MVC for public pages, Blazor for admin dashboards — because VSA keeps each feature self-contained.

Key Takeaways

  • Blazor Server maintains UI state on the server via SignalR — every interaction is a server event
  • MVC + Vue.js maintains state in the browser — the server sends HTML, JavaScript manages interactivity
  • The state machine pattern (enum-based view switching) is the cleanest way to manage Blazor page transitions
  • Drag-and-drop file upload with base64 encoding works seamlessly with VSA's JSON-based API endpoints
  • Both frontends call the same VSA CQRS handlers — the frontend choice is independent of the architecture

Frequently Asked Questions

Q: Blazor Server or MVC for VSA apps — which has better developer experience?

Blazor Server for C# developers who want to avoid JavaScript — you write components in Razor syntax with C# code-behind. MVC + Vue.js for teams with strong frontend skills who want full control over HTML/CSS/JS. Blazor's debugging is simpler (C# end-to-end); MVC's tooling is more mature (browser DevTools).

Q: How does state management differ between Blazor and MVC in VSA?

Blazor maintains state on the server — the _currentView enum and _selectedData live in the component's memory. MVC is stateless — each request is independent, and Vue.js manages UI state in the browser. Blazor's approach is simpler for complex multi-step workflows; MVC's approach scales better for high-traffic public pages.

Q: Can I use both Blazor and MVC in the same VSA project?

Yes. Add services.AddRazorComponents().AddInteractiveServerComponents() alongside services.AddControllersWithViews(). Use MVC for public-facing pages and Blazor for admin dashboards. The VSA handlers are shared — both frontends call the same CQRS handlers through the same API endpoints.

Q: Which is better for file uploads — Blazor or MVC with VSA?

MVC + Vue.js has a better file upload UX — drag-and-drop with instant preview, base64 encoding in the browser, and progress indicators. Blazor requires JS interop for file reading or a separate upload endpoint. Both ultimately send the same JSON payload to the same VSA endpoint.

Part 10 of 20 in the VSA Todo App Tutorial Series|← Previous: Part 9|Next: Part 11 →

Ready to study real VSA code?

Every Indotalent product is a complete .NET 10 application built with Vertical Slice Architecture. Complete source code — $21 each.

Explore Products

Looking for a ready-to-use traditional monolithic multilayered clean architecture?

Monolithic Clean Architecture — 1,300+ devs, 500+ forks. Clean Arch + CQRS + Repository Pattern. Free & open source for commercial use.

Star on GitHub