Hacker News Reader

Comment by mseebach | Hacker News Reader

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.

View on HN

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.

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.

Reply on news.ycombinator.com