DEV Community: Anisubhra Sarkar (Ani)

How to Build a React App from Scratch That Doesn't Fall Apart in 6 Months

Anisubhra Sarkar (Ani) — Sun, 29 Mar 2026 14:30:05 +0000

Most React apps don’t break overnight.

They decay.

At first, everything feels clean. Then features pile up, quick fixes sneak in, and decisions you didn’t think twice about start showing up everywhere.

Six months later:

changing one thing breaks another
performance feels “off” but no one knows why
and parts of the codebase become… untouchable

This isn’t about writing “better components.”
It’s about making a few decisions early that don’t age badly.

Start Simple — But Not Careless

You don’t need a complicated setup. You need a boring, reliable one.

React + TypeScript + Vite is more than enough.

npm create vite@latest my-app -- --template react-ts

Why this works in practice:

TypeScript catches things like:

function getUserName(user: { name: string }) {
  return user.name
}

// later...
getUserName(null) // ❌ caught early instead of crashing at runtime

Vite keeps dev fast even as the app grows (this matters more than you think)

You’re not optimizing for day 1.
You’re optimizing for when the codebase stops fitting in your head.

Your Folder Structure Will Either Save You or Kill You

This looks clean early on:

components/
hooks/
utils/

Until you try to work on a feature and end up opening 12 files across 6 folders.

Instead, group by feature:

features/
  auth/
    Login.tsx
    useAuth.ts
    api.ts
  dashboard/
    Dashboard.tsx
    useDashboard.ts

Now when you work on login:

everything is in one place
you don’t hunt for logic vs UI vs API

Real-world benefit:

// ❌ old way
import { login } from '../../services/api'
import { useForm } from '../../hooks/useForm'

// ✅ feature-based
import { login } from './api'
import { useAuthForm } from './useAuth'

Less jumping around = less cognitive load.

Routing Is Not an Afterthought

Routing shapes your app more than you think.

A simple setup early:

// app/router.tsx
const router = createBrowserRouter([
  { path: '/', element: <Home /> },
  { path: '/dashboard', element: <Dashboard /> },
])

Now you can:

lazy load routes
define layouts per route
scale navigation cleanly

Example with code splitting:

const Dashboard = lazy(() => import('../features/dashboard/Dashboard'))

<Suspense fallback={<div>Loading...</div>}>
  <Dashboard />
</Suspense>

If you delay routing, you’ll eventually have to:

untangle component hierarchies
rewrite layouts
move logic around

That’s painful mid-project.

State Management: Most Problems Come From Misuse

Not all state is the same — treat it differently.

1. Local UI state

const [isOpen, setIsOpen] = useState(false)

Simple, predictable.

2. Server state (this is where people mess up)

Bad:

useEffect(() => {
  fetch('/api/users')
    .then(res => res.json())
    .then(setUsers)
}, [])

Now repeat this across 10 components:

loading state?
error handling?
retries?
caching?

It becomes inconsistent fast.

Better approach (conceptually):

const { data, isLoading, error } = useQuery({
  queryKey: ['users'],
  queryFn: fetchUsers,
})

Now:

caching is automatic
loading/error is consistent
refetching is built-in

3. Global state (only when needed)

Don’t do this:

// ❌ everything goes global
const useStore = create(() => ({
  user: null,
  theme: 'light',
  modalOpen: false,
}))

You end up with a dumping ground.

Instead:

keep most state local
promote only what truly needs to be shared

Keep Components Boring

If a component is doing too much, it becomes fragile.

Bad:

function UserCard() {
  const [user, setUser] = useState(null)

  useEffect(() => {
    fetch('/api/user').then(res => res.json()).then(setUser)
  }, [])

  return <div>{user?.name}</div>
}

Problems:

tightly coupled
hard to reuse
hard to test

Better:

function useUser(id: string) {
  return useQuery({
    queryKey: ['user', id],
    queryFn: () => fetchUser(id),
  })
}

function UserCard({ id }: { id: string }) {
  const { data } = useUser(id)
  return <div>{data?.name}</div>
}

Now:

logic is reusable
UI is clean
testing is easier

Performance: Fix the Right Problem

Most performance issues aren’t about heavy logic.

They’re about rendering too much.

Example: unnecessary re-renders

function Parent() {
  const [count, setCount] = useState(0)

  return <Child onClick={() => setCount(count + 1)} />
}

Every render creates a new function → child re-renders.

Fix (only if needed):

const handleClick = useCallback(() => {
  setCount(c => c + 1)
}, [])

Example: large lists

// ❌ renders 1000 items
items.map(item => <Row key={item.id} />)

Better:

virtualize the list
render only visible items

Example: loading too much JS

// ❌ everything bundled together
import Dashboard from './Dashboard'

Better:

const Dashboard = lazy(() => import('./Dashboard'))

Load only when needed.

Responsive Design: Build It Into Components

Don’t fix responsiveness later.

Instead of:

/* page-level hacks later */
@media (max-width: 768px) {
  .dashboard { ... }
}

Do this at component level:

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
}

Now every place using card-grid is responsive by default.

That’s how you avoid messy overrides later.

Security: Small Mistakes, Big Problems

Bad:

localStorage.setItem('token', jwt)

Any script can access it → vulnerable to XSS.

Better:

store tokens in httpOnly cookies
let the browser handle sending them

Another common issue:

<div dangerouslySetInnerHTML={{ __html: userInput }} />

If userInput is not sanitized → XSS risk.

Safer approach:

sanitize input before rendering
or avoid raw HTML entirely

Testing: Focus on Behavior, Not Implementation

Bad test:

expect(component.state.isLoggedIn).toBe(true)

Breaks when you refactor.

Better:

render(<Login />)

await userEvent.type(screen.getByLabelText('Email'), 'test@mail.com')
await userEvent.click(screen.getByText('Login'))

expect(screen.getByText('Welcome')).toBeInTheDocument()

Now you’re testing what matters:

what the user sees
not how the component works internally

CI: Because Good Intentions Don’t Scale

A simple pipeline catches a lot:

- run: npm run lint
- run: npm run test
- run: npm run build

Also add pre-commit hooks:

npx husky-init

Now:

broken code doesn’t get committed
issues are caught early

Without this, standards slowly slip.

What Actually Makes an App Last

Not a library. Not a pattern.

It’s a bunch of small decisions:

organizing by feature, not file type
separating logic from UI
treating server state properly
avoiding unnecessary global state
thinking about performance early
not ignoring security basics
testing behavior, not internals
automating quality checks

None of this is hard.

The hard part is doing it when the app is still small,
when it feels like overkill.

Because later, it’s not optional —
it’s expensive.

🦄 Building Side Projects That Actually Make You a Better Developer

Anisubhra Sarkar (Ani) — Mon, 19 Jan 2026 13:41:13 +0000

For many developers, “building side projects” has become the go-to advice for skill growth, portfolio building, and job hunting.

But let’s be honest — not every side project actually makes you better.
Some end up half-finished, forgotten on GitHub, or too trivial to teach you anything meaningful.

So how do you build side projects that actually move the needle in your career as a developer?
Let’s break it down.

1. Build Projects That Solve Real Problems

The best side projects start with pain, not with a tech stack.

Instead of thinking “I want to try SvelteKit,” think:

“I hate how long it takes to track my expenses — can I fix that?”

That shift from tool-driven to problem-driven development changes everything.

💡 Examples:

Built a React Native expense tracker → learned about local storage, sync, and performance.
Created a data visualization dashboard → improved at working with APIs, charts, and complex states.
Made a browser extension → learned about browser APIs, permissions, and async flows.

Takeaway:
Pick projects that scratch your own itch — you’ll stay motivated and learn real-world problem-solving.

2. Go Beyond Tutorials

Tutorials are great for learning syntax, but projects teach systems thinking.

When you build something on your own, you’ll face:

State management challenges
Deployment issues
Version conflicts
API limits and rate throttling

That’s when true learning happens.

Try this approach:

Watch a tutorial to understand the basics.
Close it.
Rebuild a similar app from memory — add your own features, change the design, or use a different API.

✅ That’s how you move from copy-paste developer to problem-solving engineer.

3. Learn the Whole Stack (Even If You’re Frontend-Focused)

You don’t need to become a full-stack pro — but touching the backend gives you perspective.

Example:

You’re a React dev? Try adding an Express.js or Firebase backend.
You’re into Vue? Add authentication using Supabase or Clerk.
You’re a data visualization guy? Build a small ETL pipeline to feed your charts.

Even minimal backend exposure improves your understanding of API design, security, and performance bottlenecks — all invaluable in frontend roles.

4. Make It Deployable

If it’s not deployed, it’s not finished.

Shipping your project teaches you:

Environment setup & CI/CD
Versioning and dependency management
How to handle edge cases in production

Use tools like:

Vercel / Netlify for static or Next.js apps
Render / Railway for backend APIs
Firebase Hosting for full-stack prototypes

And always add a live demo link to your README — it shows initiative and completeness.

5. Focus on Depth, Not Quantity

