We decided that Wordpress sucked for us. Then we stepped into static blogging with Pelican. Then we realized that static blogging kinda sucks too. Setting it up and the dearth of themes are rough.
Can you give us some feedback? We're still working on this together, and would love to hear what you guys think.
They appear to have tuned their servers and business model for static web sites - if they don't serve any of your files, you pay nothing. Otherwise, you pay only for what you use.
Disclaimer: I've never used their services, but I've checked them out from time to time.
Commenting is made possible with Disqus, the third-party comment system.
Search can be done using Google custom search. We're looking into better ways to do this.
Sites are updated using Markdown or LaTex.
We're looking at building hosting into this as well. For now, we're helping make it easier and pushing it to your FTP or S3 buckets.
I was looking for something which could run Markdown files from Dropbox (and pick the folder from which they are pulled.) I would also like to be able to make posts (or even the entire site) private if needed (publishing workflow.)
This post is a more comprehensive overview of what we're trying to do.
Point is, as wmeredith pointed out, he is well known among web designers/developers, created Svbtle (a competing blogging platform), and has been using that as his personal logo for as long as I can remember, maybe half a decade.
1) will actually beat static files in speed
2) you lose none of the flexibility of databases. In fact, because your effective query impact is going to be much smaller, you gain. Not in what can theoretically be done, but in what can be done practically without impact on response time, you gain a lot. Also expressivity gains (SQL is good, but it doesn't match general programming languages) (e.g. drawing a graph of "this person replies to this person and never replies to this other person" would be feasible).
I suppose there's problems too:
3) you lose that your state is always on-disk. In other words : there's a chance that you/your developer will get it wrong, but you won't notice it until your process restarts, which can be months.
4) of course, you have to start monitoring memory usage in these kinds of scenarios.
Now the tradeoff is that you can't have certain dynamic elements based on state unless you use a third party service (i.e. comments). But that's obvious.
1) you need to -at least- check the disk for updates. On linux, you need to update access time. This will take time. In memory has no such obligations.
2) you still need to compress the file in memory. You can cache the result of the compression, but that won't buy you much. Specifically it'll be too large to ... see point 3.
3) Because in practice pages are generated from very little data (the template is -way- shorter than the filled in sent out text), the ability to work with the data in little pieces without allocating large buffers in memory will avoid trampling the cache, which is going to get you an insurmountable advantage.
And this is ignoring the elephants in the room:
1) Because it's a static file, you'll have to send more data to the client side in total to achieve the same result (e.g. look at how GWT does it, and even there).
2) Because you still want to show customers "their" page, you'll need several more roundtrips to achieve the same with javascript that you wouldn't need with server pages (Note how one of the GWT pagespeed optimizations is to dynamically generate the page initialization data using the webserver to avoid an initial roundtrip).
3) Pure static files lose you a lot of features. Comments, scores, ... none of that. That may or may not be acceptable.
Also of note: HN uses the filesystem as a database (ie static files).
And frankly, the moment you hit virtual memory, you won't even get to 10 qps anymore without an SSD, and 100 with an SSD.
Static serving is a trivial optimization, and like all such things, it has huge qualifiers, and only works in the case it's intended for. It will only have a speed advantage in the obvious, simple case. As soon as you want to use any sort of dynamic element, extra round-trips will kill whatever advantage you thought you had. If you actually have large amounts of repeating elements (e.g. a table of some sort, article list, pagination, ... what have you), the extra memory usage will kill your advantage.
