DEV Community: Ayush Maurya

Designing Multi-View Angular UIs: Router Outlets, outletContext, and Stateful View Composition

Ayush Maurya — Fri, 12 Dec 2025 10:15:27 +0000

In the previous article, we looked at why Angular UIs begin to fall apart when the view logic is controlled with if and switch. Conditional rendering means visibility not the state, and once your UI needs deep links, reload presistance, or multiple simultaneous screens, then it becomes very difficult to scale.

In this article we will see how routing actually helps in all, architecture in practical.

Angular gives you below three powerfull tools.

Router Outlets
Named Outlets
Outlet Context

Combined, these turn Angular's router into a true view composition engine, capable of driving dashboards, tool panels, multi-pane editors, modals, overlays, and even app-within-app layouts.

Let's break it all down.

Router Outlets Are Independent Viewports

Most developers only use the primary outlet:

<router-outlet></router-outlet>

But Angular allows as many viewports as your UI needs:

<router-outlet></router-outlet> <!-- primary -->
<router-outlet name="sidebar"></router-outlet>
<router-outlet name="inspector"></router-outlet>

Each outlet is independent:

loads its own routed component
activates and deactivates separately
can lazy-load its own module
runs guards and resolvers on its own
has its own lifecycle (OnInit/OnDestroy)

This alone lets you architect UIs that feel like VS Code, Figma, or Jira — multi-panel applications, not single-screen pages.

Routing Into Specific Outlets

A route becomes tied to a viewport using the outlet property:

{
  path: 'filters',
  component: FiltersComponent,
  outlet: 'sidebar'
}

Navigation activates it:

this.router.navigate([{ outlets: { sidebar: ['filters'] }}]);

And Angular constructs URLs that encode whole layouts:

