Comment by stuckinhell | Hacker News Reader

Comment by stuckinhell | Hacker News Reader

I wouldn't recommend people use anything that requires a database for a blog in 2023.

Edit: Since I got extremely downvoted for this comment. Here is why:

You should use static site generators for new blogs in 2023.

Performance: Static sites typically load faster than database-driven ones.

Security: Without a database, the risk of SQL injection attacks is eliminated.

Scalability: Static sites can handle high traffic without complex hosting solutions.

Maintenance: No database means fewer maintenance tasks and potential failures.

Hosting and Costs: Static sites often have cheaper and more flexible hosting options.

Decoupled Architecture: Modern trends prefer separating frontend and backend, reducing the need for databases.

Development Simplicity: Static site generators offer a straightforward content writing environment.

Backup and Portability: Static sites are easier to backup and migrate.

Edge Hosting: Static sites benefit from faster load times with distributed hosting solutions.

Static sites are a PITA when you need to add certain functionality. It's an optimization. Why start with such a crazy optimization when you can just put cloudflare etc in front of it?

Source: the fastcomments docs, blog, and several of my sites are SSG. I don't like it anymore.

Weird to see the notion of taking the documents you want to publish and saving them as documents be called "crazy". Publishing a blog post is just document preparation—you know, desktop publishing.

I'd call the let's-insert-an-unnecessary-database-here outlook the crazy thing. Not to mention, basically a violation of the Principle of Least Power <https://www.w3.org/DesignIssues/Principles.html#PLP>.

Because that's not what a blog or documentation site is. They usually have a ton of other features. sorting, searching, embedded dynamic widgets, code snippets, maybe code snippets pulls users account id and prefills it, and so on...

> Because that's not what a blog or documentation site is.

K. Ignoring that...

None of those are prerequisites. They're not listed by the author of the post linked here as among the features that he considers "essential for a blog in 2023" (nor are they even present on the Datasette Cloud blog that is the subject of the post), and it's not a "crazy optimization" to not go out of your way to introduce them.

(Is he, in your view, not actually running a blog?)

It is a crazy optimization. I cannot be convinced otherwise at this point.

Static sites sound nice and clean to a junior dev, I get it. But after using that approach for years I'll never do it again. Too much of a pain as things grow. Build step can also get slow. Django is so easy to use and extend. You can use it with sqlite, no DB to run.

Wikipedia is a nice example. Could that be SSG. Yes. Is it, and should it be? No. If your site has more traffic than Wikipedia let me know.

Do you know how much support calls I have to field for fastcomments with people trying to integrate into SSG systems with SSO or whatever that would be simple with SSR etc? A lot.

> Wikipedia is a nice example. Could that be SSG. Yes. Is it, and should it be?

No, Wikipedia is a terrible example. Absurd, even. We're talking about blogs. We can stick to that example. We don't need to reach for bad ones.

Yeah? It's a bunch of documents that link to each other :) blogs do the same.

Wikipedia is a wiki. Blogs are not wikis. Blogs do not require a wiki engine. Wikis do. The statement "Wikipedia is a nice example" remains an abomination.

I am thinking of documentation sites and blogs in the same categories, because I use them similarly. I create blog posts (documents), they have titles, categories, and they link to each other.

I'm being a bit dramatic, but it's to stop people from using SSG. I don't like working on said applications because adding every little feature is a pain and adds to the build time. Running a simple service and DB is easy - I've been doing it for a decade. I ran blogs and sites with databases when I was in HS - surely big companies can do it and put cloudflare in front of it.

I switched from a dynamic to a static site even with Cloudflare in front because I didn’t want to have any active endpoints, period. Much less hassle and worry, plus the hosting costs decrease by an order of magnitude (just dump HTML into a storage bucket, zero VMs).

Also Django and Rails are annoying as hell to deploy compared to just uploading a zip of your static site to a static site host.

With good caching and a CDN, you mitigate these issues. Database isn’t an issue.

for people disagreeing with this comment, mind elaborating?

I think 800+ million Wordpress blogs are not planning to shut down in 2023 after reading GP's comment.

I don't think there are 800+ million WordPress blogs. WordPress is used for lots and lots of websites that are not blogs at all.

Thank you, I stand corrected, 800M+ WordPress installations.

This doesn't provide a counterpoint to the original comment's point.

IMHO, it's true that a static site generator should be the way to go in 2023, instead of using a web framework with a db.

I am personally running a hugo blog, on netlify, with netlify CMS. I have 0 costs, great performances, everything needed out of the box. What else to ask for ?

Does your blog support comments?

Also, for a company blog, an SSG likely means a requirement to know Git, which could be inconvenient.

In my blog, comments are not supported, and it would be easy to add if I developed my own blog with Django. But I feel that this single feature does not overweight the simplicity and velocity I have with such setup.

If you really need comments in your blog when using Hugo, you can still integrate them with Disqus https://gohugo.io/content-management/comments/

In regards to the requirement to know Git: It is just necessary in the setup phase, the blog posts creation and edition are controlled through Netlify CMS for me.

Interesting, thank you for introducing me to Netlify CMS, didn't know about it.

My https://simonwillison.net/ blog has been running since 2002 and has 3015 long-form posts, 6718 bookmark posts and 770 quotations.

Plus tag pages, archive-by-date-pages, series pages and more.

I don't particularly want to have to wait for all of that to build!

It also offers faceted search against all of that, powered by PostgreSQL: https://simonwillison.net/search/?q=static%20site%20generato...

Incremental builds exist, so you'd really only have to build once: https://nextjs.org/docs/pages/building-your-application/data...

That said, personally, I love PG and enjoy using a DB. But I can see pro's to both sides.

Well, taoofmac.com has 20+ years, 9000-odd pieces of content (that translate into 47.000 blob storage items), multiple navigation constructs (archives, backlinks - it’s a wiki - and even a 3D sitemap), and an incremental build for a post that links to 5-6 others (and resizes images, updates the home page, archives, linked page footers and backlinks) takes ~10s, including uploading the results (and an updated SQLite database) to Azure.

I use SQLite FTS for full-text search (it’s the only non-static endpoint).

A full site re-render on a Raspberry Pi takes 5 minutes, and a full reindexing - FTS plus linkmap - plus publishing around 10, but I only do that yearly or when I update things like CSS, layout, etc.

It all runs off a Git hook, uses SQLite to hold all the FTS, base HTML and metadata, and is as asynchronous as can be (including my own asyncio blob upload library). Costs me effectively zero.

That's awesome. Parts of that sound a little bit like how my https://til.simonwillison.net/ site works.

I need to update my write up, but this is generally it: https://taoofmac.com/space/blog/2021/06/19/2036

I want to be able to hit edit on the post, do it right there, save and see my change immediately. I could set that up with a static site system but.... the admin I made for editing the post would remain the same. Furthermore the editor I have has a bind for CTRL+V that checks for images and automatically uploads them but also inserts an html tag for the media I just uploaded. This is something that is a terrible experience when editing a git repo having to manually link images and other media.

Code: https://github.com/hparadiz/technexus/blob/release/public/js... https://github.com/hparadiz/technexus/blob/release/public/js...

Reply on news.ycombinator.com