Forem: Mayuri Jha

The Frontend works.. until it doesn't

Mayuri Jha — Mon, 23 Mar 2026 06:12:08 +0000

Your UI looks Perfect… Until it meets real users

What Real-World Data Taught Me About Building Resilient Frontends

Design files are clean.
Components are reusable.
Everything aligns perfectly.

And still — things break.

Not because the code is bad.
Not because the implementation is careless.

But because the system was built around assumptions that don’t hold in production.

A Quick Context

These scenarios come from issues I’ve recently encountered while building UI.

The implementations were solid:

components were well-structured
states were handled
layouts matched design

Everything worked — for the expected data and expected environment.

But production doesn’t operate on expectations.

It operates on variability.

A Pattern I Keep Noticing

Across multiple UI issues, one pattern kept repeating:

Happy Path Bias

We design and build for:

expected data
expected layouts
expected timing

But real systems behave differently:

data is incomplete or malformed
layouts are stressed beyond design assumptions
rendering is asynchronous and unpredictable

Most frontend bugs don’t come from logic errors.

They come from the gap between ideal conditions and real-world variability.

Scenario 1: Product Title Overflow

Assumption

Titles will fit within design constraints

Reality

Content expands beyond expected bounds and starts influencing layout.

Failure Mode

Layout shifts
Adjacent components lose alignment
Vertical rhythm breaks

Fix

.product-title {
  display: -webkit-box;
  -webkit-line-clamp: 2;
  -webkit-box-orient: vertical;
  overflow: hidden;
}

Insight

This isn’t just about truncation.

It’s about containing variability so it doesn’t propagate through the layout.

Scenario 2: “+X More” — A Simple Pattern That Isn’t

Assumption

Show first 3 items, collapse the rest

Reality

Items vary in length
Layout wraps inconsistently
Edge cases emerge at boundaries

Failure Mode

Visual inconsistency
Logic tied to layout behavior
Unpredictable rendering

Fix

maxVisible = 3;

get visibleItems() {
  return this.isExpanded ? this.items : this.items.slice(0, this.maxVisible);
}

get hiddenCount() {
  return Math.max(0, this.items.length - this.maxVisible);
}

Insight

This shifts the system from:

layout-driven behavior

to:

deterministic state-driven behavior

Scenario 3: Skeleton Loaders That Break UX

Assumption

Any loading shimmer improves UX

Reality

If skeletons don’t match structure:

layout shifts when content loads
perceived performance degrades

Fix

.skeleton-title {
  height: 20px;
  width: 80%;
}

.skeleton-chip {
  height: 32px;
  width: 90px;
  border-radius: 16px;
}

Insight

Skeletons are not placeholders.

They are contracts for layout stability.

Scenario 4: ExpressionChangedAfterItHasBeenCheckedError

Assumption

UI updates naturally when data arrives

Reality

Angular enforces a strict rendering contract.

When violated, it exposes instability.

Failure Mode

ExpressionChangedAfterItHasBeenCheckedError

Fix

<div *ngIf="product">
  {{ product.name }}
</div>

{{ product$ | async }}

Insight

This is not just an Angular quirk.

It highlights a deeper principle:

Rendering must be predictable within a given cycle

Scenario 5: Resize Logic That Lies

Assumption

Screen size determines layout

Reality

Viewport ≠ device size

browser not maximized
dev tools open
split-screen usage

Fix

@HostListener('window:resize')
onResize() {
  this.isCompact = window.innerWidth < 1280;
}

Insight

Responsive systems should react to:

available space, not theoretical capacity

Scenario 6: Missing or Null Data

Assumption

API contracts are reliable

Reality

Data is often:

incomplete
null
inconsistent

Fix

{{ product?.name || '—' }}

Insight

Frontend is not just a rendering layer.

It is a resilience layer over imperfect systems.

Scenario 7: Button Alignment Drift

Assumption

