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

61–70 of 75 posts

Re: Static site generators need less rigid content APIs

#61

Post by pknopf »

cdaringe wrote: post #58
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.

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

> There isn't a one-size-fits-all

Spend an extra day and build your own. It will fit you exactly. No more, no less.

> but saying it's a poor tool because it has a lot of dependencies is silly and immaterial.

You're missing also the time it takes to customize it. For example: https://github.com/gatsbyjs/gatsby/issues/4583

How complicated can it be to have simple tree navigation? Turns out, it's pretty complicated...

I could role my own in 20 minutes without the abstractions, but no, I'm fighting uncessaray abtractions/layers/tooling that gives very little value when it comes to converting .text -> .html.

It blows my mind that people don't see this.

Read this: http://tonsky.me/blog/disenchantment/

Re: Static site generators need less rigid content APIs

#62

Post by pknopf »

kall wrote: post #56
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 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.…

> The amount of (dev) dependencies doesn’t matter that much to me, but I agree about the client side.

I read a blog post recently that really resonated with me [0].

> And dependencies? People easily add overengineered “full package solutions” to solve the simplest problems without considering their costs. And those dependencies bring other dependencies. You end up with a tree that is something in between of horror story (OMG so big and full of conflicts) and comedy (there’s no reason we include these, yet here they are):

But yeah, I don't mind where the data is stored. It's the html generation that people go overkill with.

[0] http://tonsky.me/blog/disenchantment/

Re: Static site generators need less rigid content APIs

#63

Post by pknopf »

tcfunk wrote: post #43
pknopf wrote: post #36

Earlier quoted context omitted.

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

It most certainly gives flexibility. Speed could be read as page speed or development speed, and it certainly gives the former. The latter depends on your familiarity, I suppose.

Sure, it's flexible. It can do anything you want. But only if you are willing to put up with the constant fights. See here (for one example out of many): https://github.com/gatsbyjs/gatsby/issues/4583

I urge you to just take a look at the GitHub issues and ask yourself "How much blame can be given to the tooling/tech stack for this given issue?"

Re: Static site generators need less rigid content APIs

#64

Post by frereubu »

petra wrote: post #60
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 ?

What do you mean by "dynamic"? Can you give an example?

Re: Static site generators need less rigid content APIs

#65

Post by petra »

frereubu wrote: post #64
petra wrote: post #60

Earlier quoted context omitted.

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

What do you mean by "dynamic"? Can you give an example?

Plugins that dynamic stuff based on feedback from the user: comments/forums, searching over custom post types, login , e-commerce ordering ,etc.

Re: Static site generators need less rigid content APIs

#66

Post by frereubu »

petra wrote: post #65
frereubu wrote: post #64

Earlier quoted context omitted.

What do you mean by "dynamic"? Can you give an example?

Plugins that dynamic stuff based on feedback from the user: comments/forums, searching over custom post types, login , e-commerce ordering ,etc.

Gotcha. IIRC search is taken care of by their rewriting of querystrings. Comments and things like WooCommerce aren't going to work, but if you want to do that kind of stuff SSGs aren't going to cut it - to do any kind of per-user processing you need some kind of system to do that processing, which SSGs aren't going to provide. We're thinking about using HardyPress for some of our non-profit clients because we can probably work with something like fixed donation amount buttons and Stripe.js.

Re: Static site generators need less rigid content APIs

#67

Post by boynamedsue »

petra wrote: post #59
boynamedsue wrote: post #28

Earlier quoted context omitted.

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 ?

What in particular are you asking about?

There's nothing to stop you from using JavaScript in the browser to do any number of things.

Re: Static site generators need less rigid content APIs

#68

Post by mr_toad »

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…

Markdown gets used for user contributions some of the biggest sites on the web, like Wikipedia and Reddit. Are content editors really less technical capable than Reddit contributors?

Re: Static site generators need less rigid content APIs

#69

Post by cearls »

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…

Check out HardyPress. They host WordPress in an anonymous environment that goes to “sleep” when you're not using it. A static version of the site is deployed to a CDN when you're ready to publish changes. It's been the best of both worlds for us.

https://www.hardypress.com/

Post reply on HN