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

Static site hosting hurdles

notes.volution.ro

Post reply on HN
Print view View original

81–90 of 183 posts

Re: Static site hosting hurdles

#81

Post by AnonC »

chubot wrote: post #64
laundermaf wrote: post #59

Earlier quoted context omitted.

> what's wrong with shared hosting? You answered that yourself: > It costs less than $10/month That’s a lot of dollars for a static website. There are a myriad of free options and there have been for years. Kinda disappointing that they weren’t mentioned. Anyone wanting to deploy a static website knows the big 4, completely free: Netlify, Vercel, CloudFlare Pages, GitHub Pages.

I prefer not to use free services because they're not sustainable, and they usually come with strings attached Remember I've been using this for 13 years, and if it keeps on working the same way, I'll use it for another 13 easily. (I've hosted multiple sites on it over the years) The current page claims it's $3.95 a month if you pay yearly: https://www.dreamhost.com/hosting/shared/ I thought mine was more like $8 but…

> I prefer not to use free services because they're not sustainable, and they usually come with strings attached

When I checked Dreamhost several years ago, I found that it was also an oversold service that relied on most customers using way less than the promised capacity. This doesn’t mean that it’s bad at hosting websites, but it’s not something I wanted to pay for.

So I hosted my websites with Nearly Free Speech (NFSN), where hosting is actually by what you consume. For small static sites, you could get a lot more mileage with NFSN and still not pay more than a couple of dollars a month. It’s a lot cheaper than your Dreamhost plan, and is truly sustainable because NFSN gets very close to recovering its costs plus a little more to sustain, grow and become better. NFSN also doesn’t have tricks like referral programs and other special discounts, unlike Dreamhost (talking from what I’ve seen about Dreamhost in the past).

The major downside is it doesn’t have cPanel and fancy application installers. But that shouldn’t be an issue for people who would use scp to setup web pages on a host.

Re: Static site hosting hurdles

#82

Post by dragontamer »

Dalewyn wrote: post #67
pdimitar wrote: post #63

Earlier quoted context omitted.

You over-focus on what's cool or fashionable. For many of us that's absolutely not the reason to go (or not to go) with a platform. GIT is extremely useful for versioning. I want that. If I make a dumb mistake I want to have a diff that I've fixed a typo / grammar / added more links etc. You neither need to use GitHub nor give your GitHub credentials to anything. You can just make a public repo and have it cloned / p…

Generally speaking, I subscribe to the philosophy of KISS. For a multi-user environment where a dozen people could be accessing the same file at any given time, yeah some sort of version control system will probably make everyone's life easier. For a single user environment as is likely the case for most static websites? Yeah, it's just needless complexity. In fact, you lost me at "static site generator". WTF? Just w…

> In fact, you lost me at "static site generator". WTF? Just write the damn HTML and CSS yourself, it's static after all.

At a minimum, static site generators create indexes, table-of-contents, tags, sorts by date, and other such features.

Pretty much no one writes good, raw, HTML these days. Documentation is written Sphinx, texinfo, docbook, and many other formats. Why? Because compiling chapters (or pages) together through static analysis is a very useful pattern for writing.

HTML is just an output pattern. Your actual words should be in a document generator at a minimum.

Re: Static site hosting hurdles

#83

Post by chubot »

AnonC wrote: post #81
chubot wrote: post #64

Earlier quoted context omitted.

I prefer not to use free services because they're not sustainable, and they usually come with strings attached Remember I've been using this for 13 years, and if it keeps on working the same way, I'll use it for another 13 easily. (I've hosted multiple sites on it over the years) The current page claims it's $3.95 a month if you pay yearly: https://www.dreamhost.com/hosting/shared/ I thought mine was more like $8 but…

> I prefer not to use free services because they're not sustainable, and they usually come with strings attached When I checked Dreamhost several years ago, I found that it was also an oversold service that relied on most customers using way less than the promised capacity. This doesn’t mean that it’s bad at hosting websites, but it’s not something I wanted to pay for. So I hosted my websites with Nearly Free Speech…

Sure, NearlyFreeSpeech is probably closer to the ideal I'm talking about, but I happen to use Dreamhost.

My point was that shared hosting exists, is good, and is the right solution to this problem. My point was not that you should use Dreamhost :)

I tried NearlyFreeSpeech a few years ago; some sibling comments describe my experiences

Re: Static site hosting hurdles

#84

Post by tannhaeuser »

laundermaf wrote: post #59
chubot wrote: 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…

> what's wrong with shared hosting? You answered that yourself: > It costs less than $10/month That’s a lot of dollars for a static website. There are a myriad of free options and there have been for years. Kinda disappointing that they weren’t mentioned. Anyone wanting to deploy a static website knows the big 4, completely free: Netlify, Vercel, CloudFlare Pages, GitHub Pages.

Your domain alone is going to cost about half that, and much more for fancy domains. Depending on whether you need a site mail contact (sometimes required for abuse@yoursite.com) and certificate (for any ecommerce site), we're talking about at least twice that. We do talk about serious hosting, do we?

Re: Static site hosting hurdles

#85

Post by Spivak »

