Why to use a static site generator instead of Wordpress | Hacker News Reader

Why to use a static site generator instead of Wordpress

guestlistapp.com

120 pointsoneplusone64 comments

Why NOT to use a static site generator instead of Wordpress:

- You can't update your blog unless you have a computer with the right toolchain available. That includes uploading a cute photo from your smartphone.

- You can't do delayed posts.

- You can't have local comments (you can have disqus or similar, but then comments aren't part of your page, and won't show up in searches). Pingbacks won't work.

- You probably don't need fast. Wordpress + WPcache is really fast.

If your static site does any of this, it's not static, it's a dynamic site that uses the filesystem rather than a DB for storage -- which might very well be clever, but that's not what's being argued.

Actually, you could get around the delayed posts thing. With Webby, you can specify which posts are indexed. It'd be easy to make it only publish posts if they're in the past rather than in the future (via the post date field or some other custom field). Then just run the generator automatically every hour from a cron job somewhere and you've got delayed posts.

Also, as far as I know, disqus supports trackbacks (not sure what the difference is between that and pingbacks though).

Finally, re: speed, if you get slashdotted, WPCache will still struggle. Nginx serving static files, otoh, won't even skip a beat at 100 hits a second, even on a very small VM.

WP-Supercache will cache the blog posts as static file by default. So why would it struggle ?

> If your static site does any of this, it's not static, it's a dynamic site that uses the filesystem rather than a DB for storage -- which might very well be clever, but that's not what's being argued.

Is it ? The post sounded like it was against fully dynamic CMSes, not "sites that have any dynamic feature".

It really boils down to what you choose to optimize : security, read performance, write performance, write convenience or fancy features. Depending on the usage, some criteria don't matter at all, others are critical.

Static sites (and the CMSes which generate them) are at one end of the spectrum, optimizing security and read performance while leaving the rest behind. Fully dynamic sites (and the CMSes behind them) are almost the inverse. You can compromise and fall somewhere in between.

I don't see how you can compromise. If you're just a little dynamic, then you still need to bring in a software interpreter to process the page (this is a point in the article). You also immediately lose the security of static files. To get the benefit of static files, you have to go all in -- otherwise, you might as well just be using a CMS that caches.

I highly doubt a little script written in Haskell and comprehensively tested with quickcheck lacks security like a full blown PHP/mySQL stack. Likewise, a litle super-optimized C filter is probably more efficient than a PHP interpreter, even with cache. If I'm wrong, it's because the cgi mechanism is as inefficient and insecure as a full dynamic framework.

Um.. Why cant the blog be static and have a dynamic webapp hanging off /admin/ which operates as a static site generator? The only difference would be that a program on the web server creates the static files and copies them to the correct directories, instead of a local program creating the static files and copying them to the correct directories.

Edit: I should clarify that I am refering to programs that create static html files. I read the story as dynamic == generates html from some other stored format, be it database or flat files in rst.

That's how Movable Type used to work. People complained how it took forever to regenerate a big site on a shared host.

The question is: When do you generate the files? Regenerating a large number of file every time you modify something is just bad design (much like regenerating every time a document gets requested). You're better off having a tiny script on each page that checks for modifications when requested and rebuilds if needed (to avoid scripting on the front-end you can use <img> to rebuild for the second request). Alternatives would be to have background processing or batch modifications.

Angerwhale basically does this. Every page has dependencies, and when the page is requested, it is served from cache unless the dependencies have changed. Otherwise, it is regenerated.

Yes, this is not as efficient as static files, but you can drop a file in your directory and it will render as a blog post as soon as someone wants to read it (or a page that links to it somewhere).

Isn't that the whole concept behind caching+sweepers in Rails?

Drupal can also do this with the Boost module. Boost is very similar to WP-Supercache, except it has a multi process crawler to push the site out faster and some fairly smart cache expiration settings. Also caches AJAX & XML & Pages with URL variables. GPL2 - http://drupal.org/project/boost

One of the reasons listed was better security by having no code executed on the server. That argument falls apart if you're willing to have some code running.

The webserver and OS are not code?

Oh, you mean world-accessible PHP scripts. That's easy to fix by letting your webserver handle authentication to /admin.

