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.
Top comments (0)