DEV Community: Phaneendra Kanduri

Material Design Principles Are Correct. Implementing Them Will Break You.

Phaneendra Kanduri — Sat, 18 Apr 2026 12:11:02 +0000

Long read. Written from nine years of implementation experience, not the spec.

Preface

I believe Material Design is correct. Not partially correct -- correct in its core philosophy about how interfaces should behave under load, under interaction, under uncertainty. I follow new versions closely. I implement what I can, whenever I can. I use a Pixel phone specifically because the software is built on these principles, and without that, I would genuinely prefer not using a smartphone at all.

That conviction is also what makes me honest about the cost. I have lived on both sides of it -- the belief in the philosophy, and the two-week sprint that nearly broke me trying to apply it to a page with 12 components and 7 API calls six years into a codebase. The industry does not talk honestly about that gap. This article does.

Why I Use a Pixel Phone

I use a Pixel phone. Not because of the camera. Not because of the price. Because the software is built on Material principles, and without that, I would genuinely prefer not using a smartphone at all.

That is not hyperbole. I have used enough software to know what it feels like when a product is built by people who have internalized a philosophy versus people who have implemented a component library. The difference is not subtle. It is the difference between a product that feels like it understands you and one that feels like it is tolerating you.

Google proves this at scale. So did Microsoft -- once, with Windows Phone and Windows 7. Both products were built by teams that had a coherent philosophy about how software should behave, and both felt smooth in a way that had nothing to do with hardware specs or engineering heroics. It was ideology, made executable.

Windows Phone was killed. Not because the UX was bad -- the UX was excellent. It was killed for market and ecosystem reasons that had nothing to do with software quality. That is important. Good philosophy does not guarantee market success. But its absence guarantees UX debt. And that debt compounds silently until it becomes someone's emergency sprint.

This article is about what that sprint actually costs.

Material Is Not the Only Path. It Is One of the Most Correct Ones.

Before I go further: I am not claiming Material Design is the only valid design philosophy. I have used Azure Dashboard circa 2017. I have used WordPress. Both are smooth, both handle data-heavy interfaces competently, and neither follows Material principles as rigorously as Google's own products do.

There are other coherent philosophies. Apple's HIG is one. Fluent Design, when Microsoft actually commits to it, is another. What these share with Material is not visual style -- it is the existence of a philosophy at all. A set of answers to questions like: what happens when data is loading? What happens when an element appears? What happens when the user scrolls and content shifts? How does the interface communicate uncertainty?

Products that answer these questions consistently feel smooth. Products that don't -- regardless of how polished the visual design is -- feel unreliable.

I have used Navan. I have used insurance platforms that are clearly well-funded and well-designed at the visual layer. They are frustrating. Not broken. Frustrating. Because the answers to those questions are inconsistent, and inconsistency at interaction level is something users feel even when they cannot name it.

Material Design's contribution is that it answers these questions rigorously, in writing, with rationale. That is rare. That is valuable. And that is exactly why implementing it properly is one of the hardest things you can do in frontend engineering.

The Problem Nobody Prices In

Enterprise SaaS applications are not simple. The page I was working on had roughly 12 components, 7 API calls pulling from different data sources, a sticky table header mid-page, and a popup that triggered yet another API call. Each component mounted independently. Each API call resolved at its own time.

In Angular, the default behavior is straightforward: data arrives, you assign it to a variable, Angular renders it. Clean. Simple. Completely at odds with Material principles.

What actually happens on screen: components pop in one by one. Heights shift. The sticky header jumps. Scroll position drifts. A popup appears without transition. A button materializes where there was nothing.

Users tolerate this. They have been trained to tolerate this. That tolerance is not a design success -- it is a UX debt that accumulates silently until someone files a ticket that says "the page feels janky."

That ticket is how this sprint started.

What "No Flickering" Actually Requires

The naive fix is a spinner. Throw a loader on the page, hide everything, show everything when done. Problem solved.

Except it is not solved, because nested components have their own async lifecycles, a whole-screen loader means users wait longer in perceived time even if actual load time is identical, and when the loader disappears and 12 components render simultaneously, you still get layout shift -- just deferred by one frame.

Material's actual answer is progressive disclosure: show structure first, then fill it. Reserve space before content lands. Coordinate fade-ins. No element should appear without the space already being reserved for it.

Angular does not give you this out of the box. Material's component library, at the time, did not have a skeleton loader. So I built the coordination layer myself.

Every API call got wrapped -- not just for loading state tracking, but for orchestration. The page had a single loading gate: nothing fades in until the critical path calls resolve. Secondary data sources fill in progressively after. The whole-screen loader exists only for the first render. After that, inline loaders handle async state at the component level.

Here is a simplified version of the orchestration wrapper:

// loading-orchestrator.service.ts
@Injectable({ providedIn: 'root' })
export class LoadingOrchestratorService {
  private criticalSources = new Set<string>();
  private resolvedSources = new Set<string>();
  private criticalResolved$ = new BehaviorSubject<boolean>(false);

  registerCritical(sourceId: string) {
    this.criticalSources.add(sourceId);
  }

  resolve(sourceId: string) {
    this.resolvedSources.add(sourceId);
    const allResolved = [...this.criticalSources]
      .every(id => this.resolvedSources.has(id));
    if (allResolved) {
      this.criticalResolved$.next(true);
    }
  }

  isCriticalResolved$(): Observable<boolean> {
    return this.criticalResolved$.asObservable();
  }
}

// page.component.ts
ngOnInit() {
  this.orchestrator.registerCritical('job-details');
  this.orchestrator.registerCritical('candidates');

  this.orchestrator.isCriticalResolved$()
    .pipe(filter(Boolean), take(1))
    .subscribe(() => this.pageVisible = true);

  this.jobService.getDetails(this.jobId).subscribe(data => {
    this.jobDetails = data;
    this.orchestrator.resolve('job-details');
  });

  this.candidateService.getList(this.jobId).subscribe(data => {
    this.candidates = data;
    this.orchestrator.resolve('candidates');
  });

  // Secondary -- does not block page fade-in
  this.analyticsService.getSummary(this.jobId).subscribe(data => {
    this.analytics = data;
  });
}