Code that has write-permission to anything fancy.

I'm in pedantic territory here, I don't particularly mind the idea of generating static files. My personal opinion is that having a dynamic frontend with fast caching for the most popular views is a better solution for that vast majority of CMS/blog (ie: dynamic) sites out there.

What I do mind, are "I use semi-obscure technology X, here's why X is better than established, proven and hugely popular technology Y in every conceivable way" style ego-boosting articles. I'd rather read a show and tell about how this technology solved a real-life problem for you. I also enjoy the honesty of acknowledging the shortcomings.

Nah, sorry. You're taking the logic here too far. Having no code accessible pre-auth is a huge win. Only having to worry about the authentication attack surface is a drastic improvement over Wordpress, which stores admin accounts in the same database table as anonymous blog commenters.

Jeff Atwood uses Movable Type for the same reason: it can pump out static HTML. This makes a lot of sense, get rid of the moving parts, and your site will be faster. It's also nice to have be able use your own text editor. Its great to have it under source control also!

Here's an idea: You could use this in conjunction with Dropbox and a custom workflow to automatically update your blog from the road without access to your home machine (I'm think OS X folder actions would work well here)

Related Coding Horror post:http://www.codinghorror.com/blog/archives/001291.html

Movable Type is great :D

You will see more things like this happening in the future. My site, http://ourdoings.com/ already lets you use dropbox to upload photos. It automatically makes a skeleton blog backdated by the date the photos were taken, so you can just throw all your photos into a dropbox folder, and when you have connectivity they get uploaded and organized. A guy just told me the other day he wished he'd had this during his 5.5+-year sailing trip. http://ourdoings.com/sailingtripphotos/

> It's also nice to have be able use your own text editor.

There is, for example, a FireFox plugin to let you edit a text-area in any text editor. It's called It's all Text: https://addons.mozilla.org/en-US/firefox/addon/4125

I use it to pop up a Vim window any time I'm editing a lot of text or doing heavy formatting.

>It's also nice to have be able use your own text editor.

It's also nice to be able to use your own text editor.

I really need to proof-read better. I always rethink a sentence half way through and leave artifacts.... :(

This is exactly what I use for http://danieltenner.com (well, almost - I use Webby, not Jekyll). In fact, I've made the source code for that available here, if anyone's interested:

http://github.com/swombat/danieltenner.com

Deploying like this has another advantage: you can deploy to a subdirectory of an existing app. The benefit of that is simple: pagerank transfers better from mysite.com/blog to mysite.com (since they are considered to be the same site) than from blog.mysite.com to mysite.com (since they are considered to be two different sites).

Edit: I should add that there is one disadvantage to this approach. If you have non-technical members on your team, and you want to encourage them to blog as well, making them learn to use Textile formatting and command line tools is not a great encouragement.

Kudos on having the best interface for reading I have ever seen on a blog. Yours is the only website I've ever seen that Readability makes less readable.

Hehe, thanks :-)

That was one of my tests actually, to know when the design was right - if Readability makes it better, then it still needs improvement!

Of course, that hasn't stopped some people complaining about the font size... you can't please everybody I guess :-P

> Deploying like this has another advantage: you can deploy to a subdirectory of an existing app.

Wordpress can do this too, out of the box.

Even on a Rails server?

Sure.

Passenger can do this in a nearly-painfree fashion, and thin/mongrel/unicorn/webrick(heh) can do this by simply not having your webserver use them for that directory.

I also do this, with a custom python script. Yeah, there are disadvantages, but right now I love its simplicity. I don't have to worry about keeping Wordpress updated; I just make a new static file and run the update script.

If my needs ever change (needing more than static files provide), I'll probably put in a simple Python web server, but still use the static files to edit my content. Eh, we'll see. What I have now works, and I like it -- and that's all that's important.

EDIT: In other words, the best part about a static site isn't that you don't need a web server to grab the content. It's that you have all of your blog posts, right there, in plaintext format. They're tangible and easily migratable into any future format.

When the time comes to have dynamic comments, timed posts, and other features like that, you can write a tiny Python/Ruby web server that generates HTML for you to handle some of the simpler tasks. BUT:

