DEV Community: Utkarsh Bansal

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

Utkarsh Bansal — Fri, 12 Jun 2026 18:31:01 +0000

How ESLint Actually Works: The Quality Gate Behind Modern JavaScript - DEV Community

A few days ago, I shared an article: You Don't Need Another Agent. You Need a Linter. Then I did...

dev.to

How ESLint Actually Works: The Quality Gate Behind Modern JavaScript

Utkarsh Bansal — Fri, 12 Jun 2026 12:37:30 +0000

A few days ago, I shared an article:

You Don't Need Another Agent. You Need a Linter.

Then I did what I do with anything I write: shared it around — a few publications, a few channels.

Two reasons:

First, feedback. I'd genuinely rather get roasted and fix my blind spots than stay comfortable and wrong.

Second, let's be honest: reach.
Every writer enjoys seeing a few more views.

Most of the responses were positive.

One wasn't.

A publication rejected it with the reason:

LOW_QUALITY

Fair enough.

It means there's room for improvement.

Funny enough, my caffeinated 1 AM brain disagreed.

Then it did what every developer does when someone says "this isn't good enough."

It took that personally.

So I went back and reread the article.

And after the initial ego check, I realized something serious:

The article talked in detail about ESLint, why it matters more in an AI-assisted world than ever.

What it did not do was answer the question that actually matters:

What is ESLint, how does it work, and why has half the JavaScript ecosystem quietly built its quality process around it?

So let's fix that.

Now, this isn't a sequel to my last piece about untangling vibe-coded code. It stands on its own — one thing, done properly.

A complete teardown of ESLint:

What it is
How it works internally
Why companies use it as a quality gate
The different classes of problems it solves
How plugins work
How to write your own rules
Where it fails
Why it still beats many AI-based review systems

Fair warning.

This article is going to be technical.

There will be syntax trees.

There will be compiler concepts.

There will be enough JavaScript internals to make frontend developers slightly uncomfortable.

I'll try my best to keep it readable not letting it turn into another manual - which nobody finishes.

Let's start with the question most people never ask.

What Is ESLint Actually Doing?

Most developers describe ESLint like this:

It checks code for mistakes.

Technically true. Also completely useless.

That's like describing a car as:

It helps you move.

The interesting part is how?

Consider this code:

import axios from "axios";

function getUsers() {
  return fetch("/api/users");
}

With the right rules on, ESLint can tell us:

axios is imported and never used
fetch is being used
getUsers exists
getUsers is never called
there are no syntax errors

But how?

The answer is that ESLint never reads code as text.

The first thing it does is destroy your beautiful source code.

Step 1: Your Code Stops Being Code

The moment ESLint sees a file, it passes it through a parser.

The parser converts your code into something called an Abstract Syntax Tree (AST).

Your code:

const answer = 42;

becomes something closer to:

{
  "type": "VariableDeclaration",
  "kind": "const",
  "declarations": [
    {
      "id": { "name": "answer" },
      "init": { "value": 42 }
    }
  ]
}

Notice what's missing.

Formatting. Spacing. Comments. Indentation.

The parser doesn't care. The AST only cares about meaning.

To ESLint, your source code isn't text anymore.

It's a tree.

Literally. That same const answer = 42 looks like this:

VariableDeclaration · const
└─ VariableDeclarator
   ├─ Identifier · "answer"
   └─ Literal · 42

The JSON above and this tree are the same thing. One's just easier to look at.

And every lint rule is basically a tree inspector.

That's the core idea:

Source code
   ↓
Parser
   ↓
AST
   ↓
Rules inspect nodes
   ↓
Reports / warnings / errors

Step 2: Rules Walk The Tree

Every ESLint rule is a visitor.

It walks through the nodes inside the AST and asks questions.

For example:

console.log("debug");

produces a node that looks like:

CallExpression

The no-console rule simply visits every CallExpression and asks:

Is this a console call?

If yes.

Report error.

That's it.

No AI. No embeddings. No vector database.

Just deterministic tree traversal.

Computer science doing computer science things.

Why This Is More Powerful Than It Sounds

Most people hear "static analysis" and immediately think:

So... it catches semicolons?

No.

Semicolons are the least interesting thing ESLint does.

Let's look at the categories.

Category 1: Correctness

