Live data from Hacker News

Static site hosting hurdles

notes.volution.ro

131–140 of 183 posts

Re: Static site hosting hurdles

#131
post #60

Earlier quoted context omitted.

Is there anything really wrong with a CPanel host with FTP upload? Namecheap, Dreamhost, GoDaddy even (well maybe not them lol). There are a billion shared hosts everywhere and CPanel really isn't hard to use for HTTPS enabling or getting FTP locations to work with. ------ Bonus points: shove a random .php file in there and it probably will work if you need just a little bit of dynamic content.

>Is there anything really wrong with a CPanel host with FTP upload? Nothing, other than that it's not cool with the kids because it's the grandpa's way of being a webmaster. Personally, being an old school grump, I'll choose FTP upload over Git nonsense any day of the week because why in the nine seas of the seven hells do I need to sign up for Github, upload all my crap there, download-install and run a Git daemon,…

Lots of us old school grumps still running things the old fashioned way for many years, serving millions of requests without issue, customers happy, and with a deployment pipeline anyone can understand :)

Re: Static site hosting hurdles

#132
post #52
post #8

Earlier quoted context omitted.

>We’ve already standardized the hosting side of static sites by using the file system. Worth noting that the incoming younger generations can't and don't into file systems.[1] Yes, anyone who wants to be a webmaster should do their homework, but that is besides the point. We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer. [1]: h…

I think people in the web development space will continue to understand this concept. People who are curious will learn how the internals work. For everyone else, who cares? Search is so good that it doesn’t matter where a file lives on your device. They don’t need to understand the internals of how directories work. Good riddance! Even though people knew how to use files and folders no one did it well. It was a mess…

[flagged]

Re: Static site hosting hurdles

#133
I've also come across https://staticdeploy.io/ which is self hosted and more akin to something like Vercel which manages a bit more than just serving/hosting.

Too bad it doesn't seem fully baked. I love the workflow of Vercel with the auto deployments from git and the infinite deploys via tags. Haven't found a good self-hosted alternative yet.

Re: Static site hosting hurdles

#134
post #23

Uh what's wrong with shared hosting? I use Dreamhost but there are dozens of others. It costs less than $10/month and I've used it since 2009. I think the industry (or part of a generation of programmers) somehow collectively forgot that it exists. I don't see any mention of it in the article -- it solves the problem exactly. It easily serves and survives all the spikes from Hacker News that my site gets. Shared host…

[the author here] Indeed didn't mention anything about the shared webhosting solutions, just as I didn't mention anything about S3 + CloudFront, or Backblaze B2 + a CDN in front, or Cloudflare + WebWorkers, or AWS Lambda, or any other thousand ways to do it... (Like for example there is https://redbean.dev/ > which I find just so intriguing, and not far from my own https://github.com/volution/kawipiko > proposal.) Al…

This is wrong on many levels.

Most people don't need all that complexity and configuration options, especially if you just want it to work.

Asset minification can be done locally, besides the ominous gatekeepers don't give a fuck. I've got a static website with lots of files, just HTML and CSS, not even minified I think, and a dozen lines of JS, and it's a solid 100/100 on Page Speed Insights.

Link headers? There's a HTML tag for that and it's fast enough: https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types...

You're just bloating everything up.

Re: Static site hosting hurdles

#135
post #76

Earlier quoted context omitted.

> I prefer not to use free services because they're not sustainable Just a guess from outside, but Microsoft is likely to be sustainable even if you use GitHub Pages to serve your static site on a free account.

When I say "sustainable", I don't just mean that the company might not have enough money to keep its lights on It's more that some product manager or VP will notice this free service and want to attach their strings to it. Having worked in big tech, it happens very often. Google Groups is a famous example at Google (among many). It was way better 15 years ago, but it just wasn't "worth it" to keep the lights on in it…

If you use your own domain, you can easily change your hosting should it go down.

Re: Static site hosting hurdles

#136

Earlier quoted context omitted.

"HTML on disk" does not cover headers. But it's true that cloud providers have that solved, and "DIY" bring-your-own-server don't, and the article somehow concludes that bringing your own server with the right configuration is not an option.

> [...] the article somehow concludes that bringing your own server with the right configuration is not an option. [the author here] On the contrary, it is an option to fine-tune your web-server configuration to put all the right headers in the right places. (I usually do this from HAProxy and just ignore the web-server.) However, the point I was trying to make in the article is that where these headers are configure…

But do you really need different headers for different resources for a static site? I can imagine a distinct "downloads" folder maybe, but not much more.

Re: Static site hosting hurdles

#138
Static hosting on VPS cite is easy as hell. Get a VPS with Ubuntu 22.04 for as low as 3 Euros/Month, execute the following commands:

```

sudo apt-get install -y nginx python3-certbot-nginx certbot sudo ufw allow "Nginx Full" sudo unlink /etc/nginx/sites-enabled/default sudo mkdir -p /srv/https/website sudo chown -vR $MYUSER:$MYUSER /srv/https/website

echo "I've created my website here." > /srv/https/website/index.html

cat > conf

  root /srv/https/website;
  index index.html;

  server_name $URL;

  location / {
    try_files \$uri \$uri/ =404;
  }
} EOM

sudo cp config /etc/nginx/sites-available/website sudo ln -s /etc/nginx/sites-available/website /etc/nginx/sites-enabled/website sudo certbot --nginx -n -d $URL --agree-tos --redirect -m $EMAIL --webroot -w /srv/https/website ```

Setup your DNS to the IP of VPS and you're done setting up your static website. Updates now are just `rsync`

Re: Static site hosting hurdles

#139

Earlier quoted context omitted.

> Strong disagree. You do not want both URLs to return the same content; you can have alternatives redirect to the canonical URL; but think through why you’re doing it: who is benefited by the redirect? At least with regard the with/without slash redirects there is value in these: sometimes the user copy-pastes the URL but forgets the final slash, sometimes the application he is using for bookmarking, sharing, etc. d…

You seem to have missed a good chunk of what I said. But to address some particular points: > sometimes the application he is using for bookmarking, sharing, etc. drops the slash Do you happen to have any evidence of this? I’ve heard it mentioned very occasionally, but never seen it, including any probability of it in logs (though I have seen more bizarre things), and the only ways I can imagine it being likely to ha…

[deleted]
Post reply on HN