
Why to use a static site generator instead of Wordpress - oneplusone
http://www.guestlistapp.com/blog/2009/10/21/5-reasons-to-use-a-static-site-generator-instead-of-wordpress.html
======
mseebach
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.

~~~
sophacles
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.

~~~
mseebach
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.

~~~
jrockway
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.

~~~
mseebach
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.

------
phsr
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>

~~~
brlewis
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/>

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

~~~
DanielStraight
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.

~~~
swombat
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

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

~~~
uggedal
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

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

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

~~~
Periodic
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.

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

------
prakash
Tom's post on Jekyll - [http://tom.preston-werner.com/2008/11/17/blogging-
like-a-hac...](http://tom.preston-werner.com/2008/11/17/blogging-like-a-
hacker.html)

Maciej wrote about this recently -
[http://idlewords.com/2009/09/using_wordpress_to_generate_fla...](http://idlewords.com/2009/09/using_wordpress_to_generate_flat_files.htm)

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

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

------
AndrewDucker
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).

~~~
paulsmith
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...](http://www.slideshare.net/vishnu/livejournals-backend-a-history-of-
scaling)

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.

~~~
AndrewDucker
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).

~~~
pqs
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.

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

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

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

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

~~~
dabent
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.

~~~
andrewvc
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.

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

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

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

~~~
oneplusone
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.

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

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

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

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

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

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

~~~
jrockway
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.)

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

~~~
jrockway
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.)

~~~
ilyak
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.