These rules catch code that is probably wrong.

A function that doesn't exist:

foo();

An assignment hiding inside a condition:

if (user = admin) { /* ... */ }

A promise nobody awaited:

promiseFunction();

These are not style issues. These are bugs.

The code may compile. It may even pass tests.

But eventually somebody is getting paged at 2 AM.

Category 2: Dead Code

AI loves dead code. Humans create it too. AI just does it faster.

An import that's never used:

import lodash from "lodash";

A function nobody calls anymore:

function oldImplementation() {}

One abandoned experiment later, and your repository becomes an archaeological site.

Dead code increases bundle size, maintenance cost, and confusion.

The cheapest bug is the code that doesn't exist.

ESLint helps make that happen.

Category 3: Security

This is where people start underestimating linters.

Consider:

eval(userInput);

No. Just no.

Or:

element.innerHTML = userInput;

Also no.

A decent security-focused lint setup can stop entire classes of vulnerabilities before the code ever reaches production.

Not because it's intelligent.

Because it recognizes dangerous patterns.

And dangerous patterns repeat. A lot.

Category 4: Performance

Some rules exist purely because developers keep making the same expensive mistakes.

This:

array.indexOf(value) !== -1;

can become this:

array.includes(value);

Tiny improvement.

Now repeat it across a million lines of code, and you've quietly compressed years of engineering experience into a config file.

That's what lint rules really are.

Institutional memory

The Real Superpower: Quality Gates

The biggest mistake teams make is treating ESLint like a suggestion.

A linter running in your editor is nice.

A linter blocking merges is transformative.

The moment ESLint becomes part of CI, it stops being advice.

It becomes policy.

The workflow changes from:

Hopefully somebody notices the bug in review.

to:

The code physically cannot merge.

That's a completely different game.

Good engineering isn't about creating perfect developers.

It's about creating systems where common mistakes cannot survive.

ESLint is one of those systems.

Developer writes code
   ↓
Editor lint shows warnings
   ↓
PR created
   ↓
CI runs lint
   ↓
Pass → merge
Fail → fix before merge

Community Plugins Already Solved Half Your Problems

Here's the part most developers miss.

ESLint is a rule engine.

It parses code, walks the AST, runs rules, reports violations, and that's basically the entire core.

The real power comes from everything built on top of it: plugins, shared rule sets, and years of accumulated engineering knowledge.

Need to find unused imports?

There's a plugin. eslint-plugin-unused-imports

Need TypeScript-aware analysis?

There's a plugin. @typescript-eslint

Need accessibility checks for your components?

There's a plugin. eslint-plugin-jsx-a11y or eslint-plugin-vuejs-accessibility

Need to catch dangerous security patterns?

There's a plugin. eslint-plugin-security

Need to enforce architectural boundaries between layers?

Believe it or not, there's a plugin for that too. eslint-plugin-boundaries.

You don't have to write any of this yourself.

Thousands of developers have already spent years turning common mistakes into reusable rules.

A few common examples:

eslint-plugin-unused-imports — dead imports and variables
eslint-plugin-import — circular dependencies and broken paths
@typescript-eslint — type-aware correctness rules
eslint-plugin-jsx-a11y / eslint-plugin-vuejs-accessibility — accessibility
eslint-plugin-promise — dropped awaits and async mistakes
eslint-plugin-security — dangerous patterns like eval
eslint-plugin-boundaries — architectural layer rules

That's the mental shift.

Most people think ESLint is one tool with a bunch of built-in rules.

It's closer to a platform.

A small, stable engine that lets an entire ecosystem contribute knowledge.

  eslint-plugin-import     @typescript-eslint     your local rules
   (cycles, dead code)     (type-aware checks)     (team gates)
            │                      │                      │
            └──────────────────────┼──────────────────────┘
                                   ▼
            ┌──────────────────────────────────────────┐
            │                ESLint core                 │
            │     parse → walk the AST → run → report     │
            └──────────────────────────────────────────┘

That's why ESLint has survived for so long.

The core doesn't need to know about React.

Or Vue.

Or TypeScript.

Or whatever framework we'll all be rewriting our applications in next year.

The engine stays the same.

The ecosystem keeps growing.

The core never changes. The rules feeding into it are infinite.

And eventually you realize something interesting:

