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 =)
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).
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.
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 — https://proof.pub — 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.
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 https://www.laktek.com/2016/11/29/introducing-pragma/
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.
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.
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.
tombrossman|8 years ago
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.
michaelt|8 years ago
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.
thangngoc89|8 years ago
[1]: https://gohugo.io/
TheRealPomax|8 years ago
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 =)
vcanales|8 years ago
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.
shimon_e|8 years ago
rolae|8 years ago
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
thangngoc89|8 years ago
mattkevan|8 years ago
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.
madoublet|8 years ago
https://respondcms.com/
mcescalante|8 years ago
https://github.com/jekyll/jekyll-admin
yawninganalyst|8 years ago
leipert|8 years ago
caseysoftware|8 years ago
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.
xref|8 years ago
shakna|8 years ago
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.
lenomad|8 years ago
fimdomeio|8 years ago
BeetleB|8 years ago
bitzero|8 years ago
Rjevski|8 years ago
RobGav|8 years ago
https://getpublii.com
garethsprice|8 years ago
alexcabrera|8 years ago
A real-world example would be the First Round Review (http://firstround.com/review/), designed by our studio (https://marquee.studio) and running on Proof.
bigmanwalter|8 years ago
gwbas1c|8 years ago
laktek|8 years ago
I'll be doing a private release in few weeks for the beta subscribers.
Symbiote|8 years ago
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.
claudiulodro|8 years ago
tootie|8 years ago
JoshTriplett|8 years ago
cacozen|8 years ago
The developer experience is great in static site generators such as Hugo, Gatsby, among others.
And finally, if your client needs to update content, you can use headless CMS such as Contentful, NetlifyCMS, Dato etc.
thangngoc89|8 years ago
Jemm|8 years ago
unknown|8 years ago
[deleted]