<!-- page.component.html -->
<div class="page-wrap" [class.visible]="pageVisible">
  <app-job-details [data]="jobDetails" />
  <app-candidates-table [data]="candidates" />
  <app-analytics [data]="analytics" />
</div>

The difficult part is nested components. When a parent is waiting, its children need to know to hold their render. When a parent resolves, children need to cascade in a coordinated way, not fire independently. This is not complex logic -- it is tedious, deliberate, component-by-component discipline. There is no shortcut.

The Scroll Flicker Problem

This is the one that took a week just to articulate.

The layout was: a fixed header at the top, a job details section taking roughly 40% of the page, a candidates table with its own sticky header taking 60%, and a footer. On scroll, the job details section collapsed -- driven by a JS scroll listener -- and the table expanded to fill the space. The problem: the collapse happened via a height snap, which opened a void in the layout, and the sticky table header recalculated its position against the new DOM in a single frame. The user saw it jump.

The animation below shows exactly what this looked like. Left side: without the fix. Right side: with it.

Left: sticky header jumps as layout void opens. Right: margin compensation absorbs the collapse -- no jump.

The fix is not a CSS trick. It is a discipline problem.

The scroll listener had to drive two things simultaneously: the job section collapsing, and the table's margin-top reducing by exactly the same delta. The margin absorbs the void before it opens. No reflow, no jump. The table header never moves relative to the viewport because the space it occupies never changes.

// scroll-coordinator.ts
const JOB_FULL_HEIGHT = 130;
const JOB_MIN_HEIGHT = 20;

@HostListener('window:scroll')
onScroll() {
  const scrollY = window.scrollY;
  const collapseStart = 80;
  const collapseEnd = 200;

  if (scrollY <= collapseStart) {
    this.jobHeight = JOB_FULL_HEIGHT;
    this.tableMarginTop = 0;
    return;
  }

  if (scrollY >= collapseEnd) {
    this.jobHeight = JOB_MIN_HEIGHT;
    this.tableMarginTop = 0;
    return;
  }

  const progress = (scrollY - collapseStart) / (collapseEnd - collapseStart);
  const delta = (JOB_FULL_HEIGHT - JOB_MIN_HEIGHT) * progress;

  this.jobHeight = JOB_FULL_HEIGHT - delta;
  // Margin grows as job shrinks -- table never sees a void
  this.tableMarginTop = delta;
}

The key line is this.tableMarginTop = delta. As the job section gives up height, the table gains margin by exactly the same amount. The two cancel out. From the table's perspective -- and from the user's -- nothing moved.

This sounds straightforward. Across 12 generic components with different data sources, built by different people at different times, it is not straightforward. You are retrofitting a spatial contract onto a codebase that never had one. Neither the job component nor the table component knows about each other. The page-level orchestration has to know the collapse delta and drive both simultaneously from a single scroll handler. Any timing gap between the two produces a visible jump.

The articulation took one week. This was pre-AI era. Going through the codebase, reasoning about each component's height behavior, mapping the dependency graph of API calls to visual state -- all of it manual, all of it requiring a mental model rebuilt from scratch.

The implementation took another week. The demo passed unanimously. Nothing was compromised.

That is the cost of doing it right, once, on one page, six years into a codebase.

Why It Cannot Be Retrofitted at Scale

We had approximately 500 components at this point in the product.

Applying this discipline across all of them is not a project. It is a rewrite with a different name. Each component would need its height contract audited. Each API call would need to be pulled into the orchestration layer. Every place where Angular's default change detection just assigns and renders would need to be rethought.

Some of it is not feasible at all. Components built with implicit height assumptions -- where content drives layout -- cannot simply be given explicit dimensions without redesigning the content model. The design team would need to be involved. The product team would need to sign off on the visual changes. Timelines expand immediately.

This is not a failure of will. It is geometry. The later you implement Material principles, the more surface area they touch, and the more of the product you have to rebuild to support them.

The ROI argument is real: users tolerate flickering. They have low expectations, especially in enterprise software where the alternative is a spreadsheet. For many products, especially at early stage, accepting that debt is the correct business decision.

But the debt does not stay flat. It grows with the codebase. And when the ticket finally arrives -- when a user or a stakeholder names it -- the fix is no longer a sprint. It is a quarter, if you are lucky, or a permanent compromise if you are not.

It Is Not About Code. It Is About How You Approach.

Google products are not smooth because Google engineers are better at writing JavaScript. They are smooth because the people who wrote the philosophy are embedded in the culture of the people building the product. The spec is not a reference document -- it is a shared mental model. When an engineer at Google makes a decision about loading state, they are not consulting a checklist. They are operating from an internalized answer to "what does the user know right now, and what should the interface tell them?"

That is what Microsoft had with Windows Phone. Not a better rendering engine. A coherent answer to that question, applied consistently across the product.

That coherence is what most teams are missing. Not skill. Not resources. Ideology -- and the organizational commitment to treat it as non-negotiable from day one.

When designers spec a transition, they are not speccing an animation. They are speccing a contract between data state and visual state. When a PM approves a loading state, they are not approving a spinner. They are approving the engineering time to coordinate async data across a component tree so that nothing renders before its space is reserved.

These are not implementation details. They are architectural decisions. And they need to be made before the first business component is written, not after the first complaint ticket is filed.

The Practical Conclusion

If you are starting a new product: establish the spatial and loading contract in your component architecture before you write business logic. Decide how heights are handled. Decide how API orchestration works. Decide what progressive disclosure looks like in your framework. Make it boring infrastructure now, so it is not heroic effort later.

If you are in an existing codebase: triage ruthlessly. Pick the highest-traffic, highest-complaint flows. Do the sprint. Document the contract. Use it as the template for new components going forward. Do not attempt to retrofit everything -- you will fail and the team will lose confidence in the approach.

Material is not aspirational. It is correct. The question is only when you pay for it -- at the beginning, when it is cheap, or later, when it costs everything.

