Static site generators need less rigid content APIs
1–10 of 75 posts
Re: Static site generators need less rigid content APIs
#2Perhaps should check out http://www.metalsmith.io/
Re: Static site generators need less rigid content APIs
#3Have 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.
Re: Static site generators need less rigid content APIs
#4GatsbyJS + Contentful API + Cloudinary : https://www.contentful.com/r/knowledgebase/gatsbyjs-and-cont...
https://cloudinary.com/
Re: Static site generators need less rigid content APIs
#5I 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 no way to put into the text as convenient as in wysiwyg where it is possible to select the picture I need.
Thus I decided to abandon the idea to migrate to SSG. Even though I tried it and dreamed about it a lot :)
Re: Static site generators need less rigid content APIs
#6To 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 react react-dom next" and you are good to go.
Build a react component at "pages/about.js" and boom, yoursite.com/about routes to this component.
Re: Static site generators need less rigid content APIs
#7I 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 not meant to be used or maintaining your own?
Re: Static site generators need less rigid content APIs
#8To 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…
The boom becomes real fun when you realize you can't have nested pages.
yoursite.com/profiles/jyepin
Re: Static site generators need less rigid content APIs
#9To 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)
Re: Static site generators need less rigid content APIs
#10This blog post really captures the motivation behind me creating statik.
https://github.com/pauldotknopf/statik
> This is a simple tool/library. There are no opinions or abstractions, aside from the abstraction needed to host and export content. There is nothing preventing you, the developer, from doing what you want with your project. Parse and render markdown files in a directory for a blog? Build a user manual? What ever you want, you can do.
I used it for my resume: https://github.com/pauldotknopf/resume
See my other HN comment.
https://news.ycombinator.com/item?id=18011099
> I tried using Gatsby for a project of mine. The moment I tried to do anything not supported OOTB, it seemed I was fighting the tooling (and webpack) at every corner. It was incredibly difficult just to get a simple tree navigation.
> One thing I thankful for though is that it gave me a new-found love for the simple and non-flashy libs/tooling.
> In the end, I wound up writing my own static site generator.
> You may say to yourself "So you just wrote your own Gatsby!?"
> No, I didn't. I wrote a thin lib that you can register endpoints and extract them to disk. It does absolutely nothing else. The idea is that I will wrote my own markdown rendering, navigation, html/css, etc for each project. "But what about the time it takes to implement all the features you need!" The time it takes to implement these minor things take far less time in the long run, and I will never have to be in an endless fight with the tooling to get simple tree navigation. Every feature I implement is exactly what I need, no more, no less.
> Sure, it isn't as cool as React, webpack, etc. But I'm a lot happier.