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".<p>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.<p>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.<p>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.<p>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.<p>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.<p>So no, I don't recommend static site generation to anyone who isn't a veteran error-message-googler.
There are now several competing nice services, that give you and your customer a UI to edit your static site with a webtool.<p><a href="https://cloudcannon.com" rel="nofollow">https://cloudcannon.com</a> / <a href="https://forestry.io/" rel="nofollow">https://forestry.io/</a> / <a href="https://www.siteleaf.com/" rel="nofollow">https://www.siteleaf.com/</a><p>With all of them you can set up nice content type templates and get your client to put structured content.<p>edit: formatting
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.
Depends on the use case.<p>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.<p>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.
Yes. But they don't know it. They just know that their site is faster than their competitors.<p>I've got a smallish piece of JS that gives the client a WYSIWYG editor, which speaks to Firebase.<p>When Firebase gets an update, it triggers a rebuild.<p>Best of both worlds.
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.
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.
I strongly recommended Publii, new true static CMS. It comes with GUI and themes and supports a lot modern, popular hosting option: S3, GitHub Pages, Netlify, Google Cloud or SFTP.<p><a href="https://getpublii.com" rel="nofollow">https://getpublii.com</a>
Went through a phase of recommending SSGs for some client projects. Worked well for very small projects (landing pages or one-off microsites) or for clients where we had ongoing maintenance agreements. However many clients ended up feeling short changed that they couldn't update the site themselves (despite being told this up front and opting for SSG as the cheaper option). I'd not recommend it for non-technical clients.
Plug: Our publishing platform — <a href="https://proof.pub" rel="nofollow">https://proof.pub</a> — combines an editorial suite, API-based CMS, and Javascript/Sass SDK for creating static compilers using server-side React. When content is released through the editorial suite, we perform a static compilation and push the resulting archive to CloudFront. Works great, sites load quickly, and it all scales very simply.<p>A real-world example would be the First Round Review (<a href="http://firstround.com/review/" rel="nofollow">http://firstround.com/review/</a>), designed by our studio (<a href="https://marquee.studio" rel="nofollow">https://marquee.studio</a>) and running on Proof.
If the client is somewhat technical, and doesn't mind mucking around in markdown and the occasional html then sure, why not? But most of my clients prefer having a simple to use backend for updating the site.
I'm working on a project to make it easy to have best in both worlds - static page generation with a browser front-end. Take a look at the intro blog post for a detailed explanation of idea <a href="https://www.laktek.com/2016/11/29/introducing-pragma/" rel="nofollow">https://www.laktek.com/2016/11/29/introducing-pragma/</a><p>I'll be doing a private release in few weeks for the beta subscribers.
We have a custom SSG in Github. Any commit triggers a Jenkins build, which deploys it to our test site. Clicking the "Release" button in Github triggers a production build.<p>Non-developer staff have been fine with this, editing Markdown files within the Github interface and adding the occasional PDF. If something doesn't look right on the test site, they can ask for advice.
Definitely yes. It's performant and safe by default, and you have lot's of free or cheap quality hosting with CDN (example: Netlify.com).<p>The developer experience is great in static site generators such as Hugo, Gatsby, among others.<p>And finally, if your client needs to update content, you can use headless CMS such as Contentful, NetlifyCMS, Dato etc.
Most of my customers are small business and they only update their website like 2-3 times per years. I built all of these websites with a static site generator and all text is extracted from a YAML/JSON files. If some customers requires editing the data themselves, I put a dead simple frontend on top of it for them.