Most teams don't need more tooling.

They just need to enable the plugins that already exist.

When The Defaults Aren't Enough: Write Your Own Rule

Now for the fun part — the part that makes ESLint feel less like a tool and more like a system.

Suppose your company has a design system. And somebody keeps committing raw colors:

color: "#FF0000";

instead of:

color: tokens.error;

You can complain. You can review every PR. Or you can automate the complaint.

Here's the entire rule:

// rules/no-raw-color.js
export default {
  meta: {
    type: "problem",
    messages: { rawColor: "Use a design token, not a raw hex like '{{value}}'." },
  },
  create(context) {
    return {
      // the walker hands you every string literal; you keep the ones that look like hex
      Literal(node) {
        if (typeof node.value === "string" && /^#[0-9a-f]{3,6}$/i.test(node.value)) {
          context.report({ node, messageId: "rawColor", data: { value: node.value } });
        }
      },
    };
  },
};

That's it. No npm package, no publishing. Flat config lets you wire a local rule in directly, and ESLint's built-in RuleTester lets you prove it fires on "#FF0000" and stays quiet on tokens.error.

A custom ESLint rule is usually less code than the Slack argument it prevents.

That's the real secret.

The best engineering teams don't repeatedly solve the same problem.

They automate it.

Every bug becomes a rule. Every rule becomes institutional knowledge. Every future developer benefits.

Human. Or AI. Doesn't matter.

The gate treats everybody equally.

Where ESLint Fails

Now, before somebody accuses me of turning ESLint into a religion — it has limits.

ESLint cannot tell:

if your architecture is good
if your business logic is correct
if the feature should even exist
if your product manager had a terrible idea

Those remain human problems.

Static analysis sees structure. Not intent.

A green lint report does not mean correct software.

It means your code survived a specific set of inspections.

Nothing more. Nothing less.

So Why Am I Still Talking About ESLint In The Age Of AI?

Because every week I see somebody proposing:

AI review agents
AI architecture agents
AI quality agents
AI code verification agents

And half the time, they're trying to solve problems ESLint solved years ago.

Before building another agent, ask:

Can a deterministic static analysis tool already solve this?

Because if the answer is yes, the boring tool is:

faster
cheaper
reproducible
and it doesn't hallucinate

The boring solution often wins.

Not because it's exciting. Because it works.

And software engineering eventually rewards whatever keeps production alive — even if it was invented twenty years ago.

Takeaway

The most important thing I learned from AI-assisted development wasn't how powerful AI is.

It was how valuable boring tooling remains.

ESLint isn't glamorous. Nobody posts screenshots of lint checks on LinkedIn. Nobody raises venture capital for a missing-semicolon detector.

But every large JavaScript codebase eventually discovers the same truth.

It parses code. It walks trees. It applies rules. It reports violations. That sounds humble — but the impact compounds: it catches bugs early, enforces standards, protects architecture, scales institutional memory, and keeps bad code from sneaking through the door.

And unlike the rest of us, it never gets tired.

The cheapest reviewer on your team is still a linter.

If you still think of ESLint as a semicolon cop, you're missing most of the point.

It was never about the semicolons.

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

Utkarsh Bansal — Wed, 10 Jun 2026 15:54:26 +0000

You Don't Need Another Agent. You Need a Linter. - DEV Community

In my last post I complained — a lot — about vibe code and the beautiful disaster it left...

dev.to

You Don't Need Another Agent. You Need a Linter.

Utkarsh Bansal — Wed, 10 Jun 2026 15:49:20 +0000

In my last post I complained — a lot — about vibe code and the beautiful disaster it left behind.

Now, I'm not here just to complain. There were a lot of learning opportunities too, like how to handle legacy / vibe code. Because at the end of the day, both are the same: no one knows how they work, but somehow they keep working. Touching them is like defusing a bomb — you never know how your change might cascade and break the core logic.

The good news is that vibe code is much simpler than legacy. AI, in all its glory, tries to write perfect-looking code — proper function names, comments, the works — not like legacy code where a single function runs 500 lines, with spaghetti names all over that make no sense and comments that are out of date.

And that makes it something I can actually handle. I still don't have a perfect, step-by-step playbook — but I've got pieces.

The first one. The cheapest and the oldest one. The one the industry solved decades ago and the whole "AI built my app in a day" crowd somehow forgot exists.

