8 ms·

Static site generators focus on the wrong thing

57 points by blankverse 12y ago

swanson 12y ago
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 12y ago
  > 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 .)
geekam 12y ago
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 12y ago
  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 12y ago
    > haven't makefiles had the same feature since the late 1970s? Sure, if you're willing to use make as your SSG. :-)
    - scott_karana 12y ago
      Nothing prevents you from using make (or rake) to invoke an SSG... :-)
      - pdonis 12y ago
        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 12y ago
        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. :)
- phloxicon 12y ago
  I'm really interested in that feature. Do you know which issue that is on the tracker?
  - geekam 12y ago
    Some work was done here : https://github.com/getpelican/pelican/issues/224#issuecomment-34637913 https://github.com/getpelican/pelican/issues/224#issuecommen...
coreymgilmore 12y ago
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.
rmorabia 12y ago
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 12y ago
  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
  - icebraining 12y ago
    You own the copyright; I don't believe that's what rmorabia is talking about, though I may be mistaken.
  - pdonis 12y ago
    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.
- marban 12y ago
  If you're looking for a mix between svblte and Medium you might give http://www.postagon.com http://www.postagon.com a shot.
podman 12y ago
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 12y ago
  > 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.
dminor 12y ago
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.
- Vaskivo 12y ago
  I believe most static site generators are "blog oriented". And a blog is still a website.
  - smackfu 12y ago
    Yeah, Jekyll brags about being "blog-aware" whatever that means.
- DigitalJack 12y ago
  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 12y ago
    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/
mcguire 12y ago
"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.
smutticus 12y ago
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 12y ago
  Wait, were there days when software bloat didn't happen? I think feature creep and accompanying bloat is human nature for all time.
  - keithpeter 12y ago
    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.
smacktoward 12y ago
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.
- joshcrews 12y ago
  You can get the best of both by using a dynamic site CMS, and then hooking it up to Amazon Cloudfront to cache your html. The only challenge then is page cache expiration. You can set that by either using the http headers for Cache-Control or setting page rules in Cloudfront's admin. Such a setup will scale like crazy and skip "compilation" steps
  - dreamfactory2 12y ago
    The challenge isn't page caching but object caching and rendering. SSGs are just a rerun of the 90's and don't solve anything that Varnish doesn't already. Pages are an increasingly quaint notion on an increasingly dynamic, personalised, multi-device web. Time to publish is ever more important as Google SEO measures news sources in minutes and publishing workflows often require instant publishing and internal search where there are handoffs (e.g. a subeditor and picture desk). The two real problems I see is that ESI is our best solution to rendering (and is a clunky 90s-style design), and that object cache refresh has a tendency to combinatorial explosion.
chadyj 12y ago
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
freejack 12y ago
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.
danso 12y ago
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.
spatten 12y ago
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.html http://scottpatten.ca/2011/11/speeding-up-jekyll-generation....
- jacquesm 12y ago
  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 12y ago
    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 12y ago
      Pity! Still, thanks for the tip (I can see one usecase for which it is handy, proofreading).
spatten 12y ago
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 12y ago
  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.
falcolas 12y ago
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 12y ago
  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/master/Rakefile https://github.com/prakhar1989/prakhar1989.github.com/blob/m...
  - ojilles 12y ago
    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-test.sh https://github.com/ojilles/jilles.net/blob/master/_bin/wget-... (Poorly implemented but works for me)
dreamfactory2 12y ago
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.
rschuetzler 12y ago
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 12y ago
  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 12y ago
    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.
fideloper 12y ago
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".
zzzeek 12y ago
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 12y ago
  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.
kiyoto 12y ago
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 12y ago
  I agree on security - I'm sick of updating Drupal and Wordpress for different security holes.
city41 12y ago
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/
fdik 12y ago
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.
winter_blue 12y ago
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.
h4ckth3pl4n3t 12y ago
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.
kiriappeee 12y ago
This is bizzarely coincidental. I've been at a hackathon for the last 14 hours and I'm working on a static blog based cms. All the benefits of having a CMS with the output of a blazingly fast and stable static website. Will be open sourcing it when it gets to version "CRUD ready"
tzakrajs 12y ago
Seems like a CMS that generates static pages would be the best of both worlds.

57 points by blankverse 12y ago

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 12y ago
> 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 .)

geekam 12y ago

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 12y ago
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 12y ago
  > haven't makefiles had the same feature since the late 1970s? Sure, if you're willing to use make as your SSG. :-)
  - scott_karana 12y ago
    Nothing prevents you from using make (or rake) to invoke an SSG... :-)
    - pdonis 12y ago
      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 12y ago
        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. :)
phloxicon 12y ago
I'm really interested in that feature. Do you know which issue that is on the tracker?
- geekam 12y ago
  Some work was done here : https://github.com/getpelican/pelican/issues/224#issuecomment-34637913 https://github.com/getpelican/pelican/issues/224#issuecommen...

coreymgilmore 12y ago

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.

rmorabia 12y ago

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 12y ago
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
- icebraining 12y ago
  You own the copyright; I don't believe that's what rmorabia is talking about, though I may be mistaken.
- pdonis 12y ago
  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.
marban 12y ago
If you're looking for a mix between svblte and Medium you might give http://www.postagon.com http://www.postagon.com a shot.

podman 12y ago

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 12y ago
> 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.

dminor 12y ago

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.

Vaskivo 12y ago
I believe most static site generators are "blog oriented". And a blog is still a website.
- smackfu 12y ago
  Yeah, Jekyll brags about being "blog-aware" whatever that means.
DigitalJack 12y ago
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 12y ago
  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/

mcguire 12y ago

"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.

smutticus 12y ago

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 12y ago
Wait, were there days when software bloat didn't happen? I think feature creep and accompanying bloat is human nature for all time.
- keithpeter 12y ago
  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.

smacktoward 12y ago

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.

joshcrews 12y ago
You can get the best of both by using a dynamic site CMS, and then hooking it up to Amazon Cloudfront to cache your html. The only challenge then is page cache expiration. You can set that by either using the http headers for Cache-Control or setting page rules in Cloudfront's admin. Such a setup will scale like crazy and skip "compilation" steps
- dreamfactory2 12y ago
  The challenge isn't page caching but object caching and rendering. SSGs are just a rerun of the 90's and don't solve anything that Varnish doesn't already. Pages are an increasingly quaint notion on an increasingly dynamic, personalised, multi-device web. Time to publish is ever more important as Google SEO measures news sources in minutes and publishing workflows often require instant publishing and internal search where there are handoffs (e.g. a subeditor and picture desk). The two real problems I see is that ESI is our best solution to rendering (and is a clunky 90s-style design), and that object cache refresh has a tendency to combinatorial explosion.

chadyj 12y ago

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

freejack 12y ago

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.

danso 12y ago

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.

spatten 12y ago

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.html http://scottpatten.ca/2011/11/speeding-up-jekyll-generation....

jacquesm 12y ago
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 12y ago
  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 12y ago
    Pity! Still, thanks for the tip (I can see one usecase for which it is handy, proofreading).

spatten 12y ago

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 12y ago
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.

falcolas 12y ago

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 12y ago
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/master/Rakefile https://github.com/prakhar1989/prakhar1989.github.com/blob/m...
- ojilles 12y ago
  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-test.sh https://github.com/ojilles/jilles.net/blob/master/_bin/wget-... (Poorly implemented but works for me)

dreamfactory2 12y ago

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.

rschuetzler 12y ago

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 12y ago
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 12y ago
  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.

fideloper 12y ago

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".

zzzeek 12y ago

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 12y ago
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.

kiyoto 12y ago

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 12y ago
I agree on security - I'm sick of updating Drupal and Wordpress for different security holes.

city41 12y ago

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/

fdik 12y ago

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.

winter_blue 12y ago

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.

h4ckth3pl4n3t 12y ago

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.

kiriappeee 12y ago

This is bizzarely coincidental. I've been at a hackathon for the last 14 hours and I'm working on a static blog based cms. All the benefits of having a CMS with the output of a blazingly fast and stable static website. Will be open sourcing it when it gets to version "CRUD ready"

tzakrajs 12y ago

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