Static site generators focus on the wrong thing

http://blog.pankajmore.in/static-site-generators-focus-on-the-wrong-thing

by blankverse • 12 years ago

57 98 12 years ago

blog.pankajmore.in

swanson• 12 years 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.

pdonis10• 12 years 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 .)

geekam2• 12 years 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

scott_karana3• 12 years 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...

pdonis10• 12 years ago

haven't makefiles had the same feature since the late 1970s?

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

phloxicon• 12 years ago

I'm really interested in that feature. Do you know which issue that is on the tracker?

geekam2• 12 years ago

Some work was done here : https://github.com/getpelican/pelican/issues/224#issuecommen...

coreymgilmore• 12 years 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• 12 years 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

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 is my favorite example.

prezjordan• 12 years 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

icebraining• 12 years ago

You own the copyright; I don't believe that's what rmorabia is talking about, though I may be mistaken.

pdonis10• 12 years 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• 12 years ago

If you're looking for a mix between svblte and Medium you might give http://www.postagon.com a shot.

resu_nimda• 12 years ago

What definition of "blogging" deals with ownership? Seems more like a personal issue with Medium on your end (which may even be unfounded?).

podman• 12 years 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• 12 years 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• 12 years 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• 12 years ago

I believe most static site generators are "blog oriented". And a blog is still a website.

smackfu2• 12 years ago

Yeah, Jekyll brags about being "blog-aware" whatever that means.

DigitalJack• 12 years 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/ , which is an impressiv elisting, so possibly I'll find something that fits my needs or gives me a starting point.

jcheng• 12 years 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/

mcguire• 12 years 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• 12 years 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.

0xdeadbeefbabe2• 12 years 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• 12 years 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• 12 years 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• 12 years 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

dreamfactory26• 12 years 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.

leephillips• 12 years ago

"live pages" equals "lots of hits to the database"

Is it common for people to set up a database backed website without caching? The framework I'm most familiar with, Django, will cache the results of database queries, so if, say, an article on the site becomes popular the database is hit once, and thousands of views are served from the cache.

Edit: Jweb_Guru, thanks for that clarification.

smackfu2• 12 years ago

Wordpress uses plugins for caching, last I checked.

Jweb_Guru• 12 years ago

That isn't true by default. Django will cache queries the first time they're executed for a particular request, but not in general for all requests. You can opt-in to caching pages thereafter in something like memcached, but that would be extremely questionable default behavior and a great way to cause consistency bugs.

ronaldx• 12 years ago

I agree with what you are saying, and I think this is perhaps the most important tradeoff that many CMS designs do not deal with properly.

This is particularly true of the current plethora of 'static site generators', many of which are not really improvements in any aspect.

If you build a static site, you can concentrate on making sure a rebuild is quick; if you build a dynamic site, you can concentrate on making sure the data structure is robust to scaling.

You might never be without these problems, but you can minimise them to the extent that they are no longer costing your users excessively.

It's not that we need to go back and forth: either solution could work perfectly fine for all but the heaviest sites.

jimktrains22• 12 years ago

I'm working on a new version of Gus[0] that will be able to figure out only what needs to be rebuilt and rebuild it.

Another feature for the (not to distant?) future will be generating a TF-IDF index in javascript so that a client-side search functionality could be introduced.

I also find Gus to have a pretty low bar to publishing. I write in markdown/textile/reStructuredText, build, and rsync. Granted I haven't used many other static generators (the ones I did look at didn't seem to have the features I wanted like tag or date indexes, plus it was one of my first python projects).

[0] https://github.com/jimktrains/gus

pdonis10• 12 years ago

figure out only what needs to be rebuilt and rebuild it.

I thought a number of SSGs already did this.

jacquesm7• 12 years ago

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.

diminish• 12 years ago

dynamic with caching (e.g. Varnish) is like static from security and response time perspective..but static has the advantage of local distributed fronts (cloudfront)... If we think, 99% of all blogs will be read less than 1000 times per day, the performance consideration does not matter.

reinhardt• 12 years ago

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.

elviejo• 12 years ago

I once made a static website with 12,000 articles. The key? * used a RAMDISK to generate the site and rsync to upload only the changed part to the server. * we also used JKL (a clone of jekyll in GoLang) * at some point we were doing 40 second compiles.

paulyg• 12 years ago

I agree with your assessment. To me the reason we keep ping-pnging between the two extremes is a lack of standardized and common caching mechanism. In a perfect world every web server would be behind an HTTP reverse proxy and we could just use HTTP headers to control caching. But there are a lot of quirks to that so unless you control the whole stack you don't have a proxy out front. And then you get into all other kinds of caching schemes: filesystem, memcache, redis, s3/cloudfront, etc. Which one you choose is determined by your tech stack, your PaaS, etc. Which the CMS creators have limited control over. If caching was a no brainer CMS creators could just concentrate on making the dynamic part good.

andybak2• 12 years ago

Agreed. Essentially SSGs are caching - or rather they are a way of pushing the caching problem down onto a lower level.

It's no different to 'clear the whole cache every time I change any content and store it all in memcached' - you're just substituting 'file-system' for 'memcached'.

Of course - SSG do solve another problem - that of needing complex software running on your server - you can run SSGs locally or on a centralized server - but that's not what is being discussed here.

VeejayRampay• 12 years ago

Not necessarily so. More and more, we're seeing rich-content in-browser website builders which allow customers to have their lunch and eat it. You get to customize and modify your page (optionally with WYSIWYG) online, publish it on the fly and have it generated and stored in cache somewhere in the blink of an eye. Just today, two web applications doing just that have hit the home page of HN.

It doesn't have to be either/or and I don't think the market really "oscillates" in that regard, in my opinion it will eventually provide users the best of both worlds (and maybe already does), at least for more or less static websites.

0xdeadbeefbabe2• 12 years ago

Speaking of swinging pendulums in content management systems and wrong things, don't you ever get sick of http(s)? Http gets it wrong in many ways too, but I don't hear much about alternatives.

design-of-homes• 12 years ago

I moved my blog from Wordpress to a static site but I'm actually thinking of returning to Wordpress. Wordpress gives you comments, RSS feeds, search, categorisation and mailing list subscriptions out of the box. I'm missing those features in my static site. I don't want to outsource comments to Disqus. And there are caching techniques you can use to speed up Wordpress.

I'm guessing most of the static site generators probably fulfilled the needs of the programmer who wrote them (which is totally fine and kudos to them for releasing their work so others could benefit). However, static site generators are not what you'd call "user-friendly" (in my view) unless you're comfortable with the command line and like markdown. (Wordpress isn't particulalry user-friendly either, but more so than static site generators in my opinion.)

jacquesm7• 12 years ago

Static can give you RSS feeds, and most of the other bits & pieces can be outsourced these days to parties that specialize in exactly that.

pdonis10• 12 years ago

it requires a "compilation"/"rebuilding" step that gets longer and longer as your site gets bigger

Unless the generator can keep track of what has and hasn't changed and only rebuild the changed stuff.

joshvm• 12 years ago

Obvious gotcha to that is if you have a link on every blog post to jump to the most recent entry. If you were going dynamic, that info would be inserted on page generation, if you're going static then you need to update everything.

Easy solution would be to make a duplicate page like /latest.html which updates as necessary.

drzaiusapelord• 12 years ago

CMS's won for a reason. I used to admin a Collage install, inherited from an acquisition. What a piece of shit that experience was for all involved. On top of it, everything dynamic had to be tacked on in a 90's web style with certain pages being dynamic, a bit for discussion, a different bit for login, a different bit for whatever, etc. A CMS is at least one system and these things are treated as plugins as opposed to 20 different vendors and whatever hackey scripting to keep everything talking to everything else. Even end users could see how rickety the whole production was. There's something to be said about a central monolithic structure with plugins vs a collection of scripts and html.

Deployment was usually frustrating and broke in non-obvious ways. Deploying a non-trivial Collage site was like gambling.

The experience of switching to Drupal was like night and day. Any bullshit concerns about performance were taken care of with just Varnish or a caching plugin. I can't imagine going back to an SSG and an ecosystem of disparate webapps to make it a usable website. Heck, even my side projects with Wordpress are like switching from a Model T to a Tesla compared to dealing with an SSG. Maybe SSG's are fun for sites with low requirements, but once you have a non-trivial set of features to support, then you're doing extra work and experiencing extra pain that a CMS wouldn't give you.

Also your coworkers wont be cursing your name after you leave them a patchwork of barely held together code in your wake to make the SSG based site do dynamic things CMS's find trivial. Especially if they come from a CMS background.

inthewoods2• 12 years ago

"Also your coworkers wont be cursing your name after you leave them a patchwork of barely held together code in your wake to make the SSG based site do dynamic things CMS's find trivial. Especially if they come from a CMS background."

Can you provide an example of something that CMS's find trivial that is difficult to do in an SSG?

winter_blue2• 12 years ago

Incremental compilation has been around for decades. I have a couple of scripts that generate static HTML pages for parts of my website, and I use *make -- and when I make a single change, only its corresponding page is updated. SSGs don't ever need to rebuild from scratch. Just leverage existing make/ninja/etc tools for your blog...

chadyj• 12 years 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

freejack• 12 years 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• 12 years 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.

spatten3• 12 years 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....

jacquesm7• 12 years 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)

spatten3• 12 years 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

spatten3• 12 years 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.

sitkack2• 12 years 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• 12 years 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• 12 years 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/m...

ojilles• 12 years 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-...

(Poorly implemented but works for me)

dreamfactory26• 12 years 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• 12 years 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.

sitkack2• 12 years 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• 12 years 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• 12 years 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• 12 years 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• 12 years 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• 12 years 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.

inthewoods2• 12 years ago

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

city41• 12 years 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/

[2]http://wintersmith.io/

fdik• 12 years 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

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

winter_blue2• 12 years 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• 12 years 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) 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.

tzakrajs• 12 years ago

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

Static site generators focus on the wrong thing

Related Stories