A linter.

Yes, you heard me right. A linter. ESLint.

Most people who've been in this industry already know it. It's the most boring, reliable tool in the box.

But in an era where the answer to every problem is "add another AI," it's worth saying out loud why the boring tool still wins.

What a linter actually is

If you vibe-coded your way into this world, or you're new to web dev in general and have never heard the word "lint", here's the honest version.

A linter is a set of rules you add to your repo. It reads your code without running it, checks it against those rules, and flags everything that's broken, sloppy, or about to bite you in production.

The detail people get wrong: it's not a grep for bad words.

A real linter parses your code into a syntax tree and actually reasons about its structure — what's imported, what's called, what's reachable, what types flow where.

That's why a rule like no-unused-vars can tell "you imported this and never used it" apart from "you used this without importing it."

It's also why eslint-plugin-unicorn can quietly rewrite array.indexOf(x) !== -1 into array.includes(x) (unicorn/prefer-includes), or flag a new Array(...) call that's going to bite you — without ever executing a single line.

Three properties matter:

It doesn't run your code. No side effects, no flaky network, no "works on my machine."
It's deterministic. Same code in, same result out, every single time. No temperature, no vibes.
It costs nothing. No tokens. No API bill. It runs in seconds on a laptop or a CI box.

In 2026, that last one is the whole argument.

Why this matters more than it used to

We have AI to write code. AI to review code. AI to verify code. Agents stacked on agents, each one quietly spending tokens to do something a free tool already did better.

And honestly? Most of those agents are re-solving problems that were solved long before "agent" meant what it means today.

You do not need a language model to notice that you left a debug log in production (no-console). Or imported a module you never used (unused-imports/no-unused-imports). Or wrote a function nobody calls (knip). Or forgot to await a promise (@typescript-eslint/no-floating-promises). Or made two files import each other in a circle (import/no-cycle).

A linter catches every one of those instantly, deterministically, for free — before any AI even wakes up.

So before you bolt another agent onto your pipeline, ask the boring question:

Does the free, battle-tested tool already do this?

Usually it does.

Use what already exists.

A linter is a Quality Gate

This is the real reason linters matter. Whether you're a big company or a freelancer just starting out.

A linter is a quality gate. A line in the sand that says:

This code does not get in unless it clears the bar.

Where I work, we wired this straight into the pull-request flow. A check a PR has to pass before it can merge.

Not a suggestion. Not "we'll clean it up later." A hard gate on the merge button.

The result was the kind of number that sounds made up until you live it: production issues and bad merges dropped by roughly 80%.

Magic? No.

Most of our incidents were the same boring handful — an unhandled promise that swallowed an error, a stray debug log left in, a circular import that only broke in prod. The gate caught every one of them at the door — we just stopped letting broken code through.

That's the whole trick.

A gate doesn't make anyone smarter. It just raises the floor.

A tip if you're at a big company: when you introduce the ESLint check, you'll hear a lot of pushback from devs — especially at a startup or midsize company. So be ready for a fight, and roll it out gradually: a warning gate first, then an error gate.

It doesn't stop at "missing semicolon"

Here's the common misconception people hit when they first add ESLint and see all those errors: "this thing is bad, it just nags me like my annoying brother." That's a huge underestimation.

Once you treat the linter as a real gate instead of a nag, you can teach it your specific mistakes. And it never forgets them.

Every painful bug in an AI-assisted codebase is also a pattern. And patterns are exactly what static analysis is good at.

A surprising amount of this is one config file away. Modern ESLint flat config plus a few community plugins covers most of it:

// eslint.config.js — a starter "quality gate", not a missing-semicolon nag
import unusedImports from "eslint-plugin-unused-imports";
import importPlugin from "eslint-plugin-import";
import unicorn from "eslint-plugin-unicorn";

