The theory versus the practice of “static websites”

The semantics of that abstraction are that requests come in to a specific path with headers and a body, and then responses are sent back out with headers and a body. The intermediate networking details like TLS are hidden. In fact, more and more things are being hidden from the developer, with most modern frameworks automatically managing authorization sessions and request headers. Within that abstraction, the standard "static doesn't depend on request/state, dynamic does" is pretty clean, but it does rely on the semantics provided by the abstraction.

It's a little bit like TCP being a connection-oriented protocol over a fundamentally packet-based underlying infrastructure. I can use TCP for applications that require stream-like or packet-like data transfer. Then you could argue that "in reality, the distinction doesn't exist because it's built on IP which is packet-like". Sure — but you'd be on the wrong layer of abstraction.

That's not to say the article doesn't make a good point. As developers, we should certainly always keep in mind the underlying statefulness of "stateless websites". It's always good to know your abstractions a few layers deeper than you think you need.

That said, as the second article points out, static vs dynamic can still be a useful abstraction layer, as static servers like nginx and Apache are so solid that you can usually just treat them as part of the basic HTTP infrastructure.

It was great. Until the webhost took away PHP anyway.

You might want to store user-submitted content in a database, for example. Or you might want to do authentication. You might want to provide full-text search in a multi-gigabyte dataset. You might want to provide an interface to something which can't be accessed from a web browser. You might want to validate user-provided input.

All of those require custom code running on a server. So now you have to take whatever data you have on the server, translate it into a well-defined custom transfer protocol, send it to the client, translate it back, and finally turn it into html. And the same for the other direction, but now you suddenly have to do input validation on both the client and the server to prevent anyone creating a custom client from doing anything malicious.

Or you can just turn it directly into html on the server and be done with it. It's a lot less work, and provides basically the same experience for most applications.