There was a time when frontend architecture was mostly about rendering.

The backend had the architecture.

The frontend had some templates, a few JavaScript files and maybe a jQuery plugin that nobody wanted to touch.

The browser was a window into the application.

That's not really true anymore.

Modern frontend applications don't just render data.

They fetch it, cache it, transform it, synchronize it, invalidate it, optimistically modify it, decide when it is stale, decide what the user is allowed to do with it, decide what happens when the network disappears, and decide what the user sees while all of this is happening.

At some point, this stops being "UI architecture".

It's just architecture.

And I think this is one of the more interesting things happening to frontend engineering right now.

The API stopped being the boundary

We still talk about APIs as if they were the boundary between frontend and backend.

The backend owns the business logic.

The API exposes it.

The frontend consumes it.

Nice and clean.

Except that real applications don't work like that anymore.

Imagine an endpoint returning:

{
  "status": "pending",
  "updatedAt": "2026-09-20T08:12:00Z",
  "items": [...]
}

The backend has told us what the object is.

But it hasn't told us what the application should do with it.

Should we show the old data while refreshing?

Should we display a skeleton?

Should the user be allowed to edit it?

Should editing be optimistic?

What happens if the request fails?

Should we retry?

Should another component be invalidated?

Should another browser tab know about the change?

Should the URL change?

Should the user be able to navigate away while the mutation is pending?

Should the application keep polling?

Should a stale response be ignored?

All of those are architectural decisions.

And increasingly, they happen in the frontend.

The API defines the data contract.

The frontend defines a surprisingly large part of the behavioral contract.

The most dangerous frontend bugs are often consistency bugs

One of the things you start noticing after working on sufficiently large applications is that the hardest frontend bugs are rarely rendering bugs.

They're consistency bugs.

The UI says one thing.

The cache says another.

The URL says something else.

The server has already moved on.

And somewhere in the middle is an optimistic update that nobody remembers implementing.

For example:

User clicks "Archive" -> UI immediately removes the item -> Request A starts -> User changes a filter -> Request B starts -> Request B finishes -> Request A finishes -> Old data comes back -> The item mysteriously reappears

There is no obvious "frontend bug" here.

It's a consistency problem.

You are now dealing with ordering, causality and stale writes.

That's distributed systems territory.

The fact that the distributed system happens to be running inside a browser doesn't make it less distributed.

Your browser is a distributed system with a terrible network

This becomes even more obvious when you add real-world conditions.

A user can:

• open the same application in three tabs
• lose Wi-Fi
• regain Wi-Fi
• suspend the laptop
• wake it up three hours later
• go offline while a mutation is running
• press the same button twice
• hit Back
• hit Forward
• open the same URL on another device
• keep an old tab open for two weeks

Now imagine you have a cached representation of some resource.

How long is it valid?

Who invalidates it?

What happens if another tab changes it?

What happens if the user's session expires while the tab is suspended?

What happens if the application version changes while the user is offline?

Suddenly "state management" doesn't sound like a particularly good name for the problem anymore.

It's synchronization.

The browser lifecycle is an architectural constraint

One of the most underrated things about frontend architecture is that the application doesn't control its own lifecycle.

Backend services can usually assume that they are running.

Frontend applications can't.

The browser can kill your app whenever it feels like it.

The user can close the tab.

The OS can suspend the laptop.

The browser can freeze the page.

A mobile browser can reclaim memory.

A background tab can stop doing things.

A user can restore a tab from yesterday.

This creates architectural consequences.

For example, imagine a frontend application that stores some important state only in memory.

Everything works perfectly.

Then the user:

- opens a new tab,
- accidentally closes the original one,
- reopens it from browser history.

Your "application state" is gone.

Nothing crashed.

Nothing was deployed incorrectly.

The architecture simply assumed a lifecycle the browser never promised.

This is one of those things you tend to learn only after an application has been in production long enough.

Navigation is a transaction

We usually think of navigation as:

click link -> change URL -> render page

In a serious application, it can be much more complicated.

Imagine the user is editing a large form.

They click another route.

Now you need to decide:

• can navigation happen immediately?
• should we warn them?
• should the current mutation finish?
• should the draft be persisted?
• should the URL change before the save?
• what happens if the save fails?
• what happens if the user presses Back?
• what if the destination requires data that is currently unavailable?

Navigation starts looking suspiciously like a transaction.

And that's an important shift.

The router is no longer just a collection of URLs.

It is participating in application state transitions.

The URL is one of the best state stores we've ever built

We keep inventing increasingly sophisticated state management solutions while ignoring something the browser has had for decades.

The URL.

The URL is:

• persistent
• shareable
• bookmarkable
• inspectable
• browser-native
• reload-safe
• navigable with Back and Forward
• accessible from outside the application

Consider:

/products?category=shoes&sort=price&page=4

That's a remarkably good state container.

Yet it's common to put exactly the same information into a client-side store.

Now the application has:

// URL:
page = 4

// Store:
page = 3

