Are We Devolving in Web Development? Or Is Razor Pages the Industry Growing Up?

I recently started a new web project in Visual Studio 2026. The default template? Razor Pages.

When I opened the generated code, I had a strange flashback.

HTML with server-executed logic.

It looked… familiar. Uncomfortably familiar.

If you’ve been developing long enough to remember classic ASP or early PHP, you know the feeling. Markup interwoven with server-side logic. Code blocks inside HTML. Page-centric flow. It feels like 1999 wearing a modern suit.

So the question naturally arises:

Are we devolving?

Or are we witnessing something more interesting?

The Architectural Pendulum

Software architecture rarely moves in a straight line. It swings.

We started with:

Classic ASP and PHP, where logic was mixed directly in markup. Then MVC, with its strict separation of concerns. Then the rise of SPA frameworks like React, Angular, and Vue. Then API-first backends, microservices, and the era of “component everything.”

Each phase reacted to the shortcomings of the previous one.

Classic ASP lacked structure → MVC enforced discipline.
MVC introduced ceremony → SPAs moved logic to the client.
SPAs introduced complexity → server-first frameworks resurged.
Microservices solved scaling problems → but added operational overhead.

Now we’re seeing something fascinating: a consolidation phase.

Razor Pages represents a vertical-slice architecture instead of a horizontal-layer architecture.

Instead of:

Controller → Action → View

We now have:

Page (route) → PageModel (handler) → Same .cshtml (view)

The page becomes its own mini-controller.

And yes — that looks suspiciously like old-school web development.

But it isn’t.

Why It Feels Like Devolution

The emotional reaction many experienced developers have isn’t about technology. It’s about memory.

We remember what happened when discipline broke down.

Classic ASP and early PHP applications often devolved into:

• Business logic embedded in markup

• Database calls inside views

• Tight coupling everywhere

• Un-testable spaghetti

The industry spent years creating patterns to prevent exactly that.

So when we see code blocks inside HTML again, alarms go off.

But that reaction confuses appearance with structure.

What’s Actually Different

Modern Razor Pages are not classic ASP.

Underneath the surface, you still have:

Strong typing, compile-time checking, dependency injection, middleware pipelines, async/await, model binding, convention-based routing, and enforced separation via .cshtml and .cshtml.cs files.

The code-behind pattern is enforced.
Business logic doesn’t belong in the markup.
The runtime is modern, robust, and fully integrated into the .NET ecosystem.

The similarity is superficial.
The discipline remains.

The Cost of Architectural Purity

MVC is architecturally elegant.

But for many real-world applications — especially internal enterprise systems — it can introduce unnecessary ceremony.

To render a simple page, you may need: a controller, an action method, a view model, a view, route configuration, and dependency wiring.

That structure is clean, but it’s also heavy.

Razor Pages collapses that ceremony into a feature-centric model.

If you need a Login page, you create /Login.

The route, handler, and view are co-located.

For many use cases, this aligns better with how developers think:

"I need a page that does X."

Instead of:

"I need a controller that routes to a view that binds to a model."

This is not a rejection of architecture.
It’s a reduction of friction.

Industry-Wide Convergence

This isn’t a Microsoft anomaly.

Look across the ecosystem:

Next.js shifted React back toward server rendering. Remix embraces server-first logic. HTMX promotes HTML-over-the-wire simplicity. Rails never abandoned server rendering. Laravel continues to thrive with Blade templates.

After a decade of pushing logic to the browser, the industry discovered something uncomfortable:

Most business applications are forms, database interactions, and HTML rendering.

We built distributed systems to avoid writing templates.
Then realized we’d introduced hydration complexity, build pipelines, and deployment overhead that many projects simply don’t need.

So the pendulum swings.

Not backward — but toward equilibrium.

Vertical Slicing vs Horizontal Layers

Traditional MVC organizes code by technical layer:

• Controllers

• Services

• Repositories

• Views

Razor Pages encourages organizing by feature, like /Products, /Orders, or /Admin/Users.

Everything related to that feature lives together.

This aligns with modern "feature folder" and domain-driven design philosophies.

Cohesion increases.
Navigation becomes intuitive.
Cognitive load decreases.

For many teams, that trade-off is worth it.

Maturity, Not Regression

If you’ve lived through multiple architectural eras, this shift feels significant because you see the arc.

Junior developers see Razor Pages as normal.

Veteran developers see history looping.

But what’s actually happening is maturation.

The industry has stress-tested abstraction at scale.

We’ve learned:

Over-separation can harm velocity. Client-side-everything architectures can increase complexity. Microservices add operational burden. Architectural purity, while elegant, can slow down delivery.

Now we’re asking a better question:

What is the simplest thing that works well?

That question signals maturity.

When Razor Pages Makes Sense

Razor Pages shines in scenarios like:

small to medium-sized applications, CRUD-heavy enterprise systems, internal tooling, and line-of-business apps.

Where the priority is clarity, maintainability, and delivery speed.

For complex distributed systems or API-first architectures, layered MVC or service-based designs may still be preferable.

The key is optionality.

.NET gives you choices.

Razor Pages doesn’t eliminate MVC.
It complements it.

The Broader Lesson

The deeper insight here isn’t about Razor Pages.

It’s about how our industry evolves.

We often equate complexity with progress.
We assume more abstraction means advancement.
We mistake ceremony for sophistication.

But real progress sometimes looks like subtraction.

Reducing ceremony.
Reducing friction.
Reducing cognitive overhead.

Not because we’ve forgotten what we learned.

But because we’ve integrated it.

Final Thoughts

When I first opened that Razor Page and saw server logic near markup, I felt that reflexive discomfort.

Then I stepped back.

The structure is still there.
The discipline is still there.
The ecosystem is still modern.

What changed is the packaging.

We’re not devolving.
We’re consolidating.

The web stack has entered a post-ideological phase.

We’ve tried everything on the server.
Everything on the client.
Everything as microservices.
Everything as components.

Now we’re optimizing for balance.

And sometimes, balance looks like something you’ve seen before — just built on a much stronger foundation.

That isn’t regression.

That’s refinement.