Dalewyn wrote: post #8
akerl_ wrote: post #3

It felt odd to see a doc this comprehensive on static site hosting with no mention of AWS S3/Cloudfront, given how easy it is to push content to an S3 bucket (either manually or via the CI pipeline of your choosing) and then serve it up either direct-from-S3 or via Cloudfront. But then it turns out that this is actually pushing folks towards some new paradigm of static cached HTTP responses instead of files. It pitch…

>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’m apparently young enough to be targeted by this article so I’ll weigh in. We’re better off for it, files as a storage layer and/or format (meaning how routes on web servers are defined by the folder structure) suuucks. File semantics are annoying, complicated enough that nobody really gets them right, and broken at the margins. The concept of a virtual read head and seeking around files would never be invented today. File descriptors keeping random external magic state? What could go wrong? All but a tiny few file operations not being atomic — bleugh. See the stuff Ansible has to do just to get atomic copy. Permissions, attrs, xattrs, acls, and SELinux tags are a god damn mess. Locking is also a mess and filesystem dependent — sqlite doesn’t officially support NFS because of it. And with all that useless metadata we still don’t have a way of actually reliably specifying the format or encoding of files leading to garbage library after garbage library for guessing it. File paths being binary strings on Linux is a ridiculous tripwire, running out of inodes or open file handles is a leaky abstraction, links — hard and soft are a bandaid and make traversal stupid to reason about. Look at the dumb shit tar has to do to deal with it. Holding handles to deleted files is absolutely ass backwards and a pox on the people that made it necessary for updates to work. File rotation just shouldn’t be necessary. The application having to think about compression is the wrong layer. Whoever invented unix:abstract files committed a warcrime.

If you’re someone who likes working with the filesystem directly, why? Seriously why? It really does seem like anything would be better.

Even for code, wouldn’t you rather things like Python modules or packages be first class objects? No more sys.path nonsense, no more namespacing, just your whole venv in a single trivially relocatable file.

Re: Static site hosting hurdles

#86

Post by rozenmd »

With wrangler2 (https://github.com/cloudflare/wrangler2) you can deploy a static site to Cloudflare for free (you don't get any of the features of Cloudflare Pages though):

echo '# Hmm' > index.md

npx @11ty/eleventy

npx wrangler publish --assets _site/ --name name-of-static-website --latest

Re: Static site hosting hurdles

#87

Post by Helmut10001 »

Strange that a pretty common way to serve static sites is not mentioned: Multi-stage Docker builds [e.g. 1] an nginx-alpine image in Gitlab CI, that is automatically deployed to Kubernetes/a Docker host somewhere. Add the Let's Encrypt Container for automatic SSL.

[1]: https://github.com/lewish/asciiflow/blob/fd0f72714cd307cbb02...

Re: Static site hosting hurdles

#88

Post by hnarayanan »

Helmut10001 wrote: post #87

Strange that a pretty common way to serve static sites is not mentioned: Multi-stage Docker builds [e.g. 1] an nginx-alpine image in Gitlab CI, that is automatically deployed to Kubernetes/a Docker host somewhere. Add the Let's Encrypt Container for automatic SSL. [1]: https://github.com/lewish/asciiflow/blob/fd0f72714cd307cbb02...

I highly doubt this is a common approach!

Re: Static site hosting hurdles

#89

Post by js4ever »

alberth wrote: post #25
chubot wrote: 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…

Dreamhost is hugely underrated. Their custom panel with deep integrations are phenomenal for side projects or small businesses. In under a minute you can have your web server, SSL cert, database and more all setup and working - and you don’t have to manage any of it. I wish more companies offered their level of managed services. (If anyone knows of others, I’d like to hear who)

Please check https://elest.io You can deploy WordPress, Ghost, Magento and 185 fully managed software. You get a dedicated VM with stellar performances, SSL, smtp, security, borg ans S3 backups, monitoring, logs and full root access even if it's managed. We also support CI/CD pipelines.

Disclaimer: I work there ;)

Re: Static site hosting hurdles

#90

Post by chrismorgan »

> check that with/without .html extension serving works properly; (i.e. /some-file.html should perhaps return the same content as /some-file, or even better, choose one as canonical and redirect for the other one;)

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?

If your canonical URL is /example, I see no reason at all to support .html. If it’s /example.html, I see no particular reason to support /example or /example/. If it’s /example/, there may be a smidgeon of value in supporting /example. If it’s /example and you ever have paths below that (/example/example), then there may be slight value in supporting /example/.

If you switch from one format to another, do ensure that all existing URLs work. I used to use .html, so my old *.html URLs now redirect to */, but only for old articles, not new ones that were never .html, because I like being fancy like that.

But overall, I say: for at least the .html and trailing slash suffixes, no software should ever be causing these errors (I have heard rumours of improper transformations once or twice, but seen no evidence, and neither of these are ambiguous “will the automatic linkifier include or exclude that punctuation at the end” cases), so it’s all about humans and what incorrect URLs they might type out. And most of these sorts of things, people just won’t do.

Supporting more things for the sake of it is not a virtue. There is value in failing early on incorrect input. Postel was wrong.

Post reply on HN