Congratulations.

You have invented two sources of truth for a piece of state that the browser was already perfectly capable of storing.

One of the more mature frontend questions is therefore not:

Which state management library should we use?

It's:

Does this state need to exist in JavaScript at all?

Rendering architecture is deployment architecture

SSR, CSR, streaming, server components, islands, static generation and all the other rendering strategies are often discussed as performance techniques.

That's only part of the story.

They also decide where your code runs.

And that means they decide:

• where data is fetched
• where secrets can exist
• where authorization can happen
• what can be cached
• what gets deployed together
• what can fail independently
• what gets sent to the browser
• what becomes part of the client bundle
• what infrastructure the application needs

Changing the rendering model can therefore change the architecture of the entire system.

A frontend framework decision can quietly become an infrastructure decision.

That's something that isn't particularly obvious when you're deciding how to render a component.

The frontend is where backend boundaries meet user boundaries

Backend architecture often follows domains.

Payments.

Orders.

Users.

Inventory.

Recommendations.

That's sensible.

But users don't experience domains.

They experience workflows.

A checkout page might involve:

Cart -> Inventory -> Pricing -> Discounts -> Payment -> Shipping -> Order

From the backend's perspective, that's a collection of services.

From the user's perspective, it's one operation.

The frontend is where those two worlds have to meet.

And this is where backend architecture can become surprisingly visible.

A beautifully separated backend can still produce a terrible frontend if its boundaries don't correspond to the way users actually perform work.

The frontend becomes the place where technical boundaries are translated into human workflows.

That is architecture.

Micro-frontends misunderstood the problem

Micro-frontends are often described as:

microservices for the frontend.

I think that's slightly missing the point.

The real problem they were trying to solve was often organizational.

Who owns this part of the product?

Who can change it?

Who can deploy it?

Who decides its API?

Who gets paged when it breaks?

Those are ownership questions.

You can have a single frontend deployment with very strong architectural boundaries.

You can also have twenty separately deployed micro-frontends that share so much state and infrastructure that they're effectively one giant application with twenty build pipelines.

The number of deployments doesn't tell you much.

Ownership does.

A useful architectural boundary is one that lets a team make changes without negotiating with five other teams.

That's true whether the boundary exists in a monorepo, a package, a route, a service or a separately deployed application.

The design system is an architecture constraint

Design systems are usually presented as collections of components.

Buttons.

Inputs.

Dialogs.

Dropdowns.

Cards.

But once a design system becomes sufficiently mature, it starts controlling much more than appearance.

It can determine:

• how forms are validated
• how errors are displayed
• how loading works
• how dialogs behave
• how focus is managed
• how navigation works
• how responsive behavior works
• how accessibility is implemented

At that point, the design system isn't really a component library anymore.

It's a set of constraints on how the application can be built.

And that's good.

Architecture is often about making invalid solutions difficult to express.

A design system that prevents 40 teams from inventing 40 different ways to handle loading is doing architectural work.

Shared code is not necessarily shared architecture

This is another trap that becomes obvious only at scale.

Teams often celebrate extracting something into a shared package.

Now everyone can use it.

Problem solved.

Except now everyone depends on it.

The package has become a central piece of infrastructure.

A tiny change requires coordination.

A breaking change requires migration.

A seemingly harmless dependency now has a blast radius of the entire organization.

The abstraction succeeded technically and failed organizationally.

Sometimes duplicating 30 lines of code is architecturally cheaper than sharing 30 lines of code.

This is one of those lessons that is almost impossible to appreciate from a small codebase.

At small scale:

Don't repeat yourself.

At large scale:

Be very careful about what you make everybody depend on.

The most expensive frontend code is code nobody owns

You can usually find this in mature applications.

There is some shared utility.

Nobody knows why it exists.

It has 17 consumers.

Changing it is scary.

Removing it is impossible.

The original author left four years ago.

Every team assumes another team owns it.

So nobody changes it.

This is not really technical debt.

It's ownership debt.

And ownership debt is one of the reasons frontend architecture becomes difficult at scale.

A codebase can be perfectly modular at the file level while being completely dysfunctional at the organizational level.

Feature flags are architecture too

Feature flags often look like product tooling.

But once an application has enough of them, they become another architectural layer.

Imagine:

if featureA
  if featureB
    if featureC
      ...

Now your application doesn't have one state.

It has a state space.

With 10 independent boolean flags, you theoretically have 1,024 combinations.

Most of them were never tested.

Some of them are impossible.

Some only exist for three customers.

Some existed two years ago and nobody remembers to remove them.

At that point, feature flags aren't configuration anymore.

They're another dimension of system complexity.

A Staff-level frontend engineer eventually has to think about the lifecycle of flags just as seriously as the lifecycle of code.

Permissions are not just backend concerns

Another subtle example.

The backend correctly checks:

Is this user allowed to perform this action?

Good.

But the frontend still needs to answer:

Should this action exist in the UI?

Those are different questions.

The backend is responsible for security.

