Hacker News Reader

Comment by cutler | Hacker News Reader

Fine if you can make do with static sites but that's hardly a common use case. Most of us who use a VPS are hosting Nginx with a reverse proxy to Rails, Django, Express or Laravel + PostgreSQL or MySQL where the memory costs are a fraction of the equivalent cloud offering. I tried Github pages once, rather than Netlify, and pulled my hair out trying to get HTTPS working with a personal domain. Last I checked it's still not possible.

View on HN

Author here. A big part of why I'm saying "I don't need a VPS anymore", is because I'm also saying "I don't need dynamic sites anymore". I've been building dynamic sites for two decades (once upon a time "original LAMP stack" PHP + MySQL, more recently Python + PostgreSQL). I honestly never imagined that static sites could one day compete with that. But times have changed, and the JAMstack of 2022 has all the functionality you need. I've managed to convert all my old dynamic sites to be statically generated, without really compromising on bells and whistles. And the SaaS I'm now using is (almost) all free. As far as I'm concerned, I'm having my cake and eating it too.

I think you're overplaying the "static" card. If you're using the JAMstack the static bit is only half of the equation. Need a contact form? Now you need a form-processing service and it's no longer static. If you're replacing old PHP + MySQL sites you'll need a lot more than a static site generator. "Mostly static" might be more accurate but then how long does that last? Clients typically want WordPress plus a ton of plugins. I don't see how JAMstack addresses that need. You say it's nearly 100% free but I just looked at Netlify's free tier and you're only allowed 100 form submissions per month after which they're $19 each. I don't think I would get a night's sleep with that hanging over my head.

It's up to you when you think a traditional server back-end is still warranted, there are certainly still cases where it makes sense. But if all you need is a contact form, then I'd argue that it doesn't make sense! Yes, I agree, Netlify Forms is a rip-off, if you need more than the free limit of 100 submissions per month (which personally I don't, but of course many people do). But there are many other options for simple form handling, I'd recommend looking into them. And the JAMstack can compete quite well with WordPress and co these days, check out https://myclientwants.com/

The thing is I only picked on forms off the top of my head. There's a ton of functionality in your average client site which I can't imagine JAMstack catering for without it costing a lot more than hosting it on a VPS. JAMstack seems to cater for the painting by numbers model of web development but that's only a small fraction of what clients need. The JAMstack equivalent of a typical WordPress site, I imagine, would have to pull-in a dozen external services costing a lot more than the VPS alternative. Netlify make a big deal about the low-cost scalability of the CDN factor in JAMstack but it's only low-cost when you don't use external services. It's quite the opposite, I've heard, once you've outgrown static and need a third party service for every new feature.

Agreed. I used to be on the JAMstack train, but when your dynamic needs grows, you site has more and more dependencies and some are vendor specific such as Netlify. Now I have simplified all to use just one web stack for simple static site, to crud site to rest api backend, running from container. Minimise vendor dependency so I can easily move around be it self hosted at home, vps, AWS, Cloud Run or whatever. Rather than creating more Netlify clone, I hope HN crowd can create Cloud Run clones that let you easily host a container, not just static pages.

That’s right. Plus you miss out on control, functionality, optimization, flexibility on the dev side and predictability and simplicity on the business side. It turns things upside down and for the type of work we do these are exactly the wrong tradeoffs.

> It's up to you when you think a traditional server back-end is still warranted

All the cases outside of "oh, I dump my thoughts on the page once a year".

Even for a blog in the modern world I would like:

- automatic crossposting to Twitter and Facebook

- automatic retrieval and reformatting of external content (because, for example, twitter embeds are very cumbersome, heavy and slow)

- automatic retrieval of video and images from external sites (youtube, instagram, twitter etc.) because of link rot

- delayed publishing

- search

- and a plethora of other things

Yes, you can stitch togethe a bunch of "serverless" stuff for this, but you've just "replaced" the "traditional server backend" with a bunch of traditional server backends.

JAMstack isn't really serverless at all. It's a myth.

