Yes, definitely, but I have no expectation that they will be the ones managing or updating it. My pitch is basically "I'll do the site and you can email me .docx, PDF, giant 20MB JPEGs, whatever, and I'll manage it for you".
This is even easier then something like WordPress for them, and much simpler for me. WordPress deserves credit for its ease of use for non-technical people, however I don't view this as a good metric for what to choose for a website.
I deliver the _site folder as a finished product and put it on Cloudfront with HTTPS. That's about as simple and unbreakable as it gets. Customers can then pay a monthly retainer or occasional hourly rates for updates. If they want the source files to run the generator on their own machine that's fine too, but it costs extra.
The model isn't that much different from a wedding photographer.
I use a static site generator for my blog - but as I only post once or twice a year, I generally find I'm fixing broken static site generation about as often as I'm writing a blog post.
Using a mac? I hope you've got xcode installed to give you command line tools. No, you can't get that to work without logging into your Apple account. Right, now just install these tools using homebrew. Oh, homebrew's giving some git error? Sorry, you're on your own. Got homebrew working? Right, better make sure you've got ruby and gem and python and nodejs installed. Still doesn't work? Oh, that's because you're missing redcarpet, just gem install redcarpet. It didn't work? Oh, guess I actually need a development version of ruby.
Moved to Linux? Good news, there's a jekyll package right there. Bad news is it's outdated and won't build your site. Time to install ruby and gem then use them to install jekyll. Didn't work? Oh, you don't want that version of ruby, you need the development version, gotta have the right files so you can compile things as they download.
So no, I don't recommend static site generation to anyone who isn't a veteran error-message-googler.
Hey, I think you're mistaking static site generator === Jekyll. My favorite is Hugo[1]. Just grab the binary and it can run everywhere. I mean everywhere. No need to setup the build tools, environment
This seems like an opinion that was formed based on bad experiences with some SSG that have particularly poor management processes. And that could be wildly popular SSG with the tech crowd, but popular is not the same as good.
Obviously, bad SSG are bad, but not all of them are: any SSG worth recommending to the general public in exchange for money (i.e. recommending to your customers) is one that doesn't rely on the user first making sure their "tech stack" is set up properly: it just comes with a normal installer (even if that "installer" takes advantage of the OS it's running on to grab all the dependencies it needs for itself and uses a preinstalled scripting language to run the system under the hood).
And of course typically these still have a "this project is open source, click here for our git repo!" link that normal users will NEVER use, but power users are drawn to like moths to a flame. Their experience, however, is not what you're going to sell your customers =)
Contentful and Prismic are ones I'm familiar with and they actually support both static generation and API-driven so you can take an incremental approach.
I use forestry+Jekyll on all my own sites and it works great. It's fun to see how far it's possible to go with it.
However I'm still waiting for the right client project to come along to use it with as it's rare for someone to need a custom-built site and also the fairly limited features of a static cms.
Usually if they want a simple site something like Squarespace will be the quickest and cheapest option, whereas if they have any complex requirements, like migrations or integrations with other platforms, then an open source cms framework like Drupal is often a better starting point.
I've used (and paid for) Siteleaf in the past, and Jekyll Admin is really close to it and is OSS if anyone reading is looking for an open/free alternative :)
Many clients simply don’t need a website let alone a framework such as jekyll / git-pages.
Keep it simple. Knock up a Facebook page. “Hey! We make pies, come buy some”. Job done.
My advice would be: Add a simple landing page on a matching domain which contains opening hours, address phone number and the logo. And add an entry to google maps, (bing?) and apple maps.
For a general site that's going to be maintained by a non-technical audience? Absolutely not. They need a WYSIWYG editor instead of markdown. "Deploy" for them has to be a "publish" button. Keep it simple with a self-updating WordPress on WPEngine or similar.
For API documentation sites, I use Jekyll and Slate all the time. They're going to be maintained by developers so markdown is easy. Version control is key. And syntax highlighting is important. We use Jekyll at Okta and it's easy but powerful enough to solve the big problems quickly and easily.
Second just deploying wordpress on WPEngine for them, maybe put them behind a free CloudFlare account for the CDN. But offloading the security and caching instead of dealing with WordFence and W3 Total Cache plugins etc is well worth the "expense" of wpengine, which isn't much expense at all for any kind of actual business that generates revenue.
No. It's very easy/cheap to setup something like wordpress. Teaching a client how to generate a static site is dificult and clients will have to go back to the documentation if they don't use it for a while. If you have a ui you only have to remember the /admin url and everything else is just looking at the screen and clicking the right thing.
The issue with any dynamic site is security. You can't set up Wordpress and forget about it. There has to be some mechanism for updating to the latest version for security (which may break any plugins/themes).
WordPress has had one-click updates for years and makes it easier than any other CMS I've seen. It's been doing a fine job and powering 25% of all pages on the net and growing.
Static site generators are too complicated for the general public. I usually recommend Ghost, which is like Wordpress but done right, without the security issues and the awful code.
Readit News
This is even easier then something like WordPress for them, and much simpler for me. WordPress deserves credit for its ease of use for non-technical people, however I don't view this as a good metric for what to choose for a website.
I deliver the _site folder as a finished product and put it on Cloudfront with HTTPS. That's about as simple and unbreakable as it gets. Customers can then pay a monthly retainer or occasional hourly rates for updates. If they want the source files to run the generator on their own machine that's fine too, but it costs extra.
The model isn't that much different from a wedding photographer.
Using a mac? I hope you've got xcode installed to give you command line tools. No, you can't get that to work without logging into your Apple account. Right, now just install these tools using homebrew. Oh, homebrew's giving some git error? Sorry, you're on your own. Got homebrew working? Right, better make sure you've got ruby and gem and python and nodejs installed. Still doesn't work? Oh, that's because you're missing redcarpet, just gem install redcarpet. It didn't work? Oh, guess I actually need a development version of ruby.
Moved to Linux? Good news, there's a jekyll package right there. Bad news is it's outdated and won't build your site. Time to install ruby and gem then use them to install jekyll. Didn't work? Oh, you don't want that version of ruby, you need the development version, gotta have the right files so you can compile things as they download.
So no, I don't recommend static site generation to anyone who isn't a veteran error-message-googler.
[1]: https://gohugo.io/
Obviously, bad SSG are bad, but not all of them are: any SSG worth recommending to the general public in exchange for money (i.e. recommending to your customers) is one that doesn't rely on the user first making sure their "tech stack" is set up properly: it just comes with a normal installer (even if that "installer" takes advantage of the OS it's running on to grab all the dependencies it needs for itself and uses a preinstalled scripting language to run the system under the hood).
And of course typically these still have a "this project is open source, click here for our git repo!" link that normal users will NEVER use, but power users are drawn to like moths to a flame. Their experience, however, is not what you're going to sell your customers =)
There's options like Netlify to use as CMS: https://github.com/netlify/netlify-cms
Hugo will run anywhere.
In Linux you don't need to install the distro's packaged version; source is where you should go.
There is an added difficulty, but it's not as painful as you make it seem.
https://cloudcannon.com / https://forestry.io/ / https://www.siteleaf.com/
With all of them you can set up nice content type templates and get your client to put structured content.
edit: formatting
However I'm still waiting for the right client project to come along to use it with as it's rare for someone to need a custom-built site and also the fairly limited features of a static cms.
Usually if they want a simple site something like Squarespace will be the quickest and cheapest option, whereas if they have any complex requirements, like migrations or integrations with other platforms, then an open source cms framework like Drupal is often a better starting point.
https://respondcms.com/
https://github.com/jekyll/jekyll-admin
For a general site that's going to be maintained by a non-technical audience? Absolutely not. They need a WYSIWYG editor instead of markdown. "Deploy" for them has to be a "publish" button. Keep it simple with a self-updating WordPress on WPEngine or similar.
For API documentation sites, I use Jekyll and Slate all the time. They're going to be maintained by developers so markdown is easy. Version control is key. And syntax highlighting is important. We use Jekyll at Okta and it's easy but powerful enough to solve the big problems quickly and easily.
I've got a smallish piece of JS that gives the client a WYSIWYG editor, which speaks to Firebase.
When Firebase gets an update, it triggers a rebuild.
Best of both worlds.
I'm afraid not, but mostly because it's both simple, and fairly reliant on architecture.
Basically the process is:
Firebase authentication -> Content editable editor -> Firebase database update -> GitLab CI -> Pandoc & bash to update static site to latest Firebase -> Deploy to website