You don’t need 10 small projects — you need 2–3 solid ones that demonstrate depth.

Example:

Instead of three to-do apps, build one advanced productivity tool with features like offline support, reminders, or data visualization.
Instead of cloning Instagram, build a lightweight photo-sharing app optimized for performance and accessibility.

Quality trumps quantity — especially when recruiters or peers review your portfolio.

6. Document and Reflect

Every project you build should leave a paper trail of learning.

Add a /docs or README.md file where you note:

What you learned
What challenges you faced
What you’d do differently next time

Bonus: Turn those notes into blog posts.
That’s how your side projects become content engines — boosting your visibility on Dev.to, Medium, or LinkedIn.

7. Collaborate or Contribute

Not every side project has to be solo.

Join open-source projects on GitHub.
Pair-program with a friend.
Participate in hackathons.

Collaboration introduces you to code reviews, version control discipline, and real-world teamwork — things tutorials can’t teach.

8. Treat Projects Like Experiments

Every side project doesn’t need to be a startup.
You’re experimenting — learning what works and what doesn’t.

Adopt this mindset:

“This project doesn’t have to succeed — it just has to teach me something.”

That freedom removes pressure and helps you ship faster.
Some experiments might even grow into products — but start with curiosity, not profit.

🧩 Real-World Examples

Goal	Example Project	What You’ll Learn
Improve UI/UX	Redesign a popular app’s landing page	Design systems, responsiveness
Learn APIs	Weather app with geolocation	Fetch API, error handling
Performance Optimization	Image gallery with lazy loading	Rendering performance, Lighthouse
Advanced State	Collaborative notes app	WebSockets, data sync
Security Awareness	Login form with JWT & rate limiting	Auth, security best practices

9. Show Your Work

Your side projects are your best resume.
Share them publicly on:

GitHub (for code)
Dev.to or Medium (for write-ups)
LinkedIn (for visibility)

Add visuals, deployment links, and what you learned — that’s what makes people take notice.

Even better, link related articles like:

These strengthen your credibility as a developer who understands depth, not just syntax.

Final Thoughts

Building side projects isn’t about ticking boxes — it’s about building intuition, systems thinking, and confidence.

The key isn’t how many projects you’ve built, but how much you’ve learned from each one.

The best side projects aren’t just cool — they change the way you think about building software.

So go ahead.
Build something. Ship it.
Then build the next one a little better.

JavaScript Design Patterns — And When You Should Actually Use Them

Anisubhra Sarkar (Ani) — Sun, 18 Jan 2026 10:51:44 +0000

JavaScript applications grow fast — more features, more modules, more complexity. Without structure, even senior developers end up drowning in tech debt.

Design patterns help you:

✔ Organize code
✔ Avoid duplication
✔ Improve maintainability
✔ Scale features safely
✔ Build predictable architecture

But not all classical design patterns make sense in JavaScript.
This article focuses only on patterns that are truly relevant to JS and used in real-world frontend development.

1. Singleton Pattern

What It Is

A pattern that ensures only one instance of an object exists.

Example

class AuthService {
  constructor() {
    if (AuthService.instance) return AuthService.instance;
    this.user = null;
    AuthService.instance = this;
  }
}

When to Use

Auth manager
Theme manager
App configuration
Global caching layer

Real-World Use

Your React/Angular app shouldn’t create multiple authentication handlers.
A singleton ensures global consistency.

2. Module Pattern

What It Is

Encapsulates private logic and exposes only what’s needed.

Example

const Cart = (() => {
  let items = [];
  function add(item) { items.push(item); }
  function get() { return items; }
  return { add, get };
})();

When to Use

Utility helpers
Data services
Local storage wrappers
Analytics modules

Real-World Use

Your storageService shouldn't expose internals like keys or prefixes — module pattern keeps everything safe and clean.

3. Observer Pattern

What It Is

Allows one object to notify multiple listeners when something changes.

Example

class Observable {
  constructor() { this.subscribers = []; }
  subscribe(fn) { this.subscribers.push(fn); }
  notify(value) { this.subscribers.forEach(fn => fn(value)); }
}

When to Use

Event systems
UI updates
Real-time data
Pub-sub based apps

Real-World Use

UI state updates in vanilla JS
Notifications
WebSocket live updates
Custom event emitters in React, Vue, or Node.js

4. Factory Pattern

What It Is

Creates objects without exposing creation logic.

Example

function createUser(type) {
  if (type === "admin") return { role: "admin", canDelete: true };
  return { role: "user", canDelete: false };
}

When to Use

Conditional object creation
Multiple API versions
Data adapters

Real-World Use

Payment integrations: Stripe, Paypal, Razorpay may return different shapes — a factory normalizes them.

5. Strategy Pattern

What It Is

Defines interchangeable algorithms and selects one dynamically.

Example

const feeStrategies = {
  credit: amt => amt * 0.02,
  upi: amt => amt * 0,
  debit: amt => amt * 0.01
};

function calculateFee(method, amount) {
  return feeStrategies[method](amount);
}

When to Use

Dynamic business logic
Replace long if-else chains
Pricing or discount calculations

Real-World Use

Payment fee calculation
Sorting functions for lists
Feature toggles

6. Decorator Pattern

What It Is

Wraps a function or object to extend behavior without modifying input code.

Example

function withLog(fn) {
  return (...args) => {
    console.log("Running", fn.name);
    return fn(...args);
  };
}

When to Use

Logging
Caching
Throttling / Debouncing
Authorization wrappers

Real-World Use

React higher-order components (withAuth)
Axios interceptors
Performance measurement wrappers

7. Proxy Pattern

What It Is

Intercepts interactions with an object.

Example

const user = { name: "Ani" };

const proxy = new Proxy(user, {
  get(target, prop) {
    console.log("Access:", prop);
    return target[prop];
  }
});

When to Use

Validation
Access control
Reactivity
Memoization

Real-World Use

Vue 3’s entire reactivity system is built with Proxy.

8. Command Pattern

What It Is

Encapsulates actions as objects (execute + undo).

Example

class Command {
  constructor(execute, undo) {
    this.execute = execute;
    this.undo = undo;
  }
}

When to Use

Undo/redo functionality
History tracking
Macro actions

Real-World Use

Figma undo stack
VS Code command palette
Browser-like navigation history

9. Adapter Pattern

What It Is

Converts an incompatible interface to a usable one.

Example

function axiosToFetch(response) {
  return {
    status: response.status,
    data: response.data
  };
}

When to Use

Migrating codebases
Integrating third-party APIs
Normalizing inconsistent data

Real-World Use

Converting axios responses into a unified format so your API layer works with both Fetch and Axios.

10. Mediator Pattern

What It Is

The Mediator pattern introduces a central controller that manages communication between multiple objects or components, preventing them from directly referencing each other.

Instead of components talking to each other directly (tight coupling), they communicate through the mediator.

Example

class UIEventMediator {
  constructor() {
    this.components = {};
  }

  register(name, component) {
    this.components[name] = component;
    component.setMediator(this);
  }

  notify(event, data) {
    switch (event) {
      case "USER_LOGGED_IN":
        this.components.navbar.updateUser(data);
        this.components.sidebar.showMenu();
        break;

      case "USER_LOGGED_OUT":
        this.components.navbar.clearUser();
        this.components.sidebar.hideMenu();
        break;
    }
  }
}

// Components
class Navbar {
  setMediator(mediator) {
    this.mediator = mediator;
  }

  updateUser(user) {
    console.log("Navbar updated with user:", user.name);
  }

  clearUser() {
    console.log("Navbar cleared");
  }
}

class Sidebar {
  setMediator(mediator) {
    this.mediator = mediator;
  }

  showMenu() {
    console.log("Sidebar menu shown");
  }

  hideMenu() {
    console.log("Sidebar menu hidden");
  }
}

// Usage
const mediator = new UIEventMediator();

const navbar = new Navbar();
const sidebar = new Sidebar();

mediator.register("navbar", navbar);
mediator.register("sidebar", sidebar);

// Trigger event
mediator.notify("USER_LOGGED_IN", { name: "Ani" });

When to Use

Multiple UI components depend on the same events
Components should not directly reference each other
Communication logic is getting scattered
You want a single source of truth for interactions

Real-World Use Cases

Modal systems (open/close affecting multiple components)
Authentication flows (login affects navbar, sidebar, permissions)
Dashboards where widgets react to global events
Complex forms with dependent fields
Micro-frontend communication layer

Real-Life Use Cases for These Patterns

Here’s how these patterns map to daily frontend work:

Scenario	Pattern	Why
Global auth / theme / config	Singleton	Shared state consistency
API services, storage utils	Module	Encapsulation + maintainability
UI reacting to data changes	Observer	One-to-many updates
Dynamic object creation	Factory	Clean, scalable creation logic
Switchable business rules	Strategy	Removes `if-else` chains
Wrapping logic with caching/logging	Decorator	Non-intrusive behavior
Input validation or state tracking	Proxy	Fine-grained control
Undo/Redo UI interactions	Command	Action history
Integrating external tools	Adapter	Makes different APIs work
Coordinating multiple UI components	Mediator	Centralized, decoupled communication

