Spoiler: AI models are only as good as their training data, and Blazor just doesn't have enough of it yet. Spoiler: AI models are only as good as their training data, and Blazor just doesn't have enough of it yet. Look, I get it. Blazor is cool. It's modern. It lets you write C# for the front end instead of JavaScript. It's what all the .NET developers want to use in 2025. But here's the thing I discovered while rewriting a legacy lottery simulation app: GitHub Copilot absolutely crushes it with the more straightforward ASP.NET Razor Pages, but completely falls apart when you try to get it to generate Blazor code. more straightforward ASP.NET Razor Pages And I'm not talking about minor issues. I mean it straight-up doesn't work. Claude Sonnet 4.5? Same problem. ChatGPT? Yep, struggles there too. Before you flame me in the comments—yes, I know this will probably change in the next 6 months. AI is evolving fast. But right now, at the time of writing, if you want AI to help you build ASP.NET web UIs, you're better off with the "boring" technology. Here's what happened. But right now, at the time of writing Watch Video Here https://youtu.be/sQdByQML_w8?si=rQnGHIPcEnd66Tzn&embedable=true https://youtu.be/sQdByQML_w8?si=rQnGHIPcEnd66Tzn&embedable=true Source Code The legacy Lottron2000 source code is available at this GitHub repository GitHub repository The rewrite (only parts of the code, NOT the full source) available at this GitHub repository GitHub repository The Setup: Rewriting a Legacy .NET Framework App I have this old lottery simulation app that needed to be modernized. You know the drill—ancient .NET Framework code that's been sitting there for years, doing its job but looking rough. I didn't want to just slap some code together. I wanted this done right. So I built out the backend with Clean Architecture: • Domain logic in its own project, completely separate from data access • Entity models for the database, DTOs for the front end • Services layer handling all the business logic • Proper dependency injection setup • Everything nicely organized in Visual Studio The backend was solid. GitHub Copilot actually helped quite a bit there. The architecture was clear, the patterns were well-established, and Copilot could easily infer what I was trying to do. Then came the front end. And that's where things got interesting. The Experiment: Let's Try Razor Pages First Full disclosure: I'm not a front-end guy. I can write backend code all day, but asking me to design a UI? That's where I struggle. So I was genuinely curious if AI could fill that gap for me. Here's how I set this up (and this is important): I didn't just throw Copilot at an empty project and say "build me an app." I didn't just throw Copilot at an empty project and say "build me an app." Instead, I: 1. Created an empty Razor Pages project in Visual Studio myself—gave Copilot the right template to work with 2. Had my entire well-structured backend already there—Copilot could see the domain models, the DTOs, the services 3. Wrote high-level prompts in a Word doc—basically pseudo-specs describing WHAT should be on the page, not HOW to build it 4. Let Copilot figure out the implementation details My prompts were things like: "Display the DTO objects in this order, show the user options for number generation, display the results with profit/loss calculations." I didn't specify drop-downs or text boxes or layouts. I didn't create mockups. Just high-level requirements. The Results: Razor Pages Just... Worked I'm not going to lie, I was surprised. GitHub Copilot generated: • A working PlayLottery page with proper form controls • Clean code-behind that wasn't a mess • ViewModels that actually made sense • A UI that looked... decent • Results display showing all the calculations correctly It compiled. It ran. First try. Sure, I wanted to refine some things—add the winning numbers to the display, style the tickets with borders, that kind of stuff. But each time I asked Copilot to make a change, it just... did it. Correctly. The workflow felt natural: "Hey, add this feature." Copilot adds it. "Make it look like this." Copilot styles it. Done. Then I Tried Blazor. It Was a Disaster. Okay, so Razor Pages worked great. But come on—it's 2025. I should be using Blazor, right? It's the modern way to build .NET web apps. Component-based, interactive, all that good stuff. So I tried the same approach with Blazor on a few different projects. It failed. Every time. Not "kind of worked but needed tweaking" failed. Like "this code won't even compile" failed. Or "it runs but crashes immediately" failed. Or "the architecture is just completely wrong" failed. And it wasn't just GitHub Copilot. I tried Claude Sonnet 4.5. I tried ChatGPT. Same issues across the board. These are supposed to be the best AI coding assistants available, and they're all struggling with the same thing. Why Is Blazor So Hard for AI? Here's my theory (I stress these are ONLY my educated guesses - not backed by factual research). I think it comes down to training data: I stress these are ONLY my educated guesses - not backed by factual research 1. There's Just Not Enough Blazor Code Out There 1. There's Just Not Enough Blazor Code Out There Razor Pages has been around since 2017. That's 8 years of Stack Overflow answers, GitHub repos, blog posts, and production code for AI models to learn from. Blazor? It only hit production in 2019, and honestly, a lot of the code written in those early days is outdated now because the framework kept changing. 2. Blazor Keeps Changing 2. Blazor Keeps Changing What worked in Blazor Server in 2020 is different from Blazor WebAssembly in 2022, which is different from Blazor Web Apps in 2026. The patterns, the templates, the best practices—they're all evolving. That makes the training data inconsistent and confusing for AI models. 3. It's Not As Popular As React or Vue 3. It's Not As Popular As React or Vue Real talk: Blazor hasn't taken over the world. React, Vue, Angular—those frameworks have massive ecosystems. More developers using them means more training data for AI. Blazor is still relatively niche in comparison. 4. Too Many Configuration Options 4. Too Many Configuration Options Blazor Server or WebAssembly? Interactive or static rendering? Code-behind or inline code? Auto mode? The number of ways you can configure a Blazor project creates ambiguity, and AI models don't handle ambiguity well. 5. Microsoft Keeps Tweaking the Templates 5. Microsoft Keeps Tweaking the Templates The .NET team is still refining how Blazor projects are structured. Each release brings changes. That's great for innovation, but terrible for creating a stable corpus of training examples for AI to learn from. What I Learned: AI Needs Good Training Data, Not Hype Here's the bottom line: AI coding assistants are incredibly good at what they've seen a million times before. They're not so good at newer, less-common frameworks—even if those frameworks are technically superior. If you want to maximize AI assistance: If you want to maximize AI assistance: • Pick mature, widely-adopted frameworks over cutting-edge ones • Give AI a well-architected codebase to work with—good architecture amplifies what AI can do • Set it up for success: don't ask it to generate everything from scratch, give it context • Expect to iterate—AI gets you 80% of the way there, you refine the rest • Know that this situation is temporary—what's hard today will be easy in 6 months This isn't about Razor Pages being better than Blazor. It's not. Blazor is legitimately the future of .NET web development. But right now, if you need AI to help you build a .NET web UI and you want it to actually work, Razor Pages is the play. This Will Change (Probably Soon) Here's the thing I want to emphasize: this is a snapshot at the time of writing. AI is evolving insanely fast. By the time you read this, it might already be outdated. Blazor is maturing. More developers are adopting it. More code is being written. The training data is accumulating. And AI models themselves are getting better at handling complex, multi-configuration frameworks. They're moving beyond simple pattern matching toward actual understanding of software architecture. So yeah, by the time the next version of .NET rolls around, this whole article might be irrelevant. GitHub Copilot might be crushing Blazor projects just as easily as it does Razor Pages today. But for right now? If you're in my shoes—trying to build a .NET web app with AI assistance—you need to know what actually works. Final Thoughts I went into this project excited about Blazor. I came out of it shipping a Razor Pages app. Not because Razor Pages is better. Not because I'm anti-Blazor. But because when you're working with AI, you need to meet it where it is, not where you wish it was. The real lesson here isn't about frameworks. It's about understanding that AI coding assistants are tools with limitations, and those limitations are tied to their training data. Use the boring tech that works. Build a solid architecture. Give AI the context it needs. And iterate until you get what you want. That's what worked for me. Hope it helps you too. This article is based on a real project rewriting a legacy .NET Framework lottery simulation app using GitHub Copilot in Visual Studio 2026. Your mileage may vary. AI capabilities are evolving rapidly—what's true today might not be true tomorrow. This article is based on a real project rewriting a legacy .NET Framework lottery simulation app using GitHub Copilot in Visual Studio 2026. Your mileage may vary. AI capabilities are evolving rapidly—what's true today might not be true tomorrow.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Razor Pages Beat Blazor for AI

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

AI Code Review Is Great at Nitpicks, Terrible at Systems

GitHub Copilot Adds Persistent Memory for Repository-Level Context

GPT-5.3 Codex Reviewed My .NET Data Access Library and Missed the Architecture

Claude vs ChatGPT in Copilot Agent Mode: Which AI Model Finishes Refactors Fastest?

How Artificial Neural Networks Can Code Smarter Than GUI Programmer

How GPT Pilot Codes 95% of Your App

AI Code Review Is Great at Nitpicks, Terrible at Systems

GitHub Copilot Adds Persistent Memory for Repository-Level Context

GPT-5.3 Codex Reviewed My .NET Data Access Library and Missed the Architecture

Claude vs ChatGPT in Copilot Agent Mode: Which AI Model Finishes Refactors Fastest?

How Artificial Neural Networks Can Code Smarter Than GUI Programmer

How GPT Pilot Codes 95% of Your App

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps