A few years into building web applications, I ran into a production incident that forced me to reconsider what web development actually required. A feature I had shipped started failing under load. The symptoms were strange: slow responses, intermittent errors, database connection timeouts that appeared only at certain traffic levels. The fix turned out to involve three things simultaneously — a missing database index causing a full table scan, a connection pool limit that was too low for the request concurrency, and a CDN configuration that was caching API responses that should never have been cached.
None of these issues involved writing bad HTML or CSS. None of them were caught by a linter. Fixing them required understanding TCP connection behavior, database query planning, and how CDN edge servers decide what to cache. That incident made it concrete for me: web development is the surface. Web engineering is the depth underneath it.
Web engineering is the application of engineering principles — systems thinking, measurement, formal analysis of tradeoffs — to the design, construction, and operation of web-based systems. The distinction from web development is one of scope and rigor, not technology. A web developer builds features. A web engineer thinks about how those features behave under load, how they fail gracefully when dependencies are unavailable, how they expose or protect data, and how they perform across the network conditions of real users.
In practice, most working engineers do both. The split is not a hierarchy — it is a spectrum of concerns. As a system grows in scale or criticality, engineering concerns become more important. As a product needs to ship quickly to validate ideas, development concerns dominate. Understanding both, and knowing when each matters, is the core of the discipline.
The Full Stack, Honestly Defined
The phrase "full stack" has been watered down to mean anyone who can write both JavaScript and SQL. In practice it is more specific. Frontend engineering involves understanding the browser as a platform — not just the DOM API but the rendering pipeline, the event loop, network timing, memory management, and how the browser's security model constrains what your code can do. Backend engineering involves understanding server-side application design, API contracts, data modeling, concurrency, and how to build services that are reliable under real-world conditions.
Frontend as a Platform
The browser is a complex runtime environment with its own threading model, memory constraints, and security boundaries. Writing good frontend code means understanding that JavaScript runs on a single thread, that long-running synchronous operations block rendering, that network requests are asynchronous by design, and that the same code will run on devices with vastly different capabilities. A button that works perfectly on a developer's MacBook may freeze a mid-range Android phone if the click handler runs an expensive loop synchronously.
Frontend engineering includes the performance implications of JavaScript bundle size (every kilobyte takes time to parse, not just download), the rendering mechanics of CSS (reflow vs repaint vs composite), and the security implications of what data you put in localStorage versus a cookie with the HttpOnly flag. These are not advanced topics — they are the fundamentals of the platform you are building on.
Backend as System Design
Backend engineering is fundamentally about making decisions under uncertainty. You do not know exactly how much traffic will arrive. You do not know when a dependency will be unavailable. You do not know which queries will become bottlenecks as data grows. Good backend engineering designs systems that degrade gracefully when these unknowns resolve unfavorably: rate limiting, circuit breakers, database indexes on the columns you will filter by, connection pooling sized for expected concurrency, and health check endpoints that give you visibility into what is happening in production.
The single most common cause of backend performance problems I encounter is missing database indexes. A query that works in development against a few hundred rows will time out against millions of rows on the same table without an index on the filtered column.
HTTP: The Protocol Everything Runs On
HTTP is the foundation of every web application. Understanding it at the request-response level — not just how to use fetch() — changes how you debug problems, design APIs, and think about security.
Every HTTP response has a status code that carries semantic meaning. 200 means success. 201 means a resource was created. 301 is a permanent redirect — search engines and clients will cache it and stop sending requests to the original URL. 302 is a temporary redirect. 400 means the client sent a bad request. 401 means authentication is required. 403 means authenticated but not authorized. 404 means not found. 429 means the client is being rate-limited. 500 means the server broke. Using these correctly in your API design matters because clients — browsers, apps, other services — use status codes to decide how to handle responses.
HTTP headers are where a surprising amount of security happens. The Content-Type header tells the browser how to interpret the response body — returning a JSON response with Content-Type: text/html can create XSS opportunities in older browsers. The Set-Cookie header accepts flags like HttpOnly (prevents JavaScript from reading the cookie), Secure (only sends over HTTPS), and SameSite (prevents cross-origin request forgery). The Cache-Control header tells every caching layer — the browser, CDN, proxy — whether and how long to cache the response. Getting this wrong in either direction causes either stale data bugs or unnecessary server load.
HTTP/2 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Strict-Transport-Security: max-age=63072000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict; Path=/The Browser Rendering Pipeline
Understanding what happens between receiving an HTML document and displaying a pixel on screen explains why some CSS and JavaScript patterns are expensive and others are not.
The browser parses HTML into a DOM (Document Object Model) — a tree of nodes. It parses CSS into a CSSOM (CSS Object Model) — a tree of style rules. It combines these into a render tree, which contains only the visible nodes with their computed styles. It calculates the exact position and size of every element in a process called layout (or reflow). It draws the elements into layers in paint. Finally it composites the layers together on the GPU in composite.
The expensive operations are layout and paint. Changing a property like width, height, margin, or top on an element triggers a reflow — the browser recalculates the geometry of that element and potentially all surrounding elements. This is slow. Changing transform or opacity only triggers compositing, which happens on the GPU and is fast. This is why modern CSS animations should use transform: translateX() instead of changing left, and why will-change: transform can improve performance by promoting an element to its own compositing layer.
Backend Architecture Patterns
The main architectural decision in backend systems is how to organize and distribute responsibility across services. This is a spectrum rather than a binary choice, and where you sit on it should be determined by the actual needs of your system, not by what is fashionable.
The Monolith
A monolith is a single deployable unit that contains all the application's functionality. This is not an anti-pattern — it is the correct starting architecture for most systems. A well-structured monolith is easier to develop, test, deploy, and debug than a distributed system. The engineering cost of building and operating microservices is substantial, and it only pays off when the team or traffic scale genuinely requires it. Most applications that are struggling with a monolith are struggling with a poorly structured monolith, not with the concept of monolith itself.
Microservices and Their Real Cost
Microservices decompose an application into separately deployable services that communicate over a network. The benefits are real: independent deployability, the ability to scale specific services independently, and better fault isolation when done correctly. The costs are also real: every cross-service call now involves network latency, serialization overhead, and the possibility of network failure. You have replaced in-process function calls with distributed systems problems. Testing becomes harder because you need to run multiple services together. Distributed tracing becomes necessary to understand what is happening across service boundaries. These are solvable problems, but they are real costs that should be weighed against the benefits.
Databases as Engineering Problems
Database selection is an engineering decision that should be driven by access patterns, not by hype cycles. The most important question is: how will you read this data? If you will query it relationally — joining tables, filtering by multiple columns, aggregating across rows — a relational database with proper indexes will serve you well at any scale most applications encounter. If you will always access data by a single key with no joins, a key-value store like Redis may outperform a relational database. If you will store and query hierarchical documents with no fixed schema, a document database like MongoDB has real advantages.
The most common mistake I see is choosing a NoSQL database to "avoid the complexity of schemas" and then spending months trying to answer queries that a relational database with a few indexes would have answered trivially. Schemas are not complexity — they are contracts. They make your data predictable and your queries efficient. The discipline of defining a schema upfront forces you to think clearly about your data model, which almost always produces a better result than discovering your data model through the bugs that emerge later.
API Design That Holds Up
An API is a contract between a server and its clients. Once clients depend on it, changes become expensive because they break things. Good API design minimizes the cost of that contract by being consistent, predictable, and versioned from the start.
REST organizes resources as URLs with HTTP methods expressing operations. GET /users/123 retrieves a user. PATCH /users/123 updates it. DELETE /users/123 removes it. The consistency of this model makes APIs easy to understand and use. GraphQL lets clients specify exactly what data they need in a single request, which reduces over-fetching on mobile clients and enables powerful tooling. tRPC provides end-to-end type safety between a TypeScript backend and frontend, which eliminates an entire category of runtime type errors at the cost of requiring TypeScript throughout.
Version your API from day one, even if you think you will never need it. Adding /api/v1/ to your routes costs nothing now and saves significant pain when you need to make breaking changes without disrupting existing clients.
Security as a Core Engineering Concern
Security is not a layer you add on top of a finished application. It is a property of each engineering decision — what data you collect, how you store it, what you accept as input, how you authenticate requests, what you log, and how your dependencies are managed. Every architectural decision has security implications, and the cost of retrofitting security into a system that was not designed with it in mind is almost always higher than building it in from the start.
The most practical security habit is treating all client-side input as untrusted until server-side validation has confirmed it meets expectations. This single principle prevents SQL injection, command injection, XSS, and a long list of other vulnerability classes. It does not require security expertise — it requires the habit of asking "where does this data come from, and have I verified that it is what I expect?"
Performance Engineering
Web performance directly affects user experience and business outcomes. Google's Core Web Vitals are the current standard framework: Largest Contentful Paint (LCP) measures when the main content is visible, Interaction to Next Paint (INP) measures responsiveness, and Cumulative Layout Shift (CLS) measures visual stability. These are not abstract metrics — they correspond directly to whether users experience a page as fast and usable or slow and frustrating.
The highest-impact performance improvements I encounter in practice are: serving images in modern formats (WebP, AVIF) at appropriate sizes, moving critical CSS inline to eliminate render-blocking stylesheets, lazy loading images below the fold, adding database indexes to eliminate slow queries, and configuring proper Cache-Control headers to prevent redundant requests. Before optimizing anything, measure it. Chrome DevTools' Performance panel and Lighthouse provide the data you need to identify what is actually slow rather than what you assume is slow.