Final Thoughts

Design patterns aren’t magic. They’re tools to make your JavaScript cleaner, scalable, testable, and more maintainable.

Use them when they solve a real problem — not because they're “best practice.”

🛡️ How to Keep Your Application Updated on the Latest Security Threats & Vulnerabilities

Anisubhra Sarkar (Ani) — Sun, 30 Nov 2025 07:44:24 +0000

A complete, repeatable lifecycle for keeping your application secure

Modern applications face a constant wave of threats — supply-chain attacks, browser exploits, token theft, package vulnerabilities, misconfigurations, and more. Most teams treat security updates as “catch-up work,” but real protection requires a systematic, end-to-end security intelligence framework.

Below is a practical E2E framework — a cycle your team can follow to continuously stay updated on security risks and keep your app safe.

The E2E Security Awareness Framework

This framework has 6 stages:

Observe — Monitor sources for new threats
Detect — Identify which threats impact your stack
Analyze — Understand severity, exploitability, and exposure
Mitigate — Apply updates, patches, and configuration changes
Validate — Audit, test, and verify secure behavior
Educate — Continuously upskill developers

Each stage includes tools, examples, and best practices.

1️⃣ OBSERVE — Monitor Trusted Security Sources

Your first job is staying aware. This means actively monitoring reliable, reputable sources of security information.

Core sources

OWASP (Top 10, cheat sheets, updates)
CVE Details (vulnerabilities in frameworks & libraries)
NVD (National Vulnerability Database)
Security Blogs (Google, Cloudflare, Mozilla)
Hacker News Security (real-time exploit discussions)

Team subscriptions

RSS feeds
Weekly summaries
Slack/Teams automated alerts

Goal: Never miss a vulnerability relevant to your ecosystem.

2️⃣ DETECT — Identify Threats Relevant to Your Application

Not all vulnerabilities matter.
Detection identifies which ones apply to your codebase, dependencies, or infrastructure.

Automated Dependency Scanning

npm audit
GitHub Dependabot
Snyk
OWASP Dependency-Check

Framework-specific alerts

React, Angular, Vue announcements
Node.js security releases
Vite, Webpack, Rollup security updates

Environment-level detection

Browser API changes
Infrastructure provider advisories (AWS, Vercel, Cloudflare)

Goal: Quickly spot vulnerabilities that could impact your app.

3️⃣ ANALYZE — Prioritize by Severity & Risk

This is where senior engineers add value.

Ask:

1. Severity

Critical?
Medium?
Low?

2. Exploitability

Can it be exploited remotely?
Does it require authentication?
Does it need physical access?

3. Impact

Can it leak data?
Does it allow remote execution?
Does it allow token theft?

4. Exposure in your app

Is the affected package actually used?
Is the vulnerable method being called?
Is the code path public-facing?

Recommended tools

CVSS score
Snyk impact path analysis
Code-level dependency graph review

Goal: Understand which vulnerabilities matter most.

4️⃣ MITIGATE — Patch, Update & Reconfigure

This is where you apply fixes.

Core mitigation actions

Update npm dependencies
Apply security patches
Patch container images
Update Node.js versions
Remove deprecated APIs
Add or tighten CSP & security headers
Fix insecure tokens/cookies
Add rate limiting & validation

Examples

Updating a vulnerable JWT library
Patching a cross-site scripting hole
Replacing insecure innerHTML usage
Adding SameSite to cookies
Adding input sanitization

Good practice:

Apply zero-downtime mitigation:

Feature flags
Phased rollouts
Canary deploys

Goal: Fix vulnerabilities safely and quickly.

5️⃣ VALIDATE — Test & Audit Continuously

After mitigation, ensure everything works securely.

Security Testing

Automated test suites for auth flows
Pen testing (internal or external)
SAST (Static Application Security Testing)
DAST (Dynamic Application Security Testing)
Semgrep policies
ZAP scans
Gitleaks for secrets

Checklist to verify

No broken auth flows
No leaked tokens
No incorrect role permissions
No unauthenticated API endpoints
No weak CORS rules
No client-side XSS leaks

Continuous Integration

Add:

Security linting
Dependency checks
Secrets scanning …to your CI pipeline.

Goal: Ensure mitigations didn’t break features and didn’t introduce new risks.

6️⃣ EDUCATE — Build a Security-Aware Engineering Culture

A secure application requires secure developers.

Developer training topics

XSS prevention
CSRF protection
Token handling
CORS policies
Secure API communication
Rate limiting
Secure cookies
Avoiding direct DOM manipulation
Supply-chain attack awareness

Ways to educate teams

Monthly knowledge-sharing sessions
Postmortems of real breaches
Security champions in each feature team
Architecture review + threat modeling

Use threat modeling regularly

Ask:

“How can this new feature be abused?”
“What happens if a token is stolen?”
“What if input is malicious?”
“What if rate limits are bypassed?”

Goal: Create engineers who think security-first.

Putting It All Together — The E2E Security Loop

Here’s the complete framework in one cycle:

Observe → Stay updated via feeds, blogs, communities
Detect → Find which threats affect your code
Analyze → Prioritize based on severity & exploitability
Mitigate → Patch, update, or reconfigure
Validate → Audit and test continuously
Educate → Grow team security maturity

Final Thoughts

Staying updated on threats is not optional — it’s a core engineering responsibility.

With this E2E security framework, your application will be:

More resilient
More compliant
More trustworthy
More future-proof

🌍 Why We Need Accessibility (a11y) — A Practical Guide for Modern Web Developers

Anisubhra Sarkar (Ani) — Fri, 28 Nov 2025 06:39:24 +0000

When developers hear the word accessibility (a11y), they often think of “nice-to-have improvements,” “edge cases,” or “extra work that slows down development.”

But accessibility is not optional.
Not in 2025.
Not with modern devices.
Not with global user bases.
Not with legal and ethical responsibilities in tech.

Accessibility is fundamental to building real, usable, inclusive digital experiences.

This article explains why accessibility matters, backed by real-world benefits, legal requirements, and examples from day-to-day frontend development.

1. Accessibility Is About Real Users — Not Just Disabilities

Not all accessibility needs are permanent.
There are three types of impairments:

Permanent

Blindness
Deafness
Motor impairments
Cognitive conditions

Temporary

Broken arm
Eye infection
Loud environment

Situational

Holding a baby in one arm
Sun glare on screen
Weak network
Commuting

Accessibility helps everyone — not just a subset of users.

Real-Life Example

A commuter with one hand on a train needs large touch targets.
A developer working late at night needs proper text contrast.
Your search bar’s autocomplete helps users with cognitive load and people in a hurry.

Accessibility is universal usability.

2. Accessibility Increases Conversions & Retention

Businesses often overlook this:
Accessible websites make more money.

Why?

More users can complete flows
Frictionless onboarding
Improved SEO (search engines read accessible pages better)
Better mobile conversions
Clearer UX reduces drop-offs

Real-Life Example

A checkout button that is:

Too small
Low contrast
Not reachable via keyboard

…will cause:

Lost sales
Higher abandonment
Frustration

Fixing accessibility issues in forms alone is known to increase conversions by 15–30%.

3. Accessibility Is a Legal Requirement in Many Countries

Ignoring accessibility can lead to lawsuits.

Common laws worldwide:

ADA (United States)
Section 508 (US Government)
EN 301 549 (Europe)
Accessibility Canada Act
India Guidelines for Accessibility
UK Equality Act

Even private companies have faced lawsuits for inaccessible websites (Domino’s, Target, Netflix).

Developers often underestimate this part —
but if your app fails accessibility audits, your company risks legal penalties and reputational damage.

4. Accessibility Improves Overall UX & Code Quality

When you make a feature more accessible, it naturally becomes:

Easier to use
Easier to understand
More consistent
More robust
Better structured

Real-Life Frontend Examples

❌ Without Accessibility

<button onClick={save}>Save</button>

No description
No keyboard support (if replaced with a div)
No focus styling

✅ With Accessibility

<button onClick={save} aria-label="Save changes">Save</button>

Clear meaning
Automatic keyboard support
Better semantics
Screen-readers understand context

Just using proper HTML (button instead of div) improves accessibility more than most devs realize.

5. Accessibility Helps With SEO (Yes, Really)

Google’s crawlers use:

Semantic HTML
ARIA roles
Image alt text
Proper heading structure
Link clarity

This directly improves:

Discoverability
Ranking
Page structure

Real-Life Example

A product listing like this:

❌ div soup
❌ No headings
❌ No alt text
❌ No labels

…is both inaccessible and SEO-poor.

Accessible markup → more SEO visibility → more traffic.

6. Accessibility Future-Proofs Your App

As technology evolves:

Voice interfaces
AR/VR experiences
Smart devices
Wearables

…all rely heavily on accessible structure, semantics, and metadata.

Example

If your app uses proper ARIA roles and labelled inputs, screen readers and voice assistants like Siri or Google Assistant can interact with it.

