DEV Community: Ayush Maurya

Your Abstractions Are Lying to You | Every File You Create Is a Debt

Ayush Maurya — Sun, 03 May 2026 13:02:30 +0000

There's a book from 2018 called A Philosophy of Software Design. John Ousterhout wrote it. He spent his career building operating systems and distributed systems — Tcl, RAMCloud, Raft consensus. Not exactly frontend territory.

But somewhere in that book, he describes a failure mode that I've seen in more Angular codebases than I can count.

He calls it a shallow module.

What a Module Actually Is

Every abstraction you create — a service, a directive, a component — has two dimensions.

Interface: the surface exposed to the caller. How much does someone need to know to use this thing?

Implementation: the work hidden inside. How much complexity does it actually absorb?

A deep module has a narrow interface and a powerful implementation. You interact with it through a small surface, and it does a lot for you on the other side of that surface.

A shallow module has an interface that costs roughly as much as what it gives back. You have to know a lot to use it, and it doesn't hide much in return.

Ousterhout's canonical example is Unix file I/O. Five calls — open, read, write, close, seek — hide decades of complexity: file systems, permissions, buffering, disk abstraction, OS scheduling. You don't know any of that exists. You just call read. That's a deep module.

Now think about the last service you wrote.

The Problem Is Worse in Frontend

Backend engineers are often forced into depth because they're hiding genuinely complex things — databases, networks, distributed state, file systems. The complexity exists before they write a single line of abstraction.

Frontend developers are different. Nobody forced you to create that service. Nobody required that directive. You chose to add a layer. Which means the question of whether it justifies its existence is sharper — and the failure mode of shallow abstraction is far more common.

You can write an entire Angular application full of files that follow every convention, satisfy every linter, pass every code review — and still have an app where every abstraction is lying to you. Where every layer pretends to be hiding something but is really just renaming what's below it.

Let me show you what that looks like. And what the alternative looks like.

Services: Absorb Complexity or Don't Exist

Here's the shallow version. You've seen it. You've probably written it.

@Injectable({ providedIn: 'root' })
export class UserService {
  constructor(private http: HttpClient) {}

  getUser(id: string) {
    return this.http.get(`/api/users/${id}`);
  }

  updateUser(id: string, payload: Partial<User>) {
    return this.http.put(`/api/users/${id}`, payload);
  }
}

Looks clean. But now look at the component that uses it.

this.userService.getUser(id).subscribe({
  next: (user) => {
    this.user = user;
    this.loading = false;
  },
  error: (err) => {
    this.loading = false;
    this.error = 'Something went wrong';
    console.error(err);
  }
});

The component is managing loading state, error state, type casting, and retry logic. The service renamed http.get and nothing else. Every component that calls this service will write this same ceremony independently.

That's a shallow service. The interface costs you an import and a constructor injection. The implementation gives you almost nothing in return.

Now here's what a service looks like when it earns its existence.

@Injectable({ providedIn: 'root' })
export class UserService {
  private http = inject(HttpClient);
  private cache = new Map<string, User>();

  getUser(id: string) {
    // rxResource wraps the HTTP call and gives you .value(), .isLoading(),
    // and .error() as signals — no manual state management needed
    return rxResource({
      loader: () => {
        if (this.cache.has(id)) {
          return of(this.cache.get(id)!);
        }

        return this.http.get<User>(`/api/users/${id}`).pipe(
          retry(2),
          tap(user => this.cache.set(id, user))
        );
      },
      defaultValue: null,
    });
  }

  updateUser(id: string, payload: Partial<User>) {
    return rxResource({
      loader: () =>
        this.http.put<User>(`/api/users/${id}`, payload).pipe(
          tap(updated => this.cache.set(id, updated))
        ),
      defaultValue: null,
    });
  }
}

The caller — a standalone component, no async pipe, no subscription:

@Component({
  selector: 'app-user-profile',
  template: `
    @if (userResource.isLoading()) { <p>Loading...</p> }
    @if (userResource.error()) { <p>{{ normalizeError(userResource.error()) }}</p> }
    @if (userResource.value(); as user) {
      <h2>{{ user.name }}</h2>
      <p>{{ user.email }}</p>
    }
  `
})
export class UserProfileComponent {
  private userService = inject(UserService);
  private userId = inject(ActivatedRoute).snapshot.params['id'];

