Ask HN: Are there any downsides to building a blog using only HTML pages? | Hacker News Reader

Ask HN: Are there any downsides to building a blog using only HTML pages?

17 pointsdarkhorse1333 comments

I want to write some things, and I have really nice templates (nice design, minimal vanilla JS, loads really fast) for the following pages:

- Main page of the blog (lists all the articles)

- Article page

I was thinking of making one HTML file for each post, linking them together using hyperlinks (pointing directly to the HTML files), putting everything in a folder, and dragging and dropping to my Netlify Drop account (https://app.netlify.com/drop).

What are the potential downsides to doing this? Am I really underestimating the value that modern frameworks and libraries provide?

View on HN

The major issue is HTML has no way for you to share chunks of HTML between pages e.g. a header or footer, so you'll have to copy/paste chunks manually (unlike with CSS, images and JavaScript though which you can embed on multiple pages).

I can recommend Hugo if all you need is the above (and more). It's a single binary to install/run, runs super fast and you only need to learn a couple of template tags for the above.

I'm not keen on Gatsby or Jekyll because they're an order of magnitude slower as far as I know and require you to have a pile of Node and Ruby (respectively) dependencies set up which is an extra headache and stuff that can break.

Every now and then my site that uses Jekyll will break when I push to Netlify because something changed somewhere and it's a massive drag (I know proper containerisation would solve this but this is extra work and expertise required). Hugo is really simple in contrast because you don't have any dependencies to isolate or require a complex build script.

Some people will tell you about frames and framesets

They're really impractical for this use though as they don't act the same way as HTML being inlined into your page e.g. the elements inside the iframe won't influence the size of the iframe making responsive layout a pain, CSS on the parent page won't act on the HTML inside the iframe, sharing state via JavaScript is more complex. Pages that have e.g. contact forms that are really iframes tend to stand out a mile for example.

Some people will tell you about Server Side Includes SSI

There are various ways to do client-side includes, but they mostly rely on JS to load and insert the HTML fragments.

Simple enough if you just want to include a few common elements and don't want a build step. Not so good if you want actual templating.

The state-of-the-art for building sites like these are tools like Hugo (https://gohugo.io/) and Jekyll (https://jekyllrb.com/). They generate the HTML for you so that you don't have to update 100+ HTML documents every time you need to change something.

Gatsby is worth a look in this context too

But you do have to spend hours learning the tools! Some things are far from trivial in Hugo.

Given the original constraints of the OP I don't think that would be to much of a overhead. A text and limited amount of images blog like page does not require any major tools in either of the ones mentioned. However you do have a point when you want to start adding more complex features, then it quickly becomes a lot more complicated than just fixing it in the plain html page requiring the change.

Start simple! No problem with your approach. A lot of interesting blogs look like they are made this way. You could also use some shell magic to cat a header and footer to each page.

> use some shell magic to cat a header and footer to each page.

  $ tree .

  .
  ├── footer.html
  ├── header.html
  ├── Makefile
  └── posts
      ├── a.body
      ├── b.body
      └── c.body

  $ cat Makefile 

  BODYFILES=$(shell find posts -type f -name "*.body")
  POSTS=$(BODYFILES:.body=.html)

  dist/slug.tar.gz: index.html $(POSTS)
   mkdir -p dist && tar -czf $@ $^

  index.body: $(POSTS)
   python3 -c "import sys; [print('<a href="%s">%s<a/>' % (x, x[:-5])) for x in sorted(sys.argv[1:])]" $^ > $@

  %.html:    header.html %.body footer.html
   cat $^ > $@

  clean:
   rm -rf $(POSTS) index.body index.html dist
  .PHONY: clean

> use some shell magic

eg.

1600 SLOC: https://www.bkhome.org/shellcms/index.html

1194: https://github.com/cfenollosa/bashblog

82: https://github.com/LukeSmithxyz/lb

15: https://news.ycombinator.com/item?id=24552950

I use Hugo to generate a static html blog. I use to use wordpress, but this was a nice low maintenance change.

You can customize your own template.

My process to write a new post looks like this:

write a post in markdown compile it to html with hugo rsyn to my shared host.

Just do it in whatever way seems natural to you. The way you're describing is fine. Some people here talk about scaling or hassles with many links. That simply isn't a problem unless you (against all likelihood) actually end up writing a lot of posts. In that case it's really not that hard to change your stuff to some other framework/platform/whatever. Just worry about generating content.

https://static.guim.co.uk/sys-images/Guardian/Pix/pictures/2...

Limited functionality after growth. What you're describing is fine for 10 blog posts, but what about 100? 500? How then do you manage pagination? Search? Tagging or categorisation?

Using a static site generator (or even a well-designed set of scripts) can easily scale to 1000s or 10s-100s of thousands of pages/posts. I've built these as shell scripts in the past, and used Blosxom when it was about the only tool in this space, but lately prefer tools like Hugo, Lektor, or Gatsby. One advantage of using these tools is that the better ones are SEO-savvy and can be a big help in getting your page to rank, in addition to wrangling content.

These are a big part of what's called the JAMstack, and there's a great rundown of them by the guys that run Netlify at http://staticgen.com. (Netlify's blog is a good place to learn about JAMstack even if you don't plan on using their service, which is really nice, BTW.)

Yep, I love a good static site generator, but I don't think that's what OP was talking about.

If the focus is getting some ideas written down and sharing them, doing something dead simple sounds great. Go for it.

If in some hypothetical future you've got a sprawling collection of related blog posts and are spending 80% of your time manually gardening links between posts in vim and only 20% of your time thinking about ideas and writing new posts, that could be a prompt to do a second pass and rethink how the blog is organised.

As long as you have some templating in place for your header and page skeleton, I think your method is fine.

Can you name a templating library that would be able to do this? I am looking for some good ones to test out.

It's not uncommon. This was the approach Blogspot used back in the day. It's painful at scale.

The pagination, TOC and other concerns are real issues, but a couple small scripts to pre-process the posts could handle that. Generate a bunch of HTML and then drag-and-drop.

One downside is that when you write an article, you have to go add the link in the homepage, then in any other menu that you might have, then update recent articles section, etc.

You can use a json file with article relative urls and build all the links on the client side.

You can't add comments to your blog unless you use some third-party system like Disqus.

Also, cannot add search capabilities unless you

1. use a JS solution like lunr.js OR

2. integrate with Azure Search et al. and implement yourself a small JS based search results page.

File per blog sounds great to me.

Fancy solutions evolve out of needs or wants. You don't have those needs. Enjoy the simplicity and screaming fast performance of your website.

This reminded me of Microsoft FrontPage. It would let you author HTML pages using partial templates.

These days I would recommend a static site generation tool like Hugo.

That's how I did my site, I just copy/paste a template file for every new blog post. Works fine, not complicated really.

I would recommend you own your own domain name.

The modern frameworks would be for reusing components, branding, etc.

If you're looking to access a database or apis.

I can always point the Netlify app to my own domain.

Why not use something like

https://jekyllrb.com/

It feels wrong?

It's like copy-pasting a function every time instead of #including it

Less WYSIWYG is the only con I can think of.

RSS feed?

Reply on news.ycombinator.com