export default [
  {
    plugins: { "unused-imports": unusedImports, import: importPlugin, unicorn },
    languageOptions: {
      // type-aware rules need the TS program, not just the syntax tree
      parserOptions: { projectService: true },
    },
    rules: {
      // ~100 perf + hidden-bug rules in one line; downgrade the churny ones
      ...unicorn.configs["flat/recommended"].rules,
      "unicorn/filename-case": "off",       // Vue files are PascalCase by convention
      "unicorn/prevent-abbreviations": "off", // trips on `ref`, `props`, store names
      // dead code the model left behind — auto-fixable
      "unused-imports/no-unused-imports": "error",
      "unused-imports/no-unused-vars": "warn",
      // the silent killer (see the circular-deps post) — crank maxDepth up
      "import/no-cycle": ["error", { maxDepth: 10, ignoreExternal: true }],
      // dropped awaits that swallow errors — needs the type info above
      "@typescript-eslint/no-floating-promises": "error",
      "@typescript-eslint/no-misused-promises": "error",
      // dynamic code execution: off by default in eslint:recommended, turn them on
      "no-eval": "error",
      "no-implied-eval": "error",
      "no-new-func": "error",
      "no-script-url": "error",
    },
  },
];

That's the floor.

On top of it, every time something hurt us, we added a rule so it could only hurt us once. Three of them earned their place the hard way:

Circular dependencies — import/no-cycle with maxDepth: 10 (the default of 1 only sees direct A↔B cycles), backed by dependency-cruiser for the whole-graph view. AI refactors love making two modules import each other until the build breaks only in prod. It's the single most common AI-induced bug I've seen — enough that it deserves a post of its own.
Dropped awaits — @typescript-eslint/no-floating-promises and no-misused-promises. A missing await on a file or network call silently swallows the error, and you find out when a user does. Needs type-aware linting (parserOptions.projectService) — the one setup cost worth paying.
The free-wins pack — eslint-plugin-unicorn's flat/recommended: ~100 rules for one import. A mix of performance wins (prefer-includes, prefer-set-has), real hidden-bug catches (no-array-push-push, no-thenable), and some opinionated style. Turn off the churn (unicorn/filename-case, unicorn/prevent-abbreviations, unicorn/no-null) and keep the rest. Best caught-mistakes-to-config ratio you'll find.

The rest are quieter, but each one caught something once. Skim them:

Dead code — eslint-plugin-unused-imports sweeps the imports the model added for an approach it then abandoned (auto-fixed on --fix).
No eval — no-eval, no-implied-eval, no-new-func, no-script-url. Off by default; zero legit uses, infinite ways for generated code to sneak one in.
XSS sinks — vue/no-v-html / react/no-danger, plus eslint-plugin-no-unsanitized for raw innerHTML. Any HTML injection has to pass through a sanitizer, enforced at lint time.
Hardcoded strings — eslint-plugin-i18next, so the day you add a language nothing's baked into the markup.
Test hygiene — no-focused-tests as an error, so a stray it.only can't silently shrink the CI suite.
Leaked secrets — eslint-plugin-no-secrets flags high-entropy literals that look like committed tokens.
Design drift (custom) — a ~40-line AST script that fails the build when a raw hex/size/shadow shows up where a named token should be.
Layer boundaries — eslint-plugin-boundaries to stop one layer importing another, plus a custom rule forcing risky mutations through a single function.

Each of these is a lesson we only had to learn once.

After that, the linter remembers it for us. Forever, for free, on every commit, for every contributor — human or AI.

The trick that keeps the gate from being annoying

Most people give up on linting for one reason. They turn on every rule at error on day one, drown in ten thousand warnings, and rage-quit.

Don't do that.

Run new rules warn-first. Let them report without blocking. Get the count to zero on your own schedule. Then ratchet that rule up to error so it can never regress.

Here's the reframe that matters: those warnings aren't a to-do list you owe the linter today. They're a map of where the mines are buried. You freeze the count, stop anyone from planting new ones, and clear the field at your own pace.

For the handful of legacy offenders you can't fix today, keep an explicit allowlist. And treat adding to that allowlist as the thing you're not allowed to do.

The list only ever shrinks.

That's how a gate stays strict without crying wolf — and how you tame inherited code without it blowing up in your face.

Gotchas

A linter only sees what's static. Dynamic imports, string-built code, and values resolved at runtime are invisible to it. Know the blind spots. A green lint is not "provably correct."
--fix is not free thinking. Auto-fix is great for unused imports and formatting. It is not great at deciding whether a flagged thing was a real mistake. Read the diff.
Gate on the trend, not the absolute count. Failing CI because the repo has any warnings is untenable in a vibe-coded codebase. Fail when the count grows past the baseline. That's actionable. "Be perfect" isn't.
A rule you suppress everywhere is a rule you deleted. If every other line has a disable comment, you didn't pass the gate — you removed it. Fix the code or kill the rule honestly.

The mild jab

Here's the irony I can already see coming. You've read this whole piece on why bolting AI onto already-solved problems is wasteful — and your very next move is to open a chat window and type "add ESLint and all the plugins to my repo." Or worse: "build me a code-review agent that flags unused imports and circular deps."

Stop.

Both are the wrong move. The first one drops you into a rabbit hole of 1000+ errors you'll be digging out of forever. Start with the base recommendation, then slowly work toward the rest.

As for the code-review agent — I'll pretend I didn't hear that. We just spent this whole article on why a linter beats an AI reviewer here. So why are you still reaching for it? Look, if you hate your tokens that much — if you're really itching to spend them on a problem a free, decades-old tool already solves deterministically — just send them my way. I'll put them to better use.

AI is genuinely good at the fuzzy stuff — turning an idea into reality, that dopamine hit of making something from nothing. Let it do that. Leave the heavy judgement of code quality to linter.

And let me be honest about the other side: a linter won't fix your architecture, won't catch a wrong business rule, won't tell you the feature was a bad idea. That part is still on you. What it will do is take the boring, mechanical, never-ending category of mistakes off your plate — so your brain is free for the part that actually needs one.

Takeaway

A linter is the cheapest reviewer on your team. Free, deterministic, tireless, and completely unimpressed by hype.

Make it a hard gate on merge, and you raise the floor for everyone at once.

Then teach it your own recurring mistakes — token drift, hardcoded strings, circular deps, unsafe HTML, dropped awaits — one custom rule per bug class, warn-first then ratcheted to error.

Add the linter first.

Then, if you still want an agent, at least it's reviewing code that already cleared the bar.

The cheapest reviewer you'll ever hire has been sitting in your repo the whole time.

Frontend Is Not That Simple

Utkarsh Bansal — Thu, 21 May 2026 19:15:01 +0000

I guess most of you already have a pretty basic idea of what this post is about — Frontend Engineering.

Why frontend?
“We have AI now. It can create a website in a day. Why do you even care about frontend anymore? Post something about AI blah blah blah…”

I hear you.

But the real question is: Do you actually understand frontend?

Every day, I see product managers and designers trying their hands at AI — creating MVPs in a day and celebrating like, “We don’t need engineers anymore. We can do everything ourselves now.”

And honestly? That part is impressive.

But then that same code gets handed over to engineers for optimization, scalability, maintainability, performance, accessibility, security, deployment, and production readiness.

And that’s where my nightmare begins.

AI generates code based on patterns and existing code available online. It doesn’t magically create great architecture, scalability, performance, accessibility, or production-grade systems out of thin air.

The bigger problem starts when people continuously edit AI-generated code using more AI prompts without understanding the underlying structure.

At first, it works.

Then slowly:

functions start leaking across modules
components become tightly coupled
business logic spreads everywhere
state management becomes unpredictable
abstractions collapse
duplication increases
and eventually the entire codebase turns into spaghetti

A tangled mess held together by vibes, Stack Overflow answers, and “it works on my machine.”

Then comes the question:

“Why hasn’t the app that was created in a day scaled and deployed yet?”

So for the sake of my sanity, let me take you on a small journey into what real frontend engineering actually looks like.

And do note — this is just the tip of the iceberg. Once you go deeper, it becomes an abyss.

Frontend Engineering

As per product teams:
“Someone who creates beautiful websites using the design team’s instructions.”

As per textbooks:
“HTML, CSS, and JavaScript.”
HTML is the skeleton, CSS is the skin, and JavaScript is the brain.

As per me?
It’s much more than that.