  userResource = this.userService.getUser(this.userId);

  normalizeError(err: unknown): string {
    if (err instanceof HttpErrorResponse) {
      if (err.status === 404) return 'User not found.';
      if (err.status === 403) return 'You don\'t have permission to do this.';
      if (err.status >= 500) return 'Server error. Please try again later.';
    }
    return 'An unexpected error occurred.';
  }
}

The component doesn't subscribe. Doesn't manage loading state. Doesn't catch errors manually. rxResource gives it .isLoading(), .value(), and .error() as signals — and Angular's new control flow (@if) reacts to them directly.

Notice that normalizeError lives in the component here — and that's intentional. The service absorbs infrastructure complexity: retries, caching, HTTP mechanics. Error presentation — what a 404 means to the user — is a UI concern. Each layer owns what belongs to it.

When the backend team changes their error format, you fix it in one place. Every component heals automatically.

That's what depth looks like. The interface is a single method call. The implementation absorbs retries, caching, Observable-to-Signal bridging, and loading state — none of which the caller ever sees.

Directives: Hide Coordination, Not Just Classes

The shallow version:

@Directive({ selector: '[appHighlight]' })
export class HighlightDirective {
  constructor(private el: ElementRef) {}

  @HostListener('mouseenter')
  onMouseEnter() { this.el.nativeElement.classList.add('highlighted'); }

  @HostListener('mouseleave')
  onMouseLeave() { this.el.nativeElement.classList.remove('highlighted'); }
}

A directive that toggles one class on hover. You could replace this with a CSS :hover rule. It exists as a file, needs to be declared, imported, and understood — for two lines of functionality. Shallow.

A directive becomes deep when it hides something the caller genuinely cannot do cheaply: event coordination, DOM lifecycle, cleanup contracts, timing logic. Here's a real example — click-outside detection.

@Directive({ selector: '[appClickOutside]', standalone: true })
export class ClickOutsideDirective {
  readonly clickOutside = output<void>();
  readonly enabled = input<boolean>(true);

  private el = inject(ElementRef);
  private renderer = inject(Renderer2);
  private destroyRef = inject(DestroyRef);

  constructor() {
    // setTimeout defers listener attachment past the click that opened this element
    const timer = setTimeout(() => {
      const unlisten = this.renderer.listen('document', 'click', (event: MouseEvent) => {
        if (!this.enabled()) return;
        const clickedInside = this.el.nativeElement.contains(event.target);
        if (!clickedInside) this.clickOutside.emit();
      });

      // DestroyRef replaces ngOnDestroy — cleanup is co-located with setup
      this.destroyRef.onDestroy(() => unlisten());
    });

    // Clean up the timer itself if directive is destroyed before it fires
    this.destroyRef.onDestroy(() => clearTimeout(timer));
  }
}

Usage:

<div class="dropdown" appClickOutside (clickOutside)="closeDropdown()">
  ...
</div>

The component writing this has no idea about:

The setTimeout trick that prevents the originating click from immediately closing the element it just opened
The fact that Renderer2.listen returns an unlisten function that must be called manually
The DestroyRef cleanup that prevents memory leaks and stale listeners — and that the timer itself needs clearing if the directive is destroyed before it fires
The contains() check that correctly handles clicks on child elements
The fact that enabled is a signal — this.enabled() — so it reads the latest value reactively inside the listener

Every component that needs click-outside behavior gets all of that for free. Without this directive, each one would reimplement it — and probably miss the setTimeout trick, skip the cleanup, or break on nested clicks.

Remove the directive and the caller gets substantially more complex. That's depth.

Smart/Dumb Components: The Split That Goes Wrong

The smart/dumb component pattern is one of the most useful ideas in frontend architecture. It's also one of the most commonly misapplied ones.

The failure mode: the smart component passes so many @Input() properties down that the dumb component becomes a post box — receiving state it didn't produce, relaying events it didn't originate, and hiding nothing.