The frontend is responsible for experience.

But now imagine permissions can change while the application is open.

The user has the page open.

An administrator changes their permissions.

The frontend still thinks they can perform the action.

The next request fails.

Nothing is technically wrong.

But your client now has stale authorization state.

Again, this isn't just a UI problem.

It's consistency between two independently evolving representations of reality.

Error handling is architecture

This is another thing that looks trivial until it isn't.

What does "the request failed" mean?

Does the whole page fail?

Does the component fail?

Does the old data remain visible?

Does the user get a retry button?

Does the mutation get retried automatically?

What if the server actually processed the mutation but the response was lost?

This last one is particularly nasty.

Imagine:

POST /payment -> Server processes payment successfully -> Network connection dies -> Browser receives nothing

The frontend sees:

Request failed.

But the server sees:

Payment succeeded.

Retrying may charge the user twice.

This is not a Vue/React/Angular/YouNameTheFramework problem.

It is not a fetch problem.

It is a distributed-systems problem that happens to have a button attached to it.

The frontend increasingly has to participate in solving these problems.

Observability has moved into the browser

Traditional architecture diagrams rarely show frontend observability.

They should.

Because some of the most useful production information exists only on the client.

Which route was the user on?

What feature flags were active?

Which API response was stale?

What did the user actually see?

Which JavaScript chunk failed to load?

Did the error happen before or after hydration?

Was the application running an old version?

Did the browser restore a suspended tab?

These details can completely change how you diagnose a production issue.

A backend log might tell you:

POST /orders → 200

The browser might tell you:

- User clicked "Place order"
- optimistic UI updated
- POST /orders
- 200
- navigation started
- chunk failed to load
- application crashed

Both are true.

Only one describes what the user experienced.

The frontend is also becoming a versioning problem

There is another weird property of frontend applications:

You don't control how quickly users upgrade.

You deploy version 42.

But someone might still have version 41 open in a browser tab.

Or version 40 restored from yesterday.

Or an old service worker.

Or an old cached JavaScript chunk.

Meanwhile the backend has moved on.

This creates a strange compatibility problem:

Frontend v41 vs Backend v43

The frontend is no longer simply a client of "the current backend."

It is a potentially old client talking to a continuously changing server.

Once again, we're dealing with distributed systems.

Just with browsers involved.

AI makes all of this more important

This is probably the most interesting consequence of AI-assisted development.

AI has made producing frontend code dramatically cheaper.

Components are cheap.

Hooks are cheap.

Tests are cheap.

Refactors are cheap.

A reasonable-looking abstraction can be generated in seconds.

But architecture hasn't become cheaper.

If anything, the opposite happened.

The cost of creating bad architecture went down.

That changes the economics of engineering.

Before:

Writing this abstraction will take two days. Is it worth it?

Now:

The AI can write this abstraction in thirty seconds.

The question becomes:

Should this abstraction exist at all?

AI is extremely good at local optimization.

Architecture is mostly about preventing locally reasonable decisions from becoming globally incompatible.

That's why I don't think AI makes frontend architecture less important.

I think it makes the discipline more consequential.

The frontend engineer's job is changing

The interesting part isn't that frontend engineers now write more code.

It's that they increasingly have to reason about more dimensions of the system.

Not just:

Component -> Props -> DOM

But:

User -> URL -> Navigation -> UI state -> Cached state -> Server state -> Network -> Backend -> Database

And then back again.

With failure at every step.

With stale data.

With concurrent users.

With multiple tabs.

With old deployments.

With feature flags.

With permissions.

With partial failures.

With an AI agent happily generating another abstraction because you asked it to "clean this up."

At some point, calling all of this "frontend" starts to feel a little misleading.

The browser stopped being a window

The old mental model was:

Backend = application
Frontend = presentation

Then it became:

Backend = business logic
Frontend = application

And I think we're moving toward something else.

The frontend is becoming the place where a large part of the system's behavior is assembled.

Not because the backend is becoming less important.

Quite the opposite.

The backend owns the data, invariants and authoritative state.

But the frontend owns an increasingly sophisticated interpretation of that state.

It decides how distributed pieces become one experience.

It decides how asynchronous systems become synchronous-looking interactions.

It decides how failures are represented.

It decides how old and new versions coexist.

It decides how technical boundaries become user workflows.

It decides what state survives navigation, refreshes, crashes and time.

Those are architecture decisions.

So maybe the interesting question for frontend engineers in 2026 is not:

"Which framework should we use?"

Or even:

"Should we use SSR or CSR?"

It is:

"Where does this decision belong?"

Does it belong in the URL?

The browser?

The client cache?

The server?

The API?

The design system?

The platform?

The team that owns the domain?

That's architecture.

And increasingly, frontend engineers are the people standing right in the middle of all of it.

The browser stopped being a window into the application.

It became one of the places where the application actually is.

I would genuinely like to know what you think: is the frontend really becoming the architecture, or are we simply giving an old problem a new name?

Best,

-- ł.