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.
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.
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.
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.
The article in the top of this thread is interesting. I can just add that in Hugo we have tried to make it simple for the simple stuff, but also make the "harder stuff" possible. We have naming conventions for layout files to keep it DRY (to avoid having to set "layout: blog" or something in every content file (you can)) and we have some special meaning behind "index.md" and "_index.md" -- which among other things allows for a navigable and not so rigid content tree. We even have plans to, in near future, to extend that tree into the content files themselves (ToC, paragraphs, sections). We may have different trade-offs than the article writer: With many sections and thousands of files in a deeply nested content tree, Hugo's layout system its speed may make more sense. Or not. So we do try, but it is hard to make everyone happy. I'm bep on GitHub.
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.
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?
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.
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 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 :)
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 to a static site. It's also super easy to manage rich media and as I'm falling squarely on the side of 'get shit done' it's looking like a good option.
It's trivial to cache it well and update it. Yeah it's not as secure but there's a risk vs usability judgement that has to be made. And I think I'd prefer to be producing content and having some good backups rather than just not use my site.
Forestry.io is a CMS for static sites that includes a media management interface you might like[0].
We also support uploading images to Cloudinary instead of committing them to your git repo to prevent repo bloat.
Depending on what you're trying to do, a non-CMS option that will remove some of the tedium of inserting all these images is to take advantage of Hugo's Page Bundles feature[1]. With this you could just group a bunch of images in a folder and iterate over them in your templates.
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.
If memory isn't playing tricks on me, you can go to staticgen and in the language pick bash. There was a sweet one developed with photos as front runner. It may or may not be what you are looking for.
> 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).
As much as I like Hugo, I recently stumbled upon the terrible Go templates! This is probably the strangest and most limited template engine I'm aware of. It might be nice in an application to actually limit what can be done in templates, but in a tool like Hugo where the user can not easily extend the core functionality, more powerful templates would be necessary. I hope Hugo switches to a more powerful template engine one day.
Besides that I agree with the assessment that these tools are from developers for developers. In the end a static site generator is more like a special kind of build tool and less like a CMS (what non-technical users would need).
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 perspective:
1. People often forget that "making your own" also entails a huge risk for a client. What happens if you go bust? We're constantly being contacted by organisations who were talked into a proprietary CMS and then left in the lurch when either their relationship with the agency broke down (which often happens in this situation because the agency know the client is locked into their CMS) or a company's lone developer left.
2. No content editor should have to use anything much beyond a Word-like interface, even if there are separate TinyMCE fields for separate areas in a page template. Even Markdown, which seems elegant and simple to developers, can cause all sorts of issues with non-technical content editors - and most clients outside the development bubble are non-technical. I feel like the lessons learned at the beginning of CMSes - for example, you shouldn't expect anything but pain from expecting clients to edit HTML - haven't been fully understood.
The one end-user benefit from SSGs seems to be that the site is packaged as static files and is therefore faster and easier to deploy, but is that really worth jumping through all these hoops? If any of these SSGs wants to reach a broader market, they'll need to have a WordPress-like interface that then publishes the static files and somehow manages to cope with dynamic things like search and filtering in an accessible way.
One service I've been interested by is https://www.hardypress.com/ (just tried it out, not affiliated in any way) which effectively takes a WordPress site and publishes a static version. They cope with form submissions in a similar way to Netlify (I think) and also deal relatively with querystrings that trigger a filtered listing. I think this is the only direction I'd be comfortable with for my clients because it gives them all the benefits of a user-focused CMS with a static site generator, while allowing them to take the site to one of the many other WP agencies if they choose to.
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?
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...
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 not meant to be used or maintaining your own?
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.
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.
> 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 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.
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).
To 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.
I agree with the author that SSGs are tools written by developers for their own use. But what's great about the file-based, command-line-driven interface is that it's possible to hook the input side up to some more machinery if you want a GUI CMS.
I work for Forestry.io, and our product is a CMS that aims to ease the pain of non-developers managing content for static sites. We are committed to bridging the gap between copywriters and developers. I am a big believer in the potential for static sites to transform the web, but I realize there is a lot of ground left to cover.
I'm part-way there with https://github.com/akavel/g-wiki (towards an "elegant", or maybe rather "stupid", static site generator):
• it is template-driven, via Go templates engine (the theme/wiki.tpl is the entry point, all other templates are loaded dynamically) — no need to put files in special place in hierarchy (unless you impose it on yourself);
• it has `glob` function for matching files by pattern, e.g. `glob "/20??-??-??-*.md"`, and can render the contents of files loaded this way;
• it has `matchre` function which allows simple editing of page contents (you should be able to cut contents before/after a `<!--more-->`, etc.); by the way, I kinda feel, that the three points above, taken together, probably already make it Turing-complete in some unholy, non-euclidean, blasphemous way, akin to C++ templates...
• the "only" caveat being... it's not actually a SSG (yet™). It's more of a "personal wiki/notetaking" app currently. But the next step and goal in its development is to convert it to a SSG, only I'm still pondering various approaches to go there. And... it's kinda on hiatus now, in that I'm not developing it recently. But if I will develop it, it'd be exactly to convert it to a SSG now, so you should be fairly safe to "watch" it on GitHub. If anything shows up in your inbox, most probably it'd be a set of commits converting it to a SSG. And this very thread on HN may, or may not, make me get back to work on that ;)
> Originating in simple blog engines, static site generators treat pages as a single content chunk (often in Markdown) with some metadata sprinkled on top. If you need several long chunks of content (say, a product short description, long description, technical specs, and a list of vendors), you’re out of luck.
I've struggled with this too. I'd really like to write in unadorned Markdown, because I'm using Trello as a headless CMS[0], but I also want the Markdown to map to an object containing discrete chunks of content.
The solution I settled on is to map level 1 headings to separate properties. The content that follows each level 1 heading is converted to HTML and becomes the value of the corresponding property - unless the content is a code block, in which case the code block is parsed as YAML to get a nested object instead of HTML.
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.
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.
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.
As a meta comment, this trend may also indicate a distancing of developers from end users, which may be a result of companies not being consumer oriented but acquisition oriented.
[+] [-] JeanMarcS|7 years ago|reply
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.
[+] [-] prophesi|7 years ago|reply
[0] https://forestry.io/
[1] https://www.netlifycms.org/
[+] [-] icebraining|7 years ago|reply
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.
[+] [-] boynamedsue|7 years ago|reply
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: [email protected]
[+] [-] nkristoffersen|7 years ago|reply
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.
[+] [-] bjornerik|7 years ago|reply
[+] [-] r3bl|7 years ago|reply
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/
[+] [-] dustingetz|7 years ago|reply
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?
[+] [-] icebraining|7 years ago|reply
[+] [-] avaika|7 years ago|reply
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 :)
[+] [-] PuffinBlue|7 years ago|reply
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 to a static site. It's also super easy to manage rich media and as I'm falling squarely on the side of 'get shit done' it's looking like a good option.
It's trivial to cache it well and update it. Yeah it's not as secure but there's a risk vs usability judgement that has to be made. And I think I'd prefer to be producing content and having some good backups rather than just not use my site.
[+] [-] dwalkr|7 years ago|reply
We also support uploading images to Cloudinary instead of committing them to your git repo to prevent repo bloat.
Depending on what you're trying to do, a non-CMS option that will remove some of the tedium of inserting all these images is to take advantage of Hugo's Page Bundles feature[1]. With this you could just group a bunch of images in a folder and iterate over them in your templates.
[0] https://forestry.io/docs/editing/media-library/
[1] https://gohugo.io/content-management/page-bundles/
[+] [-] scrollaway|7 years ago|reply
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.
[+] [-] Teichopsia|7 years ago|reply
[+] [-] ken|7 years ago|reply
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).
[+] [-] reacweb|7 years ago|reply
[+] [-] cryptos|7 years ago|reply
Besides that I agree with the assessment that these tools are from developers for developers. In the end a static site generator is more like a special kind of build tool and less like a CMS (what non-technical users would need).
[+] [-] frereubu|7 years ago|reply
1. People often forget that "making your own" also entails a huge risk for a client. What happens if you go bust? We're constantly being contacted by organisations who were talked into a proprietary CMS and then left in the lurch when either their relationship with the agency broke down (which often happens in this situation because the agency know the client is locked into their CMS) or a company's lone developer left.
2. No content editor should have to use anything much beyond a Word-like interface, even if there are separate TinyMCE fields for separate areas in a page template. Even Markdown, which seems elegant and simple to developers, can cause all sorts of issues with non-technical content editors - and most clients outside the development bubble are non-technical. I feel like the lessons learned at the beginning of CMSes - for example, you shouldn't expect anything but pain from expecting clients to edit HTML - haven't been fully understood.
The one end-user benefit from SSGs seems to be that the site is packaged as static files and is therefore faster and easier to deploy, but is that really worth jumping through all these hoops? If any of these SSGs wants to reach a broader market, they'll need to have a WordPress-like interface that then publishes the static files and somehow manages to cope with dynamic things like search and filtering in an accessible way.
One service I've been interested by is https://www.hardypress.com/ (just tried it out, not affiliated in any way) which effectively takes a WordPress site and publishes a static version. They cope with form submissions in a similar way to Netlify (I think) and also deal relatively with querystrings that trigger a filtered listing. I think this is the only direction I'd be comfortable with for my clients because it gives them all the benefits of a user-focused CMS with a static site generator, while allowing them to take the site to one of the many other WP agencies if they choose to.
[+] [-] mr_toad|7 years ago|reply
[+] [-] petra|7 years ago|reply
[+] [-] jokull|7 years ago|reply
[+] [-] tgp|7 years ago|reply
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...
[+] [-] nicolaslem|7 years ago|reply
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?
[+] [-] tresoldi|7 years ago|reply
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).
[+] [-] pknopf|7 years ago|reply
Exactly. I created a tool to help with this as well.
https://github.com/pauldotknopf/statik
It has no features, by design.
[+] [-] kall|7 years ago|reply
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.
[+] [-] pknopf|7 years ago|reply
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.
[+] [-] pknopf|7 years ago|reply
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.
[+] [-] kylemathews|7 years ago|reply
[+] [-] falsedan|7 years ago|reply
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).
[+] [-] jypepin|7 years ago|reply
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.
[+] [-] mlcdf|7 years ago|reply
(At least, that how it used to be last time I used it)
[+] [-] icemelt8|7 years ago|reply
[deleted]
[+] [-] dwalkr|7 years ago|reply
I work for Forestry.io, and our product is a CMS that aims to ease the pain of non-developers managing content for static sites. We are committed to bridging the gap between copywriters and developers. I am a big believer in the potential for static sites to transform the web, but I realize there is a lot of ground left to cover.
[+] [-] akavel|7 years ago|reply
• it is template-driven, via Go templates engine (the theme/wiki.tpl is the entry point, all other templates are loaded dynamically) — no need to put files in special place in hierarchy (unless you impose it on yourself);
• it has `glob` function for matching files by pattern, e.g. `glob "/20??-??-??-*.md"`, and can render the contents of files loaded this way;
• it has `matchre` function which allows simple editing of page contents (you should be able to cut contents before/after a `<!--more-->`, etc.); by the way, I kinda feel, that the three points above, taken together, probably already make it Turing-complete in some unholy, non-euclidean, blasphemous way, akin to C++ templates...
• the "only" caveat being... it's not actually a SSG (yet™). It's more of a "personal wiki/notetaking" app currently. But the next step and goal in its development is to convert it to a SSG, only I'm still pondering various approaches to go there. And... it's kinda on hiatus now, in that I'm not developing it recently. But if I will develop it, it'd be exactly to convert it to a SSG now, so you should be fairly safe to "watch" it on GitHub. If anything shows up in your inbox, most probably it'd be a set of commits converting it to a SSG. And this very thread on HN may, or may not, make me get back to work on that ;)
Please note it's also poorly documented as of now. Though it has some reasonable --help message contents, see: https://github.com/akavel/g-wiki/blob/fork/wiki.go#L49-L110
Also, for editing markdown, I personally like https://typora.io/ and, more recently, https://zettlr.com/
EDIT: You could actually already try running `wget` on it. This is actually one of the approaches I'm considering.
[+] [-] cheeaun|7 years ago|reply
[+] [-] dwilding|7 years ago|reply
> Originating in simple blog engines, static site generators treat pages as a single content chunk (often in Markdown) with some metadata sprinkled on top. If you need several long chunks of content (say, a product short description, long description, technical specs, and a list of vendors), you’re out of luck.
I've struggled with this too. I'd really like to write in unadorned Markdown, because I'm using Trello as a headless CMS[0], but I also want the Markdown to map to an object containing discrete chunks of content.
The solution I settled on is to map level 1 headings to separate properties. The content that follows each level 1 heading is converted to HTML and becomes the value of the corresponding property - unless the content is a code block, in which case the code block is parsed as YAML to get a nested object instead of HTML.
[0] https://github.com/dwilding/trello-kb
[+] [-] mcat|7 years ago|reply
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.
[+] [-] kaushalmodi|7 years ago|reply
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.
[+] [-] PuffinBlue|7 years ago|reply
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.
[+] [-] buboard|7 years ago|reply