You’re not building for screens only —
you’re building for the next decade of interfaces.

7. Accessibility Reduces Maintenance & Tech Debt

Accessible apps are:

Easier to refactor
Easier for new developers to understand
Easier to test
More resilient to redesigns

Real-Life Example

A modal built with:

Semantic HTML
Focus traps
Escape key support
ARIA labels
Proper hierarchy

…will work across redesigns without rewriting half the logic.

Accessibility forces clean architecture, not hacks.

8. Accessibility Expands Your User Base

There are 1+ billion people globally with some form of disability.

But if you include:

Elderly users
People with temporary impairments
Users in low-bandwidth regions
Users with older devices
New internet users in developing countries

Your potential user base becomes everyone.

Accessibility is about:

Inclusivity = Market Reach = Product Success

❤️ 9. Accessibility Is the Ethical Thing To Do

Beyond business, beyond law, beyond UX —
accessibility is about basic human fairness.

The web should be accessible to everyone.
If someone can’t use your app because you didn’t add:

Alt text
Labels
Contrast
Keyboard navigation

…it’s not a user’s fault.
It’s a design decision.

As developers, we build experiences that millions rely on daily.
We should build them responsibly.

Final Thoughts

Accessibility isn’t an optional enhancement.
It’s a core requirement for any modern, user-friendly, high-quality web application.

If you want to build better products, reach more users, and be a standout developer in your team:

Use semantic HTML
Add alt text
Support keyboard navigation
Ensure enough contrast
Test with screen readers
Think about real-world limitations
Make accessibility part of your development process

Accessibility isn’t extra work.
It’s part of being a great developer.

🏌How to Convince Stakeholders to Adopt New Technology in Your Project

Anisubhra Sarkar (Ani) — Sat, 22 Nov 2025 12:11:32 +0000

Introducing new technology into an existing product is rarely a technical problem — it’s a people and business problem.

You may have solid reasons to adopt:

React Server Components
A new state management library (Zustand, Signals, TanStack Query)
Web Components
A new build tool (Vite, Turbopack)
A design system overhaul
A new bundler or performance tooling
Micro-frontend architecture

…but if stakeholders aren’t convinced, none of it gets approved.

As a senior frontend engineer, your job isn’t just to write great code — it’s also to help decision-makers understand why a technology shift is valuable, what risks exist, and how the change impacts business outcomes.

This guide shows how to do exactly that.

1. Start With the Business Outcome, Not the Tech

Stakeholders don’t care about:

JSX vs templates
Virtual DOM vs Signals
Bundler speeds
Boilerplate reduction

They care about:

Faster delivery
Lower maintenance cost
Improved performance (SEO, conversions)
Reduced bugs
Better user experience
Competitive advantage

❌ “We should use React Server Components because they reduce client-side hydration.”

✅ “Switching to RSC will reduce bundle size by ~30–40%, improving page load time and increasing checkout conversions by up to 8%.”

Always translate tech benefits into money saved, money earned, or risk reduced.

2. Provide Measurable Before/After Metrics

Numbers speak louder than enthusiasm.

Example (Frontend Performance):

Metric	Current	After Proposed Change
TTI (Time to Interactive)	4.2s	2.1s
FCP	1.8s	1.1s
Bundle Size	610 KB	380 KB
Core Web Vitals	Needs Improvement	Good

Example (Developer Productivity):

Activity	Before	After
Build Time	28s	2.1s (Vite)
Developer Feedback Loop	Slow	Instant
PR Merge Time	~3 days	~1 day

This makes the pitch concrete and hard to ignore.

3. Show a Small, Low-Risk Proof of Concept (POC)

Stakeholders fear unknowns.

A proof-of-concept reduces uncertainty.

Examples:

Migrating one small component using the new technology
Converting one API call to React Query
Building one page using Server Components
Replacing Redux in only the Checkout flow
Testing Web Components inside the Design System only

Keep it:

Small
Testable
Reversible
Time-boxed

Then demo:

Performance improvements
Cleaner code
Developer workflow improvements
Reduced bugs

4. Present a Risk Management Strategy

Stakeholders worry about:

Migration cost
Downtime
Developer training
Recruiting difficulty
Vendor lock-in
Technical debt

Address risks upfront.

Example:

Risk: Developers aren’t familiar with Zustand.
Mitigation: 1-day workshop + internal docs + pair programming.

Risk: Refactoring the login system may break authentication.
Mitigation: A/B rollout + feature flags + fallbacks.

Showing that you’ve thought about risk makes you look like a leader, not just a tech enthusiast.

5. Compare Alternatives Fairly (Not Emotionally)

Never say:

❌ “This is better because everyone uses it.”

Instead do:

Feature Comparison (Example: Redux vs Zustand)

Criterion	Redux Toolkit	Zustand
Boilerplate	High	Low
Learning Curve	Moderate	Very low
Bundle Size	Larger	~1KB
Async Logic	Built-in	Add manually
Ecosystem	Mature	Growing
Ideal For	Complex apps	Mid-sized apps

This shows:

You evaluated multiple choices
You’re not biased
The decision is rational, not trendy

6. Estimate the ROI (Return on Investment)

ROI is the strongest convincing factor.

Example ROI statement:

“Migrating to Vite will save ~4 hours per developer per week due to faster builds and hot reload.
For a team of 8 developers, that’s ~32 hours weekly.
In one year, this equals ~1,600 hours saved — equivalent to hiring an extra engineer for free.”

Now it's not a “tech migration.”
It’s a cost-saving initiative.

7. Show What Competitors or Industry Leaders Are Doing

Stakeholders care deeply about staying competitive.

Examples:

React Server Components are used by Shopify, Vercel, Meta.
Web Components power design systems at Airbnb, GitHub, Salesforce.
TanStack Query is a standard at Netflix, TikTok, Shopify.
Vite is now the default in Vue, Svelte, and Astro projects.

This signals:
“We’re not experimenting — we’re aligning with industry leaders.”

8. Communicate in Their Language (Not Engineer Language)

Different stakeholders care about different things.

Engineering Managers

Maintainability
Team productivity
Long-term architecture

Product Managers

Faster features
Predictable delivery
Less regression risk

Business / Execs

Reduced cost
Better performance → more revenue
Competitive edge

Don’t pitch the same way to everyone.

9. Use the “3–Step Stakeholder Pitch Framework”

When presenting the new tech, structure it like this:

1. The Problem

“Our bundle size has reached 700KB, hurting SEO and conversion.”

2. The Solution

“Adopting React Server Components will reduce required client-side JS.”

3. The Business Benefit

“This can improve load time by 30–40% and may increase conversion rate by 5–8%.”

Short, clear, outcome-driven.

Final Thoughts

Introducing new technology is never just about the tech — it’s about strategy, communication, and alignment with business goals.

If you want stakeholders to say “yes”:

Speak in outcomes, not features
Show a small POC
Quantify benefits
Address risks proactively
Use benchmarks and examples
Present ROI
Communicate based on audience

When you do this well, you’re not just a developer —
you become a technical leader stakeholders trust.

🏄🏻‍♂️ How to Be Productive, Deliver More, and Get Ahead With AI (Without Burning Out) — A Frontend Developer’s Perspective

Anisubhra Sarkar (Ani) — Mon, 17 Nov 2025 15:38:29 +0000

Productivity in 2025 is no longer about doing more tasks — it’s about doing the right things, faster, with AI as your multiplier.

As a senior frontend developer, you’re juggling:

Feature planning
UI/UX discussions
Tech design
Coding
Reviewing PRs
Supporting juniors
Production issues
Documentation
Deadlines

AI helps you streamline all of this — if you use it right.

This article walks through how to be insanely productive, with real-world scenarios from a frontend engineer’s daily workflow.

The New Productivity Formula for Developers

Productivity = Time × AI Leverage × Focus — Distractions

AI gives you leverage.
Focus gives you momentum.
Together, they turn you into a 10× engineer without burning out.

1. Automate the Low-Value Work

(Real-World Frontend Example: PR Summaries, Documentation, and Boilerplate)

As a senior dev, you shouldn’t spend time on:

Writing repetitive PR descriptions
Documenting obvious changes
Creating basic React components
Generating API mocks
Writing unit test skeletons
Searching for snippets you’ve written 100 times

AI can do all of that instantly.

Example:

You're building a “Saved Cards” screen. After finishing the UI:

Instead of writing this manually:

PR title
PR description
Test cases
Component documentation
Edge cases
API mock response

You paste your diff or code into AI and say:

“Generate a clear PR description, test cases, and UX edge cases for this component.”

You save 20–30 minutes per PR.

Multiply that over a year… that’s days of time saved.

2. Use AI to Improve Your Thinking

(Real-World Frontend Example: Architecture & Trade-Off Decisions)

As a senior dev, your biggest responsibility is decision-making.

Should you:

Use debounce or throttle?
Use Zustand or Redux Toolkit?
Use React Query or write your own fetch wrappers?
Cache API responses or re-fetch?
Use Server Components or client-only?
Use Chakra UI or Tailwind?