Buttons will naturally stay aligned regardless of content

Reality

Content is not uniform.

Some cards have more text
Some have shorter descriptions
Heights vary dynamically

And suddenly:

👉 Buttons no longer align across cards

❌ What breaks

Inconsistent vertical alignment of CTAs
Poor scannability across items
Visual hierarchy feels off

✅ Fix

The solution is not about the button itself — it’s about the layout structure.

HTML

<div class="card">
  <div class="content">
    <!-- dynamic content -->
  </div>

  <div class="actions">
    <button>Add to Cart</button>
  </div>
</div>

CSS

.card {
  display: flex;
  flex-direction: column;
  height: 100%;
}

.actions {
  margin-top: auto;
}

.actions button {
  width: 100%;
  height: 44px;
}

💡 Insight

This ensures:

Content takes natural space
Actions are always pushed to the bottom
All buttons align consistently across cards

🧠 Deeper Principle

This is not just a styling fix.

It’s about decoupling layout stability from content variability.

Instead of letting content dictate layout:

We design layouts that remain stable despite content differences

Scenario 8: Async + Partial Rendering

Assumption

Data arrives as a complete unit

Reality

Rendering is incremental.

Fix

<div *ngIf="product; else loading">
  <!-- content -->
</div>

<ng-template #loading>
  <!-- skeleton -->
</ng-template>

Insight

UI should be designed as a set of states:

loading
partial
complete

Not a single static snapshot.

What This Really Points To

All of these scenarios are symptoms of the same underlying issue:

We design systems around ideal inputs, but run them in non-ideal environments.

A Shift in Thinking

Instead of asking:

“Does this work?”

A more useful question is:

“What happens when assumptions fail?”

Principles I Now Default To

Treat all external data as unreliable
Design for extremes, not averages
Prefer deterministic rendering over implicit behavior
Build UI as a system of states, not static screens
Contain variability instead of letting it propagate

Final Thought

Frontend engineering was never just about building interfaces.

But that realisation doesn’t come all at once — it builds gradually, through real-world scenarios and edge cases.

A significant amount of analytical and future-proof thinking goes into frontend systems. When engineered well, they don’t just render data — they absorb inconsistencies, handle unpredictability, and even mask underlying data flaws.

And this is just the surface.

There are countless such scenarios, many of which only emerge after long hours of building, debugging, and reflecting on how systems behave under real-world conditions.

Because in production:

Variability is the only constant.

These observations come from recent hands-on work where well-built components still failed under real-world conditions — not due to lack of effort, but due to assumptions that didn’t scale beyond the happy path.

Are We Over-Engineering Frontend Applications?

Mayuri Jha — Thu, 12 Mar 2026 11:51:54 +0000

Frontend development didn’t become complex overnight.

A decade ago, building a web interface mostly meant writing:

HTML
CSS
JavaScript

As applications grew more interactive, frameworks emerged to structure UI logic and improve maintainability.

Then came build tooling like Webpack to manage modules and optimize assets. Over time, frameworks began bundling these tools into their own ecosystems.

As applications continued to scale, additional layers followed:

routing libraries
state management tools
testing frameworks
server-side rendering
CI/CD pipelines and automated deployments

A visual of Frontend stack evolution below:

Each addition solved a real problem.

But together, they also raise an important question:

Have we slowly built a stack that is more complex than most applications actually need?

Sometimes all of this is used to build something surprisingly simple.

A dashboard with a few forms and API calls.

So the question becomes:

Are we solving real problems, or are we adding complexity because the ecosystem encourages it?

What Over-Engineering Looks Like in Modern Frontend

1. Complex State Management for Simple State

Consider this example.

We introduce:

Redux / NgRx
actions
reducers
selectors
middleware

Just to manage something like:

isSidebarOpen = true;

Modern frameworks already provide simpler solutions:

Angular Signals
React useState
lightweight stores like Zustand