Windows Phone proved you can build something philosophically excellent and still lose the market. That is a business problem. What it also proved is that philosophy-first software feels different in your hands. Users know. They may not be able to name it. But they know.

Build accordingly.

I work on frontend architecture, performance engineering, and large-scale migrations. More at dev.to/9thquadrant.

How I Stumbled Into Cloudflare Before It Took Over the Internet (2017)

Phaneendra Kanduri — Sun, 01 Mar 2026 08:47:15 +0000

The problem: WordPress site loading in ~10s. No git. No control. Just pain.

I tried the classic frontend interview answer for website optimization:

Moved external JS to end of body
Moved external CSS to head
Photoshopped images down to reasonable sizes

Result: 10s → 9s. Not a win.

I had no access to WordPress's default JS/CSS bundles. Database queries ran on every page load. I was stuck.

Desperation research

I needed to understand how websites actually load, not just frontend theory. But the full network layer, browser rendering pipeline, and WordPress's request-response cycle.

StackOverflow felt too high-stakes for what I thought was a basic question. Google and WordPress plugin repositories were my starting point.

Most WordPress developers reach for a plugin first. I did too. None of them solved the problem.

Then I found the term: CDN.

During this research, I also discovered Automattic, the company behind WordPress. I have a habit of checking parent companies ever since I learned Alphabet owns Google. Finding Automattic made me realize for the first time: there are companies building infrastructure that runs the internet at scale.

Enter The Cloudflare

CDN research surfaced two main options: Akamai and Cloudflare. Cloudflare's free tier and DNS-level integration made it the obvious choice for a small company with no DevOps budget.

I researched DNS configuration, got approval from my manager for a trial run, changed the DNS records, and waited 24 hours for propagation.

Result: 10s → 0.9s.

The client emailed us unprompted: "Website is really fast now. Only the chatbot is slow."

The chatbot had a setTimeout(2000) to let the page load first. I removed it immediately.

It felt like I'd been trying to drain a swimming pool with a bucket until I found the pump.

What stuck with me

That 10s → 0.9s improvement taught me that infrastructure solves problems code optimization alone can't touch. It's why I now evaluate CDN strategy, edge caching, and origin offloading as first-order concerns in any performance audit, not afterthoughts.

Key takeaways:

CDNs solve problems frontend optimization alone can't touch
Sometimes the answer isn't in your code. It's in understanding how infrastructure works at scale
Cloudflare was already solving the right problems in 2017, long before it became ubiquitous

Mistakes I Made as a Frontend Engineer (And What They Actually Cost Me)

Phaneendra Kanduri — Sat, 28 Feb 2026 06:26:08 +0000

I've shipped a 2s → 0.2s FCP improvement.
I've cut build times from 20 minutes to 90 seconds by making the right framework call. I've led an Angular migration across 500+ components with a 12-engineer team.

None of that changes the fact that I made avoidable mistakes early in my career.
Some
from ignorance, some from arrogance, some from nobody being around to tell me otherwise.

This is for junior and mid-level engineers who are still in the window where these
mistakes are correctable.

1. I Stayed With jQuery Because It Was Working (2013 - 2015)

In college, I built personal projects with jQuery. It worked. I never had a reason to look further. No one around me, faculty included knew much more than that. So I didn't push.

That attitude this is enough, I'm getting results — followed me into my first job.
When the industry had already moved to Angular and React, I was still thinking in jQuery
terms. I had to learn a component-based mental model on the job, under delivery pressure,
without the luxury of focused learning time.

What it actually cost: Not the job. But the first year was harder than it needed to
be. I was catching up on fundamentals while simultaneously trying to ship features.

The lesson: Curiosity in college is free. It costs nothing to ask what are teams
actually using in production right now? That question alone would have changed my
trajectory by 12 months.

2. I Ignored TypeScript Until a Production Bug Forced My Hand

Early in my career, TypeScript felt like overhead. I was writing JavaScript, things were
working, and adding types felt like extra ceremony with no visible return.

Then I passed a wrong type in production. It wasn't a subtle edge case. It was a runtime failure that reached users. That was the moment I stopped telling myself TypeScript was unnecessary overhead.

What I found after actually learning TypeScript:

Refactoring became significantly safer. I could rename, restructure, and move things without hunting for every consumer manually.
Code review got faster because intent was explicit.
Reusability improved. Properly typed interfaces forced me to think about contracts before implementation.

The lesson: TypeScript isn't ceremony. It's a communication layer between you, your
teammates, and future-you. The overhead is front-loaded. The payoff compounds.

3. I Thought DSA Didn't Apply to Frontend

For years, I treated Data Structures and Algorithms as a hiring filter — something you
studied for interviews and forgot immediately after. Frontend is UI, right? State
management, component trees, CSS. What does Big O have to do with any of that?

Then I hit a real performance problem.

We had a filtering operation running on a large dataset. The existing code used array
iteration and nested loops for comparisons — the team had written it that way, it worked,
and nobody questioned it. I replaced the comparison logic with a Set. That single
change gave us a 200ms performance gain.

Users notice 200ms. It's the difference between an interaction feeling instant and feeling
sluggish.

I also used recursion extensively in production — tree traversal for nested UI structures,
recursive rendering logic, hierarchical data transformations. These aren't academic
exercises. They show up in real frontend work regularly.

The lesson: You won't use Dijkstra's algorithm in a React component. But you will
absolutely encounter problems where knowing the right data structure is the difference
between a fast product and a slow one. DSA teaches you to think about operations, not
just write code that works.

4. I Hammered Angular's `@Input` Listeners Without Thinking About the Cost

In Angular, @Input with ngOnChanges is the obvious way to react to parent-to-child
data flow. I used it heavily. It was the path of least resistance, and for a while,
nothing visibly broke.

Then we hit scale.

The symptoms came gradually, then all at once: keystrokes appearing in bursts after a
delay, dropdowns not opening, the sidebar freezing mid-interaction, the browser throwing
a page crash dialog asking users to either wait or exit. Users couldn't reliably interact
with the product.

The root cause: too many change detection cycles firing simultaneously across too many
components, all triggered by input changes cascading through the tree.