Instead of endless Google rabbit holes, AI helps you reason instantly.

Example:

You’re building a dashboard with frequent API updates.

Ask AI:

“Given a real-time dashboard with 10+ API calls, compare polling, WebSockets, and SSE with pros/cons, scalability, cost, and ease of implementation.”

You get:

Trade-offs
Real-world implications
Suggested approach
Performance notes

AI becomes your architecture assistant, helping you avoid bad decisions.

3. Write 10× Faster

(Real-World Example: Emails, Tech Specs, Feature Summaries)

Senior developers write more than juniors:

RFCs
Design documents
Comments
Onboarding docs
Status updates
Bug analysis

AI eliminates the blank-screen problem.

Example:

Your PM asks:

“Can you send a quick summary of the new caching strategy?”

Instead of typing manually, you say:

“Summarize this caching strategy in a non-technical tone for product managers.”

AI produces a clean paragraph. You edit it for accuracy. Done in 2 minutes.

4. Supercharge Your Learning

(Real-World Example: Debugging & Understanding Complex Browser Behavior)

Learning on the job is constant, especially in frontend where tools evolve daily.

Example:

You're debugging why a modal animation feels janky on low-end Android devices.

Ask AI:

“Explain how browser layout, paint, and composite cycles work using this example animation code.”

AI breaks down:

Which CSS properties trigger repaint
How GPU compositing works
Why transform performs better than top/left
How to measure jank using DevTools

You learn in 5 minutes what could have taken an hour.

5. Build Side Projects Faster

(Real-World Frontend Example: Creating Full Stacks in a Weekend)

Side projects differentiate senior developers from others.
AI helps you build 3–5× faster.

Example:

You want to build a “Latency Checker for AWS Media Regions”

You ask AI:

To generate an architecture using React + AWS Lambda
To provide the initial UI layout
To create loading skeleton states
To generate sample test data
To generate API handlers
To generate Lighthouse performance improvements

It doesn't replace you.
It boosts your throughput.

What used to take 2 weeks can now be done in 3 days.

6. Stay Consistent, Not Motivated

(Real-World Example: Weekly Planning and Task Breakdown)

Motivation dies.
Consistency wins.

AI helps you plan realistically.

Example:

On Monday, you tell AI:

“Help me plan my week as a senior frontend dev working on a dashboard project. Break tasks into 45-minute work blocks.”

It generates:

Feature tasks
Refactor tasks
Testing blocks
Review blocks
Buffer time for bugs

By Wednesday evening, you ask:

“Show me what I accomplished and what I should move to tomorrow.”

AI acts like:

Project manager
Accountability partner
Planning assistant

You stay on track, even on low-motivation days.

7. Use the AI Feedback Loop

(Real-World Example: Improving PRs and Coding Style)

After finishing code, ask AI:

“Review this code for readability, best practices, and performance. Suggest improvements.”

AI points out:

Complex conditions
Missing memoization
Large components
Repeated logic
Inefficient data structures

You're not just writing faster —
you’re writing better.

This compounds your skills over months.

8. Avoid the Biggest Mistake: Fully Delegating Thinking

AI writes code.

But only you know:

App architecture
Business rules
Edge cases
Team standards
Performance strategies

AI should assist —
not replace judgment.

Example:

AI writes a React Query hook.
You must still:

Add cache configs
Handle race conditions
Apply correct stale times
Handle OAuth expiries
Consider offline scenarios

This is why senior devs remain invaluable.

9. Your Competitive Advantage: Learning & Delivering 5× Faster

The modern frontend ecosystem moves ridiculously fast:

React Server Components
Signals architecture
Browser performance APIs
Web components
Edge runtimes
AI-assisted dev flows

The developer who learns faster
wins faster.

AI gives you:

A coach
A tutor
A debugger
A reviewer
A senior architect
A documentation generator

All in one.

That's unfair leverage —
use it.

Final Thoughts — The Future Belongs to AI-Augmented Developers

AI won't replace frontend developers.
But AI-augmented developers will outperform everyone else.

If you want to deliver more, grow faster, and stay ahead:

Automate low-value tasks
Use AI for thinking, planning, and debugging
Build projects faster
Communicate better
Learn continuously
Use AI as leverage, not a crutch

Don’t try to compete with AI.
Collaborate with it — and multiply your output.

Stop Misusing : When to Use
and for Better Performance and Accessibility

Anisubhra Sarkar (Ani) — Wed, 12 Nov 2025 16:40:30 +0000

Images aren’t just visual decorations — they’re essential for communication, usability, and engagement on the web. But using the right HTML tag makes a huge difference in accessibility, SEO, and performance.

Developers often use <img> for everything, but HTML actually gives us a trio of elements — <img>, <figure>, and <picture> — each serving a unique purpose.

Let’s explore what each does, when to use them, and how they work together in real-world scenarios.

1. `<img>` — The Core Image Tag

What It Does

The <img> element is the simplest and most direct way to display an image on a webpage. It’s used when the image is purely visual content and doesn’t need extra context, captions, or dynamic behavior.

<img src="cat.jpg" alt="A cute cat relaxing on the couch">

When to Use

You’re showing a standalone image within content (like a thumbnail, logo, or product image).
The image isn’t complex enough to need captions or responsive logic.
You want quick, lightweight embedding for images.

Why It Matters

The <img> tag integrates tightly with accessibility tools and search engines. Screen readers depend on the alt attribute to describe the image, while search engines use it to understand context for image indexing.

✅ Best Practices

Always use alt text — describe what the image means, not just what it shows:

   <img src="team-photo.jpg" alt="Our development team at the 2024 Hackathon">

Add lazy loading to defer offscreen images:

   <img src="product.jpg" alt="Product image" loading="lazy">

Use descriptive filenames (office-interior.webp instead of IMG_001.webp) to improve SEO.
Choose modern formats like WebP or AVIF for better compression and smaller file sizes.

🚫 Avoid

Using <img> for decorative icons — use CSS background images or inline SVGs instead.
Adding images without alt, as it harms accessibility and SEO.

2. `<figure>` — Semantic Grouping for Images & Captions

What It Does

The <figure> tag wraps media — like an image, chart, or video — along with an optional <figcaption>.
It gives semantic meaning to the visual content and its caption, treating them as one unit.

<figure>
  <img src="cat.jpg" alt="A cat lounging on a windowsill">
  <figcaption>Cats love sunny spots and cozy corners.</figcaption>
</figure>

When to Use

You want to add a caption or explanation to an image.
The image conveys data, insight, or documentation value (not just decoration).
You’re writing blogs, documentation, case studies, or scientific content.

💡 Real-World Example

In technical blogs or dashboards, you might show a chart or visual data:

<figure>
  <img src="revenue-growth.png" alt="Bar chart showing revenue growth by quarter">
  <figcaption>Figure 1: Q4 2024 revenue grew 35% year-over-year.</figcaption>
</figure>

This gives the image a label and context, improving both comprehension and SEO.

Why It Matters

The <figure> and <figcaption> pairing enhances semantic meaning.
Screen readers automatically associate captions with images.
It improves accessibility and content structure, especially for academic or data-driven sites.

✅ Best Practices

Use <figcaption> only for captions — not for unrelated descriptions.
A <figure> can contain multiple elements, like an image and a chart legend.
You can even use <figure> for videos or code snippets:

   <figure>
     <video controls src="demo.mp4"></video>
     <figcaption>Figure 2: Product demo in action.</figcaption>
   </figure>

3. `<picture>` — Responsive and Art-Direction Images

What It Does

The <picture> element lets you define multiple image sources for different conditions — like screen size, resolution, or format support.
It gives you fine-grained control over what image loads and when, without relying solely on CSS.

<picture>
  <source srcset="cat.avif" type="image/avif">
  <source srcset="cat.webp" type="image/webp">
  <source media="(min-width: 800px)" srcset="cat-large.jpg">
  <img src="cat-small.jpg" alt="A playful cat sitting on a sofa">
</picture>

When to Use

You need different image sizes for desktop and mobile.
You want to serve modern formats (like AVIF or WebP) with fallbacks.
You’re optimizing hero images, banners, or large visuals.

💡 Real-World Example: Art Direction

<picture>
  <source media="(max-width: 600px)" srcset="banner-mobile.jpg">
  <source media="(min-width: 601px)" srcset="banner-desktop.jpg">
  <img src="banner-default.jpg" alt="Mountain view with sunset sky">
</picture>

This way, mobile users get a cropped, lighter image, while desktop users get the full scenic version — reducing load time and improving visual quality.

Why It Matters

Greatly improves performance and bandwidth efficiency.
Helps maintain visual storytelling across devices (“art direction”).
Allows format fallbacks — older browsers can still load JPEGs when newer ones prefer WebP or AVIF.

✅ Best Practices

Always include a fallback <img> for browsers that don’t support <picture>.
Optimize each source file — don’t just resize; re-crop for context.
Test across devices — ensure that the image still aligns with layout and typography.

🧠 Summary: Choosing the Right Tag

