Static site generators need less rigid content APIs • Hacker News Board

Re: Static site generators need less rigid content APIs

#31

Post by PuffinBlue » Thu, Oct 11, 2018, 12:36 PM UTC

kaushalmodi wrote: post #21

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 Hu…

Nothing that you wrote really comes across as anything but 'yeah, Hugo is complicated'. Which is sort of the point of the specific call out of Hugo.

And I've been using it for a very long time now. I actually wrote the original _index.md explainer page for the docs at the time the switch was made to stop it being 'abused' for section front matter. At least, I think that was the work around people were using, I forget after all the changes there have been.

Hugo is a powerful tool. I'm sure there are ways to do almost anything with it, and some of them answer the critiques in the article. But it's constantly changing (it's still a long way from version 1.0) and its power and flexibility bring a steep learning curve and their own way of doing things, which seems to also be what the article is commenting on in general with static site generators.

Re: Static site generators need less rigid content APIs

#32

Post by nkristoffersen » Thu, Oct 11, 2018, 12:41 PM UTC

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 use Gatsby and then teach clients how to write markdown. Then they edit markdown content in gitlab, once they save (commit), the CI/CD regenerates the website and deploys to S3/Cloudfront.

There are other solutions, such as using wordpress or contentful to provide content and then regenerate the website when something changes. I think the creator of Gatsby is creating something like that as a business.

Re: Static site generators need less rigid content APIs

#33

Post by kaushalmodi » Thu, Oct 11, 2018, 12:43 PM UTC

PuffinBlue wrote: post #31

kaushalmodi wrote: post #21

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 Hu…

Nothing that you wrote really comes across as anything but 'yeah, Hugo is complicated'. Which is sort of the point of the specific call out of Hugo. And I've been using it for a very long time now. I actually wrote the original _index.md explainer page for the docs at the time the switch was made to stop it being 'abused' for section front matter. At least, I think that was the work around people were using, I forget…

My comment was directed at the incorrect statements that sound like facts that the author made.

I am not saying that people are born knowing how to use Hugo. Hugo is powerful. If you want to tweak it (the theme), change how your site looks and all, you would need to understand how Hugo works, learn templating,etc.

If you are happy with one of the existing templates, you don't need most of that.

Nothing comes for free. You either learn or live with what an existing theme has. I think, this applies, to anything in general.

Re: Static site generators need less rigid content APIs

#34

Post by nkristoffersen » Thu, Oct 11, 2018, 12:46 PM UTC

pknopf wrote: post #12

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.

The bottom line is flexibility and speed. With Gatsby you get both. Only looking at it as a .txt > .html convertor is very limiting. I generate 1,500 webpages every day from custom datasources with Gatsby. Using React components gives me DRY code. This gives me very great flexibility during development and great SEO and speed in production.

Re: Static site generators need less rigid content APIs

#35

Post by r3bl » Thu, Oct 11, 2018, 1:10 PM UTC

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…

Jekyll has most of what you're looking for as a plug in: jekyll-admin[0].

It doesn't handle authentication, so you'll need to put /admin under authentication on the web server level, but it allows you to edit and write pages, save them to drafts, view them as drafts, publish them, modify their metadata...

The only downside is image hosting, where the friction is still a bit too high.

[0] https://jekyll.github.io/jekyll-admin/

Re: Static site generators need less rigid content APIs

#36

Post by pknopf » Thu, Oct 11, 2018, 1:19 PM UTC

nkristoffersen wrote: post #34

pknopf wrote: post #12

Earlier quoted context omitted.

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.

The bottom line is flexibility and speed. With Gatsby you get both. Only looking at it as a .txt > .html convertor is very limiting. I generate 1,500 webpages every day from custom datasources with Gatsby. Using React components gives me DRY code. This gives me very great flexibility during development and great SEO and speed in production.

> The bottom line is flexibility and speed

Gatsby gives you neither.

Give me a tree navigation. Oh, it's not supported? Now, in order to implement it, I have to figure nodes/graphql/webpack/fragments (I know the tech, but it it's _used_) to get a solution that I could whip up myself in 30 minutes if the tooling and techstach wasn't bogging me down.

There is a hidden cost to large peices of software with high ceremony. Most people ignore it because of the initial speed you get in setting up the project, but fail to realize the downstream time that will be wasted dancing with these large hammers.

Re: Static site generators need less rigid content APIs

#37

Post by tgp » Thu, Oct 11, 2018, 1:20 PM UTC

jokull wrote: post #13

Lektor by Armin Ronacher is a lot more fully featured and based on a different model than most static generators. Pretty sure it handles this use case.

Yes, Lektor is great. The outstanding features are the admin interface which allows even non-technical people to create and edit content, and the content models which allow to work nicely with structured data.

For example, in the past I have built a multilingual media database with Lektor, where items could be, say, books or movies, and depending on the content type I could enter a "number of pages" (int) or "duration" (time) or "author" (selection from a list of "person"-typed contents), and the admin interface would be auto-generated. I haven't seen a similar functionality in other SSGs.

Downside: For large sites rebuilding takes very, very long...

Re: Static site generators need less rigid content APIs

#38

Post by wild_preference » Thu, Oct 11, 2018, 1:22 PM UTC

Thu11Oct wrote: post #17

As long as you have a Markdown parser and a template engine, building your own static generator for your current use-case is easier than understanding how to use an existing one.

But now you may be wasting time dicking around with it instead of focusing on the goal of writing content. In my experience the procrastination of DIY is very tempting and it’s fun to pretend like you truly needed to DIY.

Re: Static site generators need less rigid content APIs

#39

Post by prophesi » Thu, Oct 11, 2018, 1:44 PM UTC

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…

For Hugo in particular, Forestry[0] is really nice. If you're already using Netlify for deployment, they also have a CMS[1] that works well with most Static Site Generators.

[0] https://forestry.io/

[1] https://www.netlifycms.org/

Re: Static site generators need less rigid content APIs

#40

Post by reacweb » Thu, Oct 11, 2018, 1:52 PM UTC

I am developping my SSG. For the moment, it is

  for file in *.md ; do
     echo " converting $file"
     pandoc $file -f markdown -t html5 \
        -H templates/header-prod.html \
        -B templates/nav.html \
        -A templates/footer-prod.html \
        --template=./default.html5 \
        -o ../out/${file%.md}.html \
        -s  --data-dir=./ \
        --highlight-style pygments \
        --variable=file:${file%.md}.html
  done
  scp -r ../out/* me@cloud:/var/www/html

Someday, I will improve it for a smarter generation of index.html. For the moment, my struggle is style.css.