/dashboard(main:details//sidebar:filters//inspector:info)

Ugly? Yes.
Accurate representation of UI state? Absolutely.

It's the browser's built-in serialization of your app's layout.

Handling Multiple Outlets Through Routing

You can activate several outlets simultaneously:

this.router.navigate([
  '/workspace',
  {
    outlets: {
      primary:   ['overview'],
      sidebar:   ['filters'],
      inspector: ['info', 42]
    }
  }
]);

This one navigation call:

loads three components
initializes three route trees
sets up three separate lifecycles
completely represents the UI in the URL

Reload → same layout
Share → same layout
Back → outlet-level navigation
Forward → restore split views

Try building that with switch and flags.

outletContext — Per-Outlet Configuration

Sometimes the same component should behave differently depending on which outlet loaded it.

Example:
A UserListComponent rendered compact in a sidebar but fully detailed in the main viewport.

Create an outlet context:

<router-outlet name="sidebar" [outletContext]="{ mode: 'compact' }"></router-outlet>
<router-outlet name="main" [outletContext]="{ mode: 'full' }"></router-outlet>

Access it inside the routed component:

constructor(@Inject(ROUTER_OUTLET_CONTEXT) public ctx: any) {}

Now the same component behaves differently:

this.viewMode = this.ctx.mode;

This pattern replaces:

duplicated components
over-engineered route data
bloated services
messy input trees

It is per-viewport configuration, not global state.

Practical Use Cases for outletContext

1. Same Component, Different Behavior

Sidebar version vs main-panel version
Compact vs full mode
Readonly vs editable mode

2. Multi-pane comparison tools

Two outlets both load ReportComponent, each with different context:

<router-outlet name="left" [outletContext]="{ reportId: 10 }"></router-outlet>
<router-outlet name="right" [outletContext]="{ reportId: 20 }"></router-outlet>

3. View-level configuration that doesn't belong in URL params

UI mode
theme variant
collapsed/expanded state
feature flags

4. Independent dashboard panels with per-panel settings

Each panel's routed component gets its own configuration.

Outlets as a Pattern for Modals and Overlays

Modals are often implemented with *ngIf, making them:

invisible to routing
not restorable
not shareable
not navigable

Using a dedicated modal outlet:

<router-outlet name="modal"></router-outlet>

Routes:

{ path: 'confirm', component: ConfirmDialogComponent, outlet: 'modal' }

Open modal:

this.router.navigate([{ outlets: { modal: ['confirm'] } }]);

Close modal:

this.router.navigate([{ outlets: { modal: null } }]);

Now modals:

survive refresh
can be deep-linked
respect back/forward
can be tested as routes, not DOM state

This transforms UI behavior into application state, which is exactly where it belongs.

Design Guidance: When to Use What

Use the primary outlet when:

Your app has one main view region.
Content is page-like.
You don't need complex layouts.

Use named outlets when:

You have genuinely separate viewports.
Your UI needs multiple visible screens at once.
You're building a dashboard, editor, control panel, or tool.

Use outletContext when:

Each outlet needs its own configuration.
Behavior changes per viewport.
You don't want to pollute route params or services.

Use modals via outlets when:

You want back/forward navigation for dialogs.
You want deep-linkable or shareable modals.
You want clean UI lifecycles.

Avoid abusing routing as global state

Domain state belongs in services or stores.
View structure belongs in outlets.
outletContext is only for per-outlet customization.

Get this separation right, and your Angular application becomes both predictable and scalable.

Closing

Multi-outlet routing and outlet contexts let Angular behave like a stateful UI framework, not just a page router. Once you start viewing outlets as independent viewports, routing becomes a powerful layout and state engine.

In the next article, we'll dive into real examples and patterns for combining multiple outlets with outletContext to build dashboard-level applications with clean, maintainable architecture

A Framework-Level Look at Angular Views: Why Your Angular UI Falls Apart — and How Routing Fixes It

Ayush Maurya — Tue, 09 Dec 2025 11:19:42 +0000

Almost every Angular developer begins with *ngIf and *ngSwitch.

They're simple, intuitive, and they work… until they don't.

As your application grows, you start building heavier features — perhaps a dashboard with a side-panel inspector, or a split-screen comparison tool. You stitch pieces together with boolean flags, if checks, and switch clauses, and the UI slowly starts to feel fragile.

Then the requirements expand.

Users want customizable layouts.

They want their view state preserved.

They want the application to feel consistent, reloadable, and navigable.

Suddenly *ngIf and *ngSwitch stop feeling like the right tools.

How many components can you manage through a switch statement?
How do you synchronize state across multiple visible views in a dashboard?
How do you persist that state across reloads — or expose it in the URL?

Eventually, everything points to routing.

The Realization

When I started with Angular, routing felt messy and overcomplicated.

The thing we need to understand is that if or switch clause are for handling visibility of the component, not the state.

It's not a rigid rule, but by the end of this article, the distinction will feel obvious — and you'll understand why routing solve problems that conditionals simply can't.

Why Experienced Teams Reach for Router Outlets

Engineers reach for *ngIf because it's quick. Experienced teams reach for router outlets because they want the UI to behave like a real application, not a stitched-together widget board.

Conditional Rendering: What If/Switch Really Do

When you use *ngIf or ngSwitch, the UI state:

disappears on refresh
isn't linkable
isn't navigable via back/forward buttons
can't be restored
can't be shared through a URL
isn't synchronized across components

It's just ephemeral UI state.

Great for tiny things. Completely breaks down for structured UIs.

Routing: A URL as a Source of Truth

Routing gives you something conditionals never can: a stable, externalized state machine.

If your dashboard URL looks like:

/dashboard(main:details//left:filters//right:info)

The user can:

bookmark it
reload it
share it
open it in a new tab
use the back button
restore it after browser restart

Try doing that with:

showFilters = true

You can't.

This matters massively for:

admin dashboards
analytics tools
IDE-like applications
UIs with inspectors, drawers, secondary panels

Anywhere the layout itself matters, routing becomes mandatory.

Routing Makes UI Behavior Deterministic

If the UI is controlled through routes, state transitions look like this:

click → router.navigate() → new URL → new component loads

That chain gives you:

clean separation between view containers and components
testability (you can test routing instead of brittle DOM states)
predictable teardown + instantiate cycles

With *ngIf, components stick around until destroyed manually, and transitions become messy:

stale subscriptions
memory leaks
state leftover from previous view
components not re-instantiating properly

You've seen these bugs before — they're everywhere in legacy systems.

Routing Gives Independent Lifecycles Per Outlet

Multiple outlets each manage their own component lifecycle.

Example:

<router-outlet name="sidebar"></router-outlet>
<router-outlet name="details"></router-outlet>

Each one:

resolves guards
runs resolvers
loads modules lazily
handles deactivation/activation
destroys previous component cleanly

*ngIf can't replicate this without manually re-implementing the router.

Routing Lets Your UI Behave Like a Real Application

Does the user expect browser navigation to work?

If the UI has panels that open/close, details that load, tabs, filters, etc. —

Users expect:

Ctrl+L → paste URL → exact same state
Back → previous view
Forward → next view
Reload → same data, same layout

An *ngIf-driven UI can't honor these expectations.

The Real Reason People Avoid Routing

Most engineers don't understand auxiliary routes and named outlets.

The moment they learn them, they stop writing giant "HTML Franken-templates" with 15 nested *ngIf conditions.

Routing scales. *ngIf doesn't.

Clean Distinction to Remember

Use routing when the user's view should be restorable, shareable, navigable, or modular.
Use *ngIf when the UI state is unimportant, temporary, or purely local.

This is the same reason VSCode, Figma, Jira, GitHub, and all advanced UIs use router-like state machines — not ad-hoc conditionals.

At this point we've only seen why routing beats conditional rendering for complex UIs. In the next article, I'll go deeper into how to use Angular's outlet contexts and multi-outlet routing to treat the router as a true state-management layer for view composition.

Why JavaScript Never Adopted RxJS — It Solved a Problem JavaScript Never Had

Ayush Maurya — Sat, 08 Nov 2025 10:49:51 +0000

A junior developer once asked me:

“RxJS has been around for years, and so many developers use it.

Why hasn’t JavaScript just added something like it natively?”

To which I answered:

Reactivity is mainly a frontend problem. It’s about dealing with one user’s continuously changing state — events, inputs, UI updates. The backend, in contrast, deals in stateless operations. Each request stands alone. The state lives in databases, not in-memory streams. You don’t “observe” backend data changes directly — you react through messages, queues, or databases. Kafka or Redis Streams handle that domain, not RxJS.

That was my quick answer.

But the question was too interesting to leave there — so I dug deeper.

RxJS Has Proven Itself

RxJS has powered Angular’s reactivity model for over a decade.

It’s elegant in handling asynchronous data, widely respected, and deeply integrated in the frontend ecosystem.

Yet despite its longevity and popularity, Observables never became part of JavaScript itself.

The reason is simpler — and deeper — than most realize:

RxJS solved a problem JavaScript itself never really had.

What RxJS Actually Solves

RxJS is built on the concept of Observables — objects that represent streams of asynchronous data that can emit multiple values over time.

A Promise resolves once.
An Observable keeps emitting.

That makes it perfect for situations like:

Listening to continuous user input
Handling WebSocket data
Managing UI state that updates over time

It’s powerful and expressive — you can map, filter, debounce, combine, and merge asynchronous streams just like you manipulate arrays.

So, if it’s that powerful... why didn’t JavaScript itself embrace it?

JavaScript’s Evolution Is Conservative by Design

JavaScript’s core design philosophy is universality and minimalism.

The TC39 committee — the group that decides what gets added to the language — only standardizes features that:

Apply across all JavaScript environments (browser, server, embedded)
Don’t introduce unnecessary conceptual weight or complexity

RxJS breaks both of those principles.

Reactivity is mainly a frontend concern — about one user’s continuously changing state.

The backend’s problems are different: stateless operations, distributed events, and persistence handled by external systems.

The Observable Proposal That Never Landed

This wasn’t just theoretical — JavaScript almost adopted Observables.

In 2017, a TC39 proposal sought to introduce a minimal Observable type. It reached Stage 1, attracted attention… then quietly stalled.

Why It Failed

RxJS already provided a complete, mature ecosystem.
Observables are inherently complex — cold vs. hot, cancellation, multicasting, operator design, interop with Promises, etc.
Frameworks had already diverged:
- Angular leaned on RxJS
- React favored hooks and state
- Vue built its own reactivity model

The committee couldn’t justify making one paradigm official when the community was already solving the same problem in multiple, incompatible ways.

So JavaScript took the conservative route:

standardize the smallest useful abstraction — Promises — and let the ecosystem handle the rest.

Promises Were the Problem JavaScript Did Have

Promises fixed a universal issue: callback hell.

Before Promises, async code was deeply nested, hard to reason about, and full of error-handling traps. Every JS developer — frontend or backend — needed a cleaner model for single-result async work. Then async/await came, making async code look synchronous — elegant and readable. That was the problem JavaScript actually needed to solve: a single-value, eventual result.

Observables, on the other hand, were about ongoing reactivity — a smaller, domain-specific need mostly confined to the frontend world.

So Promises became part of the language; Observables remained a library concern.

Signals: The Simpler Next Step in Reactivity

But reactivity didn’t disappear — it evolved.

Signals are the next iteration: smaller, simpler, and more predictable.

Signals aren’t streams of events like Observables. They’re reactive state containers that automatically track dependencies and update when values change. You don’t subscribe to them; you just declare relationships.

Example

const count = signal(0);
const doubled = computed(() => count() * 2);

count.set(5);
console.log(doubled()); // 10 — automatically updated

No subscription. No operators. No teardown.
Just reactive state, tracked automatically.

Signals shift reactivity from streams of events to graphs of state — simpler, more deterministic, and easier to optimize.

Thanks for Reading ❤️

If this article helped you, share it and give it like.
It’ll hardly take a minute, but it really motivates me to write more deep-dive articles like this.

I don’t just write “how-tos” — I write about why things are designed the way they are,so you can master them inside-out.

Understanding Go's Context Package

Ayush Maurya — Thu, 02 Oct 2025 21:45:24 +0000

I still see many developers struggling with Go’s context package. It can be confusing not just for newcomers, but even for those who’ve been writing Go for a while.

I mostly work in frontend, and during my time with Node.js, I never encountered anything quite like Go’s context.

This guide will help you understand it better. By the end, you’ll know exactly what you’re doing — and why — whenever you use it.

Why Do We Need Context?

Instead of starting with what context is, let’s look at the problem it solves.

Imagine you need batteries for your remote control car, so you ask a friend to go buy them. But just as they leave, you find batteries in your drawer. Now you want your friend to stop and come back.

For this to work, your friend must be aware of the situation in your room.

In Go terms:

Your “room” is like the background context — the environment your operations run in.
Your friend’s awareness of whether to continue or stop the trip is like a cancelable context.

Another example: imagine a function that compresses an image. You don’t want to wait 20 seconds for it to finish. If it completes in 10 seconds, great; if not, you want the ability to cancel the operation.

This is exactly what Go’s context allows you to do: propagate deadlines, cancellations, and request-scoped values across your functions.

A Simple Example: Lucky Numbers

Let’s start simple. Here’s a function that just returns a lucky number:

package main

import (
    "fmt"
)

func main() {
    d, err := requestLuckyNumber()
    if err != nil {
        fmt.Println("Request failed")
        return
    }
    fmt.Println(d)
}

func requestLuckyNumber() (int, error) {
    luckyNumber := 666
    return luckyNumber, nil
}

Nothing fancy here — it always returns 666.

Now let’s turn this into a little game: we want the function to return the lucky number only if it completes within 500ms. If it takes longer, we cancel it and return an error.

This is where context comes in.

Creating a Context with Timeout

We can create a timeout context like this:

ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()

context.Background() is the root context. Think of it as your “room.”
WithTimeout creates a child context that automatically cancels after 500ms.
cancel is a function to manually cancel the context (cleanup resources, stop goroutines, etc.).
Always defer cancel() to avoid leaks.

Using Context in Your Function

Now let’s modify our function to respect this context:

func request(ctx context.Context) (int, error) {
    ch := make(chan int, 1)

    go func() {
        // Simulate some work
        time.Sleep(500 * time.Millisecond)
        ch <- 666
    }()

    for {
        select {
        case <-ctx.Done():
            return 0, ctx.Err() // context canceled or timed out
        case result := <-ch:
            return result, nil
        }
    }
}

What’s happening here:

We run the “work” in a goroutine.
The select statement listens for two cases:
- <-ctx.Done() → fires if the context is canceled or times out.
- result := <-ch → fires when the work completes.

If the work finishes on time, we get our lucky number. Otherwise, the function exits early with an error.

Putting It All Together

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 600*time.Millisecond)
    defer cancel()

    d, err := request(ctx)
    if err != nil {
        fmt.Println("Request failed:", err)
        return
    }

    fmt.Println("Lucky number is:", d)
}

