What "Serverless" Actually Means Now
Serverless is one of those terms that sounds like it's describing something that doesn't exist. In the context of web development, it's shorthand for a specific way of deploying code that shifts infrastructure responsibility away from the developer. Chris Coyier joined the podcast to unpack what serverless architectures really involve and why front-end developers in particular are paying attention.
At its core, serverless doesn't mean there are no servers — it means you don't have to worry about running them. Instead of provisioning and maintaining a machine or container that's always on, you deploy functions that execute on demand. The cloud provider handles scaling, availability, and the operational overhead, and you only pay for the compute time your code actually uses.
This is a meaningful shift from traditional setups where you might rent a server with a fixed capacity, or even from container-based deployments where you still manage orchestration. With serverless, there's no idle time to pay for and no capacity planning to do ahead of a traffic spike. If nobody's hitting your endpoint, the function simply isn't running.
Why Front-End Developers Care
Serverless becomes particularly interesting for front-end developers because it lets them handle backend tasks without standing up an entire application server. Coyier's microsite on the topic frames it directly: it's about giving front-end folks access to backend capabilities they might otherwise avoid.
A typical scenario is handling form submissions. A static site can't process a POST request on its own, so developers traditionally needed a backend service or a third-party form handler. With a serverless function, you can write a small piece of JavaScript that runs when a form is submitted, processes the data, and sends it somewhere — no separate server to configure. The same pattern extends to other lightweight tasks like sending emails, validating tokens, or querying a database.
The appeal goes beyond just convenience. For front-end developers, serverless functions can be written in familiar languages and maintained directly in the same repository as their front-end code. That removes the context switch of working on separate codebases with different deployment pipelines, which is often a barrier to touching the backend at all.
A Different Mentality From Traditional Backends
It's important not to conflate serverless with backend development as a whole. A serverless function is still code running somewhere, but the way you think about it is different. You're not designing for a long-running process that manages connections or holds state in memory. Each invocation is treated as an isolated event, and you're responsible for making it stateless and quick to execute.
That constraint changes how you write and architect things. You can't assume a local variable survives between calls because the environment might be torn down and recreated. You also need to be conscious of cold starts — the delay when a function hasn't been invoked in a while and the platform has to spin up a fresh environment. The source and context for these trade-offs are all part of what makes the serverless model distinct from renting a dedicated box, and it's why the model is worth evaluating on a case-by-case basis rather than adopting everywhere by default.
Why “Serverless” Is a Misnomer That Won
Chris Coyier, co-founder of CodePen and creator of CSS-Tricks, is a front-end developer by preference. That makes his interest in serverless architectures somewhat personal: it lets him apply the JavaScript skills he has spent years honing to the server side of web development.
The term “serverless” is, of course, misleading. There are still servers. Coyier acknowledges that having a visceral reaction to the word is practically a required first step in understanding it. But the term has already won, and fighting it is pointless.
What made serverless concrete for many developers was AWS Lambda. You hand a function to AWS, it gets a URL, and hitting that URL executes the function. The appeal is obvious: the function can hold API keys securely and talk to databases without exposing anything in client-side JavaScript. Lambda functions were tied to regions, though newer offerings like Lambda@Edge span all of them. Every major cloud provider now has a similar product, including CloudFlare Workers, which run JavaScript at the CDN layer. Coyier notes that CDNs already feel less “server-y” than traditional infrastructure, making workers feel even further removed from conventional servers.
Cheaper, More Secure, and Built From Small Pieces
A common analogy compares serverless to using a ride-sharing service. You don’t own a car, but cars still exist — you summon one only when needed and avoid the upfront costs of purchase, maintenance, and fuel. The pricing model reflects that. A back-end developer used to sizing servers by memory and CPU discovers that serverless can cost a fraction of what they were paying. At that point, ignoring the cost difference is practically being bad at your job.
Security also improves. Your code isn’t sitting next to sensitive data on your own network. If a lambda or worker attempts to break out and probe its surroundings, there is nothing there to find. The architecture also encourages small, modular components that each do one thing well.
Not an Either/Or Architecture
Serverless doesn’t require abandoning traditional infrastructure. Databases remain relevant. If a relational database is the correct way to store data, it still is. Serverless happens to be growing up alongside JAMstack, which advocates serving pre-built static files from CDNs. JAMstack says: pull data from a database either ahead of time (during a build) or after time (via client-side JavaScript), but don’t generate documents on the server at request time. That is a paradigm shift, not a ban on databases.
The two ideas don’t have to travel together. A JAMstack site can have nothing to do with serverless. Likewise, CodePen is a Ruby on Rails app running on many EC2 instances, yet it uses serverless functions wherever possible. Mixed architectures also work for real-world constraints. For a large e-commerce site with 10,000 products, rebuilding everything statically may be inefficient. You can let that part hydrate dynamically through serverless functions while pre-rendering the rest of the site. Even legacy systems from the 2000s can be dragged forward by gluing a JSON API layer onto an old database.
Coyier prefers not to make his stack “a little bit of everything,” but acknowledges technical death from over-fragmentation. Serverless functions can speak to each other, and an orchestrator function that stitches together multiple calls is generally smarter than making the client talk to many servers. The idea of “small pieces loosely joined” applies nicely, though it comes with testing challenges — verifying seven functions that work together is harder than testing one.
Real Tasks on CodePen
CodePen puts serverless to work in concrete ways. The site lets users write Sass, Less, Babel, and TypeScript in the browser. Shipping an entire compiler to every client isn’t smart, so each preprocessor runs as its own tiny lambda. Send it source code, get back the processed result. These lambdas are so cheap they almost count as free.
Screenshots of Pens are another example. Every Pen has a screenshot URL, and that URL is a CloudFlare Worker backed by a key-value store. When the URL is requested, the worker quickly checks whether the screenshot already exists. If it does, it serves it from CloudFlare, which can also optimize format and dimensions on the fly. If not, it asks another serverless function to generate the image, stores it in an S3 bucket, and serves it. There’s no queuing server and no manual intervention, despite tens of millions of images being served.
One specific task that only makes sense as serverless: a function that generates clever Glitch-style slugs from an open-source dictionary. Shipping a multi-megabyte word list to the client would be terrible, but Node on a server doesn’t care. A beginner JavaScript developer can write that function in about eight lines and get a working API.
Testing and Deployment Realities
Testing serverless functions is still evolving. A function is essentially a normal Node function, so you can execute it locally like any other code, but testing HTTP request behavior is harder. Tools exist to help. The company called Serverless (“.com”) makes a widely regarded framework for writing and deploying functions to real providers, though its name is terribly confusing. CloudFlare Workers use a tool called Wrangler, which spins up a local environment that simulates the CDN request flow.
Workers are notable for a different reason: they can manipulate HTML while a request passes through — almost like jQuery for the edge. One recent CodePen example involved fetching content from one site and injecting it into a div on another. Doing this client-side would hurt SEO and resilience. Doing it on a traditional server risks the whole page dying if the network call fails. A worker fetches site A, pulls content from site B, and serves the combined page — looking fully server-rendered, but executed at the edge in milliseconds because it’s server-to-server traffic, not constrained by the user’s connection.
Secrets, Suppliers, and the Future
API keys are a form of provider buy-in. Providers offer web interfaces for storing keys and making them available at runtime. But putting keys in source control is bad practice. CodePen recently adopted git-crypt to encrypt keys in repositories while keeping them usable locally.
Serverless probably doesn’t unlock capabilities that were previously impossible, but it commoditizes them. Coyier imagines a future marketplace of high-quality open-source functions — say, a screenshot function that everyone uses because it handles edge cases well. He maintains a resource site at serverless.css-tricks.com (note the dash), listing providers for serverless services. Forms are a hot category: with more than 20 services vying to process form submissions, it’s a crowded market.
Reliability ultimately rests with the providers. Coyier trusts companies like AWS and CloudFlare more than self-hosting when it comes to uptime. The bigger risk is your own code failing. Handling that requires structuring for failure, perhaps retrying a request rather than giving up.
Coyier’s current side project is an Electron client for a text-based online RPG he played during the AOL era. It renders with the Mithril JavaScript library, which is like React without JSX. The game involves heavy data manipulation, so rendering speed genuinely matters. It’s rare for him to contribute to someone else’s project, but it has forced him to learn different technology choices — which, he says, is the only way he ever learns anything.
