
Static site generators focus on the wrong thing - blankverse
http://blog.pankajmore.in/static-site-generators-focus-on-the-wrong-thing
======
smacktoward
This is an argument that literally goes back to the dawn of the CMS.

CMS designs tend to fall somewhere between two extremes: completely static
(grinding out HTML files) and completely dynamic (generating new pages for
each request). Static is appealing because it scales like crazy, but it's also
unappealing because it requires a "compilation"/"rebuilding" step that gets
longer and longer as your site gets bigger. Dynamic is appealing because it
requires no "rebuilding" step, you just click "Save" and your words
immediately appear, but it's also unappealing because "live pages" equals
"lots of hits to the database", which makes scaling to handle even moderate
amounts of traffic a problem. In other words, there is no "silver bullet"
approach, just a set of tradeoffs.

The market oscillates between these two extremes, usually on the basis of
whatever product is fashionable at the moment -- a new It Product gets lots of
buzz for the positive elements of its choice of static/dynamic, which are
apparent immediately, but its newness means it hasn't been used long enough
for people to experience the downsides. Those come later. And when they do,
people flee to a new It Product on the other end of the spectrum, where the
process repeats.

~~~
jacquesm
There is one argument against dynamic sites where a static one will do: a
static website is reliant only for security on the http server and the
underlying OS.

Dynamic sites run so much code during page generation that there are a lot of
ways in which you could try to use all that code to do something unintended.
And some of those ways pay off.

A static site cleanly separates the moment of code execution and the moment of
serving up the content in time, does not even have to happen on the same
server.

So from an operational security perspective, if you _can_ run a site
statically you probably should. And what with blogs outsourcing comments to
disqus and the like quite a few of them are candidate for being served up
statically.

As for the performance element, if a site has 1000 pages then re-generating
that site will be the same load as serving up 1000 pages when the caches are
cold. So that's 1000 visitors. If that's slow then it is annoying to the site
admins, not to the visitors. It's an off-line process, it doesn't have to be
fast to work. All that matters is that the end product can then be served up
blazingly fast.

Any website that does not require user generated input or logged in users is a
really good candidate for this workflow.

~~~
reinhardt
> All that matters is that the end product can then be served up blazingly
> fast.

TFA argues exactly against this point. All that matter (or rather, what
matters more) is minimizing the friction for the blog author in order to stay
motivated, not if it takes a fraction of a second more for a page to load.

~~~
jacquesm
That's strongly dependent on how many people visit a particular blog. For
smaller blogs, sure the page generation time is not relevant.

~~~
mercer
Indeed. For many people this issue is premature optimization.

When I tried to decide between a Middleman app with minimal configuration work
and easy deploy (Heroku), or Ghost, Wordpress, or something like that, one
consideration was page generation time.

I calculated that most optimistically, I'd probably write at most three
articles a week (which is _very_ optimistic). That means approximately 150
articles a year. That's pretty quick to generate, so I could even leave the
generation process to heroku on first page refresh if I wanted.

------
rmorabia
Medium is NOT a blogging platform, contrary to popular belief. Blogging is
owning your content, and when you write for Mediium, make no mistake, it
belongs to Medium.

Although, I just switched over from Wordpress to Jekyll, and I find it there
to be a lot less friction for publishing. I talked more about the new and
exciting workflow of Jekyll at
[http://rmorabia.com/redesign](http://rmorabia.com/redesign)

I really don't agree with the author here. Hackability is what's aided my
decision to publish more. It's just that a lot of people get caught up in the
hackability more than the publishing.

Also, there's no data backing this post. I've seen plenty of active Hakyll
sites. [http://gwern.net](http://gwern.net) is my favorite example.

~~~
prezjordan
I invite you to glance over the Medium Terms of Service. "You own the rights
to the content you post on Medium."

[https://medium.com/policy/9db0094a1e0f#0fae](https://medium.com/policy/9db0094a1e0f#0fae)

~~~
pdonis
But you don't control how it's published:

"However, by posting or transferring content to Medium, you give us permission
to use your content solely to do the things we need to do to provide Medium
Services, including, without limitation, storing, displaying, reproducing, and
distributing your content. This may include promoting your content with
partner companies or services for broader broadcast, distribution, or
publication."

(They do say they won't _sell_ your content to third parties without your
consent, which is good.)

And you don't control if and when the terms of service change.

------
swanson
It partially depends on how you choose to deploy. If you are compiling your
site locally and then pushing the static HTML to a server, you might
experience some delay in generating the site. If you use GitHub pages, you
just git push and the changes show up almost instantly. I've never run into
the case where I felt like it took too long to go from my git push to seeing
the post live in the browser - by the time I switch to the browser and refresh
the page, the post is there.

I do think that most of the static site generators focus on the wrong thing.
The main appeal of a SSG to me is that you can focus solely on the content and
none of the other crap typically associated with blogging (updating
wordpress/security issues, trying to write in some stupid WYSIWYG web form,
dicking around with formatting tags, setting up caching plugins because my
blog falls over when it's on HN) - all I do is write some Markdown and I'm
done.

~~~
pdonis
_> The main appeal of a SSG to me is that you can focus solely on the content_

Can't upvote this enough. I want my blogging tools to just get out of my way.
(I ended up writing my own for that reason, because none of the ones I tried
did it well enough:
[https://github.com/pdonis/simpleblog3](https://github.com/pdonis/simpleblog3)
.)

------
spatten
Funny, I looked at the same tech stacks and came to exactly the opposite
conclusion.

I want to be able to write on my computer, in Markdown, using the tools I want
(I blog in either Emacs or iA Writer, depending on whether I want to be in
"programmer brain" or "writer brain"). I guess I spend enough time in Markdown
that I don't need to preview that much, so I don't find the switch to the
browser and reload the page cycle especially frequent or onerous. Definitely
less onerous than the click preview and wait for it to load cycle I had on
WordPress.

Having to log into a browser and type into a crappy little rich text editor
would lower my (already extremely low) blogging frequency to non-existence.

But hey, that's my choice -- you should use whatever works for you. I'm just
glad that we have the plethora of options.

~~~
sitkack
We are conflating things between the UI we want to add content and how we want
it served. I'd love to be able to edit locally in my own markup and push to a
server dynamically. Bring back frontpage extensions for Markdown.

------
kiyoto
I write a lot (in Japanese) on the web and have had some meaningful traffic. I
think the most I got on a single day is like 150k visitors. And I've tried
everything from raw HTML to SSG to Wordpress to a homegrown CMS.

The truth of the matter is, for most web writers, any CMS is plenty
performant. You probably won't even need a cache, and if you end up needing
one, it's usually pretty straightforward to add it. And it's pretty self-
evident to me that updating one document and saving it is easier than re-
generating the updated parts of your website with some script before git-this-
git-that.

One good argument against CMS is security: many of them have a history of
security woes. This is partly why I ended up writing my own very minimal CMS
engine. All it does is read some markdown files and render them. For me, that
achieves both security (or at least if not, it's easier for me to go through
my 100 lines of Ruby code than the Wordpress codebase) and low friction.

~~~
inthewoods
I agree on security - I'm sick of updating Drupal and Wordpress for different
security holes.

------
zzzeek
you can build a software service that allows one to maintain a static site in
a git repo, which is then published to a host somewhere. the service can go as
far as having you input the location of your git repo anywhere in the world,
and the location of your hosting, whether it be an S3 bucket, rsync or FTP
host, and it can then provide ordinary blog edit / workflow tools which use
the git repo as persistence and the hosting location as output. The service
would support any number of popular static platforms, or one of its own.

When you do this, you work with the platform as long as you want. Then you can
walk away from it - all your content is in your git repo and up on your web
host as though the middle layer never existed. Another service can pick up on
the same task, which you then point to the same endpoints to continue. If you
know how to use git and your host directly, great. If you don't, who cares,
these services take care of it for you as a transparent endpoint.

In fact you could even charge money for this kind of thing. Or even make it
more open ended than just blogs and web pages, but that's where my thinking
got jumbled on this idea and I only got as far as buying a domain for it.

Obviously sites like medium and everyone else would never do this, because it
means you can leave their platform immediately. People who are capable of
executing this idea pretty much don't need it, and it's otherwise hard to
monetize. The desire to lock people into things is really what ruins
everything.

~~~
jostylr
I have this idea too. I call it WriteWeb and I am focusing on git to s3.

My thought is to write a book and sell that. It would be aimed at those who
want to create content-rich websites (less blogs, more lasting and organized).
So the middle man server is just a bit of quick glue and easily
replaced/localized.

The goal is to help people get their stories out there without a lot of
irrelevant technical choices. Just start writing content and the system gets
it out there.

I also like the idea of version control, issues, and wiki planning the github
gives. And with prose.io, editing markdown files directly in a github repo is
very pleasant.

------
mcguire
" _I feel that Hakyll sites are least updated and most abandoned. Of course,
there are outliers. But I am focusing on the majority._ "

"Not often updated and mostly abandoned" describes most blogs, no matter which
technology is used to create them.

It's true that static site generators are not frictionless, but I think they
have the least friction of any non-hosted alternative---at least if you can
keep from screwing around with the generator all the time. Hosted alternatives
are a completely different matter.

------
dminor
Sure, but they're not called static blog generators, they're static _site_
generators. They are specifically for people who want static sites, not
specifically people who want frictionless blogging.

~~~
DigitalJack
They should be called static blog generators because that's what they all do.
You can try to finagle generic sites out of them, but all the ones I have
looked at all focus on blogging. I don't want a blog generator and find this
immensely irritating.

However I just found this site:
[http://staticsitegenerators.net/](http://staticsitegenerators.net/) , which
is an impressiv elisting, so possibly I'll find something that fits my needs
or gives me a starting point.

~~~
jcheng
I found Middleman extremely nice for generic websites. It doesn't even have
blog-specific functionality built in (though there is a plugin if you want
it).

[http://middlemanapp.com/](http://middlemanapp.com/)

------
rschuetzler
I think this post missed the mark by claiming that Hakyll blogs aren't updated
because it's Hakyll, and therefore hard. I think the type of person who will
set up a Hakyll blog just may not be the kind of person who will blog
frequently. I have set up a Jekyll blog, Wordpress, Ghost, and now I'm using
Octopress. Each time I set up a new blog I think "Ya, this new platform is
great. It will be exactly what I need to blog regularly." Then a month later I
still haven't posted anything. I enjoy blogging with Jekyll. I like writing my
posts in Markdown, and I have no problem with the "git commit, push cycle." I
just don't blog that often, and so far no platform I have found has changed
that fact.

~~~
sitkack
I think doing some sociology studies around computer languages would be really
interesting.

Do people that use Haskell self select for doing new things?

~~~
marcosdumay
People that like to try new things are certainly more likely than others to
try a language created as late as the 90's that never had a marketing budget.

------
city41
I feel SSGs solved exactly the correct problem: enabling storing posts in
version control, using whatever editor you prefer to write them, and a very
quick feedback loop through a live preview. This enables much more elaborate
posts to be written. I recently wrote a long article on JavaScript promises[1]
that I can't even imagine trying to tackle in say WordPress. I use
Wintersmith[2] for my blog and it was a key factor in creating such a long
post

[1][http://mattgreer.org/articles/promises-in-wicked-
detail/](http://mattgreer.org/articles/promises-in-wicked-detail/)

[2][http://wintersmith.io/](http://wintersmith.io/)

------
chadyj
Middleman has a little known WYSIWYG blog editor extension that focuses on
easy content creation and editing. It is a paid extension but it does address
the points raised in the article [http://middleman-blog-
editor.awardwinningfjords.com](http://middleman-blog-
editor.awardwinningfjords.com)

------
geekam
I use Pelican[1] (Python) SSG and they are adding (have added?) a feature to
skip articles that have not been touched. That makes compilation really fast.

[1]
[https://github.com/getpelican/pelican](https://github.com/getpelican/pelican)

~~~
scott_karana
I appreciate that they have that feature, but haven't makefiles had the same
feature since the late 1970s?

I love the _idea_ of a static site generator, but they're really, _really_
reinventing the wheel...

~~~
pdonis
_> haven't makefiles had the same feature since the late 1970s?_

Sure, if you're willing to use make as your SSG. :-)

~~~
scott_karana
Nothing prevents you from using make (or rake) to invoke an SSG... :-)

~~~
pdonis
Only if the SSG can operate at the single-file level. Most SSGs operate at the
entire-site level; there's no way to invoke them and tell them "just rebuild
this one page", which is what you'd have to do to use make or rake as your
change-detector.

Also, I'm not sure how well make or rake would work with version control,
since make/rake, AFAIK, look at file modification times to detect changes, and
DVCS pulls clobber those. In other words, suppose I make a change on machine
A, re-generate the site, then push; then I pull from machine B. Make on
machine B may not be able to tell that the site was re-generated, because the
file timestamps are not preserved by the push/pull, so machine B is seeing
different ones than machine A did.

~~~
scott_karana
It's true, yeah.

Anyways, my point wasn't that make is sufficient (it isn't), but that a lot of
SSGs have been pretty embarrassingly feature-sparse. Understandable, I
suppose. :)

------
smutticus
I recently upgraded my Jekyll install, and I must say this beast is becoming
bloated. One of the many gem packages it now requires is a JS interpreter.
Why?

I use an SSG because they're simple, don't require dynamic page loads and are
more secure. However, the 'simple' part of this is wearing thin. Like so much
of modern web software the developers only add things to it. They never remove
or refactor. So you end up with massive dependencies and libraries from
everywhere. It's crap software.

I still use it because I'm too busy to migrate to something else. Also,
because I realize that whatever new tool I migrate to will eventually face the
same fate. Eventually any compact SSG will eventually bloat just like Jekyll
has. It's the nature of development these days.

~~~
0xdeadbeefbabe
Wait, were there days when software bloat didn't happen? I think feature creep
and accompanying bloat is human nature for all time.

~~~
keithpeter
Hummm, I used to use three bash scripts to publish the vanity site, now its
two, I just 'curate' the list of pages by adding list items.

Markdown -> script to generate a page with a header and footer and basic
navigation.

Another separate script to invoke lftp to sync with remote server when ready
to publish. Lftp looks after incremental updating.

In emergency, I can ssh into server and edit the html with nano. As I have
shell access, I could just run the page generation script on the server I
suppose.

------
winter_blue
This guy totally misses the point, even as to why Tom Preston-Werner kicked
off Jekyll. His goals were:

* Have blog posts be plain-text files, in Markdown or some other such similar human-readable format. Not locked away in a MySQL database that can't be easily versioned with Git.

* Versioning: plain text lends itself really well to versioning. Diffs are meaningful. It's easy and light-weight, and pragmatic to version a bunch of simple markdown files.

* Finally: fine-tuned output control. This is what Liquid lets you accomplish. You can specify your HTML pages in Liquid, and easily give your blog a new look. The simplicity, ease, and freedom that this system gives a person with basic web dev skills, shouldn't be ignored.

------
falcolas
I know the author said automation wasn't what they wanted, but gods below this
problem begging to be automated away.

1) Only compile newly updated items.

2) git commit -am 'new post'

3) git push origin master

The first step needs to be built out in the tool itself, but the rest is a
simple bash script, really. It's not even something that needs to be
monitored. If you did want to monitor it, it's a few simple `curl` commands
away from pushing to prowl or NMA. No need to sit at your computer waiting for
it to finish.

Seems like a good weekend project - build a set of tools around Jekyll (and/or
any number of other static site generation tools), and let the laurels rain
down.

~~~
krat0sprakhar
Can't agree with this more. All you need is a simple rakefile[0] that does it
for you. I have something like this for myself -

    
    
      prakhar1989.github.com git/master*
      $ rake
      rake default  # List tasks
      rake draft    # Create a new draft in ./_drafts
      rake post     # Create a new post in ./_posts
      rake preview  # Live Preview (use mode=drafts for drafts)
      rake publish  # Push to github
    

[0] -
[https://github.com/prakhar1989/prakhar1989.github.com/blob/m...](https://github.com/prakhar1989/prakhar1989.github.com/blob/master/Rakefile)

~~~
ojilles
I have the same, with one addition (that would be running at the end of your
'publish' step): a 47-line bash script that will spider the whole site to find
any internal 404 links.

[https://github.com/ojilles/jilles.net/blob/master/_bin/wget-...](https://github.com/ojilles/jilles.net/blob/master/_bin/wget-
test.sh)

(Poorly implemented but works for me)

------
h4ckth3pl4n3t
I agree with many of the points made in this article however I believe the
conclusion is flawed. Many SSGs focus on the wrong thing, but not all of them.
Fed up with Jekyll (which I used after being fed up with Wordpress) I wanted
something with even less friction.

I came across Hugo ([http://hugo.spf13.com](http://hugo.spf13.com)) and have
been super happy ever since. Here's some of the reasons why:

1\. Really easy to install. One binary, no dependencies or package managers

2\. Really fast. Renders my entire site with hundreds of posts in less than
half a second. Even changes to templates or themes (which affect every page in
the site) render in milliseconds. Wordpress couldn't even render a single page
that quickly.

3\. Because it is so fast the live reload feature Hugo has works really well.
Keep a browser window open and see a nearly instant preview every time I save
a file.

4\. Deploying is as simple as running a 3 line shell script I wrote in a
couple minutes. Since I'm already in the terminal running the script is
trivial. I can even run it from within Vim. Thanks to Rsync it takes around 3
seconds to deploy my content. Again, less time that it takes to hit preview
and then save in Wordpress.

And all of these are the default.

------
coreymgilmore
I agree with the difficulty in using SSG and the friction that deploying them
creates (especially when you have to update something on all posts). Having
used a few SSG in the past, I have now been using Ghost regularly and greatly
enjoy it (the live-view next to "markdown"-view is very well done).

The hosted version of Ghost is amazingly simply to use. Sign up and publish.
Done. The download and self-host is a bit more difficult, but nothing any
tech-savy person shouldn't be able to figure out.

To me, the simplicity of Ghost is the best feature and trumps any missing
features.

------
fdik
I wrote my own one, and am blogging with it. And no, it's not “focusing on the
wrong thing” – it's focusing on the totally right thing, which is doing
exactly what I need.

And it's 822 LOC, so it's easy to write, easy to handle. No big issues, no PHP
security hole, no Wordpress monsters to administrate. Another 508 LOC give
users comments with Markdown using Djangoproject.

And, last but not least: I prefer writing my blog articles partly automated
using vim. YMMV.

[http://blog.fdik.org](http://blog.fdik.org)

But hey, if you don't like it: just write your own one.

------
podman
I think the usefulness of a SSG really depends on your goals. If your goal is
simply to publish a blog, perhaps a SSG is not the right solution for you.
SSGs are interesting because they have zero external dependences. I can just
deploy my blog to Amazon S3, use CloudFront if I so choose, and never have to
worry about scalability or how much traffic my blog can handle. To me, that is
more important than the perceived friction that it takes to get a post online.

~~~
callahad
> SSGs are interesting because they have zero external dependences.

Not necessarily. In most cases, they simply move the external dependencies
from the server side to the client side.

------
spatten
If your jekyll generation time is getting too large, you can limit the number
of posts it generates like this:

    
    
        jekyll --limit_posts 3
    

It makes your site feel like new again :) I made this into a rake task which I
blogged about here:

[http://scottpatten.ca/2011/11/speeding-up-jekyll-
generation....](http://scottpatten.ca/2011/11/speeding-up-jekyll-
generation.html)

~~~
jacquesm
I looked at your blog post but it leaves some questions.

Does this also update 'latest posts' boxes and tag clouds on all the other
pages?

What about the homepage?

(I used OctoPress, not Jekyll but I suspect there is a way in there to use
this same trick)

~~~
spatten
No, it definitely doesn't do that. I use the `limit_posts` option when I'm
writing a single blog post, and then have a "rake deploy" task that re-
generates the site fully (without the `limit_posts` option) before rsyncing it
up to the server.

I guess I should put the full Rakefile up on that post. Here are the relevant
parts:

    
    
        desc "generate and deploy"
        task :deploy => ['jekyll:generate', 'deploy:deploy']
        
        namespace :deploy do 
          task :deploy do
            `rsync -r _site/ #{USER}@#{HOST}:#{DEPLOY_DIR}/`
          end
        end
        
        namespace :jekyll do
          desc "start the jekyll server in auto mode"
          task :server, :num_posts do |t, args|
            num_posts = args[:num_posts]
            cmd = "jekyll --auto --server --pygments"
            cmd += " --limit_posts #{num_posts}" if num_posts
            puts "running #{cmd}"
            exec(cmd)
          end
        
          desc "generate the site one time"
          task :generate => :clean do
            `jekyll --no-auto --pygments`
          end
        
          desc "remove the generated site"
          task :clean do
            `rm -rf _site`
          end
        end

~~~
jacquesm
Pity! Still, thanks for the tip (I can see one usecase for which it is handy,
proofreading).

------
fideloper
I'm not even sure about the analytics part being important, both because (to
me, personally) the only interesting metrics on my blog are really "who shares
my content where" and "are people reading my content". So, Google Analytics
and done for me.

My blog isn't my business, although I certainly use content (blogs,
newsletters, eBooks) as part of my "personal brand".

------
dreamfactory2
I think there's an interesting phenomenon at play here - the swing from
interpretation to compilation across the board. It's not just happening in
SSGs but also CSS (SASS etc), frameworks (PHP composer, NPM), languages (Go,
Rust). Seems weird to be adding such layers of indirection when we are already
suffering from overcomplexity and when processing is cheaper and faster.

------
freejack
The activity most likely to lead to more blogging is "more writing". Its easy
to blame the CMS/Blogging tool/SSG, etc., but really - those who write, will.

------
tzakrajs
Seems like a CMS that generates static pages would be the best of both worlds.

------
danso
It's hard to either agree or disagree with the author here...because it
depends on what your definition of "blogger" is.

For most of the technically-inclined, the bottleneck is the writing process.
The friction in the commandline-compile-and-push stage seems to me like a
minor concern...because if it took you 20min. to 20 hours to write the post,
what difference does it make that it then takes 1 or even 10 minutes to push
the post to S3?

And consider one of the benefits of most static blogging implementations, in
which the writer can choose his/her text-editor of choice, which is especially
useful if you are using Markdown? Another useful feature is that with all of
the blog posts hosted as flat files, you can easily grep/replace across an
entire folder or even all of your posts, in a way that is significantly more
difficult in a database-backed site, in which you have to destructure the
schema.

What kind of idiot blogger would put something in a bunch of posts only to
later decide to grep/replace it all?...well, it could be something as simple
as someone wanting to add affiliate links to all their existing URL references
to Amazon pages? Or it doesn't have to be a replace function...sometimes I
want to use grep to find terms/concepts I've blogged about before (most search
utilities on dynamic blogs do not support regex).

My main blog is a self-hosted WordPress site. I'm OK with it but I find that
there's a lot of friction to just build out a post. This is my workflow:

1\. Draft and write a post in Sublime Text and Markdown

2\. Convert to HTML (self-hosted Wordpress does not yet have a Markdown
editor, and I'm loathe to install a plugin)

3\. Paste HTML into WordPress body

4\. Hit Publish

Simple enough, but it's almost never the case that my text is perfect...and so
now I have to either go back to the original Markdown file and restart the
steps, or edit the WordPress textbox which means that my canonical version of
the text now exists on WordPress.

And did I mention that WP is dog slow on shared hosting? I've setup caching,
which has allowed my site to stand up to the Reddit and HN front pages, but
when I'm editing/adding content, it can take 5 to 10 seconds to move between
the admin pages.

All of this friction means that I rarely update my own blog, even though I
have dozens of draft posts in my Dropbox in Markdown format...most of that is
because I just don't finish those drafts, but some of that negligence is
because the thought of logging into WordPress and going through the process of
simply publishing is enough to put me off.

On the other hand, I use Tumblr on a very regular basis, even though it's
simply to post photos and captions. Yes, part of my ease here is because I'm
just posting photos, but Tumblr's relative speed makes it a service I _want_
to post photos to...And of course, the tradeoff is now Tumblr owns all of my
content and I have an even harder time mass-managing it.

So it's all tradeoffs...the OP is right, but not right for many of the kinds
of people who have the expertise to build and deploy a static site.

