Leaving Tumblr, Writing Again

Sure, I agree that a relational database *can* do it, the problem with doing it that way in this instance is that you would lose most of the flexibility that WordPress gives you. I think in reality the reason why WordPress is so popular, even amongst developers who are more than capable of writing their own or using far more specialised tools (I love RefineryCMS, and use it a lot with clients), is that it is so easy. A couple of clicks here and there, and suddenly you’ve got another massive chunk of functionality. Sure, it comes at the cost of performance, but it’s just so stress-free.

I’m still amazed that any web based community thinks that a 2-10sec+ load time is ok for a normal blog page, because it’ll all get covered by the caching engine so end users shouldn’t ever experience it, but since I’ve joined the club I shouldn’t really bitch. The concept is brilliant – it’s probably empowered more end users to experiment and try and improve their web presences than any other software, but the execution shows that its a 3rd generation implementation of spaghetticode. If I had the time I’d love to rewrite it in MVC, probably in Node with a MongoDB (or Riak) backend – you could keep 95% of the ease of installation etc, and give it a colossal performance boost.

However bad WordPress’ application design is, it can’t even come close to competing with Magento as a ridiculous, mind-bogglingly bad concept. I recently consulted on a client’s e-commerce site to try and speed it up, and was stunned to find that it was running 1000ish queries per page, many of them duplicates. I’m not a fan of EAV, it seems inherently stupid, but this database diagram genuinely takes the prize for the biggest overcomplication in database design history – unless you can beat it?