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

Why You Should Write Your Own Static Site Generator

arne.me

Post reply on HN
Print view View original

71–80 of 136 posts

Re: Why You Should Write Your Own Static Site Generator

#71

Post by nextlevelwizard »

hombre_fatal wrote: post #19

It's a fun project to try out new tech, but you have to acknowledge that you're doing it for fun rather than any sort of necessary reason. It's like when you build a game engine and never get around to doing the hard part: building the game. It's a procrastination time hole that mostly just distracts us from the harder, less concrete, less fun thing we supposedly set out to do in the first place. It keeps us from shi…

As long as you use a static site generator instead some bloated blogging platform with tons of scripts and a database.

If you write about tech and your site doesn’t load instantly why should anyone read your words since you obviously don’t care

Re: Why You Should Write Your Own Static Site Generator

#72

Post by _xivi »

mrpotato wrote: post #51

Just like a bunch of us here, I also wrote an SSG. I setup a cronjob to fetch weather data and run the SSG to parse the XML and render a weather "website" on my VPS. But for the blogs I've had/have, I just use a pre-existing one (zola). There are hundreds of SSGs out there, why bother building yet another one if one already exists for transforming your preferred base doc (markdown, asciidoc, morse code, etc)

> There are hundreds of SSGs out there, why bother building yet another one if one already exists for

It's really not that rosy tbf. I went through something like: SvelteKit, 11ty, Astro, Zola, hugo, and possibly others in-between.

It's pretty easy to develop a preference where none of the mainstream SSGs fare well at. Some established large SSGs might do X but they have their own challenges too.

You start migrating by filtering based on some criteria, and find a match that does a great job initially, only to get bitten later, when you've migrated and settled and start seeing the cracks.

For example, Zola, and many others, doesn't support asciidoc. The handful that do have their own problems too. (I'm now with hugo which support asciidoc but I'm still determined to build my own ssg)

It's not fantasizing about the perfect tool, as much as developing a setup where you're comfortable and happy. Especially in the case of SSG, where you're more exposed to the internals and by extension any errors/problems.

Re: Why You Should Write Your Own Static Site Generator

#73

Post by neilv »

For over 2 decades, my personal Web site has been generated from one big Emacs Lisp file (plus a filesystem tree of image and downloadable files).

Both the code and the text data were in the one file.

The code included features like rich syntax coloring source view of files (fairly unusual at the time) that were also downloadable, and calendar-based blog navigation.

Over time, the code changed a little, such as to convert from HTML tables to CSS with the same look.

Just the one file, in Emacs, was a very rapid and lightweight way to work. Imagine a code file that includes simple function definitions, like that below, and calls to those functions, passed a mix of static and generated data for the pages.

    (defun web5-write-html-file-format-sideheads
        (root-dir subdir leaf-fname title-list sections)
      (if (stringp title-list)
          (setq title-list (list title-list)))
      (web5-write-file root-dir
                       (concat subdir "/" (or leaf-fname "index.html"))
                       (web5-page-html title-list
                                       (web5-format-sideheads title-list
                                                              sections))))
If I were doing it today, I'd probably do lots of Markdown files and a bespoke generator program, though that wouldn't be quite as rapid to develop as the Emacs single file one was.

Re: Why You Should Write Your Own Static Site Generator

#74

Post by _xivi »

mo_42 wrote: post #3

> [...] but most importantly you have to architect your website to match what the framework expects. I guess that's what a framework is about. You get some abstractions that make your life easier and you pay by buying into the concepts. > [...] some friends I've talked to where still on Next.js 12 and really felt the pressure to upgrade to not fall behind even more. If the current version is doing its job, why update…

> If the current version is doing its job, why update? It's a SSG not a browser that connects to the internet.

Because it's a hassle and you'll be left behind when you need a new dependency or there's a feature you like. By then, you have years of updates behind including depreciations, conflicts, etc. It might turn to a full-blown migration. All that is much easier if you update along.

Re: Why You Should Write Your Own Static Site Generator

#76

Post by thenoblesunfish »

I did a very minimal version of this myself recently, and it was very fun! I don't even have Markdown - I just write HTML and have a couple of helper Python scripts to update headers, generate boilerplate for images, etc. It's nonscalable and not really for anyone else, but fun, easy to understand, and there is not much to go wrong.

Re: Why You Should Write Your Own Static Site Generator

#77

Post by wormius »

valianteffort wrote: post #56
miroljub wrote: post #48

Earlier quoted context omitted.

But if you write a static site generator, you can blog about it. And that can be the first and the last post of your blog. If you don't write one, the chance is good, your blog would stay empty.

Why are you personally attacking me like this? In all seriousness does everyone and their mom write a static site generator? I did because its fun and easy. Off the shelf ones can be cumbersome and not work quite how I want them to.

I've thought about it only because I hate having to figure out someone's frameworks and way of doing things.

I'm not a professional programmer and it feels like most of these are for people who already work with various frameworks professionally and know their way around these things. I am too old to spend time trying to figure out all the frameworks so I'd rather just whip up something with my half-assed skills and DIY.

Re: Why You Should Write Your Own Static Site Generator

#78

Post by abdullahkhalids »

BeetleB wrote: post #27
h2odragon wrote: post #7

Did an SSG last month. I had used pelican before; but I wanted to get a better handle on using Markdown and Jinja libraries "from the other side" as well. I would have needed to adapt my file structure or write some code to let pelican scan my idiosyncratic hierarchy to generate the posts. Turns out Markdown is easier to use on your own scripts, than it is to tweak its configuration in pelican; and Jinja is quite sim…

I know people write SSGs because of frustration with their existing one, but did you consider writing a tool that "publishes" to Pelican? That's kind of what I do: I write all my posts in a single org file, and have Emacs process them and output rst files for Pelican's consumption.

I have used pelican for my website for a decade now.

I also host my book-draft on my site. I initially tried to get Pelican to do it, or to write something that publishes to Pelican, but it just didn't work. I ended up writing a hundred lines of fairly simply python to do the same job.

Re: Why You Should Write Your Own Static Site Generator

#79

Post by JaDogg »

forrestthewoods wrote: post #41

Disagree. Just write raw HTML. It’s much much easier and gives you trivial control. It’s much easier to write raw HTML and HTML-to-Markdown than the other way.

This is why the static site generator I wrote support embedding raw html :p

Re: Why You Should Write Your Own Static Site Generator

#80

Post by karurosu »

I didn't realize this was so common. In my crazy days I wrote a SSG using only XSLT, so you wrote a big xml with the content and it would output a full site ready to upload.

It needed a specific XSLT processor as most couldn't generate individual files, but it was nice that it worked with off the shelf software, so technically I didn't write a single line of code.

(XSLT is madness, don't attempt)

Post reply on HN