Yet teams sometimes default to heavy architectures by habit, not necessity.

2. Micro-Frontends for Apps That Don’t Need Them

Micro-frontends are incredibly powerful for:

very large organizations
multiple independent teams
separate deployment pipelines

But they sometimes appear in projects with:

4–5 developers
a single product
a handful of pages

The result?

duplicated dependencies
complicated builds
deployment headaches

All for a problem that never existed.

3. Abstraction Layers Everywhere

Many frontend architectures end up looking like this:

Component
↓
Container
↓
Facade
↓
Service
↓
Adapter
↓
API Client

All of that… for a simple API request.

Abstractions are useful when they hide complexity.

But when they create complexity, they become a burden.

4. Framework Churn

Frontend development evolves incredibly fast.

Just look at the past decade and this is not all:

→ jQuery
→ AngularJS
→ React
→ Redux
→ Hooks
→ Server Components
→ Signals

Every few years, developers reconsider how applications should be structured.

Sometimes these changes genuinely improve developer experience.

Other times, they introduce new patterns that solve problems many apps never had.

Why This Happens

Over-engineering isn’t usually intentional.

It often emerges from good intentions.

1. Designing for Problems That Might Never Exist

Teams sometimes build systems designed for future scale:

“What if we have 20 teams working on this later?”

So the project starts with:

micro-frontends
distributed architectures
complex state systems

But many applications never reach that scale.

2. Copying Big Tech Architectures

Many articles describe how companies like Netflix or Google structure their frontend systems.

But these companies operate at massive scale.

Their architecture solves problems that most teams will never encounter.

Adopting those patterns prematurely can create unnecessary complexity.

3. The Tooling Ecosystem

Frontend development has an enormous ecosystem.

New tools appear constantly, each solving a specific problem.

But combining many of them can lead to something like:

framework
+ state library
+ router
+ data fetching library
+ meta framework
+ build tool

Suddenly the stack becomes harder to understand than the application itself.

When Complexity Is Actually Necessary

Not all complexity is bad.

Large applications genuinely benefit from structured architecture.

Examples include:

enterprise SaaS platforms
banking systems
large admin dashboards
multi-team platforms

In these cases:

strong architecture
predictable patterns
structured state management

can make systems easier to maintain over time.

A Better Approach: Progressive Complexity

Instead of starting complex, many teams now adopt progressive architecture.

Start simple:

Components
↓
Local state
↓
Simple services

As the application grows, evolve gradually:

State management
↓
Shared architecture
↓
Advanced patterns

This avoids premature optimization while still allowing systems to scale when necessary.

The Hidden Cost of Over-Engineering

Over-engineering affects more than just code.

It can lead to:

slower development
harder onboarding
steeper learning curves
increased maintenance cost

In many cases, simplicity improves long-term maintainability.

A Useful Rule of Thumb

Before adding a new tool or architectural pattern, ask three questions:

What problem does this solve today?
Could the framework already handle this?
Would the system break if we stayed simpler?

If the answers aren’t clear, the added complexity may not be justified.

Final Thought

Modern frontend development is incredibly powerful.

But sometimes the most valuable engineering skill is restraint.

Not every application needs a complex architecture.

Sometimes the best solution is simply:

Build the simplest thing that works — and evolve it when reality demands it.

Let’s Talk

Have you ever worked on a frontend project that felt over-engineered?
What architectural decision caused the most unnecessary complexity?
Where do you think the balance between simplicity and scalability lies?

RxJS Subjects in the Angular Signals Era: Obsolete or Still Powerful?

Mayuri Jha — Tue, 10 Mar 2026 15:48:14 +0000

For years, Angular developers lived in a world powered by RxJS.

Streams, subscriptions, operators, Subjects — if you wanted reactive behavior in Angular, RxJS was the way.

Then Angular introduced Signals, a new reactivity model that promised something developers had been craving:

Simpler state management with less boilerplate.