> A big part of why I'm saying "I don't need a VPS anymore", is because I'm also saying "I don't need dynamic sites anymore". I've been building dynamic sites for two decades (once upon a time "original LAMP stack" PHP + MySQL, more recently Python + PostgreSQL). I honestly never imagined that static sites could one day compete with that. But times have changed, and the JAMstack of 2022 has all the functionality you need.

This IMO should have been the main point of the article, not VPSes. No one can argue that a maintaining a live website is better if a few HTML pages will do.

> "I've managed to convert all my old dynamic sites to be statically generated, without really compromising on bells and whistles."

In your linked article you say:

"Anyway, site search is only a nice-to-have...and folks can just use Google with the site: operator instead"

To me that sounds like a compromise.

I'm out of my depth talking about SSG-powered sites because I've never developed them. My area is frontend design-dev, without the engineering stripes or desire for overly complicated builds. That's why PHP and the traditional dynamic sites work for me.

PHP, javascript, templates and a good reliable CMS allows me - the non-engineer, to do really interesting things such as site search with lots of added unique tricks to make users happy when they search for things.

Beyond my needs, the non-technical people I build sites for need to manage the content easily. That's where I scratch my head with the SSG offerings in that regard. Where the CMS is often the lowest priority, with bizarre suggestions and workarounds to fill the CMS void. For complex content-heavy sites with lots of products, forms, landing pages and categories, a good CMS is really important... and a general architecture that isn't scattered around big tech services IMHO.

Author here.

Re: search. It's not that site search is impossible, or even particularly hard, with a JAMstack site. It's just that I didn't consider it MVP for my personal site. I know how it can be done, and I'll implement it when I have time.

Re: CMS. I know where you're coming from, I spent a good decade or so specialising in traditional CMSes / frameworks myself, mainly Drupal and Django. There are various answers to the CMS question for static sites - the ones that I'm most familiar with are https://forestry.io/ and https://tina.io/ (and I've heard no end of buzz about <https://www.sanity.io/>). Those solutions are solid, I wouldn't call them "bizarre suggestions and workarounds". And they're good enough for most needs, IMHO. But I haven't tried pitching them to clients yet.

>Fine if you can make do with static sites but that's hardly a common use case.

This feels odd to me. Unless you are building a web site that is a product, why do you need anything besides a static site? I am going to go as far as to claim that: most websites should be static sites.

>I tried Github pages once, rather than Netlify, and pulled my hair out trying to get HTTPS working with a personal domain. Last I checked it's still not possible.

Don't know when you checked last, but this is false and has been for years. My personal page/blog/demo has been running in Github pages for past 5 years and I've had custom domain the whole time. I can't remember if HTTPS was from the beginning, but it sure is there now.

If memory serves me correctly all you need to do is to point your domain to githubs name server and add a file called `CNAME` with your custom domain to your repo to get it working.

It was about 2 years ago. Followed all the instructions but one of the https variants didn't work. I'll have another go. What's the url of your blog?

> I tried Github pages once…and pulled my hair out trying to get HTTPS working with a personal domain.

Last I checked HTTPs was available by default even on custom domains. I did have to remove and re-add my custom domain on a Github pages site that was created before this was the case. But after doing that, it was 0-config.

It's been available for a long time but when I tried I forget which but one of the 6 url formats didn't work, ie.

    http://domain.com
    http://www.domain.com
    https://domain.com
    https://www.domain.com
    domain.com
    www.domain.com

Try them all with your domain. Unless things have improved one of them will fail.

Just tried with my custom-domain GitHub pages, things have improved since you tried.

I'll echo this, all format versions of my personal domain work with Github pages too.

> Nginx with a reverse proxy to Rails, Django, Express or Laravel

/me over here reverse proxying to Hunchentoot with CL framework of the week. Have yet to see a serverless setup that even has any idea what CL is . . .

Why would a serverless setup need to know anything about CL if it's just exposing an API endpoint?

CL is Common Lisp.

If you're just returning JSON what does it matter which language?

> If you're just returning JSON

I'm not. Not sure where you got that idea.

Github pages works fine with HTTPS and my personal domain, and has for a couple years now.

What's your domain?

Reply on news.ycombinator.com