Frontend Engineering
├── UI Development — What everyone sees
├── State Management — What no one sees until it breaks
├── Routing — Mostly ignored, but critical unless you enjoy navigation nightmares
├── Design Systems — Design tokens keep the UI consistent
├── API/Data Layer — Most production issues start here
├── Authentication — One of the biggest production concerns
├── Performance — In production, every millisecond matters
├── Accessibility — Most developers ignore this until they shouldn’t
├── SEO — Decides whether people even discover your product
├── Security — Skip this and enjoy your legal/security nightmare
├── Build Tooling — A massive game changer if you truly understand it
├── Testing — Protects both your product and your sleep
├── Monitoring — Users will always find bugs in ways you never expected
├── Analytics — So you can actually measure improvements instead of guessing
├── Deployment — Because shipping localhost to customers isn’t a strategy
├── CI/CD — Automating releases so deployments don’t become rituals
├── Internationalization — Your app eventually speaks more than one language
├── Offline/PWA — Because internet connections aren’t always reliable
├── Realtime Systems — Notifications, chats, collaboration, live updates
├── Architecture — The difference between scaling smoothly and suffering later
└── Developer Experience — Better DX = faster teams and fewer headaches

Now some people will say:
“Come on, this is an over-the-top explanation.”

And honestly?
They’re not completely wrong.

But it’s also true that all of these areas fall under frontend engineering in modern production systems.

Now the next question is:

“Do we really need all of this?”

Most of the time? Probably not.

Modern frameworks already provide many things out of the box.
For example, when you create a Vue project today, you already get tools like Vite, package managers like npm/pnpm/yarn, routing setups, build pipelines, and much more.

But if you want to build something truly great — something scalable, performant, maintainable, and production-ready — eventually you’ll have to understand these layers.

That’s where frontend engineering actually begins.

And if you’re wondering what the “abyss” looks like…

It looks something like this:

Frontend Engineering
├── Rendering Strategies (CSR, SSR, SSG, ISR, Streaming)
├── Hydration & Partial Hydration
├── Reactivity Systems & Virtual DOM internals
├── Compiler Architecture
├── Browser Rendering Pipeline
├── GPU Acceleration & Paint Optimization
├── Edge Computing
├── Caching Layers
├── WebSockets & CRDTs
├── Distributed State Synchronization
├── Micro Frontends
├── Monorepo Architecture
├── Design Token Pipelines
├── Runtime Performance Profiling
├── Web Security Hardening
├── Memory Leak Debugging
├── Service Workers
├── Rendering at Scale
├── Bundle Optimization
├── Build System Internals
├── Accessibility Compliance
├── Observability Engineering
├── Frontend Infrastructure
├── Server Components
├── WASM Integration
├── Compiler Toolchains
└── Browser Engine Edge Cases

And somewhere in between all this, you realize:

Frontend engineering was never just about making buttons look pretty.

Article 3 of 100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc

Utkarsh Bansal — Sun, 02 Mar 2025 14:39:22 +0000

Handling Git mistakes is a crucial skill for any developer. Recently, I found myself in a situation where a simple feature branch turned into a mess—too many commits, merge conflicts, and unclear history. Instead of starting over, I took the time to properly fix it.

Here’s what helped:
✔️ git reset — Undo unnecessary commits
✔️ git cherry-pick — Apply specific changes cleanly
✔️ git reflog — Recover lost commits
✔️ git stash — Save work without committing

Learning to manage Git efficiently makes PRs easier to review and keeps repositories clean.

If you’ve ever struggled with a tangled Git history, this article might help.

📖 Read more: https://medium.com/p/19c1f22e29ed

Day 3/100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc Start here: https://medium.com/p/19c1f22e29ed

Utkarsh Bansal — Sun, 02 Mar 2025 14:35:50 +0000

Day 2/100: ‘Wait, don’t we already have this function?’ — Publishing Your First NPM Package 📦

Utkarsh Bansal — Sat, 15 Feb 2025 17:23:41 +0000

Another project, another déjà vu moment.

I was about to copy-paste a helper function again when it hit me: “Didn’t I just use this in another repo?” Instead of repeating history, I finally did what I should’ve done long ago—packaged it up and published it to NPM.

Publishing an NPM package is easier than you think, and once you do it, you’ll wonder why you didn’t sooner. No more hunting through old repos, just clean, reusable code.

🛠️ Ready to publish yours? Start here: https://link.medium.com/h2mfQqqn0Qb

“Wait, don’t we already have this function” — Publishing Your First NPM Package | by Utkarsh Bansal | Feb, 2025 | Medium

Utkarsh Bansal ・ Feb 15, 2025 ・
Medium

Day 1/100: Exploring Frontend Storage 🖥️