The fix required going back and auditing the architecture — determining what actually
needed to react to changes versus what was reacting unnecessarily. It was migration work
that shouldn't have been necessary.

The lesson: ngOnChanges and @Input listeners are not free. Every one you add is
a hook into Angular's change detection. At component scale, this compounds. Before wiring
up an input listener, ask: does this component actually need to re-evaluate on every
parent change, or can this be derived, memoized, or handled further up the tree?

5. I Overused Directives and Created a Click Listener Explosion

Directives in Angular are powerful. I used them extensively for shared behavior, which
is correct in principle. The mistake was not thinking about what happens when a directive
is instantiated hundreds of times across a large application.

I had a directive that listened to click events. It was applied broadly. Each instance
created its own event listener. On a screen with many instances, we had hundreds of
active click listeners running simultaneously.

The user-visible symptom: a simple search bar — no search-as-you-type, just a standard
Enter key to trigger an API call — became unresponsive. Users couldn't type. Keystrokes
were being swallowed. What should have been a trivial interaction was broken by listener
saturation.

The fix: replace the distributed listener pattern with a single event source in a
service, broadcast via an observable. One listener. One source of truth. The UI became
responsive immediately.

The lesson: When a directive handles DOM events and gets used at scale, you don't
have one listener — you have N listeners. Before writing event-handling logic into a
directive, ask whether a centralized service with a single subscription would serve the
same purpose with a fraction of the overhead.

6. I Refactored Code That Wasn't My Ticket — And I'd Do It Again

This one is more complicated.

Management's view: refactoring work you weren't assigned is wasted time. It's scope
creep. It's not in the sprint.

My experience over four years: I refactored proactively whenever I saw something
structurally wrong — float-based layouts that should have been flexbox, JS-driven
dropdown state that should have been CSS focus-within, array comparisons that should
have been Set lookups. Nobody asked me to. I just did it.

This happened seven times in four years. And in every single case, within the next
sprint, I had a feature to build on that exact component.

The float→flexbox refactors were the clearest example. A CSS float layout is brittle.
It breaks under theme changes, under translation string length variation, under responsive
breakpoints. When I was handed a feature that required layout changes to those components,
my prior refactor meant I was working with a clean, predictable structure instead of
fighting the existing one. What would have taken 3 days was done in a day.

The opportunistic refactoring wasn't wasted time — it was pre-paid time. The sprint
where I refactored looked inefficient. The sprint where the feature landed showed the
return.

Replacing JS-based click listeners on dropdowns with CSS focus-within also reduced the
event listener footprint across the application — the same class of problem described
in mistake 5, resolved structurally rather than reactively.

The lesson: Proactive refactoring is a bet. You're spending time now against
uncertain future return. In my experience, if you have enough system knowledge to
know a component is going to be touched again soon, it's usually a good bet. The
mistake is doing it indiscriminately. The skill is doing it with judgment.

Final Thought

Most of these mistakes share a root: I optimized for working now without thinking
about cost at scale. jQuery worked. @Input listeners worked. Directives worked.
Array loops worked.

Until they didn't.

Frontend engineering at scale is not about making things work. It's about understanding
what you're trading when you make a choice — and being honest about when that trade
stops being worth it.

These mistakes are what actually make you an engineer, not just someone who writes code.
The engineers AI can't replace are the ones who've already made them.

Hopefully this is that someone for you.

An Engineer's Practical Manual for Using AI Code Assistants

Phaneendra Kanduri — Tue, 24 Feb 2026 10:01:21 +0000

AI code assistants are everywhere now. But most engineers either treat them like magic oracles or ignore them entirely. Neither approach works.

Here's a practical manual for getting actual value from AI tools without letting them wreck your codebase.

TL;DR

Treat AI like a smart intern who is good at execution, bad at judgment
Set your communication style upfront in custom instructions
Define non-negotiables AI must remember (tech stack, conventions, compliance)
End every task with "Ask questions if you have gaps"
For long projects, ask AI to document progress in a file
Monitor actively. AI will go out of bounds
Double-check everything, twice again before shipping
AI accelerates scaffolding, doesn't replace decision-making

1. Treat AI Like a Smart, Overenthusiastic Intern

This is the most important mental model.

AI tools are not senior engineers. They don't understand system constraints, political context, or why a "simple refactor" will break 6 downstream consumers. But they're excellent at scaffolding, repetitive transforms, and generating first drafts.

What this means in practice:

You still own the architecture
You still own the tradeoffs
AI handles the grunt work: boilerplate, repetitive edits, documentation templates, test scaffolding

Example: During a platform migration, AI scaffolded 200+ Components files and saved ~40 hours of manual work. But the engineer still designed the directory structure, schema, and migration sequence.

2. Set Your Communication Style Upfront

AI adapts to how you speak to it. If you're vague, you'll get vague output. If you're direct, you'll get direct output.

Set custom instructions once:

Direct, structured, blunt. No filler, no apologies.
Flag gaps in my request if they exist.
When code has edge cases I didn't mention, list them before generating.

This cuts back-and-forth by ~50%. Instead of:

"Sure! I'd be happy to help. Let me create a component for you. Would you like me to include props for styling?"

You get:

"Missing: error state handling, loading state, TypeScript types for onSubmit. Proceeding with basic implementation."

Set the tone once. Enforce it consistently.

3. Define Non-Negotiables That AI Must Remember

Some context applies to every task. Don't repeat yourself, encode it once.

Examples:

"Always use functional components with TypeScript. No class components."
"Accessibility is non-negotiable. Include ARIA labels and keyboard nav by default."
"When writing tests, use Enzyme, not React Testing Library"
"Performance matters. Flag unnecessary re-renders or heavy computations."

This prevents AI from generating outdated patterns or ignoring your team's conventions.

4. Always End Tasks With: "Ask Questions If You Have Gaps"

AI will confidently generate wrong code if you don't give it permission to push back.

Bad prompt:

"Build a dropdown component with keyboard navigation."

Better prompt:

"Build a dropdown component with keyboard navigation (arrow keys, Enter, Escape). Must be WCAG 2.1 AA compliant. Ask questions if you need clarification on interaction patterns or edge cases."