Now your function respects the 600ms limit. If the task takes too long, it gracefully cancels.

Other Useful Context Functions

context.WithCancel → Manually cancel a context from another goroutine.
context.WithDeadline → Cancel automatically at a specific time.
context.WithValue → Pass request-scoped values down the call chain.

Example:

ctx := context.WithValue(context.Background(), "userID", 42)
user := ctx.Value("userID").(int)
fmt.Println(user) // 42

⚠️ Tip: Only use WithValue for request-scoped data, not for optional parameters.

Summary

context helps control long-running operations with cancellation and timeouts.
Always pass context explicitly to functions that may need it.
Use WithTimeout, WithCancel, and WithDeadline for control.
Avoid using WithValue for configuration — it’s meant only for request-scoped data.

By understanding context, you can write Go programs that are safer, cleaner, and more responsive — avoiding goroutine leaks and stuck operations.

💡 If you found this useful, leave a comment or share it. Feedback keeps me motivated to write more content like this!

I’m a Frontend Dev. Stop Forcing Me to Be a Full-Stack.

Ayush Maurya — Thu, 02 Oct 2025 21:08:25 +0000

This post is very different from my usual technical content — it’s raw and frustrated, based on my personal job-hunting experience. If you’re a frontend dev, you might relate.

For the last 2–3 months, I’ve been trying to switch jobs. And after dozens of interviews, I’m done pretending everything is okay.