Tag	Purpose	Use When	Example
`<img>`	Display a basic image	Simple visuals like logos, product images, blog graphics	`<img src="logo.webp" alt="Company logo">`
`<figure>`	Add semantic meaning and captions	Illustrations, charts, code samples, photos with captions	`<figure><img><figcaption></figcaption></figure>`
`<picture>`	Serve responsive or alternate images	Hero banners, adaptive layouts, performance-focused sites	`<picture><source><img></picture>`

Combining `<picture>` and `<figure>`

For the best of both worlds — responsive design + semantic meaning — combine them:

<figure>
  <picture>
    <source srcset="cat.webp" type="image/webp">
    <source srcset="cat.jpg" type="image/jpeg">
    <img src="cat.jpg" alt="A cat curled up in a blanket">
  </picture>
  <figcaption>Figure 3: Lazy mornings — optimized for both users and browsers.</figcaption>
</figure>

This combination ensures your content is responsive, accessible, and semantically rich.

Final Thoughts

HTML gives us more than one way to include images — because not all images are created equal.

Use <img> for simple content images.
Use <figure> when you need captions or contextual meaning.
Use <picture> when performance and responsiveness matter most.

Together, they form a foundation for accessible, performant, and semantically meaningful web content — something every modern frontend developer should master.

Are Web Components Finally Ready to Replace Frameworks?

Anisubhra Sarkar (Ani) — Mon, 03 Nov 2025 07:03:06 +0000

For years, frameworks like React, Angular, and Vue have dominated frontend development.
But in recent times, you might’ve noticed a quiet shift — more developers and companies are revisiting a question that once felt absurd:

“Do we even need a framework anymore?”

Enter Web Components — a set of browser-native APIs that allow developers to create reusable, encapsulated, and framework-agnostic UI elements.
But are they really ready to replace frameworks in 2025? Let’s find out.

What Exactly Are Web Components?

Web Components are not a single technology — they’re a collection of standardized APIs that enable you to build custom HTML elements with encapsulated logic and styles.

They’re built on four main pillars:

Custom Elements
Define your own HTML elements (<user-card>, <date-picker>) with custom behavior.
Shadow DOM
Provides encapsulation so your component’s styles and markup don’t leak or get affected by the global DOM.
HTML Templates
Use the <template> tag to define reusable chunks of markup that can be cloned and rendered efficiently.
ES Modules
Enable modular, reusable, and importable component logic — without needing a bundler or framework.

Why Web Components Matter

For the first time, browsers give us a framework-like experience natively, without extra abstractions.

They offer:

Encapsulation: Styles and DOM scoped per component.
Reusability: Works across any framework (or none at all).
Stability: Backed by W3C standards, not a company or library.
Interoperability: You can use the same component in React, Vue, or even plain HTML.

Example: A Simple `<user-card>` Component

<user-card></user-card>

<script>
  class UserCard extends HTMLElement {
    constructor() {
      super();
      const shadow = this.attachShadow({ mode: "open" });

      shadow.innerHTML = `
        <style>
          .card {
            padding: 1rem;
            border: 1px solid #ccc;
            border-radius: 8px;
            font-family: sans-serif;
            max-width: 200px;
          }
          .name {
            font-weight: bold;
            margin-bottom: 0.5rem;
          }
        </style>
        <div class="card">
          <div class="name">John Doe</div>
          <div class="email">johndoe@example.com</div>
        </div>
      `;
    }
  }

  customElements.define("user-card", UserCard);
</script>

You can drop this <user-card> element anywhere — React, Angular, Vue, or even static HTML — and it’ll just work.

That’s the power of standardization.

The Case For Web Components

✅ 1. Framework-Agnostic Reusability

Web Components are like universal building blocks. You can reuse the same <date-picker> or <tooltip> in React, Angular, or even legacy apps.

That’s why big organizations like Salesforce (Lightning Web Components), Ionic, and Adobe Spectrum are using them for design systems shared across teams.

✅ 2. Performance by Design

Unlike frameworks, there’s no virtual DOM overhead.
The browser natively handles rendering and updating — meaning faster startup times and smaller bundles.

✅ 3. Encapsulation & Maintainability

Shadow DOM provides true isolation.
Your CSS and JS can’t leak into the global scope — a godsend for large-scale applications with dozens of dev teams.

✅ 4. Long-Term Stability

Frameworks come and go. (RIP Ember, Meteor 👋)
Web Components are built on open web standards, ensuring they’ll work as long as browsers exist.

⚠️ The Case Against Web Components

❌ 1. Developer Experience Gaps

While native APIs are powerful, they’re also verbose.
Managing reactivity, state updates, or complex data flow feels clunky compared to React’s useState or Vue’s ref().

❌ 2. Missing Ecosystem

Frameworks provide mature ecosystems — routing, state management, testing, SSR, and dev tools.
Web Components require assembling these pieces manually (or via helper libraries).

❌ 3. Integration Pain

Yes, Web Components can work inside React or Vue — but passing data or listening for events often needs extra wrappers or bridges.

❌ 4. Limited Reactivity

Unlike frameworks with reactive bindings, you’ll need manual DOM updates (this.shadowRoot.querySelector(...)) or frameworks like Lit to simplify reactivity.

The Rise of Web Component Libraries

To bridge these gaps, a new generation of libraries makes Web Components easier to build:

Library	Description	When to Use
Lit	Lightweight library from Google for reactive Web Components	When you need a “React-like” DX with standards
Stencil.js	Compiler for reusable, framework-agnostic components	Perfect for design systems
Hybrids	Declarative functional approach for custom elements	For simpler, functional-style components
FAST (by Microsoft)	Enterprise-grade Web Component framework	Ideal for scalable UI systems

These tools give Web Components the reactivity and ergonomics developers expect — without locking them into a specific framework.

⭐️ When Web Components Shine

Use Web Components When:

You’re building a design system or component library shared across multiple frameworks.
Your team works on micro-frontends with different stacks.
You want to avoid framework lock-in.
You need stable, long-term UI elements for enterprise products.

🚫 When to Stick with Frameworks

Use React, Angular, or Vue When:

You’re building feature-rich, stateful SPAs.
You need routing, SSR, or hydration out of the box.
Your app depends heavily on reactivity and developer tooling.
You prioritize DX and ecosystem over raw standardization.

🚀 Performance Snapshot (2025)

Metric	Web Components	React (v19)	Vue (v3.4)	Angular (v18)
Startup Time	⚡ Fast (no runtime)	Moderate (Virtual DOM)	Fast	Moderate
Bundle Size	Small	Medium	Small	Larger
Memory Footprint	Low	Medium	Low	High
Reactivity	Manual (or via Lit)	Excellent	Excellent	Good
Cross-Framework Reuse	✅ Excellent	❌ Limited	❌ Limited	❌ Limited

🧭 Real-World Adoption

Ionic Framework rebuilt its entire UI layer using Stencil-powered Web Components.
GitHub uses Web Components for its UI primitives (<details>, <clipboard-copy>).
Adobe and Salesforce rely on them for unified design systems.

The ecosystem is no longer experimental — it’s quietly production-ready.

Final Thoughts

So, are Web Components ready to replace frameworks?

Not entirely — but they’ve finally earned their seat at the table.

Frameworks still offer superior tooling, reactivity, and developer ergonomics.
But Web Components now excel at cross-framework reusability, long-term stability, and performance — things frameworks struggle with.

The future probably isn’t any JS Framework vs Web Components —
It’s Framework + Web Components, working together.

🤖 AI Is Coming for Your Code — But Here’s Why Frontend Devs Shouldn’t Worry

Anisubhra Sarkar (Ani) — Fri, 31 Oct 2025 08:17:52 +0000

AI is transforming how we write, test, and ship code. Tools like GitHub Copilot, ChatGPT, and Codeium can already generate components, suggest fixes, and even build full apps from prompts.

It’s natural to wonder — if AI can write code, where does that leave developers?

As a senior frontend engineer, I’ve seen this shift up close. And here’s the truth:

AI will change how we code — but it won’t replace why we code.

Let’s unpack what AI means for frontend development and why human creativity still holds the upper hand.

1. AI Is Great at Code — But Not at Context

AI models excel at pattern recognition. They’re great at writing code that looks right — but not always code that works right for your specific system.

Example:
Ask an AI to build a “responsive navbar with dark mode” — it’ll give you HTML/CSS that looks solid.
But ask it to integrate that with your team’s design system, authentication layer, or analytics hooks — that’s where things fall apart.

Frontend isn’t just about syntax. It’s about:

Understanding user journeys.
Handling inconsistent APIs.
Balancing performance, accessibility, and design trade-offs.

AI doesn’t have that intuition — yet.

2. Frontend Is as Much Design as It Is Code

Building great frontends means solving for humans:

What happens when the network drops?
Can users with disabilities navigate the app easily?
Does it feel fast and responsive on a low-end phone?

AI can generate markup, but it can’t feel friction or frustration like users do.

✅ Human devs will always be needed to:

Test real user experience across devices.
Make trade-offs between visual fidelity and performance.
Ensure accessibility (ARIA, focus states, keyboard navigation).

