Ask HN: Do you suggest static site generators to your customers?
Do you suggest static site generators to your customers? How has your experience been with this? What are the services you use for a complete setup?
52 comments
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.
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.
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
[1]: https://gohugo.io/
[1]: https://gohugo.io/
I switched to Hugo too. I haven't really dug deeply enough into it, though.
If it's working for you, no need to dig it. That's my principle.
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 =)
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 =)
This comment is a huge exaggeration of the effort it takes. You don't even really need full xcode to run terminal on mac.
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.
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.
And this is why I love arch linux and even use it on all my servers. These days I rarely run into a package that doesn't work or is severely outdated.
There are now several competing nice services, that give you and your customer a UI to edit your static site with a webtool.
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
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
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.
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.
Plug: RespondCMS if you want to roll your own multi-site, static site generator with a simple approach to themes and plugins.
https://respondcms.com/
https://respondcms.com/
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 :)
https://github.com/jekyll/jekyll-admin
https://github.com/jekyll/jekyll-admin
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.
Depends on the use case.
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.
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.
Yes. But they don't know it. They just know that their site is faster than their competitors.
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'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.
That's very interesting. Is any of this code open-source?
The Firebase part?
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
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
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.
The problem is that updating plugins very often breaks stuff.
I've been running a heavily customized WordPress with literally dozens of plugins since 2005 and that has most definitely not been my experience.
One I can remember is that Facebook's official plugin stopped working and we had to switch to some other social integration plugin.
Another one was the embeded media player which just disappeared. That was somehow related to shortcodes.
Another one was the embeded media player which just disappeared. That was somehow related to shortcodes.
I've only had that happen twice in a dozen years.
a static site CMS would provide the same functionality. Something like https://forestry.io/
Another option is https://www.getlektor.com of Armin Ronacher fame.
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.
https://getpublii.com
https://getpublii.com
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.
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.
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.
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.
But can a web-based updater can still generate a static back-end?
Depends what you mean by "static" at this point. I've created sites that were updated infrequently, and so I wrote a script to build out a static mirror of the site after updating. By exposing only the static mirror you get the best of both worlds. For a higher end setup, you can run a static caching layer on the HTTP server netting you the same performance benefits but without manually building the mirrored version.
Will be interesting to see when the next generation of "content APIs" hit - client updates a field in a backend somewhere and it rolls out to static sites, apps, bots etc... all over.
There already exists some nice projects for this, like https://www.netlifycms.org/
There's also Movable Type, which has been around for 16 years now.
That's fine for content based sites, but often times the client wants to edit their homepage as well.
[deleted]
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.
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.
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.
I suggest WordPress using WP Super Cache. Best of both worlds. You get static pages with all the ease-of-use that WordPress provides.
Yes. I built a statically generated site to a Fortune 50 company. Not a microsite either, but one that was highly visible.
Using which site generator?
I made one. That was probably unnecessary, but they weren't super comfortable with open source. I probably could have sold them on Jekyll or Harp, but I wanted something fun to do :)
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).
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.
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.
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.
I miss Apple's iWeb. Wish they would bring it back.
[deleted]