If you have Wordpress-like requirements, use Wordpress.

If you don't, a static blog can be a real joy to work with.

If you want a couple small niceties that a static blog can't have (delayed posts, etc), shove a quick homemade webserver in front.

And in either of those cases, if you are doing more work than you wanted, switch to an easier option. Making a static blog can sometimes be an easy, low-mental-energy hobby project to work on, even if you reinvent the wheel just a little.

I'm also using a custom Python script to generate my blog (http://journal.uggedal.com). It can be found here: http://github.com/uggedal/reprise

Delayed posts:

    at now + 1day yourstaticgenerator.py

Isn't this obvious? We have a really good toolchain for dealing with filesystems. The toolchain for dealing with content in databases is not nearly as good. As a result static content should be kept in the filesystem, even if you have to play tricks to do it.

The use case for web pages created dynamically out of the database is user generated content. There our existing toolchain doesn't matter because users don't get access to your filesystem so you have to create new tools anyways. And a database makes it easier to keep data structured, takes care of transactional mechanics, and has good tools for things like failing over in event of a machine crash.

Seriously we had a build/compilation step as part of deployment back in the first website I ever worked on. We didn't use a CMS to do it though, we used a homegrown templating system (later changed to Template Toolkit) and a Makefile.

There is a Firefox plugin called "It's all Text!" that puts a little edit button at the bottom of every multiline text widget. This button fires up your favorite text editor, and when you save it writes the text back into that text widget.

I replied to another post with this before finding yours.

One thing we programmers ought to recognize is that it really is all text. From the moment we type on our keyboard to the time it's viewed in the reader's browser. If we separate our presentation layer (like HTML rendering) from our content layer (the actual text with some annotations for things like headers), we are free to edit the content as we see fit and then we can port it into any presentation layer, from a text editor to a blog.

Also, you could always just edit in your favorite editor and then copy and paste, no? Or write a script to take a bunch of flat files and inject them into your database.

Markdown

Copy and paste isn't that reliable, I've had lots of little annoyances with line breaks and other formatting issues.

Tom's post on Jekyll - http://tom.preston-werner.com/2008/11/17/blogging-like-a-hac...

Maciej wrote about this recently - http://idlewords.com/2009/09/using_wordpress_to_generate_fla...

With the addition of a plugin or two and a sane Apache configuration, Wordpress can handle some pretty extreme loads. This is not to say that it's perfect, but rather that performance doesn't have to be a concern if you know what you're doing.

To me the biggest selling point for Wordpress is it's flexibility. I'm willing to take a performance hit for that.

I was hoping that this would direct to a could not connect to database page.

It's a neat way of working - but it does leave you with limited functionality.

I've gone entirely the other way - my blog is http://andrewducker.livejournal.com - everything is database driven and there's no static content at all.

