If you're hosting a static site... life is easy. Throw your content in any s3 compatible storage and point a CDN at it. Done. It will cost literal pennies a year (The domain name will be by far the most expensive piece, and lots of places will give that to you for free if you don't care about being a subdomain).
That too complicated for you? Host it on a raspberry pi out of your bedroom. For the vast majority of traffic loads... that thing is going to be A-OK, even on a crappy consumer line (You'll probably be violating your TOS with your provider if it's a commercial site... but I've found they really don't seem to care unless you're causing them headaches, and a static site ain't gonna cause many headaches).
That too complicated for you? 10 lines of js with express will stand up a prefectly functional static site. Or you literally just install nginx and configure a single server block.
Static sites are fucking easy. It is ridiculously easy to serve static content these days. And borderline free (again - the domain name is going to DWARF the rest of your costs combined, even if you're only paying 5 bucks for the name).
How do you generate your static content? Who cares - do whatever feels best to you (I personally think rails is a bonkers solution, but if you want to use rake tasks to create your output... more power to ya?)
It really sounds like the author doesn't understand what a static site is, because JAMstack also isn't a static site solution (It has API right there in the name).
If you need to be consuming APIs with changing data... you aren't a static site (even if the html/js/css you serve happens to be static). In which case... rails is a fine choice, but if you're only serving the html/js/css and hitting 3rd party apis... I would still recommend an s3 bucket with a CDN.
I haven’t really sat down and done the numbers; does anyone have a reason to think this isn’t a real concern? I’d love to stop worrying about it.
Ex - Cloudflare has a flat-rate CDN that has no price changes based on bandwidth spikes, and is free for non-commercial use.
Cloudfront is free up to 1TB of egress.
BunnyCDN is a penny a GB.
etc...
And they basically all include DDOS mitigation - so if it's DDOS instead of actual traffic, you usually aren't billed for it.
Not to mention, you'll usually get much better regional performance, since they'll just cache it and serve it from a local instance closer to your user.
You're still going to pay egress with a VPS. So a CDN makes sense in either case.
At least the static content is potentially less resource heavy but I don’t see how your concerns don’t apply to any online service.
I suppose it is, but it's possible for someone to DOS a $5/month server too (touch wood they don't).
AWS could get expensive but it will always be up, so there's a trade-off there. You could use AWS WAF to mitigate someone running up your bill, but I'm not sure how well it works/how easy it is to configure/how cost-effective it is.
Installing Rails means installing very many Gem packages. That is just too much.
When you'd build the page dynamically, you'd also write a static .html before serving the html to the visitor. From then on, the .html got served.
On a new build, you'd rm the .htmls.
Back at the time, it seemed to be "the simplest thing that could possibly work" for multiplying a server's traffic capacity by 10000.
Strange to say use rails for static, but the author argues how server less is a nightmare. Though, I also think the same, use nextjs just for the react frontend and a proper backend.
Just use hugo/whatever and host on s3. This shouldn't even be a debate, let alone they've already done 3 rewrites. Bunch of clowns.