Hacker News new | past | comments | ask | show | jobs | submit login

I am a crusty old (I mean punch card old) 'programmer', with multitude of languages under my belt. [theoretical proof that I should be able to do a static site with my one good eye closed.]

I love the concept.

That said, I do have a bone to pick with the listed generators. They over complicate or fail to explain the site development and the documentation is often a twisted nightmare.

It is absolutely true, that if I could get the site generated as I want it, it would be less cost for the server, faster, and so on as described.

I really believe that static site generators are lagging in adoption, because unclear documentation.




The documentation problem is because they're trying to be everything for everyone imo. You end up with this bizarre labyrinth of conventions (and extension points) for which the only way to navigate is the documentation (and the documentation is unclear, so...)

I'm of the mind that if you want a static site generator, then... you should just build one yourself! Something completely tailored to you can be built in about the same time that it'd take to figure out how tf to get the features you want working with whatever static generator that's popular right now.


This.

I was tired of having to learn how each SSG worked so I ended up writing my very-specific-for-my-needs one in an afternoon (and polishing in a few days more)[0]

Surprisingly, my SSG is starting to look like those SSG I didn't want to use. Is it the natural evolution or am I being biased after years of reading lots of SSG docs? :-)

[0] https://github.com/luismedel/clarin


One of the most annoying things about computers to me is that they require constant maintenance. I don't want to do maintenance anymore; I want a mechanic to do it for me. I have built my own bed, desk, shelves, serving trays, fixed my own cars, plumbing, electric, screens, hinges, walls, drawers, tended my own garden, and wrote my own software. The garden is the only thing I still enjoy maintaining. So I use a SSG. They fix bugs and add features and patch security holes and do releases, and I just download and run it.

Incidentally, I really would like some kind of free offline WYSIWYG html editor for the body of pages, if anyone has a suggestion? I've looked but all the simple ones seem to require JavaScript knowledge? I just want to make content :(


I previously used jekyll-admin, which gives you a web editor for your local Jekyll installation. I was happy with it: https://github.com/jekyll/jekyll-admin


BlueGriffon?


It seems out of service. Last version from 2019.

The tooltips and dialogs are all empty on macOS (the latest Big Sur).


> I'm of the mind that if you want a static site generator, then... you should just build one yourself!

If you have any specific needs that you'd rather not compromise on then I agree completely, and do in fact have a plan to make my own. I expect it'll be quicker than trying to panel beat somebody else's into submission.

There is no middle ground - all the existing ones are either simple and/or strongly opinionated (great if you are happy with the fixed style and features) or so flexible and complex that it'll take to many plugins and hours poking it and it's documentation that you are practically programming the whole site anyway.

> Something completely tailored to you can be built in about the same time

And if you have any complex ideas you can develop it piecemeal instead of needing to think about everything in detail from the start to make sure the framework truly supports what you want (without you having to write a custom plugin) and you aren't starting in a way that'll make features difficult to add in later.

I don't really think that what I'm doing is making a static site generator, certainly not a generic one. I'm creating a dynamic but slowly changing site with a very strong caching layer.

> with whatever static generator that's popular right now

A key advantage of using an existing SSG is that you essentially get free upgrades from time-to-time, useful if the new features/options are actually useful or otherwise desirable to you. But that only works if the one you pick is one that survives the churn long term.

"Right now" is also key though. I might use one of the simple opinionated SSGs first with a view to getting some stuff out quickly and convert over later. Or I may just make a fully dynamic setup and convert to static if there is any chance the content is popular enough that the resource saving & response time benefits matter at all.


For programmers this is absolutely true. And because the SSG itself isn't exposed to arbitrary threats, there's not nearly the same need to have someone else do security maintenance on it.

Pick your favourite programming language, load some files, do string.replace(), job done.


I just feel that I often need some feature that is a bit time consuming to build. On the other hand the site generators I've tried had missed some feature or another also and they are usually harder to change.


Documentation, in general, is God-awful.

I mean, we live in an age, where, if Medium says that something is >7min read, no one reads stuff, and everyone uses videos to give, and consume, information.

I wrote a fairly ambitious infrastructure system, and spent months writing detailed, accurate, relevant, documentation.

That no one ever read.

It wasn't until I transferred the system over to a new team, who started posting videos on Facebook, that it started to take off. It's now the de facto world standard. Documentation is important, but so is the medium.

Sheesh. Kids, these days (Get off mah lawn!).

I write about how I do documentation, here (I need to update for DocC): https://littlegreenviper.com/miscellany/leaving-a-legacy/

It's definitely a >7min read.


I am a not that old (like pre-php old) programmer. For a personal website, crafting your own static website generator is so easy and fast that I would not even bother reading someone else's documentation.


I also did my own SSG, what it basically does is that it adds header.htm and footer.htm to each file in the folder... I first used server side includes (SSI), but often ended up having to edit all files because I needed to make a change in the SSI code. With the SSG I can just re-generate all files.


This is the way. All I wanted was to be able to write markdown and have it produce an aesthetic that I like. And syntax highlighting of code blocks. Pretty trivial to wire up.


Allow me to share my own SSG, and let me now if the documentation is clear, please :) https://github.com/imdario/zas

There are some issues to iron, but it's functional.


On that page, I clicked on your name (http://dario.im/) for what I suppose was going to get me to a page generated by zas. You may want to take another look at it :-)


Agreed...I found Hugo to be an incomprehensible hairball. I spent days and days trying to get it doing what I wanted without success.

Jekyll however was a pleasure to use and I got the results I wanted in an afternoon.


I'd argue that Gatsby et al aren't in fact SSGs but rather thinly veiled React apps.


Gatsby generates a React app, and it embeds that in a set of pages, and renders the content to a set of JSON files as well. When a page is requested the pre-generated page downloads, using only HTML+CSS to display the content for that page. If the user has JS enabled the React app runs and attaches itself to the links in the page to take over how they work. When the user navigates to different page it downloads the content as JSON, and renders it as any other React app would. I think it can also preload content as well.

So in a sense you're correct, it does generate a React app, but it is also true that a Gatsby site works like any other SSG'ed website when you don't have JS enabled. Arguably it's the best of both worlds. It's classic progressive enhancement.

The downside is that it makes the code more complex.

Gatsby does have other rendering options as well - https://www.gatsbyjs.com/docs/conceptual/rendering-options/


My experience is that vanilla Gatsby, out of the box, performs horribly on things like PageSpeed compared to “true” SSGs like Hugo or Jekyll.

And progressive enhancement is kind of a solution looking for a problem, there are a lot of low hanging perf fruits you can pick before considering PE.


progressive enhancement is kind of a solution looking for a problem

Progressive enhancement is a solution to the problem of giving users the best experience possible without serving unnecessary code, or breaking the site, for users who don't have the capability to run particular features. It's not a perf thing. It's a features thing. And it's a very real problem (see every site that only works in Chrome for details.)


I think 11ty and Astro are better in this regard.


The ones I've tried or at least looked at had pretty good docs up to a limit. For simple things most of them had pretty good docs. For advanced features it was a hit-or-miss with the docs. It may say how to do the things I wanted or it may not. Or it said it in such a way it was hard for me to find the info. In some cases it might have been impossible without coding a plug-in myself but then it was a bit unclear if it was impossible or just no clearly documented.

I do see many static site generators as something that requires that you are a developer. At least you must understand html and templates (and folders and markdown) but often you end up doing things that are basically just programming.


On top of that, SSGs appear as magic to newcomers to webdev and many have a really hard time debugging a build error when things go wrong. I've seen it multiple times (especially with gatsby)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: