A flat file CMS is typically less scalable than a database backed CMS. With a database backed CMS, you can run a database cluster and a bunch of front-end servers, and scale up horizontally. But shared file systems are typically really bad for performance, so with a flat file CMS you can basically only scale up vertically.

Meanwhile, with a static site, you can host the end result directly on a CDN, which will give you a whole different level of performance than when you have to build each request on one server somewhere...

Flat file CMSs will also be just as vulnerable to security issues and malware injection as database backed CMSs. So you'll need to stay on top of updating them and keeping up with exploits.

Static sites, on the other hand, are practically invulnerable as long as you host them on a decent service, and they'll never suddenly break because your host updated PHP or whatever...

A simple plugin we made for netlify.com to handle different images for devices with different pixel densities, without all the complexity of the picture tag.

Check out our directory as well: https://www.staticgen.com

It has more details on each of them and lets you sort them by stars, forks and issues.

I gave a talk about moving from a dynamic to a static approach at the latest Static Web-Tech meetup, and there's a (low quality, sorry) video of the talk here:

http://www.staticwebtech.com/

Jekyll, Middleman, Roots and Hugo stands out a bit, in my mind.

Jekyll because it's so widespread and made super popular by the GitHub Pages integration. Traditionally very blogging focused, but lately it's become better at more general sites.

Middleman and Roots because they're built by top agencies that use them for serious projects (Instrument and Carrot).

Hugo because it's so damn fast. I've been checking out the build times on our clients at Netlify that use Hugo, and they're super impressive. Main drawback with Hugo is the lack of a plugin engine...

Actually it seems to be a Flat file CMS and not a static site generator.

There's a really big difference. A static site generator has a build command and spits out a whole site in just plain HTML/CSS/JS that you can host directly on a web server or a CDN without any dynamic code needed to serve the site.

This means you can put everything on a CDN, it eliminates all the security risks you get from running PHP (or Ruby, Node, etc) on your servers and makes it trivial to scale to even millions of visitors.

A flat file CMS on the other hand, is just like any other dynamic CMS except that it uses flat files on a filesystem to store content instead of a database.

This makes it a bit simpler to host (as long as you host it on just 1 server) since you don't need a DB installed, but it'll often be slower than a database backed CMS, harder to scale and no more secure (you're still running PHP code on every request).

Check out our service Netlify.

It lets you automate the Jekyll build, just like Github pages but supporting any plugin, and lets you host the whole site directly on a CDN.

Typically you'll see a 2-100 times speedup over running from a single server and you'll see much better uptime as well since our CDN will simply route around individual nodes going down...

Takes just a couple of seconds to setup automated deploys of a Jekyll/Middleman/Roots site...

Looks really cool! Would love to see Netlify in the Web Hosting Section.

It's the most full-featured static hosting platform. Like Github Pages on steroids.

Looks like you started a new Jekyll blog, so you're pretty much all set now.

If you make updates to your files through the Github web UI, netlify will fetch them and update the site.

If you have ruby installed, just clone the github repository locally and run:

bundle install

From the command line in the new folder. Then:

bundle jekyll watch

Will start a local dev server and you can start editing.

Once you push your edits to github, netlify builds and deploys the site again.

Yeah, run local server for testing and push to github to deploy.

netlify.com is a Jekyll based static site and the web UI for netlify itself is an angular app. Obviously both hosted on netlify.

When working on the sites I run a local server with browser-sync.

This is pretty much the ideal for front-end development since the site updates instantly without browser refresh when changing CSS, and the browser auto-refreshes when changing HTML or JS.

It can be a bit of a pain to get a proper live-reload/browser-sync for a Jekyll site, but with Carrot's Roots livereload is built-in.

Once I'm happy with the changes I've made locally, I commit and push to Github, and then netlify takes care of doing a production deploy.

Oh nice, we're on Designer News :)

I'm one of the founders. Happy to answer any questions!

We're building the ideal publishing solution for static websites or apps, and believe that with the right infrastructure and tooling, the large majority of websites could be made as static sites. Making them faster, safer, simpler and cheaper than traditional dynamic sites.

Co-founder of Netlify and BitBalloon here.

We've been doing CDN hosting for static sites for more than a year now, and have both CLI tools, a public API and full web UI's.

Not sure how to put this without coming across as a bit agressive, but:

DO NOT USER SURGE FOR A PRODUCTION SITE RIGHT NOW!!!

I did some tests, to compare our products. And surge sets these caching headers on EVERYTHING including your HTML files:

This header tells any browser or intermediary cache, that it's ok to just keep a copy of the current file in the cache and use that for up to 1 year without ever checking back with the origin server.

What this means is that if you put a production site on surge right now: there's NO WAY to ever make sure your users ever see any changes you make to your site within the next year. Even if you move to another host and completely redo your site, users will keep seeing the current version of your site until it happens to get pushed out of their cache!!

Surge guys: make it super high priority to fix this! You can really, really screw some people over. If someone within a large company access a site with these cache headers, chances are their corporate proxy cache will store all the files locally and never check back with your servers until they expire... I realize it's a free product, but this could cause real problems for people!

Apart from that the current SSL support is vulnerable to several known attacks: https://www.ssllabs.com/ssltest/analyze.html?d=bite-sized-apple.surge.sh