Suddenly, many Angular developers began asking:

Do we still need RxJS Subjects?
Are Signals replacing RxJS?
Should we rewrite everything?

Before we panic-delete our Subject imports, let's understand what actually changed.

A Quick Mental Model

Think of it like this:

Signals are like a spreadsheet cell.

When a value changes, everything depending on it updates automatically.

RxJS is like a pipeline of events.

Data flows through operators, transformations, and async processes.

Both are reactive — but they solve different problems.

The Old Angular Pattern: RxJS Everywhere

Before Signals, developers often used BehaviorSubject even for simple component state.

Example:

private countSubject = new BehaviorSubject<number>(0);
count$ = this.countSubject.asObservable();

increment() {
  this.countSubject.next(this.countSubject.value + 1);
}

Template:

{{ count$ | async }}

For beginners, this raised questions like:

Why do I need BehaviorSubject?
Why asObservable()?
Why the async pipe?

A lot of code… for something as simple as a counter.

The Signals Way

Now the same example becomes:

count = signal(0);

increment() {
  this.count.update(v => v + 1);
}

Template:

{{ count() }}

That's it.

No subscriptions.
No async pipe.
No Subject.

This is where Signals shine.

Where Signals Truly Replace RxJS Subjects

Signals are fantastic for application state.

1. Component State

Instead of:

loading$ = new BehaviorSubject(false);

You can simply write:

loading = signal(false);

2. Derived State

Previously:

total$ = combineLatest([price$, quantity$]).pipe(
  map(([p, q]) => p * q)
);

With Signals:

total = computed(() => price() * quantity());

This reads almost like plain English.

3. UI Reactivity

Signals integrate directly with Angular change detection.

Update the signal → UI updates automatically.

No subscriptions needed.

But Signals Don't Replace Everything

Here's where beginners often misunderstand.

Signals manage state.
RxJS manages streams.

Those are different things.

Where RxJS Subjects Are Still the Better Choice

1. Event Streams

Imagine a chat application receiving messages.

messages$ = new Subject<Message>();

socket.onmessage = msg => {
  this.messages$.next(msg);
};

This is a stream of events, not a single state value.

Signals are not designed for this pattern.

2. Complex Async Workflows

Consider a search box.

You want to:

debounce typing
cancel previous requests
fetch new results

RxJS handles this beautifully:

search$
  .pipe(
    debounceTime(300),
    switchMap(query => this.http.get(`/api?q=${query}`))
  )
  .subscribe();

Signals do not provide operators like:

debounce
switchMap
retry
merge streams

That is RxJS territory.

3. WebSockets & Real-Time Data

Live data streams fit RxJS naturally.

Examples include:

stock price feeds
live chat
multiplayer game updates

Signals are state holders, not event streams.

The Best Approach: Use Both

The Angular team never intended Signals to replace RxJS.

Instead, they built tools to connect them together.

Observable → Signal

users = toSignal(this.http.get<User[]>('/api/users'));

Now your template can simply use:

{{ users()?.length }}

Signal → Observable

user$ = toObservable(userSignal);

Useful when integrating with RxJS pipelines.

A Practical Architecture

Modern Angular apps often follow this pattern:

RxJS handles data flow.

Signals handle UI state.

When to Use Signals

Use Signals when dealing with:

component state
UI state
derived values
reactive templates
replacing BehaviorSubject in components

When to Use RxJS Subjects

Use Subjects when dealing with:

event streams
async workflows
WebSockets
complex operator chains
cancellation logic

My Take

Angular development is evolving toward something simpler:

Less boilerplate
Clearer reactivity
Better separation between state and streams

In many cases, Signals can replace BehaviorSubject when managing simple component or service state.

However, RxJS remains incredibly powerful for:

asynchronous streams
event pipelines
complex reactive workflows

Signals didn't replace RxJS.

They just gave Angular developers the right tool for the right job.