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

51–60 of 75 posts

Re: Static site generators need less rigid content APIs

#51

Post by falsedan »

I’ve been baffled by how brittle static site generator tools are, and how forcefully they push their workflow/concepts onto the user.

I gave up on Jekyll when I tried to hook it up to hit & push each published site as a branch patented to the site branch & the corresponding master commit that was used to generate it.

I ended up fiddling with my SSG and exploring software designs that make it easy to add in weird extra behaviour. I really like how Dist::Zilla (Perl package publishing tool) allows so much flexibility and reuse, without many strong opinions of its own (mostly that packages are a collection of files and that prepare plugins should run before publish ones).

Re: Static site generators need less rigid content APIs

#52

Post by icebraining »

dustingetz wrote: post #25

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 – ren…

I have to say, the fact that your (quite simple) blog immediately loads a 10MB javascript file doesn't endear me to the concept. If that's to power the "secret dustingetz.com admin dashboard", I'd suggest loading it only when the link is pressed.

Re: Static site generators need less rigid content APIs

#54

Post by ken »

> I sometimes talk with developers who praise static site generators as simple, which is hogwash. I’ve seen a few projects where content editors were handed off a site based on a SSG (especially in startups where devs may dominate the conversation), and could not manage any change without a lot of training and assistance. Nothing simple about that. What those developers probably mean is that they find static site generators elegant.

It sounds like this article is using "simple" to mean "easy", and "elegant" to mean "simple".

An SSG is simple, and it's easy for people who know "the command line, the plain-files-and-scripts philosophy, git and ssh" (which is not quite the same as "developers", though there's usually a large overlap).

Re: Static site generators need less rigid content APIs

#55

Post by dustingetz »

icebraining wrote: post #52
dustingetz wrote: post #25

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 – ren…

I have to say, the fact that your (quite simple) blog immediately loads a 10MB javascript file doesn't endear me to the concept. If that's to power the "secret dustingetz.com admin dashboard", I'd suggest loading it only when the link is pressed.

www.hyperfiddle.net has no javascript payload at all.

dustingetz.com and the docs app both have embedded hyperfiddle editors, so they run in a development configuration. The 10MB is for the real-time editor which depends on the ClojureScript compiler and standard library. A production javascript configuration will bake/compile/dead-code-eliminate in advance and then asset sizes will be comparable to any ClojureScript project (which is to say, better than almost all JavaScript projects). We haven't gotten around to doing this yet. Thanks for checking out hyperfiddle!

Re: Static site generators need less rigid content APIs

#56

Post by kall »

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 amount of (dev) dependencies doesn’t matter that much to me, but I agree about the client side. I wish gatsby could emit a version without client side routing / react. I also find the way to create and manage pages (and yeah trees) is not as flexible as it should be.

"Just a txt > html converter" is what every developer builds for themselves at some point and hence the 300 different projects that already do that. I‘m glad someone is making a database backed (kind of) static site generator for once, even if it brings some code weight with it.

Re: Static site generators need less rigid content APIs

#57

Post by mcat »

Give TakeShape a try https://www.takeshape.io/.

I'm one of the Co-founders. We built TakeShape to be a more end to end static site CMS. TakeShape has a GraphQL API and Static Site generator that uses nunjucks for templating. You could also just as easily only use the GraphQL API with React or GatsbyJS's new native 3rd party API support.

TakeShape has built-in integration with s3, GCS, FTP and Netlify.

TakeShape comes after 7 years of running a design agency and trying to balance the best of many different styles of CMS and site creation approaches.

Re: Static site generators need less rigid content APIs

#58

Post by cdaringe »

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.

You are grossly simplifying the value that SSGs provide and problems they solve. Gatsby has some quirks, but it does strike a good balance of providing value whilst giving you plenty of control. It does the data capture and transformation of content I want, it gives me a place to explore and visualize those parsed datas, and it lets me control how to render that content in a context that very closely resembles the final artifact (jsx, html). It doesn't cram a new DSL down your throat (jsx is close to html enough, and, it's optional). It has excellent debugging in node and the browser. Hugo doesn't have those, Jekyll super doesn't have those, and everyone's home grown scripts certainly don't have all of those. There isn't a one-size-fits-all, but saying it's a poor tool because it has a lot of dependencies is silly and immaterial.

Re: Static site generators need less rigid content APIs

#59

Post by petra »

boynamedsue wrote: post #28
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

How do you solve the dynamic parts that are sometimes required in a site ?

Re: Static site generators need less rigid content APIs

#60

Post by petra »

frereubu wrote: post #48

I've been building websites since the mid 1990s (including everything from small personal sites to large content-managed sites for the BBC), and I now run an agency that builds WordPress sites for large non-profit clients. I've been looking at SSGs myself recently, and much as I like the idea of static sites I've come to very similar conclusions to the author. There are two observations I have about this from my pers…

What about dynamic wordpress plugins, don't you see at a big issue for hardypress ?
Post reply on HN