> PHP has the world's simplest deployment model for web applications: copy some files to a directory<p>And set up a webserver. Perhaps compile mod_php for Apache and configure it, taking care to do it securely. Then configure php too, again taking care to do it securely. Only then you can drop a bunch of files in a docroot and have PHP process them. And put some .htaccess files in so that things that aren't supposed to be directly executed can't be. I think it all just appeared simple, but it wasn't. It was dumb luck and lowest common denominator configurations on shared hosting that made it appear easy.
That is such a well articulated observation, it resonates strongly with my own experience.<p>I grew up on PHP, it was the first thing beyond BASIC I ever wrote, and I wrote a lot and enjoyed it so much. It really was this magic thing, that you just modified whatever file you needed to modify, throw it on the server, and hit f5 to see your changes reflected.. No processes to restart, no state to be lost, you jammed, and it was a very gentle way to learn.
I can empathize with your lament that it used to be easy to spin up a quick website. It sounds to me like your experience as a software developer blocks you from willfully making mistakes we've all learned the hard way.<p>SSI still works, and you can turn it on with Nginx. It's still quite limiting and fragile.<p>PHP still works, but as your project grows, unless you have equally experienced PHP developers, you'll see things get out of hand quickly with scope issues.<p>CGI will still work, but similar to PHP, it's a headache to setup the sandbox so a malicious or naive committer doesn't clobber the environment. At least PHP's defaults were pretty sane until someone does something cute and bypasses magic quotes and introduces some SQL injection.<p>Let's give AWS Lambda some credit though, it's virtualized and containerized CGI and can scale to handle loads that you'd think your backend was written in Elixir.
Frontpage, now that's a word I haven't heard in a long time. I used to make little pages with Frontpage and inspect the generated text to learn HTML.
I still build mildly dynamic websites in PHP once in a while. But this is only useful when it is a very small website (max 5 pages?) because you have to work with a directory structure to go without framework.<p>The moment your site gets a little bigger you need some kind of routing. This means you start redirecting all requests to one PHP file.<p>Then you start using forms and you need a database, a little framework for responses, and so on.<p>So you very quickly need a framework. This can of course be a very small framework.<p>The point is, small frameworks are so easy to setup you start skipping the 'mildly dynamic website' part because it doesn't scale at all.
You might be interested in <a href="https://stitcherd.vhodges.dev/" rel="nofollow">https://stitcherd.vhodges.dev/</a> a side project of mine.<p>It's pretty basic right now, but can already handle a number of use cases for injecting dynamic content into a mostly static site. (Essentially SSI using css selectors and DOM changes on the server side).<p>Alas I haven't had much time to work on it lately, but I plan to use it for something at $DAYJOB so it will get some attention at some point.
"These are sometimes used to host full-blown web applications but I don't see them being used to facilitate mildly dynamic functionality. mod_perl and mod_lua, for example, don't really offer any kind of functionality allowing you to dip [in] and out of Perl/Lua code inside HTML."<p>I want to understand this statement however I only use Lua with haproxy to achieve "mildly dynamic" pages. It is difficult for me to understand what exactly the author wants to do without an example.<p>Are there any good examples showing that the author is correct, i.e., that it is impossible to "dip in and out" of Lua inside HTML.<p>Certainly I recall projects that purported to offer Lua as a CGI-like interpreter, "Lua Server Pages", or something similar. Have they not delivered on their promises.<p>For example, see<p><a href="http://keplerproject.github.io/cgilua/manual.html" rel="nofollow">http://keplerproject.github.io/cgilua/manual.html</a><p><a href="https://fuguhub.com/LuaServerPages.lsp" rel="nofollow">https://fuguhub.com/LuaServerPages.lsp</a><p><a href="http://barracudaserver.com/Lua-Server-Pages.html" rel="nofollow">http://barracudaserver.com/Lua-Server-Pages.html</a><p><a href="http://xupnpd.org/luasp/" rel="nofollow">http://xupnpd.org/luasp/</a><p><a href="https://redbean.dev/" rel="nofollow">https://redbean.dev/</a>
Honestly this type of workflow is what I love(d) about rails. ERB is a nice enough templating language such that most trivial functionality is pretty much HTML, but dynamic content can be added in in a php-like way. Equally 'jammable' is the server side code as well - Database is abstracted away, and all server side APIs and application code is all the same ol' Ruby. Django is similar with their own system for python, and equally easy to use. These web frameworks were exceedingly popular at one point, to the point where when node came along, along came express.js with it touted as "rails for node". But aside from rails itself, and possibly django, and php in a more minimal sense, there really isn't this kind of thing anymore? Why did we abandon it?<p>I guess the common criticism is "it doesn't scale" but it seemed perfectly fine for me and my needs, and countless others, right up until every major rails project on github was "last updated: 2014". Feels like the rug was pulled out from under our feet. An exodus without cause, an ark without a flood.
I'd disagree about Lambda functions.<p>I wouldn't use them for most things but I built an email mailing list manager that uses Lambda for several things such as bounce handling, subscribes, verification, unsubscribes, etc.<p>Sometimes I go (more than a few) months without looking at the system. Then I write a blog post that hits it big and get a few hundred sign ups in a few hours.<p>If I were trying to deploy the manager as part of a web site the calculations would be different, but as a stand-alone application I dread the thought of running the manager as a cloud instance or VPS. If I ran the system on a really adequate instance it would cost way too much to run. If I ran the machine on an instance I could afford, every six months or so the system would get a burst of traffic, go swap crazy (quit running AND possibly running up an extra $200 a month in EBS I/O charges) and need maintenance to get it back up.<p>The API gateway for the Lambda function is almost Salesforce.com expensive on a per-request basis but it cheap when you consider the value of an email subscription and that I never have to think about the thing.
> Or maybe they just stuck it out and edited every page manually when they wanted to change the header or footer.<p>We had a tool for this called frames!
I've been wondering why the approach that many imageboards had to dynamic content didn't catch on further.<p>Essentially, on those boards, HTML wouldn't be rendered for each request but instead regenerated and stored on each update (POST request etc). The update script would generate a plain html file and store it in the www directory of a static web server, overwriting the previous version of that file. For GET requests, the server simply returned the current version of whatever file was requested.<p>This allowed the server to employ the full range of optimizations for static files (caching, partial content headers, etc) while still essentially serving dynamic content.<p>Of course, this kind of architecture makes only sense if updates are rare compared to GETs and if very little of the content depends on individual user identity. However e.g. for blogs or news sites, both conditions are usually given.<p>If there are small amounts of individualized content, this content could be pulled in via scripts.
I've noticed this gap too, and started a (very alpha, experimental, and lately neglected) side project[0] that attempts to fit into this niche: a web server oriented explicitly towards "mildly dynamic" use cases. In its current form deployment/updates are definitely not as easy as with shared PHP hosting (I have ideas for how to improve that eventually) and it probably won't scale well to lots of traffic or lots of dynamism (e.g. it spins off separate processes to handle scripting/computation, just like CGI does), but it's been fun to work on and I think helps me cope with the ennui I feel whenever I'm faced with the modern "best practice" of "let's make everything a SPA".<p>[0]: <a href="https://github.com/mkantor/operator" rel="nofollow">https://github.com/mkantor/operator</a>
I've been working on a "mildly dynamic website" using a modern stack: A simple Rust webserver (about 30 lines setup in the Axum framework) running in a trivial Docker image (just copies in the binary + static assets) hosted on fly.io (which is completely managed and free for up to 3 VMs).<p>It's been great: I have all the flexibility of a dynamic template engine and a turing complete language running before that. But equally if I want to hardcode HTML then I can. And because it's Rust its still wicked fast (I'm getting 50ms page loads including all assets) and resource usage is almost non-existent (it's running on a VM with 256mb ram).
Using server side includes support that your nginx/apache/etc webserver binary already has is another very small attack surface way to mild dynamism. I know it sounds 90s and stupid but it's really very useful with no downsides.
I've stumbled upon your website from linked articles from time to time and I really like the new layout. It's kinda as bare-bones (in a good sense) as the old one but just that much nicer to read.
I really like the flexibility of Linux, PHP and .. bash scripts that run from cron and populate my SSI files :) My site is lightweight and I don't use frameworks for PHP so load time is exceedingly quick. I take comfort in the fact that if power availability gets tough, I'll be able to transfer the site to something like a Raspberry Pi.
As someone fairly new to software, I was brought up on React, Node.js, Flask, Typescript, and AWS Lambda as my tech stack. Is there a definitive resource where I can learn about the older methods of web dev that are talked about in this article?
> the average modern web developer has no comprehension of what the web actually is<p>And suggesting that there's anything wrong with this is "gatekeeping".
There is nothing "Dynamic" about a website like imgur.com or twitter.com or reddit.com. They are megabytes of javascript heavy and are things you check every once in a while, not things that change before your eyes. I find twitter's 'new tweets' popups annoying and in any case i refresh the page because it s already too heavy from too much infinite-scrolling