So here’s my honest, frustrated take on what’s wrong with tech interviews — especially for frontend developers in India.

I’ve been in the industry for over 4 years. I’ve done the whole frontend–backend dance. Built apps, fixed bugs, fought with legacy code, dealt with design handovers that made no sense, and shipped things under pressure that somehow still worked.

But I love frontend. That’s what I breathe. I like building clean UI, smooth animations, and fast and responsive designs. I know how to make a button feel right.

But the interviewers?
They don’t care.

“You applied for Angular dev, but let me grill you on Kafka…”

Every other job post screams:

We’re hiring a frontend Angular developer.

And yet, the interviews are like:

“How would you optimize a MongoDB query?”
“Explain an event-driven system using Kafka.”
“Explain how you’d build microservices.”

Excuse me? Did I miss the part where this turned into a backend SDE-2 round?

No one’s asking:

How would you optimize FCP or LCP?
How do you handle memory leaks in Angular?
Can you build a Canvas animation from scratch?
But hey, sure, let’s test me on database indexing strategies. Because apparently, writing frontend isn’t “real development” unless you’re also knee-deep in SQL joins.

“Bro, you should know full stack.”

No.
I applied for frontend, and that’s what I want to do.

Not because I can’t write backend — I can. But because I don’t want to. I like the challenge of making things feel fast, look clean, and work across a million devices. I love sweating over that last frame drop on an animation. I enjoy figuring out why a layout breaks on an iPad Mini Gen 5.