AI might suggest “what looks good,” but only you can decide “what feels right.”

3. The Rise of the “AI-Augmented Developer”

Rather than replacing developers, AI is becoming a power multiplier.

Today’s strongest engineers aren’t the ones typing the fastest — they’re the ones prompting the smartest.

Here’s what that looks like in real-world frontend work:

Faster scaffolding: Generate boilerplate React components or routes using Vercel v0, Bolt.new, or Locofy.ai.
Smarter debugging: Ask GitHub Copilot X or ChatGPT 5 to explain a stack trace or suggest fixes.
Code review help: Tools like Codeium and Aidev can flag complexity, unused dependencies, or performance pitfalls.
Refactoring aid: Use Cursor IDE or Sourcegraph Cody to modernize legacy React codebases with better hooks or TypeScript types.

⭐️ The developers who win in the AI era will be those who:

Use AI to automate the repetitive, so they can focus on the creative.

4. Why Frontend Is Harder for AI to Fully Automate

Frontend code lives at the intersection of human behavior and system logic.
AI can’t perfectly predict:

How users will interact with a feature.
What’s visually intuitive for different cultures.
The emotional tone of microinteractions or animations.

While AI can handle back-end boilerplate (CRUD, schemas, APIs), frontend development requires empathy — a trait uniquely human.

5. The Real Future: Human-AI Collaboration

Imagine this workflow:

You describe a component → Vercel’s v0 instantly generates JSX with Tailwind.
You tweak styles → AI updates the design system tokens automatically.
AI runs accessibility and performance checks via Lighthouse AI integration.
You deploy with human oversight, focusing on interaction quality and design feel.

That’s the direction we’re heading — AI as a design and code co-pilot, not a replacement.

Frameworks like React, Next.js, and SvelteKit are already integrating AI-assisted tooling for performance insights, testing, and documentation.

AI will handle the repetitive 60% — leaving you to innovate on the remaining 40% that truly matters.

6. What Frontend Devs Should Focus On in the AI Era

If you’re a frontend developer in 2025, don’t fear AI — future-proof yourself with these skills instead:

🧠 A. Deep UI/UX Understanding

AI can mimic design, but not emotion. Learn interaction design, motion principles, and accessibility.

⚡ B. System Thinking

Understand how your frontend connects to APIs, CDNs, and CI/CD pipelines.

🚀 C. Performance & Optimization

AI may suggest code, but you know how it performs in real-world conditions.
Check out my post on Web Performance Optimization Techniques to level up this skill.

💬 D. Communication & Collaboration

AI doesn’t do meetings or trade-offs. Engineers who can articulate decisions will remain indispensable.

7. Remember: Creativity Is the New Job Security

The developers who’ll thrive aren’t the ones competing against AI — they’re the ones creating with it.

Frontend devs have always been closest to users, design, and innovation.
AI will just give us better tools, not take away our role.

Code is the medium, but creativity is the craft.
AI can help you write — but only you can make it matter.

Final Thoughts

AI will rewrite parts of how we build, but not the why.
Frontend developers won’t disappear — they’ll evolve into AI-empowered creators who design experiences, not just components.

So no — AI isn’t coming for your code.
It’s coming to collaborate on it.

🧰 Tools to Explore — Your AI Frontend Toolkit

Tool	Category	What It Does Best
GitHub Copilot / Copilot X	Code generation	Inline AI suggestions, context-aware code fixes
Vercel v0	UI scaffolding	Generate React + Tailwind components from prompts
Cursor IDE	Smart IDE	AI-assisted refactoring and debugging
Codeium / Cody	AI Pair Programmer	Contextual code explanations, reviews, and refactors
ChatGPT (GPT-5)	Problem solving	Explain code, fix bugs, or simulate interviews
Bolt.new	App builder	Create full React apps from text prompts
Locofy.ai	Design-to-code	Turn Figma designs into responsive code
Lighthouse AI (experimental)	QA & audits	Analyze accessibility and performance automatically

💡 These tools don’t replace you — they amplify you. Use them to move faster, not to skip understanding.

⚔️ React vs Angular vs Vue: A Senior Developer’s Honest Take in 2025

Anisubhra Sarkar (Ani) — Fri, 31 Oct 2025 05:01:53 +0000

Front-end frameworks have come a long way. What started as a battle between React, Angular, and Vue has now evolved into an ecosystem of tools, meta-frameworks, and architecture patterns.

As a senior frontend developer with hands-on experience across these frameworks, here’s my honest take on where each stands in 2025, what they do best, and when you should pick one over the others.

The 2025 Landscape: Maturity Over Hype

We’re past the “framework wars.” All three — React, Angular, and Vue — are mature, production-ready, and widely adopted. The real question now is:

“Which one aligns with your team’s goals, architecture, and long-term maintainability?”

Let’s look at each framework from a real-world, senior developer’s perspective.

⚛️ React — The Ecosystem King

Overview

React, maintained by Meta (Facebook), remains the most popular frontend library in 2025. Its flexibility, massive ecosystem, and community support keep it the go-to choice for startups and enterprises alike.

Performance

React’s performance relies on its Virtual DOM and reconciliation algorithm. With React 19, major upgrades include:

React Compiler — automatic memoization for components.
Concurrent Rendering — smoother updates under heavy load.
Server Components — smaller client bundles and better SEO.

Strengths

Flexibility: React is a library, not a full framework. You choose your router, state management, and build tools.
Ecosystem Power: Libraries like Next.js, Remix, TanStack Query, and Zustand make React more capable than ever.
Performance Enhancements: React 19’s compiler, concurrent rendering, and Server Components make large-scale apps smoother.
Strong Community Support: Endless tutorials, open-source tools, and hiring demand.

Weaknesses

Too Many Choices: Beginners often get lost in “what to pick” — Redux or Zustand? Vite or CRA?
Boilerplate for Complex Apps: Without a strong architectural guide, large apps can become messy.
JSX Learning Curve: Mixing markup and logic can feel weird initially.

Best Use Cases

Large, scalable applications (dashboards, SaaS products).
Teams that value flexibility and cutting-edge tooling.
When hiring React devs easily is a priority.

🅰️ Angular — The Enterprise Powerhouse

Overview

Angular, backed by Google, continues to shine in enterprise-grade environments. It offers a complete solution out of the box — routing, forms, HTTP, and dependency injection — all powered by TypeScript.

Performance

Angular’s Ivy rendering engine (and its successor Hydration rendering in v18) focuses on incremental DOM updates rather than virtual DOM diffing.

Ahead-of-Time (AOT) compilation reduces runtime overhead.
Change detection optimization ensures efficient updates.
Tree-shaking & lazy loading improve bundle size for modular apps.

Strengths

Opinionated Framework: Angular gives you structure and consistency — no “which library to pick” confusion.
TypeScript First: Excellent type safety and compile-time checks.
Built-in Tools: CLI, RxJS, and dependency injection system make scaling easier.
Long-Term Support (LTS): Enterprises love Angular for its stability and predictable release cycle.

Weaknesses

Steeper Learning Curve: The architecture (modules, decorators, DI) can feel overwhelming at first.
Verbose Code: Requires more boilerplate than React or Vue.
Heavier Initial Bundle: Though improving, Angular’s bundles can still be large.

Best Use Cases

Large enterprise systems with multiple teams.
Applications requiring strict structure and maintainability.
Teams already deep into TypeScript and RxJS.

🅥 Vue — The Developer-Friendly Middle Ground

Overview

Vue remains a favorite among developers for its simplicity and elegance. With Vue 3 and the Composition API, it’s now just as powerful as React or Angular, but easier to learn and integrate.

Performance

Vue’s Virtual DOM is optimized for fine-grained reactivity. Unlike React, Vue tracks component dependencies precisely — only updating what’s necessary.

Reactivity system: Uses proxies for minimal re-renders.
SSR & hydration: Nuxt 3 delivers exceptional time-to-interactive speeds.
Compact bundle size: Typically smaller than React or Angular.

Strengths

Gentle Learning Curve: Easier for new developers to pick up.
Single-File Components (SFCs): Keep template, logic, and styles neatly organized.
Composition API: Enables cleaner reusability and type safety.
Growing Ecosystem: Tools like Nuxt 3 (SSR) and Pinia (state management) are production-ready.

Weaknesses

Smaller Ecosystem (compared to React): Fewer third-party libraries for niche use cases.
Limited Enterprise Adoption: React and Angular still dominate large companies.
Talent Pool: Harder to hire experienced Vue devs in some regions.

Best Use Cases

Small to mid-size applications and MVPs.
Teams valuing simplicity and developer experience.
When rapid prototyping or low maintenance is key.

📁 File-Based Routing Trend

In 2025, file-based routing has become standard across all major ecosystems:

Next.js / Remix (React)
Nuxt 3 (Vue)
AnalogJS / Angular v18+ (Angular)

This simplifies project setup and aligns frontend frameworks with backend frameworks like Rails or Laravel.

✅ Why it matters: Developers now focus on features instead of wiring up routers manually.

