Live data from Hacker News

The demise of the mildly dynamic website (2022)

devever.net

101–110 of 183 posts

Re: The demise of the mildly dynamic website (2022)

#101
post #100

Semi-related: what's the best place to learn the old school style of working with php, I already know laravel but it feels so far removed from normal php that I am not confident working with it on it's own.

I would try some "old style" php frameworks. Like CodeIgniter or Yii. If you want even simpler, then maybe try Slim framework. You'll have to add your own data access lib. If you want Grug brain PHP then there's https://github.com/bcosca/fatfree You can also use composer package manager to build your framework with libs like routing, sql query builder, etc.

> Fast and clean template engine

Is PHP not already a template language?

The whole idea of PHP frameworks always confused me. Why do I need a router when I can simply add new files at the routes I want?

Re: The demise of the mildly dynamic website (2022)

#102
This article resonates with me. I do love "mildly dynamic websites", and have fond memories of my days hacking together PHP websites 15 years ago.

And what I am working on today might be called a bridge for the "dynamicity gap". I'm making an open source server to write web apps entirely in SQL ( https://sql.ophir.dev/ ). It has the "one file per page" logic of PHP, and makes it easy to add bits of dynamic behavior with just a normal INSERT statement and a SELECT over dynamic data.

Re: The demise of the mildly dynamic website (2022)

#103
post #94

Earlier quoted context omitted.

Do you enable unattended upgrades and kernel live patching? If not, then that doesn't seem secure.

`dnf upgrade` or `apt update && apt upgrade` once a month isn't so much work. If either includes a kernel upgrade then it's `reboot now` and I'm done.

But if you're doing that, it's not just sitting there, and you'd never get anywhere close to years of uptime.

Re: The demise of the mildly dynamic website (2022)

#104
post #9

> What captured people's imaginations about AWS Lambda is that it lets you a) give any piece of code an URL, and b) that code doesn't consume resources when it's not being used. Yet these are also exactly the attributes possessed by PHP or CGI scripts. In fact, it's far easier for me to write a PHP script and rsync it to a web server of mine than for me to figure out the extensive and complex tooling for creating, ma…

Once you add API gateway, IAM roles/permissions, VPC, security groups, it gets a lot more complicated. Then you want to host a static web site, reverse proxying to API gateway, add CloudFront, WAF, etc. You'll go crazy setting this up manually, so you'll also want Terraform or CloudFormation to make it repeatable. For anything complex, you'll run into "slow start" issues and have to look at provisioned concurrency. L…

Yeah, it's an absolute explosion of complexity, and with it comes the risk that you miss something and are faced with a security issue or giant bill or both.

What I would kill for is something in between all of this and FTPing PHP around like it's 1999. I've hunted for years for middle-ground solutions and haven't found anything. Security, cost, performance etc are important, sure, but what I really yearn for is a simple, easy, bulletproof solution like the days of yore when a handful of simple scripts could chug on for decades. Two decades ago you could set up a simple site that needed no attention for twenty years. Today's technologies require constant attention and updates and if you blink then everything requires an update that's not compatible with your code. Meanwhile, PHP from 2004 can be trivially run in 2024. What's the PHP-and-FTP of today? Does it exist?

Re: The demise of the mildly dynamic website (2022)

#105

This perspective isn't really making an apples-to-apples comparison. The author is comparing modern framework bloat to the simplicity of a standalone PHP script, but disregarding the underlying stack that it takes to serve those scripts (i.e., the Linux, Apache/Nginx, MySQL/Postgres in LAMP). Back in those days, it was never really as simple as "sftp my .php file into a folder and call it a day". If you were on a sha…

(too long... here's part 2): 4) Serverless as "CGI but it's trendy, [with vendor lock-in and a more complex deployment process]" What vendor lock-in? Most of the code is just vanilla JS. There might be a different deployment procedure if you're using Cloudflare vs Lambda vs Vercel vs Serverless Framework, but those are typically still simpler than having to set up an SFTP connection or git repo in a remote folder. Wi…

Thank you for that lengthy diatribe, which I heartily agree with. It's really all about separation of concerns.

Re: The demise of the mildly dynamic website (2022)

#106
post #14

I think the spirit of this article is correct, although some of the digs at modern web tech and SPAs seem to be beside the point. I used to have a "mildly dynamic website." It was a $5 digital ocean box. It ran nginx with php-fpm, mostly so it could have a Wordpress install in a subdirectory, and it had a unicorn setup for an experimental Rails app somewhere in there. Given that environment, the "mildly dynamic websi…

> it requires endless system maintenance. Otherwise all the PHP stuff becomes vulnerable to random hacks How so? I've seen PHP websites & apps run for 10+ years in production without updates. Even longer with a simple "sudo apt update" every few months and a "composer update" every year or so. The maintenance rate is actually very very low.

Years ago a Digital Ocean virtual server of mine stopped working because I had never upgraded Ubuntu to the newest major version. After a few years, the version of Ubuntu was no longer supported by the Digital Ocean hypervisor and couldn't mount or boot at all.

In my experience, yes you absolutely need maintenance. In the past I've had to upgrade from HTTP to HTTPS, upgrade the OS, upgrade to newer versions of external API and embedded components because the old ones were deprecated, handle a domain registrar shutting down, and then yes absolutely PHP updates and upgrades for security that then start giving you warnings because less secure versions of functions are being deprecated...

And frequently updating the one thing that's broken necessitates upgrading a bunch of other things that breaks other things.

I literally cannot imagine how you would keep a PHP site running on a virtual server for 10 years without any maintenance. I need to address an issue probably roughly once a year.

Re: The demise of the mildly dynamic website (2022)

#107
post #75
post #58

I like the idea of just renaming an `html` file to `php` and adding a bit dynamic stuff. A webserver that could do this with JavaScript/TypeScript would be cool! (Or maybe I should learn php…)

Yeah, I was shocked when, coming from PHP, I realized that in Python, in order to serve a website, you have to start and maintain an extra server process.

Don't forget deploying updates by either (a) stopping your Python application and then restarting it, hoping your users are not too badly inconvenienced in the interim, or (b) rigging together some kind of blue-green deployment setup. Meanwhile, the PHP developer runs rsync and the deployment is done.

Re: The demise of the mildly dynamic website (2022)

#109
I think CDNs led to the demise of "mildly dynamic" websites. They made static websites get served super fast, so you got the most benefit from completely static sites.

You could still include a small amount of JS to make a mostly-static site partially dynamic if you were logged in. Limited mostly to things like including the user's username on the page when logged in.

Re: The demise of the mildly dynamic website (2022)

#110
post #108

PHP deployment was indeed easy. But it turns out "dump everything in docroot and let mod_php interpret and execute whatever it finds there" had security implications...

indeed.

the gap with PHP and alternative stacks has mostly closed.

PHP apps now alse get deployed by container or VM... so why not go with something like Kotlin + kotlin.html (HTML eDSL for server-side templating and HTMX), Ktor or http4k (web libs), jOOQ (SQL eDSL with some typesafety on queries) and Postgres?

the PHP, MySQL (MyISAM), mod_php, Apache days are over. and it's not only for security reasons: there are alternatives that score better in every dimension AND run/deploy well on cheap hosting

Post reply on HN