But companies here?
They don’t want frontend devs.
They want backend devs who also happen to know HTML.

“Backend is harder, bro.”

Yeah? Then why does your blazing fast API still result in a UI that takes 4 seconds to update?

Have you ever debugged a performance issue caused by a bloated table component with 100 columns and an infinite scroll that crashes on Safari Mobile?
Have you ever spent hours shaving milliseconds off paint timings just so your app feels usable on a budget Android phone?

Backend is hard, sure.
But don’t pretend frontend is just “putting buttons on a page.”
Frontend is performance, responsiveness, accessibility, UX, and design — all tangled together with business logic, browser quirks, and user expectations.

“If you can’t do it, I’ll throw it in a cursor.”
I was debugging a UI animation bug. It was messy and took time. A senior dev (backend, obviously) said:

“If you can’t fix it, give it to me — I’ll just throw it in a cursor.”

Honestly?
Unless it’s some heavy backend logic, sure — I can tell the cursor to do some x-y calculation, maybe write an update query, and get it over with. That’s easy.

But how the hell do you tell a cursor about the animation playing in your head?

How do you explain easing curves, scroll acceleration, responsiveness across devices, or the GPU render pipeline… to a cursor?

This is exactly the problem — treating frontend like it’s something you can brute force with database logic.

Final Thought: Let Me Do What I’m Good At