Utkarsh Bansal — Sat, 15 Feb 2025 17:17:05 +0000

Modern frontend development isn't just about UI—it’s about efficient data management. From cookies to IndexedDB, each storage option plays a crucial role in performance, security, and user experience.

This is my first article where I break down key data management, performance optimization, and security best practices — while addressing key security issues and sharing industry insights…

📖 Read: https://lnkd.in/g-A6H87H

DEV Community: Utkarsh Bansal

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

How ESLint Actually Works: The Quality Gate Behind Modern JavaScript - DEV Community

How ESLint Actually Works: The Quality Gate Behind Modern JavaScript

What Is ESLint Actually Doing?

Step 1: Your Code Stops Being Code

Step 2: Rules Walk The Tree

Why This Is More Powerful Than It Sounds

Category 1: Correctness

Category 2: Dead Code

Category 3: Security

Category 4: Performance

The Real Superpower: Quality Gates

Community Plugins Already Solved Half Your Problems

When The Defaults Aren't Enough: Write Your Own Rule

Where ESLint Fails

So Why Am I Still Talking About ESLint In The Age Of AI?

Takeaway

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

You Don't Need Another Agent. You Need a Linter. - DEV Community

You Don't Need Another Agent. You Need a Linter.

What a linter actually is

Why this matters more than it used to

A linter is a Quality Gate

It doesn't stop at "missing semicolon"

The trick that keeps the gate from being annoying

Gotchas

The mild jab

Takeaway

Frontend Is Not That Simple

Frontend Engineering

Article 3 of 100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc

Day 3/100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc Start here: https://medium.com/p/19c1f22e29ed

Day 2/100: ‘Wait, don’t we already have this function?’ — Publishing Your First NPM Package 📦

“Wait, don’t we already have this function” — Publishing Your First NPM Package | by Utkarsh Bansal | Feb, 2025 | Medium

Utkarsh Bansal ・ Feb 15, 2025 ・
Medium

Day 1/100: Exploring Frontend Storage 🖥️

Harnessing Frontend Storage: A Comprehensive Guide to Browser-Based Data Management | by Utkarsh Bansal | Feb, 2025 | Medium

Utkarsh Bansal ・ Feb 14, 2025 ・
Medium

DEV Community: Utkarsh Bansal

**What's the most over-engineered AI solution you've seen for a problem a linter already solves?** We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

How ESLint Actually Works: The Quality Gate Behind Modern JavaScript - DEV Community

How ESLint Actually Works: The Quality Gate Behind Modern JavaScript

What Is ESLint Actually Doing?

Step 1: Your Code Stops Being Code

Step 2: Rules Walk The Tree

Why This Is More Powerful Than It Sounds

Category 1: Correctness

Category 2: Dead Code

Category 3: Security

Category 4: Performance

The Real Superpower: Quality Gates

Community Plugins Already Solved Half Your Problems

When The Defaults Aren't Enough: Write Your Own Rule

Where ESLint Fails

So Why Am I Still Talking About ESLint In The Age Of AI?

Takeaway

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

You Don't Need Another Agent. You Need a Linter. - DEV Community

You Don't Need Another Agent. You Need a Linter.

What a linter actually is

Why this matters more than it used to

A linter is a Quality Gate

It doesn't stop at "missing semicolon"

The trick that keeps the gate from being annoying

Gotchas

The mild jab

Takeaway

Frontend Is Not That Simple

Frontend Engineering

Article 3 of 100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc

Day 3/100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc Start here: https://medium.com/p/19c1f22e29ed

Day 2/100: ‘Wait, don’t we already have this function?’ — Publishing Your First NPM Package 📦

“Wait, don’t we already have this function” — Publishing Your First NPM Package | by Utkarsh Bansal | Feb, 2025 | Medium

Utkarsh Bansal ・ Feb 15, 2025 ・ Medium

Day 1/100: Exploring Frontend Storage 🖥️

Harnessing Frontend Storage: A Comprehensive Guide to Browser-Based Data Management | by Utkarsh Bansal | Feb, 2025 | Medium

Utkarsh Bansal ・ Feb 14, 2025 ・ Medium

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

Utkarsh Bansal ・ Feb 15, 2025 ・
Medium

Utkarsh Bansal ・ Feb 14, 2025 ・
Medium