Choosing a new direction in tech
For the last 10 years, Drupal has been my go-to tool to get great web sites built. However, it is clear to all but the true believers that time is ending. The total number of Drupal web sites peaked in early 2016. Even now, 3.5 years after D8 was launched, there are still 2.5 times as many sites running version 7 than version 8. Drupal has gone in a direction that does not suit sites built by most people, myself included. It is a great pity, as all the amazing ecosystem of code, developers and others that gathered around earlier versions of Drupal has been thrown away.
It becomes very difficult to build web sites when few others are using the same technology as the pool of people sharing solutions and contributing open source code shrinks. So by the start of 2018 the downward trend was very clear and I began casting around for where to go next.
Switching technology stack is a big investment for a developer as there can be a lot of learning involved and hitting peak productivity with new tools can take months or years. To keep the changes and re-learning to a minimum I tried out several tools related to or similar to Drupal. The first was Backdrop, a fork of Drupal 7. Under the hood it is practically identical to D7 so the transition was very easy and I spent a few weeks building a prototype for a startup with it. However, Backdrop is maintained by a very small team of developers and there is basically no ecosystem around it so by the end of that project it was clear that this path was not well travelled and leads to the wilderness.
With Backdrop ruled out, I tried other tools. SilverStripe has a New Zealand government-mandated monopoly on all work done for them so for developers based in Wellington it can be a lucrative niche. I’ve built a handful of sites with it over the years and took another run at it but it didn’t measure up. A tiny community, very little code available, dominated by one company.
I have resisted the pull of WordPress for many years. It is wildly popular for good reason but after this many years on the job the type of sites that WP is ideally suited for are no longer the type I want to build. But half a dozen jobs that were perfect for WordPress came up so I gave it a chance to see if much had improved in 2018. I even rebuilt this web site to use WordPress instead of Drupal. For small sites, such as this, it was fine. Unfortunately, the perennial problems with WordPress remain. It’s still cluttered, messy, insecure, often involving cowboy developers throwing together rubbish.
By now I was most of the way through 2018 and it was slowly dawning on me that I was going to need to get more drastic. The problem is deeper than just Drupal or Backdrop or WordPress – the problem is the CMS paradigm itself. Using a CMS usually means the first 80% of the build is very easy and the last 20% very very difficult. The resulting web sites, if they are anything non-trivial, tend to be bloated and buggy unless things are done “just right” which requires deep knowledge of the platform. Even though Drupal is written using PHP, most PHP developers would still need months or years to become proficient at it so finding developers tends to be difficult.
Casting a wider net, my attention turned to frameworks. A programming framework is a collection of building blocks whereas a CMS is more like a prefab house. It’s a bit slower to build houses if you start with blocks but a prefab house can never be a skyscraper. And if I was going to learn a new framework, why be restricted to just PHP? PHP is dying out while Python is up and coming, so a Python framework is probably a good bet. Plus, I’m just really tired of PHP’s ugly $ ; { } symbols.
For Python web development frameworks, there are really only two mainstream options, Django and Flask. By reading their web sites and browsing their documentation they both seemed very promising. The only way to be sure is to actually build something and the last thing I’d want to do is maroon a customer in an abandoned dead-end if it turned out badly (I learned that lesson in 2006 with a foray into Ruby on Rails!), so it’d be better to build something small for myself. So I dived into the documentation and built the demo projects outlined by both frameworks. They’re quite similar but Django felt too heavy, prescriptive and abstract. In contrast, Flask felt just right. Simple, straightforward and powerful.
With that choice, I started a major project using Flask – rebuilding a previous personal project of mine, ChoreBuster, using Flask and it’s going great!