The second version produces:

"Should focus trap inside the dropdown when open?"
"Should Escape close and return focus to the trigger?"
"Should arrow keys wrap at list boundaries?"

Now you're reviewing a solution that handles real-world behavior, not a demo-quality stub.

5. For Multi-Week Projects: Make AI Document Progress

When working on long-running tasks (e.g., framework migrations, large refactors), ask AI to maintain a progress log.

Prompt template:

"We're upgrading our framework. This will take 3 weeks. After each session, update PROGRESS_LOG.md with:

What we completed today

Blockers encountered

Next steps

When I return, I should be able to read the log and resume without context loss."

Example log entry:

## 2024-01-15: Upgraded core packages

- Completed: Core packages updated to latest version
- Blockers: 14 components using deprecated APIs
- Next: Migrate deprecated API usage
- Estimate: 2 days for API migration

This is critical. AI has no memory between sessions. If you don't externalize progress, you're starting from scratch every time.

6. AI Will Go Out of Bounds. Always Monitor Actively

AI optimizes for "solving the prompt," not "solving the right problem."

Real example:

An engineer asked AI to optimize a Python script. It rewrote the entire script using a different parsing library, which:

Broke compatibility with existing plugins
Introduced a new dependency
Required changes to CI/CD

The AI's solution was faster, but architecturally wrong.

How to prevent this:

Set constraints upfront: "Do not introduce new dependencies without asking."
Review diffs before running code
Test in isolated environments first

AI will go off-script. Your job is to catch it before it hits production.

7. Double-Check Everything. Then Twice Again.

AI-generated code is never production-ready on the first pass.

Standard review checklist:

Does it handle edge cases? (Empty arrays, null values, network errors)
Is it accessible? (Keyboard nav, ARIA, focus management)
Is it performant? (Unnecessary re-renders, large bundle size)
Does it follow team conventions? (Naming, file structure, test patterns)
Will it break in 6 months? (Deprecated APIs, hardcoded assumptions)

Real scenario: AI generated GraphQL queries that worked but over-fetched data, pulling entire content trees when only leaf nodes were needed.

Fixing this required:

Understanding the schema
Knowing the API's performance characteristics
Rewriting queries with proper field and depth limits

AI got 70% of the way there. The last 30% required domain knowledge.

8. AI Accelerates Scaffolding. It Doesn't Replace Decision-Making

Where AI excels:

Migrations: Generated files, parsers, layouts → saved ~40 hours
PWA setup: Service worker boilerplate, cache strategies → saved ~8 hours
Accessibility audits: Scanned for missing ARIA labels, generated fixes → saved ~12 hours

Where AI fails and humans must step in:

Deciding between micro-frontends vs. monolith (architectural tradeoff)
Evaluating framework options (performance + DX tradeoff)
Negotiating with designers on performance vs. aesthetics (subjective judgment)

What AI Is Actually Good For

Excellent:

Boilerplate generation (repos, components, configs)
Repetitive transforms (file renames, import updates, data migrations)
Documentation (README templates, API docs, guides)
Test scaffolding (basic unit test structure, mock setup)

Mediocre:

Complex refactors (high risk of breaking changes)
Performance optimization (requires profiling and domain knowledge)
Debugging (suggests fixes, but often misses root cause)

Bad:

