== Traditionally there are fewer steps in setting up a static website It's common to say that it's "easier" to set up a static website than a dynamic one, although people usually don't try too hard to define what is easier about it. I've come to think that one reason for this perception is that historically, setting up a static website has effectively been a subset of setting up a dynamic website. One reason for this is the same fundamental dynamic [[that has made serving static files efficient StaticFilesAndEfficiency]], which is that historically most dynamic websites had some static components. Since dynamic websites had static components, general web servers supported serving static files essentially by default even if they were partially oriented toward dynamic sites. If you were setting up a dynamic site, you set up your web server and then configured both the static side (for your static assets) and the dynamic side (for your dynamic application). If you were setting up a static site, you set up the general web server, set up the static side, and stopped. Often the setup for the static side was quite simple (as opposed to the general web server setup). (Traditional general purpose web servers also usually made it easier to set up the static side than the dynamic one, so it was less work to set up a purely static website with them than to set up a purely dynamic one. Often the static side essentially worked by default while you had a lot of fiddling for the dynamic side.) My impression is that this is somewhat changing today, with an increasing number of (dynamic) application servers that can be put directly on the Internet (or behind a proxying CDN like Cloudflare). These application servers don't need any additional configuration to do dynamic things; they're dynamic out of the box (and often support some static file serving too, although it's not necessarily their focus). The extreme version of this is various 'serverless' environments that are entirely dynamic. (Serverless environments are often coupled to a separate way of serving static assets, but it's separate; if you want to serve your static assets through the same interface as your dynamic side, I think you generally have to wrap them up in a dynamic container.) PS: To take a thought from [[The Demise of the Mildly Dynamic Website https://www.devever.net/~hl/mildlydynamic]] ([[via https://lobste.rs/s/xqlim2/demise_mildly_dynamic_website]]), one part of the power of the old fashioned Apache and PHP (and sometimes Server Side Includes) environment was how seamlessly you could move from static to dynamic content and how easy it was to set that up. In simple setups, you didn't really have to do anything globally (beyond enabling PHP); instead you could decide what was static and what was dynamic on a page by page basis with no global configuration necessary.