Live data from Hacker News

The demise of the mildly dynamic website (2022)

devever.net

11–20 of 183 posts

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

#11
post #3

Server side includes are still the perfect amount of power if you want to do templating stuff like comments.html footer.html or right_menu.html includes across all site pages. And the attack surface is so minimal and code so stable there's basically no increased risk using SSI over just html with nginx and similar webservers.

Ah but! The problem is SSI includes the bang directive, which outputs the results of a shell command.

Once that's available, people will demand and abuse it, and we're back at cgi-bin.

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

#12
I like this article except for the part about Lambda. The author doesn't seem to get that for some use cases there are serious benefits to having bits of code that run only when you need it, and only getting billed for those runs instead of getting billed for a VM or container runtime that's always present.

Obviously if your application involves processing a predictable high volume of requests, then you're probably better off running it on your own server/container, but depending on your use case there are times where Functions-as-a-service are the prefect solution.

The part about "why use lambda when cgi-bin exists" reminds me of the HN comment on the DropBox announcement from 2007 where the guy says something like "this is cool but why would anyone use it when you can just whip together ftp and svn on a debian box and have the same thing?"

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

#13

> 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…

> They aren't equivalent at all. The web server is hosted on an OS and both require ongoing maintenance.

From a technical standpoint, surely the servers running Lambda have an OS and require maintenance internally by Amazon at some level (even if it's dev-ops-abstracted away for their operators). It's just their responsibility instead of yours, and it's also their responsibility to find other work for those servers when your code isn't running (or bear the cost of an idle server). It's like if they were letting you push PHP functions to their web server, using the quoted comparison.

Useful from a business standpoint, yes. Revolutionary, maybe not as much as it seems at first glance. That's the takeaway I got.

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

#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 website" experience that TFA talks about was absolutely true. If I wanted a simple script to accept form input, or some little tiny dynamic experimental website, I could trivially deploy it. I could write PHP (ugh) or whatever other backend service I felt like writing. I ported the Rails app to golang after a while. It was fun. It made for a low cost of entry for experimental, hackish things. It's a nice workshop if you have it.

The thing is — if you are running this setup on your own linux virtual machine — it requires endless system maintenance. Otherwise all the PHP stuff becomes vulnerable to random hacks. And the base OS needs endless security updates. And maybe you want backups, because you got lazy about maintaining your ansible scripts for system setup. And the price of the $5 virtual linux box tends to go up over the years. And the "personal website" model of the web has kind of declined (not that it's altogether dead, just marginalized by twitter/facebook).

So I got exhausted by having to maintain the environment (I already do enough system maintenance at work) and decided to switch to static HTML sites on S3. You can't hack it anymore. But so far — I can live with it.

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

#15

> 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…

> They aren't equivalent at all. The web server is hosted on an OS and both require ongoing maintenance. From a technical standpoint, surely the servers running Lambda have an OS and require maintenance internally by Amazon at some level (even if it's dev-ops-abstracted away for their operators). It's just their responsibility instead of yours, and it's also their responsibility to find other work for those servers w…

And, of course, they don't just "bear the cost of an idle server". Just like any other fixed costs in any other industry, those costs get smeared over the charged prices. Unless there is some serious economy of scale (i.e. ops at Amazon managing to handle the upkeep of a 1000 of their servers for less than 1/1000 it costs you to manage 1 of your server), you're ending up paying somewhat more. But then again, you don't have to spend time to manage your own server which is probably a positive trade-off.

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

#16

I like this article except for the part about Lambda. The author doesn't seem to get that for some use cases there are serious benefits to having bits of code that run only when you need it, and only getting billed for those runs instead of getting billed for a VM or container runtime that's always present. Obviously if your application involves processing a predictable high volume of requests, then you're probably b…

I think it kind of goes both ways. There are times when you absolutely want lambda functions instead of cgi-bin scripts. But conversely - there are times when you absolutely want cgi-bin instead of lambda. (For interfacing with other linux services or packages, for example). The two tools don't always substitute for each other.

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

#17
post #3

Server side includes are still the perfect amount of power if you want to do templating stuff like comments.html footer.html or right_menu.html includes across all site pages. And the attack surface is so minimal and code so stable there's basically no increased risk using SSI over just html with nginx and similar webservers.

Ah but! The problem is SSI includes the bang directive, which outputs the results of a shell command. Once that's available, people will demand and abuse it, and we're back at cgi-bin.

> SSI includes the bang directive,

Not in ngx_http_ssi_module or any modern webserver I've used? As for "people"? What people? I guess your implicit assumption is this is a group or commercial project? I was thinking more website made by a human person.

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

#18
post #16

I like this article except for the part about Lambda. The author doesn't seem to get that for some use cases there are serious benefits to having bits of code that run only when you need it, and only getting billed for those runs instead of getting billed for a VM or container runtime that's always present. Obviously if your application involves processing a predictable high volume of requests, then you're probably b…

I think it kind of goes both ways. There are times when you absolutely want lambda functions instead of cgi-bin scripts. But conversely - there are times when you absolutely want cgi-bin instead of lambda. (For interfacing with other linux services or packages, for example). The two tools don't always substitute for each other.

I mean, that is the difference between using something because it's the flavor of the day and using something because it's the best tool for the job.

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

#19
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…

And then you forgot to add "I had to stick it behind cloudflare because someone decided to DDOS it and send me 500GB/s traffic for no apparent reason at all.

The early web was the wild west. The modern web has turned into small fry trying to hide in the shadows of megalodons so they don't get ate by a goliath.

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

#20
post #3

Server side includes are still the perfect amount of power if you want to do templating stuff like comments.html footer.html or right_menu.html includes across all site pages. And the attack surface is so minimal and code so stable there's basically no increased risk using SSI over just html with nginx and similar webservers.

But can you write Doom with SSI?
Post reply on HN