// The dumb component that isn't doing anything dumb
@Component({ selector: 'app-user-profile-card', template: `...` })
export class UserProfileCardComponent {
  @Input() userId!: string;
  @Input() user: User | null = null;
  @Input() loading = false;
  @Input() error: string | null = null;
  @Input() isCurrentUser = false;
  @Input() canEdit = false;
  @Input() editMode = false;

  @Output() edit = new EventEmitter<void>();
  @Output() save = new EventEmitter<Partial<User>>();
  @Output() cancel = new EventEmitter<void>();
}

Seven inputs. Three outputs. What does this component own? Nothing. It's a template with plumbing. Remove it and paste the template into the smart component — nothing meaningful changes.

The editMode flag is the clearest symptom. That's pure UI state. It has nothing to do with routing, services, or the outside world. The smart component has no business owning it. But because it's passed down, the smart component now manages three methods — onEdit, onCancel, onSave — that exist purely to shuttle state back up from a component that should have owned it locally.

Here's what the split looks like when the depth is in the right place.

Smart component:

@Component({
  selector: 'app-user-profile-page',
  standalone: true,
  template: `
    <app-user-profile-card
      [userResource]="userResource"
      [permissions]="permissions()"
      (save)="onSave($event)"
    />
  `
})
export class UserProfilePageComponent {
  private route = inject(ActivatedRoute);
  private userService = inject(UserService);
  private authService = inject(AuthService);

  private userId = this.route.snapshot.params['id'];

  // rxResource gives the card .isLoading(), .value(), .error() as signals
  userResource = this.userService.getUser(this.userId);

  // permissions is a signal — no async pipe, no subscription
  permissions = this.authService.permissionsFor(this.userId);

  onSave(payload: Partial<User>) {
    this.userService.updateUser(this.userId, payload);
  }
}

Dumb component:

@Component({ selector: 'app-user-profile-card', standalone: true, template: `
  @if (userResource.isLoading()) { <p>Loading...</p> }
  @if (userResource.error()) { <p>Something went wrong.</p> }

  @if (userResource.value(); as user) {
    <h2>{{ user.name }}</h2>
    <p>{{ user.email }}</p>

    @if (permissions()?.canEdit && !editMode()) {
      <button (click)="editMode.set(true)">Edit</button>
    }

    @if (editMode()) {
      <app-user-edit-form
        [user]="user"
        (save)="handleSave($event)"
        (cancel)="editMode.set(false)"
      />
    }
  }
`})
export class UserProfileCardComponent {
  readonly userResource = input.required<ResourceRef<User>>();
  readonly permissions = input<{ isCurrentUser: boolean; canEdit: boolean } | null>(null);

  readonly save = output<Partial<User>>();

  // editMode is local signal state — the smart component never touches it
  editMode = signal(false);

  handleSave(payload: Partial<User>) {
    this.save.emit(payload);
    this.editMode.set(false);
  }
}

Seven inputs became two. Three outputs became one. editMode moved to where it belongs — inside the component whose job is to manage that interaction.

The dumb component got simpler at the interface but richer in behavior. It now owns its local state, manages its own transitions, and cleans up after itself. Remove it now and the smart component would have to absorb all of that. Which means it was actually hiding something.

The Test That Unifies All Three

Every time you create an abstraction, ask one question:

If I delete this, does the caller get meaningfully more complex?

If yes — the abstraction was earning its depth. Keep it.

If no — it was a layer without a reason. The complexity didn't get hidden. It got deferred upward, to be rediscovered by every caller, independently, forever.

This isn't about how many files you have or how well you follow conventions. A codebase can be perfectly structured and still full of abstractions that are lying about how much work they're doing.

Ousterhout wrote about this in the context of operating systems. But the failure mode is identical in a five-file Angular feature module. The scale is different. The pattern is the same.

A Note If You've Been Reading This Series

This post is part of an ongoing series called Don't Fight the Framework, Embrace It — about what it actually means to understand Angular at the level where you stop guessing and start knowing.

That posts covered the rendering engine, Ivy's locality principle, LView/TView internals, and how change detection actually works under the hood.

This one is different. It's not about Angular internals. It's about a design principle old enough to predate Angular by decades — and why it applies to your codebase more precisely than most Angular-specific advice does.

The internals tell you how the framework works. This tells you whether what you're building on top of it is worth building at all.

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().