I’m not asking for much.

If the JD says “Frontend Developer,” stop trying to test me like I’m applying for a backend-heavy full-stack role.
I’ll happily say “I don’t know” when you throw backend problems at me — not because I’m dumb, but because I’m not applying to solve those problems.

Let frontend devs be frontend devs.

Stop wasting our time.
Stop disrespecting the craft.
And maybe, just maybe, let us do the work we actually love.

Ayush Maurya
Frontend Engineer. Angular, React, WebGL, and way too much patience for interviews that don’t know what they’re hiring for.

How Browsers Parse and Render HTML: From Request to Paint

Ayush Maurya — Sun, 06 Jul 2025 18:14:04 +0000

This all started today when I was trying something like this:

const containerHeight = innerDivHeight.scrollHeight + 'px';
container.style.height = containerHeight;

const container2Height = innerDiv2Height.scrollHeight + 'px';
container2.style.height = containerHeight;

Yeah, not the best way to go about it.

Just out of curiosity, I started digging into how the browser handles such changes and realized that even small DOM mutations can trigger a reflow or repaint.

So, instead of doing it this way, you should ideally write:

const containerHeight = innerDivHeight.scrollHeight + 'px';
const container2Height = innerDiv2Height.scrollHeight + 'px';

container.style.height = containerHeight;
container2.style.height = container2Height;

How HTML Works in the Browser

It all begins when the browser requests the server for the HTML file. The moment it starts receiving the first byte, the browser doesn’t wait — it begins parsing immediately using a streaming parser.

Let’s break this process down.

1. Tokenization and DOM Construction

The browser starts by converting the raw HTML into tokens (e.g. div, h1, p, etc.). Each tag, along with its attributes and values, is turned into a token.

Once tokenized, the browser constructs the DOM (Document Object Model) — a tree-like structure representing the hierarchical relationships between elements.

That’s why when you use JavaScript to select multiple elements, you get a NodeList. That NodeList is a slice of the DOM that the browser built during this stage.

2. CSSOM & JavaScript Blocking

Now that the DOM is ready, the browser still hasn’t rendered anything visually yet.

CSSOM
The browser parses the CSS in a similar way — raw bytes → tokens → CSSOM (CSS Object Model). The CSSOM is a structured representation of all styling rules.

