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

21–30 of 75 posts

Re: Static site generators need less rigid content APIs

#21

Post by kaushalmodi »

The post author seems to have not reviewed at least the Hugo docs very well. One clean sign is that he listed "Page Bundles", "Leaf Bundles", index.md and _index.md as "different concepts", when in fact they are all Page Bundles.

Also the author completely missed the point that everything is a "page".

I wish I had time to write a detailed reply to this post but looks like the author has made up his mind to puke on Hugo. I hope this reply serves as a warning that the author's warning about Hugo is very uneducated.

AMA regarding clarification about Hugo in that post.

Re: Static site generators need less rigid content APIs

#22

Post by JeanMarcS »

For sure everyone have his favorite way of doing things and what seemed obvious for some will look strange for others.

As I tested myself several SSG, I (as many it seems !) thought « Well, none fit my needs so let’s make one »

My problem was that I need an interface for the final clients, which are no tech at all, to be able to edit content.

Solutions like Hugo are not possible as it would means install it on a computer at the client office, and make him/her understand how to deploy. No go.

As the post states, they would also have to learn some stuff. Even more no go.

So for those case, the solution is to use a CMS like Wordpress. Which I don’t want.

So I built my own, using the best of both worlds.

For the backoffice, for managing content, a PHP/MySQL classic, with a media gallery and a tinyMce. Pages are in categories which can have subcategories and pages, as deep as you want.

Each page must have a template.

A preview button (which is the key) and an export site button.

And that’s all.

Of course, it only suits my needs (as me or some clients like web agencies will be in charge of the templating) and have no means of going public, so don’t fit what OP was looking for.

But it works, it was a two days job to create, and as it’s all mine, I can add any functionality I want.

Re: Static site generators need less rigid content APIs

#23

Post by scrollaway »

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…

Give Ghost a try (https://ghost.org/). They have, I believe, potential to eventually add static site generation. There's an open issue about it, I really hope it happens.

I agree with you that sitegen from git is just too cumbersome when the articles aren't very bare/simple. Also when there are multiple users contributing, especially non-technical users.

Re: Static site generators need less rigid content APIs

#24

Post by PuffinBlue »

fvsch wrote: post #20
PuffinBlue wrote: post #15

Earlier quoted context omitted.

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).

I'm just looking through now. It does look pretty good. I'll have to play with it and see if it falls in the right spot between 'I'm too lazy, just point and click' and wanting something lighter-weight and easier to reason about.

Re: Static site generators need less rigid content APIs

#25

Post by dustingetz »

1) Git is basically a database with certain requirements around the time dimension, thus static site generators can be equivalently backed by a database with similar properties

2) Datomic is such a database – an accumulate-only log with explicit time dimension that can be queried JOIN-style, WHERE-style and GraphQL-style

3) Thus crud apps backed by Datomic are suitable to be delivered from CDN like static sites – rendered pages, API, everything

Here is such a static site backed by a database: http://www2.hyperfiddle.net/:markdown/ final rendered site: http://www.hyperfiddle.net/ – since it is server rendered React.js, obviously you can use React.js to render your pages, so you get a fully extensible markdown pipeline as you can see.

Here is my blog, a static site: http://www.dustingetz.com/ It is also a progressive web app, so if you navigate around with the browser dev tools open, you will see API requests served from disk since they are Cache-Control: Immutable. Yet, here is the live CRUD dashboard for it's database: http://dustingetzcom.hyperfiddle.net/:hyperblog!dashboard/

It's great for docs, for example: http://docs.hyperfiddle.net/ (We turned off server side rendering for this one but you can leave it on!)

Did I mention Hyperfiddle also does arbitrary CRUD database apps, live in your browser - queries, schema, views, everything?

Re: Static site generators need less rigid content APIs

#26

Post by tresoldi »

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…

I felt the same when looking for a generator that could be learned in one afternoon and which would allow me to easily change templates/themes whenever I felt like it, months later. The solution was to rely exclusively on pandoc for markdown to HTML conversion, generating some .md files when necessary (such as from a bibliography, or if so I wanted from a blog/ directory). All without any real templating and relying only upon my bare CSS knowledge -- a nice side effect was forcing me to adopt a minimalist approach.

The entire "generator" is a silly Python script: https://github.com/tresoldi/tresoldi.github.io/blob/master/b... (the site is at http://www.tiagotresoldi.com/ , in case anyone cares).

Re: Static site generators need less rigid content APIs

#27

Post by PuffinBlue »

scrollaway wrote: post #23
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…

Give Ghost a try ( https://ghost.org/ ). They have, I believe, potential to eventually add static site generation. There's an open issue about it, I really hope it happens. I agree with you that sitegen from git is just too cumbersome when the articles aren't very bare/simple. Also when there are multiple users contributing, especially non-technical users.

Ghost is expensive. Actually it's incredibly expensive when compared to the competition feature wise.

It's also a pain to self-host (especially compared to competition seeing as it's basically a requirement to go for a full VPS install) and is pretty opaque when anything goes wrong.

It's easy to use and slick, and I'm not OP, but it's not for me at least.

Re: Static site generators need less rigid content APIs

#28

Post by boynamedsue »

JeanMarcS wrote: post #22

For sure everyone have his favorite way of doing things and what seemed obvious for some will look strange for others. As I tested myself several SSG, I (as many it seems !) thought « Well, none fit my needs so let’s make one » My problem was that I need an interface for the final clients, which are no tech at all, to be able to edit content. Solutions like Hugo are not possible as it would means install it on a comp…

I reimplemented the Wordpress API on my own static site service so that Wordpress clients can be used seamlessly.

The idea is that Wordpress clients can be used to create content, but the output is a static site served from S3 and Cloudfront.

If you want to try it, send me an email: hello@perspect.com

Re: Static site generators need less rigid content APIs

#29

Post by icebraining »

JeanMarcS wrote: post #22

For sure everyone have his favorite way of doing things and what seemed obvious for some will look strange for others. As I tested myself several SSG, I (as many it seems !) thought « Well, none fit my needs so let’s make one » My problem was that I need an interface for the final clients, which are no tech at all, to be able to edit content. Solutions like Hugo are not possible as it would means install it on a comp…

So for those case, the solution is to use a CMS like Wordpress. Which I don’t want.

There are already a few CMSs for static sites, much like the solution you've made. The old-school one is Movable Type, but nowadays there's also one by Netlify, Publii, Siteleaf and a few others. There are also plugins for Wordpress that generate static sites from it (meaning you don't have to expose WP itself to the outside world).

That said, making your own solution can be the best option.

Re: Static site generators need less rigid content APIs

#30

Post by boynamedsue »

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…

This may be the comment you've been waiting for! I implemented Wordpress API compatibility on top of a static site service.

Send me an email at hello@perspect.com to try the service.

Post reply on HN