Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The demise of the mildly dynamic website (2022)

devever.net

Post reply on HN
Print view View original

121–130 of 183 posts

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

#121

Post by notatoad »

chubot wrote: post #50
afavour wrote: post #35

Earlier quoted context omitted.

The author’s assertion isn’t correct though. Yes, technically speaking a PHP script that isn’t being executed isn’t itself costing you money. But it’s stored on server that is running 24/7 and is costing you money. Set up in the traditional way, CGI/PHP is priced by server uptime, be that per hour, per day, per month, whatever. The server runs all the time, it waits for requests, it processes them. By contrast Lambda…

There's nothing stopping anyone from implementing a cloud that runs CGI or FastCGI that scales down to zero (with per second billing), and scales up to infinity. It's just that nobody has chosen to do so Though I suppose not without reason. Google App Engine was one of the first "PaaS", billed on a fine-grained level, and it WAS initially based on CGI. Later they changed it to in-process WSGI, probably because workin…

>There's nothing stopping anyone from implementing a cloud that runs CGI or FastCGI that scales down to zero (with per second billing), and scales up to infinity. >It's just that nobody has chosen to do so

i suspect they have. i'm sure there's a ton of different in-house implementations out there at various enterprises, that are a minimal wrapper on aws lambda to turn an ALB request into a CGI request

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

#122

Post by notatoad »

leobg wrote: post #75
jak2k wrote: 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.

you don't have to - apache will execute your python cgi scripts just as happily as it will execute your php cgi scripts.

it's just that python developers figured out that having options other than cgi, and being freed from the rigid directory structures is really nice.

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

#123

Post by remram »

imabotbeep2937 wrote: post #118
dreadnip wrote: post #63

Earlier quoted context omitted.

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

"I have run production websites where I didn't patch security for months or years on end." Linux users wondering why nobody takes them seriously.

I have a box with nearly 5 years uptime, the one it replaced had at least that much, my experience matches GP's. unattended-upgrades gives you 99% of the patches, a manual upgrade every few months will get you the rest.

If you see a problem with this, why not point it out directly, instead of this snark?

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

#124

Post by resoluteteeth »

Reason077 wrote: post #112

I dunno. Isn't HN an example of a "mildly dynamic website"?

The article is talking about things like pages that are primarily static but with a comment box added as a dynamic part.

In this sense, I think the entirety of HN would count as "dynamic" by the standard in the article, so it would not be "mildly dynamic".

Are you thinking about something like "progressive enhancement" with JavaScript? Because that is not what the article is describing as "mildly dynamic".

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

#125

Post by icedchai »

llm_trw wrote: post #120
owenversteeg wrote: post #104

Earlier quoted context omitted.

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

It's still php-and-ftp. Sometimes I get fancy and use python and ssh.

I was going to say the same thing. I generally use Laravel instead of "raw" PHP these days, but still...

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

#126

Post by citizen_friend »

imabotbeep2937 wrote: post #118
dreadnip wrote: post #63

Earlier quoted context omitted.

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

"I have run production websites where I didn't patch security for months or years on end." Linux users wondering why nobody takes them seriously.

Security people on high alert for every possible scenario with no sense of relative risk or attack surface wonder why their concerns aren’t taken seriously.

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

#127

Post by nucleardog »

simonbw wrote: post #114

I think some of this article resonates with me, but I also think a big part of it rubs me the wrong way. It seems to assume that everyone has a webserver running a LAMP stack. If you have a static site on a webserver running PHP then of course PHP is going to require the least amount of effort to make your site mildly dynamic. On the other hand, if you have nothing , I don't think that the fastest/easiest way to a mi…

> It seems to assume that everyone has a webserver running a LAMP stack.

Shared hosts are pretty near a dime a dozen. Or just `apt-get install apache2 libapache2-mod-php` and you’re ready to go with no project changes.

> You have a much easier to set up local dev server (Install `node`, then `npm install` and `npm dev`)

Which version of node? Which version of npm? When I come back to this in six months am I going to find out some dependency relies on a dependency that relies on a dependency that only works on node 3.14 and end up installing nvm and stepping through versions trying to get this running?

For PHP I will need to install PHP. For this kind of stuff basically any version from the past decade will work. It’s in every package manager everywhere, has a windows installer, etc. (There’s a reason every PHP dev isn’t using a PHP equivalent to “PHP version manager”.)

Once that’s installed, just `php -S 127.0.0.1:8000` and open it in your browser. Serves all your static files and stuff too without any changes to any of them—an existing jumble of HTML and CSS is a 100% valid PHP project.

It’s usually substantially easier for me to get a ten year old PHP project running than a six month old JS project.

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

#128

Post by theendisney »

sophacles wrote: post #83
Sharlin wrote: post #49

Earlier quoted context omitted.

Running PHP on a VM in a data center doesn’t cost you anything either while the VM isn’t doing stuff, and you still have something to ssh into and manage and investigate without layers of abstraction bolted on top. And PHP-on-httpd is pretty much one of the most newcomer-friendly straight-to-coding environments ever developed.

Where can I get a VM in a data center that doesn't cost me anything?

cost and convenience: Time is money.

Whatever works for you is more important than 5 euro.

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

#129

Post by inopinatus »

icedchai wrote: post #9
politelemon wrote: post #2

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

> nice if Lambda just reused the CGI interface

Lambda is an event-driven system; synchronous, stateful request/reply for HTTP is shoehorned onto that. At heart it's a scale-out queue processor, not a web server. This whole "lambda gives your code a URL" folks speak of, is actually an API Gateway thing. This is also why Lambda has at-least-once semantics rather than that at-most-once, which definitely surprises the casual web developer from time to time ("why did that happen twice??").

That said, I don't disagree with the sentiment; it would be quite nice if API Gateway had a simple option to map incoming request parameters to CGI-like attribute names in the event payload.

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

#130

Post by konfusinomicon »

owenversteeg wrote: post #104
icedchai wrote: post #9

Earlier quoted context omitted.

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

tgere are far better ways but for the sake of simplicity I suppose you could ssh in to box, cd /some/dir, and git pull on the latest branch. that way atleast you have version control and can rollback quickly if you bork your site
Post reply on HN