The non-serverless version still works fine, even in modern JS land. The simple approach still works if you have some knowledge around setting up a server and configuring a few things.

I also think that the advice around Authentication is often misguided. For simple cases it's not that hard to add authentication without a separate service. There is too much scaring the newbies around that topic, when they are probably about as likely to mess up authentication when they try to configure an excessively complex library compared to implementing basic session authentication with the tools their framework provides.

Even in the good old days you still had a database provider (often PHP plus MySQL in the classic LAMP stack) and in some cases an Auth provider (especially if you consider classic tools like Wordpress and Drupal as Auth providers). (Relatedly, the advice about Auth is best "don't roll your own auth" and that doesn't mean that you have to use an Auth provider, but at least use a library vetted by others. I also tend to add "don't keep passwords in your database" because that is a [legal/accounting] liability issue [more than being "hard", though it can seem hard to do right], which does make it good advice to find a third-party Auth provider you trust if you must support password-based workflows. Luckily some new options and libraries for password-less Auth are becoming slowly more common.)

The great big irony here is just that "serverless hosting" is just an extremely silly new name for "shared hosting". The basic economics are the same: instead of paying for a whole server, pay for what you use, then share the remaining resources with other sites.

The new serverless hosts aren't just trying to replicate the "good old days" experience, in some cases they've inherited it. They've also just had the bad luck of hindsight from past shared hosting model problems: insecure FTP is dead (so there's much less of a feeling of "just copy the files over"), allowing direct crontab editing is known to be dangerous in shared hosts so serverless options need their own (often extremely custom) timed kickoff DSLs, hosting static files and application files in the same place is known to cause accidents so there's a greater separation in static hosting and serverless applications, and so forth. A lot of those same complications happened to a lot of the "classic" shared hosts, too. (Which is why many of those entrenched to specialize in known applications over time, cPanel anything you want as long as it is Wordpress or Drupal or one of the other six blog apps the host vetted. The disappearance of "shared hosting" wasn't just that modern development got complicated but that modern shared machine security got harder.)

"Serverless" is one of those names that kinda-sorta-almost makes sense: It's that your code runs "on no server (in particular)" rather than "on no server (at all)".

Someone stripped off that nuance in trying to come up with a concise buzzphrase for code that expects ephemeral access to an arbitrary server.

We can still do that. It still works. You can still just use rails or Laravel and deploy to heroku. Or just a single php file.

The only reason we don’t do it anymore in the cases where that would be enough and instead overengineer everything is because others will look us down.