Important point:

CSS blocks HTML parsing.

When the parser encounters a link or style, it pauses HTML parsing until the CSS is loaded and parsed.

This happens because layout depends on style, and the browser can’t render elements accurately without knowing how they should look.

JavaScript
Same thing for JavaScript.

When the browser hits a <script> tag (especially one without async or defer, it pauses everything, downloads the script, executes it, and then resumes HTML parsing.

Why? Because JavaScript can manipulate the DOM. So, the browser has to wait to avoid building a tree that JS might change anyway.

Note: CSS is prioritized over JavaScript when both are blocking resources.

3. Render Tree Construction

At this point, the DOM and CSSOM exist independently — they don’t yet know about each other.

The browser engine combines them to build the Render Tree.

Render Tree = DOM (structure) + CSSOM (style)

It figures out what needs to be rendered and how — calculating layout, dimensions, positioning, margins, paddings, etc., using:

Box model
Flex/grid rules
Relationships in the DOM
This is the stage where the actual layout is determined.

4. Painting and Compositing

Now comes the painting phase — the browser draws actual pixels on your screen.

Text, colors, borders, shadows — everything is drawn layer by layer.
Each layer is rasterized into a bitmap.
These bitmaps are uploaded to the GPU as textures.
The GPU composites all textures into a single frame to display.

This phase is super sensitive — every style change or unoptimized animation can trigger repaints or reflows, which can hit performance.

The painting happens recursively — children are painted first, and then the parents.

Conclusion

All of this — DOM parsing, CSSOM creation, JS blocking, layout calculation, GPU compositing — happens just to render a simple HTML page.

Mind-blowing, right?

For a deeper dive, check out this video on YouTube:
https://www.youtube.com/watch?v=SmE4OwHztCc

If you liked this article, feel free to like and follow for more frontend deep dives.

Why Do We Need to Manage the State of an Application?

Ayush Maurya — Sat, 05 Jul 2025 21:15:27 +0000

A week ago, an interviewer asked me: Why do we need to manage state in a frontend application? Why can’t HTTP handle it for us?

There can be multiple answers to this, but the simplest one is:
HTTP is a stateless protocol.

What Does Stateless Mean?

Each HTTP request is independent. The server doesn’t know anything about previous requests.
It doesn’t know who is making the request — whether you’re the same user who made the previous one or not.

Why So? Can’t We Make HTTP Stateful?
Technically, we could. But HTTP was intentionally designed to be stateless.
It was made this way to ensure simplicity and scalability.

Why Exactly?
1. Scalability
The server doesn’t store session information between requests.
This makes it easy to load-balance requests across a pool of servers.

When your application grows, you no longer rely on just one server.
If HTTP were stateful, a request would always need to go back to the same server holding that user’s session/token, which limits scalability.

But because it’s stateless, any server can handle any request.
2. Simplicity
In a stateless protocol, each request is self-contained — it carries everything the server needs to understand and respond.

This means:

No need to track sessions or store user-specific context.
Every request must include all relevant data.
Example:

GET /user-profile Authorization: Bearer <token>
The server does:

Validates token
Fetches user info
Responds
No memory of this is retained after the response

3. Performance

Stateful systems usually need to keep track of:

User sessions
In-progress workflows
Auth states
Temp files or cached data
This consumes memory and resources.

But in stateless systems (like HTTP):

The server forgets everything after responding.
There’s no per-user memory cost, which is critical at web scale.

Imagine if a million users log in, and the server has to manage tokens or sessions for each. That’s a massive RAM overhead.

So, Where Does Frontend State Management Come In?

On the frontend, your application deals with dynamic data that changes over time and needs to persist across user interactions.

Without state management, your UI would become chaotic — you’d lose track of what to render and when.

Using a centralized or controlled state (like Signals, RxJS, NgRx, etc.) makes your app easier to debug and maintain.
You know that when state X changes, component Y re-renders.

Real-World Example:
Let’s say a user adds items to a shopping cart.

If you don’t store the cart count on the frontend, what do you do?
Ask the server every single time to get the updated count, even for just rendering the number on the cart icon?

Instead, you get the cart data once (on load) and store it on the frontend.
Efficient, fast, and with no unnecessary network calls.

But Are There Stateful Protocols?
Yes, some protocols are stateful, and for good reason.

WebSockets
SMTP (partially stateful)
FTP, and others.

WebSockets — One You See Often:

Starts as HTTP (stateless), then upgrades to a persistent, full-duplex connection.
The server remembers the connection and can push data to the client at any time.
Used in chat apps, games, stock tickers, and anything requiring real-time communication.

TL;DR:

HTTP is stateless by design — it helps with scalability, simplicity, and performance.
Because of that, managing state on the frontend becomes crucial to maintain a smooth, dynamic, and efficient user experience.

If you found this post helpful or learned something new, feel free to follow for more content like this. I regularly share insights from real-world dev experiences, especially around frontend architecture, performance, and those tricky interview moments we all face.

Angular’s ngDoCheck: The Powerful but Dangerous Lifecycle Hook

Ayush Maurya — Thu, 26 Jun 2025 19:35:10 +0000

ngDoCheck is underrated — but dangerous if misused.

This lifecycle hook runs every time Angular performs change detection, regardless of whether the @Input() properties have changed or not.

Since it gets called frequently, putting heavy logic inside ngDoCheck can make your app laggy or unresponsive. But in some scenarios, it's incredibly useful.

When to Use ngDoCheck

1. Detecting deep changes in Objects or Arrays

Angular performs a shallow comparison on @Input() properties. So, if an object or array is mutated, ngOnChanges() won’t fire.

What do most devs do here? They often work around it by cloning the array or object and reassigning it — or worse, serializing it with JSON.stringify() and parsing it back. Gross.

Instead, use ngDoCheck to manually detect changes in such cases.

2. Tracking internal state changes
ngDoCheck also triggers when any internal value of the component changes — not just @Input() bindings. This makes it useful for watching component-local state too.

When You Should Use ngDoCheck

Angular’s default change detection misses what you actually care about.
You’re dealing with mutable data, and ngOnChanges() isn’t firing.
You need fine-grained control over reactivity.

Real-World Example

Say you have a chat UI. The parent component pushes messages into an existing array, but doesn’t create a new array. Angular won’t detect this change.

@Component({
  selector: 'app-chat',
  template: `<ul><li *ngFor="let msg of messages">{{ msg }}</li></ul>`,
})
export class ChatComponent implements DoCheck {
  @Input() messages: string[] = [];
  private prevLength = 0;
  ngDoCheck() {
    if (this.messages.length !== this.prevLength) {
      console.log('New messages received');
      this.prevLength = this.messages.length;
    }
  }
}

This lets you detect new messages even if the array reference didn’t change.

ngDoCheck() + IterableDiffers / KeyValueDiffers
Angular also gives you tools for detecting changes in arrays or objects.

Example using IterableDiffers:

constructor(private differs: IterableDiffers) {}
private differ = this.differs.find([]).create();

ngDoCheck() {
  const changes = this.differ.diff(this.myArray);
  if (changes) {
    console.log('Array changed!');
  }
}

This is cleaner and avoids manual comparison logic.

When to Avoid ngDoCheck

You’re using immutable data (e.g., @Input() user is reassigned, not mutated) — just use ngOnChanges()
You only need to track a simple @Input() value
You’re worried about performance, and this isn’t absolutely necessary

As Angular’s documentation clearly states:

“Typically, you should not use both ngDoCheck and ngOnChanges to respond to changes on the same input.”

TL;DR

Use ngDoCheck only when:

You’re working with mutable data
Angular’s change detection isn’t enough
You know what you’re doing and you really need it
Otherwise, stick with ngOnChanges().