Architecture decisions (tradeoffs require human judgment)
Security-critical code (high stakes, low tolerance for error)
Organizational dynamics (AI doesn't understand politics or people)

Final Take

AI tools are productivity multipliers, not replacements.

They can cut scaffolding time by ~60%. They eliminate entire classes of grunt work. But they haven't changed the fact that someone still needs to know what to build, why to build it, and how to evaluate if it's correct.

That someone is you.

Use AI to move faster. But never stop thinking.

What's your experience with AI code assistants? What patterns have worked (or failed spectacularly) for you?

Your Icon Strategy Is a Hidden Tech Debt Bomb

Phaneendra Kanduri — Fri, 20 Feb 2026 07:33:33 +0000

Three approaches to scaling icons across hundreds of components. Two of them will cost you.

Why Icons Are Never Just Icons

Icons feel like a solved problem. Pick a library, drop them in, move on.

That works fine at 10 components. At 100 components, you start feeling friction. At 500 components with 100 icons across multiple feature modules, your icon strategy is either invisible infrastructure or a daily source of pain.

Most teams don't make a deliberate icon decision. They inherit one. And by the time the problems show up, the icons are everywhere.

This article covers three approaches, what breaks in each, and which one actually holds up in a large enterprise SaaS context.

Approach 1: Font-Based Icons

This is the most common starting point. Libraries like Font Awesome, Material Icons, and Google's own icon font work by mapping icon names to glyphs inside a custom font file. You reference them by class name or by writing the icon name as text.

<span class="material-icons">save</span>

It feels clean. One CDN link, infinite icons, no SVG anywhere.

Where It Breaks

Font icons are network-dependent by design. The font file has to load before any icon renders.

I've seen this fail on Google's own properties. When the font hasn't loaded yet, the icon name renders as plain text. A button meant to show a save icon shows the word "save" instead. On a slow connection or a constrained device, this isn't an edge case — it's the experience.

For a public-facing marketing page, that might be acceptable. For an enterprise SaaS product used daily by thousands of users, it is not. Your users will see broken UI. And it will happen precisely when their network or device is already under stress.

Beyond rendering, font icons carry another problem: you load the entire font file even if you use 12 icons. You cannot tree-shake a font. Every icon the library ships is in the bundle whether your product uses it or not.

Verdict: Rules itself out for enterprise. Network dependency and no tree-shaking are disqualifying at scale.

Approach 2: Inline SVG

The natural response to font icon failures is to go directly to SVG. SVGs are vectors, they render perfectly at any size, they don't depend on a font file, and they're just markup.

So you paste the SVG directly into your component template.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24">
  <path fill="#333333" class="icon-primary" d="M17 3H5a2 2 ..."/>
</svg>

It works. Until it doesn't.

Where It Breaks

The first problem is duplication. If the save icon appears in 15 components, the SVG markup is copy-pasted into 15 files. When the design team updates the icon — corrects a path, adjusts stroke width, updates the color — you're hunting across 15 files to apply the change. Miss one and you have an inconsistency that will take weeks to notice.

The second problem is that colors and classes are often hardcoded inside the SVG markup itself. fill="#333333" is not a variable. It's a value. Changing it requires touching every instance. Creating a variant — same icon, different color for a different state — means another copy.

The third problem is migration. When this pattern has been in use for a year across a large codebase, moving away from it is not a refactor. It's an excavation. Every file that inlined SVG needs to be found, assessed, and updated individually.

I tried this approach. The duplication was immediate and obvious. The design team updated an icon and the inconsistency spread faster than we could track it.

Verdict: Acceptable for small projects with few icons. Breaks down fast at scale. Migration cost is high.

Approach 3: SVG as Standalone Components

This is the approach that holds up.

Each icon is its own component. The SVG lives inside that component. Props control the variants — size, color, stroke, anything that needs to change between usages.

// SaveIcon component (framework-agnostic concept)

interface IconProps {
  size?: number;
  color?: string;
  strokeWidth?: number;
}

// Template / JSX
<svg
  xmlns="http://www.w3.org/2000/svg"
  [width]="size"
  [height]="size"
  viewBox="0 0 24 24"
>
  <path [attr.fill]="color" d="M17 3H5a2 2 ..." />
</svg>

Every consumer of this icon imports the component and passes props. No SVG markup in the consumer's file. No duplication.

// Consumer
<SaveIcon size={20} color="var(--icon-primary)" />

Why This Wins at Scale

Maintainability. When the design team updates the save icon, you update one file. One component. Every consumer gets the update automatically. No hunting, no inconsistency.

Variants without duplication. Need the same icon in a disabled state, a hover state, an error state? Pass a prop. Don't copy the file.

Bundle control. Each icon is a discrete module. If a feature only needs 10 icons, it imports 10 components. Nothing else ships with it. When I ran a module visualizer on the codebase after this migration, I could see exactly which icons each module imported — and nothing extra. Around 100 icons across a 500-component codebase, with each module importing only what it actually used.

Migration path. Because each icon is a named, importable component, replacing or updating the underlying SVG is a single-file change. Renaming or deprecating an icon is trackable through standard import analysis.

Design system alignment. Icon components sit naturally inside a shared component library or design system. They're versioned, documented, and owned — not scattered across feature folders as copy-pasted markup.

The Trade-off

Initial setup takes longer. You're creating a component per icon, not dropping in a CDN link. For a library of 100 icons, that's a one-time investment that pays back within the first few design updates.

If you're on a two-week spike with a throwaway prototype, this is overkill. For anything that will be maintained past the first quarter, it is the only approach that doesn't accumulate debt.

Decision Guide

Scenario	Recommended Approach
Quick prototype, throwaway project	Font icons or inline SVG
Small product, <20 icons, stable design	Inline SVG
Enterprise SaaS, 50+ icons, active design iteration	SVG components
Shared design system across multiple products	SVG components, non-negotiable

The Pattern That Scales

Font icons trade render reliability for convenience. Inline SVG trades maintainability for simplicity. SVG components trade setup time for everything that matters after day one.

In a large B2B SaaS environment — multiple feature modules, active design iteration, a team that rotates — the icon strategy compounds quietly in the background. The wrong choice doesn't hurt immediately. It hurts when the design team updates a core icon and you realize it lives in 40 files. It hurts when a new engineer can't tell where an icon comes from or how to create a variant without duplicating it.

The component approach is more setup upfront. It is less everything else, forever.

Make the decision deliberately. Most teams don't, and they pay for it later.

4 Years of Dual-Stacking: The High Cost of React’s Flexibility

Phaneendra Kanduri — Thu, 19 Feb 2026 09:49:29 +0000

Not a framework war. A working engineer's honest accounting.

The Setup

I spent four years at Phenom (a B2B HR tech company) working on three concurrent frontend contexts:

A large internal product built in Angular (v9 → v15, ~500 components, 5,000+ active users)
A Pilot product started in React, with the stated USP of eventual React Native migration
A Chrome extension that injected an iframe and loaded a React application inside it

This isn't a theoretical comparison. I lived in both codebases every week for nearly four years. The React product never launched as an app — it shipped as a responsive website instead. The Angular product is still running.

I'm biased toward Angular. I know it. This article explains why, and I'll let you decide if the bias is earned.

What React Actually Gives You

React is not a framework. It's a UI library. That distinction sounds academic until you're six months into a team of eight and you realize no two engineers made the same architectural call.

In the Pilot React product I worked on, the early team had to make decisions that Angular would have made for them:

State management: Redux? Zustand? Context? Jotai? Each had advocates.
Routing: React Router v5 → v6 introduced breaking changes mid-project.
Styling: styled-components vs. SCSS modules, tailwind? never fully resolved.
File structure: flat, feature-based, domain-driven, three opinions, no standard.

I joined when the product had 5 components in wireframe. By the time I transitioned out, it had approximately 200 components. The architectural debt from those early unconstrained choices compounded with every component added.

React gives you freedom. Freedom without structure, at scale, becomes liability.

What Angular Actually Forces You To Do

Angular forces structure before you write a single line of business logic.

Every feature has a dedicated template, stylesheet, component class, service, and route configuration. There are interceptors for HTTP. There are guards for navigation. There's a module system, and now, standalone components which makes you think in boundaries, not just files.

When I led the Angular upgrade from v9 → v12, and later identified standalone components in v15 as an architectural improvement and made the business case to leadership - the migration was significant but tractable. ~500 components. A team of 12–15 engineers. The framework gave us enough shared language that we could execute it without rebuilding the mental model.

That would have been a different story in React. A comparable refactor migrating from one state management library to another which has no prescribed path. Every team invents its own.

Angular Signals, introduced in recent versions, close the last real gap React had in reactivity ergonomics. There is no longer a compelling reactive programming argument for React over Angular in enterprise contexts.

Dependency Injection Is Not About Testability. It's About Time.

Everyone says Angular DI makes testing easier. That's true, but it's the wrong headline.

The real payoff shows up three years later, when someone maybe you, maybe not opens a file they didn't write.

Compare these two lines doing the same thing:

Angular:

const a = someFunction();
const c = dependencyService.validateThisService(a);
console.log(c);

React:

const a = someFunction();
const c = validateThisService(a);
console.log(c);

A React developer will say: just click through to the import. You'll see where it's from.

That's fair. If you're in the file for the first time today, in a familiar codebase, with good IDE support.

But visit that line 3 years later, in a file you didn't write, in a codebase that's rotated engineers twice. Now validateThisService could be a local utility, a shared library function, a barrel export from a utils folder, or something that's been copy-pasted and diverged.

You have to trace it.

In Angular, dependencyService.validateThisService(a) tells you something before you click anything. There is a service. It owns this validation. If you want to know what else that service does, it's one tab. If you want to know where it's injected from, it's the constructor. The code has a return address.

The function call in React has no return address. It's floating. It could be from anywhere. And in a 200-component codebase with three engineers who made different structural choices — it often is.

This is not a readability debate.

This is the difference between code that documents its own dependencies and code that delegates that job to whoever's reading it at the worst possible time.

Adults write code that explains itself after they've left the building.

Internationalization Is an Afterthought Everywhere Except Angular

Angular ships with @angular/localize. One package. Built by the same team that built the framework. No third-party dependency to evaluate, no community split between competing libraries.

The translation workflow is straightforward: mark strings, extract them, hand off one file to your translators, get it back, done.

When I delivered multilingual features for Fortune 500 EU clients, the translation file was the artifact. Not a collection of JSON files spread across feature folders. Not a barrel export someone assembled. One file with a clear structure that a non-engineer translator could open and work with.

That's the adult version of internationalization. It doesn't make you feel clever. It just works, every time, the same way.

The Manager Observation

This is the part where I'll lose some readers, but it tracks with my experience.

Technical managers who have shipped and maintained large frontend codebases over 3+ years tend to reach for Angular. Not because it's trendy — because they've felt the cost of the alternative.

Managers who have moved through roles quickly, prioritizing hiring speed and ecosystem breadth, tend to reach for React. The React ecosystem is wide. That width reads as optionality. But optionality without constraint is just deferred decision-making — and someone downstream pays for it.

This is not an attack on React engineers. It's an observation about what happens when framework choice is driven by hiring market size rather than long-term maintainability.

The Chrome Extension Context

The Chrome extension was React. Injecting an iframe into third-party pages and loading a full React application inside it. This context actually suited React well: isolated scope, small surface area, no long-running state across sessions. Framework overhead didn't compound the way it does in a 500-component product.

This is the honest answer: React is not wrong. It's often wrong for the context it gets chosen for.

My Actual Position

Angular is boring. It's verbose. It has a learning curve that filters out engineers who won't invest in understanding it. It is not exciting to maintain. It is not flexible. It will not let your team build whatever they want however they want.

That is exactly why I use it for serious work.

The frontend ecosystem rewards novelty. Angular rewards discipline. For enterprise, long-running, high-user-count applications — I have not yet seen a credible argument that the tradeoffs favor React.

If you're building a startup MVP with a team of two and a 6-month runway, use whatever ships fastest. But if you're building something that will be maintained by 10+ engineers across 4+ years, the structure Angular enforces is not overhead, it's insurance.

I'm biased. But I've done the work that earns the bias.

Tags: angular react frontend architecture webdev

From 2s to 0.2s: Why Astro is the New Gold Standard for Marketing Sites

Phaneendra Kanduri — Wed, 18 Feb 2026 09:43:04 +0000

Some of the best architectural decisions I've made never went to production. This is one of them.

The Breaking Point

We were running a high-traffic marketing site - heavy A/B testing, dynamic banners, offers, primarily organic traffic from email opens. The kind of site where first impressions are everything and every second of load time has a direct business cost.

Our stack was Gatsby. And it was falling apart.

Build times were getting out of hand. Load times were degrading. Then Netlify acquired Gatsby and support effectively stalled. We also started hitting Netlify downtime and third-party integration blockers that compounded an already fragile setup. The site was expensive to maintain and getting slower.

Leadership assigned me to research a new stack. The brief was open - evaluate options, build POCs, present findings.

The Room Had Already Decided

The moment it was brought up in standup, the team rallied around Next.js. Everyone had experience with it. Everyone had opinions on why it would work. It was the obvious choice.

I understood why. Next.js is a mature, well-supported framework with a strong ecosystem. For most use cases, it's a reasonable default.

But I wasn't there to validate consensus. I was there to find the right answer for the product.

So I ran the Next.js POC anyway - properly, without shortcuts. The developer experience was good. The ecosystem was solid. And then I looked at the output.

Non-interactive components were being hydrated. Common JS bundles were being shipped to the client unnecessarily. The thread blocking time was higher than it needed to be for a site where most components never respond to user input. For an application, this is an acceptable tradeoff. For a marketing site built to load fast and convert, it's the wrong architecture.

The framework was technically sound. It was the wrong tool for what the product actually needed.

Finding Astro

I kept researching. Astro had been gaining traction with a specific promise: ship zero JS by default, hydrate only what needs to be interactive. For a marketing site, that's not a feature - that's the entire architectural requirement.

I built the POC. Same content, same structure, equivalent functionality.

The numbers were not close.

Metric	Gatsby (Production)	Next.js POC	Astro POC
FCP	2s	~1.2s	0.2s
LCP	10s	~5s	2s

FCP dropped 90%. LCP dropped 80%. These weren't micro-optimizations - they were the direct result of not shipping unnecessary JavaScript to a page that didn't need it.

Where AI Fit In

I used AI heavily during the POC phase - wireframes, component scaffolding, boilerplate generation. It compressed weeks of setup into days.

But AI didn't make the architectural call. It couldn't reason about why a marketing site with non-interactive components has no business hydrating them. It couldn't weigh the tradeoff between developer familiarity and production performance. It couldn't recognize that the team's instinct toward Next.js was a comfort zone decision, not a product decision.

That judgment of understanding what the product actually needed and selecting the tool that served it. That's where the human work was.

What Happened After

I presented both POCs to leadership with full benchmarks. The Astro numbers were clear. The recommendation was clear.

Then the whole team was laid off. Company was on the brink of an IPO, circumstances changed, and that was that. Neither stack ever went to production.

What I Walked Away With

The work didn't ship. The thinking did.

When you're assigned a technical decision, the room will often have already made up its mind. Your job isn't to confirm that. Your job is to understand what the product needs and find the architecture that serves it - regardless of what's familiar, regardless of what's popular, regardless of what the consensus is pointing at.

AI will keep getting better at execution. It will scaffold faster, generate more, automate more. What it won't do is walk into a standup, hear a team default to the comfortable answer, and ask whether that answer is actually right.

That's still the job.

One More Thing

Recently, Cloudflare acquired Astro. A framework built to ship minimal JavaScript, backed by one of the largest infrastructure companies on the internet.
When I ran those POCs, Astro was the underdog pick against a category default. That acquisition is validation, not just of the framework, but of the architectural reasoning behind choosing it.

The right tool for the product, before the market agreed.

Stacking Multiple Dialogs in React Without Hooks or Effects

Phaneendra Kanduri — Wed, 18 Feb 2026 08:52:33 +0000

Managing z-index across multiple stacked dialogs in React gets messy fast. I ran this problem through an AI tool out of curiosity and it generated this:

jsxconst DialogManager = ({ dialogs }) => {
  return (
    <>
      {dialogs.map((dialog, index) => {
        const zIndexBackdrop = 1000 + (5 * (index + 1));
        const zIndexContent = zIndexBackdrop + 2;

        return (
          <div key={dialog.id}>
            <div
              className="modal-backdrop show"
              style={{ zIndex: zIndexBackdrop }}
            />
            <div
              role="dialog"
              aria-modal="true"
              style={{ zIndex: zIndexContent }}
            >
              {dialog.content}
            </div>
          </div>
        );
      })}
    </>
  );
};

Functional, but it runs the z-index calculation on every render cycle. For a static stacking requirement, that's unnecessary execution. Styling problems should be solved in the style layer.

Here's the approach I came up with using SCSS:

@for $i from 1 through 6 {
  $zIndexBackdrop: #{1000 + (5 * $i)};
  $zIndexContent:  #{1000 + (5 * $i) + 2};

  .modal-backdrop.show:nth-of-type(#{$i}) {
    z-index: $zIndexBackdrop;
  }

  div[role="dialog"][aria-modal="true"]:nth-of-type(#{$i}) {
    z-index: $zIndexContent;
  }
}

This loop generates z-index rules for up to 6 dialog layers at compile time - zero runtime cost. The backdrop and content for each layer are spaced 2 units apart, with 5-unit gaps between layers to leave room for other elements if needed.

A few things to know before using this:

nth-of-type is sensitive to DOM structure. If other elements of the same type exist in the same context, the selector can misfire. Verify your rendered DOM matches the assumption.
The ceiling of 6 is arbitrary — adjust the loop range, base value, and step size to fit your z-index scale.
This compiles down to plain CSS. No runtime, no state, no effect hooks. That's the point.

DEV Community: Phaneendra Kanduri

Material Design Principles Are Correct. Implementing Them Will Break You.

Preface

Why I Use a Pixel Phone

Material Is Not the Only Path. It Is One of the Most Correct Ones.

The Problem Nobody Prices In

What "No Flickering" Actually Requires

The Scroll Flicker Problem

Why It Cannot Be Retrofitted at Scale

It Is Not About Code. It Is About How You Approach.

The Practical Conclusion

How I Stumbled Into Cloudflare Before It Took Over the Internet (2017)

I tried the classic frontend interview answer for website optimization:

Desperation research

Enter The Cloudflare

What stuck with me

Mistakes I Made as a Frontend Engineer (And What They Actually Cost Me)

1. I Stayed With jQuery Because It Was Working (2013 - 2015)

2. I Ignored TypeScript Until a Production Bug Forced My Hand

3. I Thought DSA Didn't Apply to Frontend

4. I Hammered Angular's @Input Listeners Without Thinking About the Cost

5. I Overused Directives and Created a Click Listener Explosion

6. I Refactored Code That Wasn't My Ticket — And I'd Do It Again

Final Thought

An Engineer's Practical Manual for Using AI Code Assistants

TL;DR

1. Treat AI Like a Smart, Overenthusiastic Intern

2. Set Your Communication Style Upfront

3. Define Non-Negotiables That AI Must Remember

4. Always End Tasks With: "Ask Questions If You Have Gaps"

5. For Multi-Week Projects: Make AI Document Progress

6. AI Will Go Out of Bounds. Always Monitor Actively

7. Double-Check Everything. Then Twice Again.

8. AI Accelerates Scaffolding. It Doesn't Replace Decision-Making

What AI Is Actually Good For

Final Take

Your Icon Strategy Is a Hidden Tech Debt Bomb

Why Icons Are Never Just Icons

Approach 1: Font-Based Icons

Where It Breaks

Approach 2: Inline SVG

Where It Breaks

Approach 3: SVG as Standalone Components

Why This Wins at Scale

The Trade-off

Decision Guide

The Pattern That Scales

4 Years of Dual-Stacking: The High Cost of React’s Flexibility

The Setup

What React Actually Gives You

What Angular Actually Forces You To Do

Dependency Injection Is Not About Testability. It's About Time.

Internationalization Is an Afterthought Everywhere Except Angular

The Manager Observation

The Chrome Extension Context

My Actual Position

From 2s to 0.2s: Why Astro is the New Gold Standard for Marketing Sites

The Breaking Point

The Room Had Already Decided

Finding Astro

Where AI Fit In

What Happened After

What I Walked Away With

One More Thing

Stacking Multiple Dialogs in React Without Hooks or Effects

4. I Hammered Angular's `@Input` Listeners Without Thinking About the Cost