- 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.
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.
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).
Oh, you mean world-accessible PHP scripts. That's easy to fix by letting your webserver handle authentication to /admin.
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.
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.
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.
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
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.... :(
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.
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.
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
Wordpress can do this too, out of the box.
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.
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.
at now + 1day yourstaticgenerator.py
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.
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.
Maciej wrote about this recently - http://idlewords.com/2009/09/using_wordpress_to_generate_fla...
To me the biggest selling point for Wordpress is it's flexibility. I'm willing to take a performance hit for that.
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).
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.
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.
The only trick is to integrate that with comment forms and the like. But even that isn't too hard to code around.
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.
Disclaimer: I have a static generated blog.
Worked fine, I just didn't really like using Blogger.
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.
(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.)
Timestamps help alot if you're paranoid, also.
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.