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

Static site generators need less rigid content APIs

fvsch.com

Post reply on HN
Print view View original

11–20 of 75 posts

Re: Static site generators need less rigid content APIs

#11

Post by pknopf »

nicolaslem wrote: post #7

I think static site generators need a more rigid content API. Problems start when these tools try to pack too many features trying to make everyone happy. They become small CMS and as the author mentions introduce poorly documented hard to grasp features. Rolling your own specific static generator is quite easy, the bulk of the work being gluing libraries together. What is worse, using an existing tool in a way it is…

> Rolling your own specific static generator is quite easy

Exactly. I created a tool to help with this as well.

https://github.com/pauldotknopf/statik

It has no features, by design.

Re: Static site generators need less rigid content APIs

#12

Post by pknopf »

kall wrote: post #3

Have you looked at gatsby? It doesn‘t fullfill all points but it comes closer than any other SSG. I think it fully satisfies 3, 4, 5 and 6. The content API that is not limited to filesystem data puts it in a different category than other SSGs for me. They also seem to have the ambition to take on wordpress. It can involve some configuration though. It doesn‘t make the use case in the article trivially easy either.

IMO, Gatsby is one of the biggest hammers for smallest nails.

I mean, how many dependencies/ceremony do we need to convert .txt > .html?

Webpack? Graphql? Client-side routing? I mean, if you want to have fun with shiny tech, go for it, but it really is the wrong tool for the job.

Re: Static site generators need less rigid content APIs

#14

Post by cryptos »

As much as I like Hugo, I recently stumbled upon the terrible Go templates! This is probably the strangest and most limited template engine I'm aware of. It might be nice in an application to actually limit what can be done in templates, but in a tool like Hugo where the user can not easily extend the core functionality, more powerful templates would be necessary. I hope Hugo switches to a more powerful template engine one day.

Besides that I agree with the assessment that these tools are from developers for developers. In the end a static site generator is more like a special kind of build tool and less like a CMS (what non-technical users would need).

Re: Static site generators need less rigid content APIs

#15

Post by PuffinBlue »

avaika wrote: post #5

I do like the idea to have a statically generated site and have all the content in plain text managed via git. Unfortunately it is ideal for text oriented content only. Once there is a lot of images in your content it becomes a pain to manage it in a convenient way. I tried pelican, but failed as didn't find an acceptable way to write a content. I have a kind of blog with around 30 to 50 photos per post and there is…

Yep. I'm hopeful that someone will inevitably turn up in the comments and reveal a great way to do it but everything I've seem is just janky and awkward.

I've basically stopped using my static site as a result of media management being a pain. I'm probably going to do back to Wordpress or something (shock horror!). Wordpress isn't hard to manage at all quite frankly, it's just a different set of compromises compared to a static site. It's also super easy to manage rich media and as I'm falling squarely on the side of 'get shit done' it's looking like a good option.

It's trivial to cache it well and update it. Yeah it's not as secure but there's a risk vs usability judgement that has to be made. And I think I'd prefer to be producing content and having some good backups rather than just not use my site.

Re: Static site generators need less rigid content APIs

#19

Post by jypepin »

mlcdf wrote: post #9
jypepin wrote: post #6

To address OP's point about the need to have a bit more control and freedom in the complexity of the content (instead of having only markdown etc), Next.js offers an "export" script that will export the app as a static asset. I made a static website with it recently and found it very quick to use, assuming you know React. No config or setup required (something rare on js projects nowadays), really just "npm install r…

And with that about page comes a bundle of several kb of Javascript... (At least, that how it used to be last time I used it)

yes it does indeed. I'm not saying it's perfect, but it is a very convenient way of generating a static site with more complex content than simple markdown :)

Re: Static site generators need less rigid content APIs

#20

Post by fvsch »

PuffinBlue wrote: post #15
avaika wrote: post #5

I do like the idea to have a statically generated site and have all the content in plain text managed via git. Unfortunately it is ideal for text oriented content only. Once there is a lot of images in your content it becomes a pain to manage it in a convenient way. I tried pelican, but failed as didn't find an acceptable way to write a content. I have a kind of blog with around 30 to 50 photos per post and there is…

Yep. I'm hopeful that someone will inevitably turn up in the comments and reveal a great way to do it but everything I've seem is just janky and awkward. I've basically stopped using my static site as a result of media management being a pain. I'm probably going to do back to Wordpress or something (shock horror!). Wordpress isn't hard to manage at all quite frankly, it's just a different set of compromises compared…

If you’re not against PHP and hosting PHP code, as mentioned in the OP my go-to tool would be Kirby. The mix of static content and a powerful content API is the sweet spot for me, when I don’t absolutely need static HTML. It does require a paid licence though (note: I’m not affiliated with Kirby or its developers).
Post reply on HN