Which, I'm sure, is slower - but it also makes updates to the layout (for instance) faster, as you're not having to regenerate the entire site. Plus, of course, you get huge wodges of functionality, like the commenting system (which is the best I've seen anywwhere).

LiveJournal's hardly a fair counterpoint -- it's a massive site with a complex, highly-tuned architecture, designed to be as fast as a dynamic, database-backed site can be:

http://www.slideshare.net/vishnu/livejournals-backend-a-hist...

Most people who install Wordpress are doing it on a modest shared server or VPS. The point of the article is the benefits of baking and serving static files for these folks are greater than the potential risks of having a single Apache + mod_php + MySQL instance keel over under heavy load.

That was kinda my point. The middle ground doesn't hold much benefit (as far as I can see) - you have to manage the complexity yourself and it's risky. I'd either want a simple system that's not goint to blow up on me (i.e. static files) or I want a fully functional system that's run by someone else (i.e. livejournal).

I recently migrated my WP.org blog to WP.com because of this. Now I feel safe.

Nevertheless, I publish my personal site using Emacs' Org-mode and if I were to start a blog from scratch I would use something like org-mode or jekyll.

Probably because I need the feeling of being in control of my data.

I hate to tell you, but you can have some of the best of both worlds, as other commenters have pointed out: WP SuperCache (see http://ocaoimh.ie/wp-super-cache/ ) serves static pages. Unless you update 20+ times per day, it probably doesn't matter that the site takes a minute to rebuild after posting.

Does anybody know how to export WP posts to plain text files? Maybe a script that reads the export.xml file.

IIRC Jekyll has a WordPres importer, which I presume does something similar.

This is an excellent idea--no program other than basic web server talks to the internet--just static files.

I've thought an idea like this could be used for more than just a blog (and maybe it is in certain cases). Rather than pulling up the pages every time, have a build process merge content and a template to form HTML pages. It could be used on sites that are potentially huge, but render an ultra-fast site with thousands of pages.

The only trick is to integrate that with comment forms and the like. But even that isn't too hard to code around.

I'm currently making a dynamic rewrite of a legacy CMS written to generate static files. The static CMS is a huge PITA. Yeah you can slip dynamic features in there 'just' where you need them. What you wind up with is a mess, and once your site gets a lot of content you start generating a LOT of files. Our rebuild process can take a couple hours, and while it does that it's pegging the disk.

There's nothing wrong with static sites, for something like a blog it's OK. The feature set is fairly limited. But once you do want to add dynamic stuff, it can get tricky. I'd say for most projects starting with a static generator is a mistake because unless you know for sure the requirements won't change you can easily paint yourself into a corner.

Also see tools like R3 - http://developer.yahoo.com/r3/

I'll throw in my two cents: 99% of the blogs change no more than once a day. What is the point of needless complexity, databases, settings, etc. I like simple, single script that rewrites my content for the web since I still have my content on disk. I can easily grep for content.

Disclaimer: I have a static generated blog.

I would be interested to see a follow up post after the honeymoon phase ends. I switched from WP to webby, loved it at first, but will be reverting soon. Static is faster, but php is fast enough for most blogs, and WP is full featured.

We have been using it for about 3ish months now and have not run into any issues. It is conceivable that the blog would eventually move over to a real CMS (not wordpress) once we have a need for dynamic content, but the website will stay static for the foreseeable future.

Same thing, but I switched from WordPress to webby to Movable Type. It's somehow easier for me to make posts in MarsEdit and publish them immediately rather than creating a new text file in TextMate, writing, then going to terminal to type "webby deploy".

I used to use Blogger this way - you would give them your FTP info and it would publish static files.

Worked fine, I just didn't really like using Blogger.

Anybody remember City Desk? I loved it http://www.fogcreek.com/CityDesk/

pyblosxom can run dynamically or be used as a static renderer. The same input files are used for both so you can start with static rendered content uploaded to your web server, and then easily migrate to running dynamically. I use it both ways, works good.

ikiwiki (http://ikiwiki.info/) as static site generator looks cool to me.

bytepawn.com and blog.scalien.com are also generated by bash scripts.

The real problem here is PHP/MySQL, not the dynamicism per se.

A blogging platform based on Rhino (EcmaScript) on JVM hosted on virtualized server (or in cloud) would easily resist slashdot effect.

And using file-based storage it would be storage-friendly, too.

And nobody prevents you from using external editor for WordPress, even.

File-based storage may be "storage-friendly", but it isn't retrieval-friendly. For example, finding the list of all tags your blog uses requires a linear scan over every document in the system. Not fast. (Visit http://blog.jrock.us/. It does this. It takes a long time to load.)

You can cache cache that in-memory! Because you've got a persistent app server.

How do you know when to invalidate the cache without doing a scan over all the files?

(Answer: hope your filesystem updates the directory change time when a file inside changes, or that your app server is inotify-ed of the change. Both are more complicated than querying a database.

If I used KiokuDB for Angerwhale, it would only take me one key lookup for things that currently involve traversing the directory tree. Caching is nice, but it is not the solution to all problems.)

You know when you update your data. Therefore, you invalidate your cache when you update your data.

Timestamps help alot if you're paranoid, also.

what? a (dynamic) cms resist /. easily on a virtualized host? can you please explain it more?

Why not? Serving pages fully off cache.

How many hits per second is slashdot effect? We could count.

I think slashdot effect mostly happens because database (mysql, generally) locks down, and we're removing that bottleneck by going into file-based storage and in-memory caching.

Reply on news.ycombinator.com