Why Modern Web Development Keeps Rebuilding Application Foundations from Scratch

I have been working in web development for nearly 30 years.

Back in the era when HTML-based sites were estimated page by page, I started using PHP to centralize headers, footers, and menus. By integrating with databases, development speed increased dramatically, and maintenance effort decreased. About 30 years ago, when I built a site to keep records of billiards matches for fun, writing the same table structure repeatedly with <table><tr><td>... became tedious. So, I turned everything into data. I also made it so that each user's page could be created with a single click as the number of users grew.

Based on those experiences, I have always thought about how to build web systems that are easy to manage and require minimal effort.

Concerns about recent web development

The development speed relative to the pages and features being realized is slowing down, isn't it?
npm dependencies exceed hundreds, and membership management, permission management, and workflows are all built from scratch every time.

And every time a project starts,
a new "foundation" is built
as if the previous system never existed.

Job postings simply state:
"Experience in TypeScript-based development."

I have organized my thoughts on the question: Is this really evolution?

---

Web development had two evolutionary lineages from the start

In fact, I believe there have historically been two different currents in web development.

1. The web page production lineage

This has consistently been a history of

efficiency and structuring.

• CMS
• Template management
• Components and modularization
• Content models
• Workflows
• Permissions
• Plugins
• CCK (Content Construction Kit) *structural management of custom fields

In other words,

A world that has continuously asked, "How can we mass-produce structures efficiently?"

Joomla, Drupal, and WordPress have long performed this structuring based on standard systems engineering principles.

---

2. The web system development lineage

This followed a completely different evolution.

• Web migration of business screens
• Screen-based development
• UI-centric
• Framework-centric

It was strongly influenced by the influx of:

• C/S developers
• Java business application developers
• System integrators (SIers)

As a result,

The philosophy of web structuring was not adequately inherited.

I believe this is also the reason for the increase in development that started abruptly without considering architecture, based on the idea that "if you build screens, it's the web," without understanding the basics of the web. While things have improved significantly now, I think this is also why the UI of government websites remained lackluster for a long time.

Headless was an evolution, but the philosophy of foundational infrastructure has been neglected

Headless is definitely an evolution.

• Clarification of API boundaries
• Distributed execution
• Edge Runtime
• Streaming SSR
• Advanced caching strategies

However, at the same time:

The ideal form of an application infrastructure has become obscured.

It seems that regardless of the distinction between programming language skills and architectural design skills, opportunities have increased for people to develop systems simply because they "can use that language," without delving into the latter.

As a result:

• User management → DIY
• Permissions/Authorization → DIY
• Workflow → DIY
• Plugin architecture → DIY
• Cache consistency → DIY

These seem to have become the norm.

I often see user management platforms, e-commerce platforms, and template frameworks—which were abundant in the PHP era—being recreated from scratch.

Why "Just let AI build it" destroys web development

—From sites that recreate application infrastructure every single time—

There is a phrase I hear often lately:

"Why don't you just let the AI build it each time?"

It is true that AI is good at:

• Generating UI
• Generating React code
• Generating API calls

However:

Application infrastructure cannot be created through local optimization.

AI tends to rewrite unique structures into more standard ones.

In other words:

"My own unique infrastructure is easily destroyed by AI."

Conversely, infrastructures that possess universal structures, such as:

• RBAC (Role-Based Access Control)
• Clean Architecture
• DDD (Domain-Driven Design)
• OpenAPI contract
• Event-driven architecture

...are resistant to AI.

Infrastructure becomes business assets

For example, Recruit's "Hot Pepper" was initially operated by agents entering content on behalf of clients. However, by transitioning to a CMS and allowing customers to input their own content, the service scale grew explosively. Furthermore, by refining the application infrastructure, it became easy to create similar services.

In other words:

The content business evolved into an infrastructure business.

This is a trait common to services like:

• Shopify
• Salesforce
• Notion

Web development is now in a phase of reintegration

Web development has not regressed.

• The runtime has evolved
• The execution model has evolved

However:

The design culture has become fragmented.

Web development philosophy required for the future

What is needed from here on out is, I believe, the fusion of page production philosophy and system development philosophy.

In other words:

Application infrastructure development.

Application to AI-driven development

If the application infrastructure—that is, the foundation of the web system—is solid, the AI only needs to concern itself with the individual logic running on top of it. Furthermore, you could even break it down into low-code or no-code development without needing AI at all.

What we should fundamentally aim for is not the utilization of AI, but the construction of a proprietary application infrastructure.

The know-how for doing so is buried within the development assets of previous generations. Unfortunately, in many cases, that architectural design was never documented. We should take the ingenuity of our predecessors, translate it into design, and redesign it using new languages.

Companies that can create such a flow will be able to proceed with efficient web development without being swayed by AI for years to come. Lately, I am often sought after for advice as a senior developer regarding this very topic.