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

151–160 of 183 posts

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

#151

Post by ArneBab »

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…

Don’t you have a virtual server? I’m pretty sure that my managed webserver runs on some virtual machine somewhere on a bigger server, and when it is not doing stuff, other tasks are running there and using the CPU and bandwidth.

There is likely some fixed memory and disk space cost, but those are negligible with todays capacities.

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

#152

Post by ArneBab »

icedchai wrote: post #125
llm_trw wrote: post #120

Earlier quoted context omitted.

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

I nowadays mostly use a simple static website plus minimal Javascript, but I still have PHP sites.

It still works. And PHP today is at least factor 3 faster than PHP was back then — on the same hardware.

So maybe just use PHP and ftps or sftp?

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

#154

Post by graemep »

pixl97 wrote: post #98
graemep wrote: post #24

Earlier quoted context omitted.

Most of those that are find for a static site but not dynamic are those that are not fixed by just applying updates from the distro. You still need to update your app code even if you are using someone elses servers, so its the same either way.

Note that the parent said "uptimes measured in years", so they are either using a more complex system with multiple servers, or they are not doing security updates.

I agree I would not endorse uptimes measures in years, which means not doing kernel updates - but OP does qualify that with "in some cases".

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

#155

Post by selcuka »

notatoad wrote: post #119
decasia wrote: 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 decided to switch to static HTML sites on S3 it's really hard to overstate how great s3 sites are with cloudfront in front of them. mine costs me the added complexity for any level of dynamic-ness is really just not worth it, unless i'm going to go to the trouble of making a full-on app that needs a revenue model.

CloudFlare Pages are another great product for zero maintenance static sites, and they can be made mildly (or heavily, if you want) dynamic with CloudFlare Workers.

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

#156

Post by troupo »

EGreg wrote: post #97
troupo wrote: post #81

Earlier quoted context omitted.

> where you might not build ANY back end at all, just use some sort of JAM stack. So, a backend > And now, CloudFlare Workers supports a key-value store and a SQL database So, a backend.

A back end with autoscaling on CDN. Not a single server, like you'd set up.

The autoscaling 99% of businesses don't need, and won't need even when they hit their 1 million DAU

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

#157

Post by troupo »

derefr wrote: post #96
troupo wrote: post #90

Earlier quoted context omitted.

You write a long wall of text that does boring to dispute what I wrote. The cheapest DO droplet is 4 dollars a month. It is more than capable of running "10 scripts", and will last your startup with three users indefinitely long. If you're concerned about that cost, lambdas will not save you

Maybe we write very different kinds of scripts. For my startup, such a "script" might be: 1. An hourly itemized invoicing batch job for incremental usage-based billing, that pulls billable users from an ERP DB, grabs their usage with a complex Snowflake query (= where our structured access logs get piped), then does a CQRS reduction over the credit-and-spend state from each user's existing invoice line-items for the…

I still don't see a need for lambdas or how a cost to run them on a DO droplet/Hetzner server would be so prohibitive that you'd be concerned about saving a few dollars a month.

Note: There's a reason I keep saying "You need 'omg distributed' perhaps after your millionth user, and even then it's highly debatable."

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

#158

Post by troupo »

solardev wrote: post #95
troupo wrote: post #85

Earlier quoted context omitted.

> What vendor lock-in? Most of the code is just vanilla JS. That runs in a specific environment with vendor-specific IAM configurations, vendor-specific DNS configurations, vendor-specific network configurations, vendor-specific service integrations, vendor-specific runtimes and restrictions, vendor-specific...

That sounds like an AWS thing? There's a lot of frameworks that can deploy straight to Vercel, Cloudflare Pages, Netlify, etc. without all that. And if you really want to manage all that, it would apply to both PHP sites and JS and anything else. That's really more of a discussion of fully vs partially managed cloud solutions, not PHP or JS or any framework in particular.

> There's a lot of frameworks that can deploy straight to Vercel, Cloudflare Pages, Netlify, etc. without all that.

All of them need all that. And those frameworks are for a reason: they sweep a lot of these things under a rug, and after a certain complexity you will have a vendor lock-in. Just because you will end up depending on certain policies that other vendors don't provide. Or on certain services that other vendors don't provide. Or guarantees that other vendors don't provide. Or pricing that... Or...

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

#159

Post by poincaredisk »

josephcsible wrote: post #103
cutler wrote: post #94

Earlier quoted context omitted.

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

I'm most cases people stress uptime too much. Developers worry about downtime during restarts and overcomplicate everything because of it. Meanwhile, my national railway reservation system has an hour of planned downtime daily and life carries on.

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

#160

Post by mapmap »

massysett wrote: post #43
edflsafoiewq wrote: post #21

Earlier quoted context omitted.

Shared hosting is probably better, and AFAIK more common, for the mildly dynamic website. The host handles a lot of the admin tasks like OS updates that you have to handle yourself with a VPS.

NearlyFreeSpeech.NET is good for this. Their main tier - "production" sites - are very inexpensive and the admins take care of OS and server-software updates. They have another tier - "non-production" sites - that are even cheaper and can be perfectly sufficient for a personal homepage. The admins maintain these servers as well but they might do beta testing on them. The environment is fully hackable and has PHP, SSH…

Does it support dot net?
Post reply on HN