🚀 Performance Comparison

Feature / Metric	React	Angular	Vue
Rendering Model	Virtual DOM	Incremental DOM	Virtual DOM + Reactivity
Change Detection	Reconciliation (Diffing)	Zone.js (Observable-based)	Dependency Tracking
Bundle Size	Small–Medium	Larger	Small
SSR Support	Excellent (Next.js)	Good (Angular Universal)	Excellent (Nuxt 3)
Load Time	Fast (with Compiler)	Moderate	Fast
Scalability	High (with structure)	Excellent	Moderate–High

🧠 Developer Experience Comparison

Feature	React	Angular	Vue
Learning Curve	Moderate	Steep	Easy
Flexibility	High	Medium	High
Type Safety	Optional (TS)	Built-in	Optional
Ecosystem	Huge	Strong	Growing
Performance	Excellent (React 19)	Great	Excellent
Community	Largest	Strong	Friendly
Ideal For	Startups, SaaS	Enterprises	MVPs, SMEs

🧩 Real-World Examples

Use Case	Recommended Framework
Enterprise dashboards	Angular
Data-heavy SaaS products	React
Rapid prototypes or MVPs	Vue
SEO-friendly blogs/websites	React (Next.js) or Vue (Nuxt 3)
Long-term maintainable apps	Angular or React

My Take as a Senior Developer in 2025

If I had to choose today:

For enterprise-scale apps: Angular still wins for structure and stability.
For flexibility and ecosystem: React remains king.
For elegance and ease: Vue is unbeatable.

In the end, no framework is perfect — what matters is:

Your team’s expertise
Your scalability needs
Your project timeline

Pick the tool that best serves your context, not the one that’s trending on the Internet.

Final Thoughts

React, Angular, and Vue have matured into reliable ecosystems rather than competitors. The “framework wars” are over — now it’s about fit, architecture, and developer experience.

As we move into 2025 and beyond, frontend development is less about the tools you choose and more about how you build for performance, accessibility, and maintainability.

📱 The Ultimate Guide to Building Mobile-Friendly Websites: Best Practices, Advanced Techniques and Google AMP

Anisubhra Sarkar (Ani) — Sun, 14 Sep 2025 11:09:26 +0000

With mobile devices accounting for more than half of global web traffic, a mobile-friendly website is no longer optional — it’s essential. A well-optimized mobile site doesn’t just improve user experience; it also boosts search engine rankings, as Google prioritizes mobile-first indexing.

But true mobile-friendliness goes beyond just making things “responsive.” It includes performance, accessibility, usability, design principles, and modern technologies like PWAs and AMP.

This guide covers everything you need to know about building mobile-friendly websites that are fast, accessible, and delightful to use.

Why Mobile-Friendly Websites Matter

1. Mobile-First Indexing

Google primarily uses the mobile version of a site for indexing and ranking. If your mobile site isn’t optimized, expect drops in SEO and visibility.

👉 For a deeper dive into SEO-focused practices, check out my article on Frontend SEO Best Practices: A Developer’s Guide to Optimizing Your Website.

2. Better User Experience

A mobile-optimized site ensures:

Fast load times
Easy navigation on smaller screens
Readable text, buttons, and images

3. Higher Engagement & Conversions

Mobile users demand frictionless experiences. Optimization reduces bounce rates and increases conversions — whether for sales, sign-ups, or engagement.

Core Aspects of a Mobile-Friendly Website

1. Responsive Design

Layouts should adapt across screen sizes and orientations.

Techniques:

CSS Grid / Flexbox for flexible layouts.
Media queries for breakpoints.
Avoid fixed widths (width: 100% instead of 600px).

.grid {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  gap: 16px;
}

@media (max-width: 768px) {
  .grid { grid-template-columns: repeat(2, 1fr); }
}

@media (max-width: 480px) {
  .grid { grid-template-columns: 1fr; }
}

2. Mobile-First Design Approach

Design for smallest screens first, then enhance for larger devices.

/* Mobile-first */
.container { font-size: 16px; }

/* Tablet */
@media (min-width: 768px) {
  .container { font-size: 18px; }
}

/* Desktop */
@media (min-width: 1024px) {
  .container { font-size: 20px; }
}

✅ Benefits: prioritizes essentials, prevents layout issues, improves performance.

3. Speed Optimization

Performance is critical for mobile users on slower networks.

Strategies:

Use a CDN for assets.
Minify CSS/JS/HTML.
Enable compression (Gzip/Brotli).
Preload critical resources like fonts.
Lazy load images/videos:

  <img src="image.jpg" loading="lazy" alt="Lazy Loaded">

Use modern formats: WebP, AVIF.

👉 Want to dive deeper into performance? Here are some of my in-depth guides:

4. Touchscreen Usability

Mobile users navigate with fingers, not cursors.

Buttons/links should be ≥48×48px.
Avoid hover-only effects.
Add gestures (swipes for carousels/menus).

👉 For smoother UI interactions, check out my article on Smooth, Jank-Free Animations with CSS and JavaScript: Performance Best Practices.

5. Simplified Navigation

Keep navigation clear and accessible.

Use hamburger menus on smaller screens.
Add sticky headers for always-available navigation.
Keep menu depth shallow — avoid long hierarchies.

6. Readable Typography

Good typography is key for small screens.

Use relative units (rem, em).
Minimum font size: 16px.
Line-height: at least 1.5.

body {
  font-size: 1rem;
  line-height: 1.6;
}

7. Test Across Devices

Don’t assume — test.

Google Mobile-Friendly Test
Chrome/Firefox DevTools → responsive mode
BrowserStack for cross-device testing

👉 For a deeper dive into ensuring consistent behavior across browsers, check out my article on Best Practices for Ensuring Cross-Browser Compatibility in Front-End Development.

🚀 Advanced Considerations for Mobile Friendliness

8. Progressive Web Apps (PWAs)

PWAs bring app-like experiences to the mobile web:

Installable on devices
Offline support via Service Workers
Push notifications

// manifest.json
{
  "name": "My App",
  "short_name": "App",
  "start_url": "/",
  "display": "standalone"
}

Best for: e-commerce, news portals, productivity tools.

👉 Want to learn more? Read my full guide on Building Progressive Web Apps: How to Create Offline-Capable, Installable Web Applications.

9. Accessibility (a11y)

Mobile-friendly also means accessible.

Use semantic HTML (<nav>, <button>, <header>).
Add alt text to images.
Maintain high contrast.
Use ARIA attributes where needed.

<button aria-label="Close menu">✖️</button>

10. Dark Mode & User Preferences

Many users expect dark mode. It also saves battery.

@media (prefers-color-scheme: dark) {
  body { background: #121212; color: #fff; }
}

11. Input & Form Optimization

Forms are pain points on mobile.

Use the right input types (email, tel, number).
Enable autofill and optimized keyboards.
Keep forms short or split into steps.

<input type="email" placeholder="Email" autocomplete="email" />

12. Viewport & Safe Areas

Ensure layouts adapt to modern devices with notches.

<meta name="viewport" content="width=device-width, initial-scale=1">

body { padding-top: env(safe-area-inset-top); }

13. Mobile-Friendly Ads & Popups

Avoid intrusive interstitials — they hurt SEO and UX.

✅ Use banners or delayed prompts.
✅ Respect content visibility.

14. Analytics & Monitoring

Measure real-world performance.

Track Core Web Vitals (LCP, CLS, FID).
Use Lighthouse.
Monitor mobile metrics in Google Analytics 4.

👉 Learn more about improving real-world performance in my article on How to Optimize Core Web Vitals for Better Google Rankings and User Experience.

15. Security

Mobile users expect trust and safety.

Enforce HTTPS.
Use secure cookies.
Avoid exposing sensitive data in URLs.

👉 Want to dive deeper into protecting your apps? Check out my article on JavaScript Frontend Security Best Practices.

⚡ Google’s Accelerated Mobile Pages (AMP)

AMP delivers ultra-fast mobile pages with simplified HTML and restrictions.

✅ Pros: blazing speed, SEO boost, reduced bounce.
❌ Cons: limited customization, extra maintenance, heavy reliance on Google infra.

Use AMP if: You run a content-heavy site (blogs, news portals) where speed & rankings matter most.

📝 Recap

To build a mobile-friendly site:

Responsive design (Grid, Flexbox, media queries)
Mobile-first workflows
Speed optimizations (lazy loading, CDNs, compression)
Touch-friendly UI
Simple navigation
Readable typography
Multi-device testing
Leverage PWAs for app-like UX
Build for accessibility
Support dark mode
Optimize forms
Handle viewport safe areas
Keep ads/popups user-friendly
Monitor with analytics
Enforce security best practices
Consider AMP for content-heavy sites

Final Thoughts

Mobile-friendliness is no longer a “feature” — it’s the foundation of modern web development. It means combining:

Responsive layouts
Performance at scale
Accessibility and usability
Modern enhancements like PWAs and dark mode

By making these principles part of your development workflow, you’ll deliver experiences that are fast, reliable, and loved by both users and search engines.