My favorite web development tools.
For this post I want to share some of my favorite web-application development tools. When I started thinking about this though, I realized there were so many, and which I use depends so much on what it is that I am trying to do, that I decided to take maybe a somewhat strange approach to this. I am going to approach it as a comparison on two sets of tools: python web development tools vs php CMS-es.
Over the years I have used plenty of tools, mainly in python, php and java to create web and desktop applications. All tools, frameworks and languages have their uses and pros and cons. None of them solve all problems. So you need to choose the tools that fit the problem, and you are good at using as well. Many other considerations come into play as well, like the size of the development team, history of the organization, other tools, etc. For this article I am assuming readers are in my own situation: that is small teams of developers or sometimes even single developers creating applications for people and organizations that need software that “just works”, users that don’t really know their requirements too well (so need flexibility) and don’t have too complicated and standardized work-flows that result in very complicated requirements. So I am not talking about the (multi) million dollar enterprise level development projects.
For me recently the choice when getting a problem that needed to be solved was: do I develop something myself from scratch, using my favorite python web-application frameworks and tools or do I implement something in an existing CMS, which is normally Drupal. So those are the tools this article will be about and when to use either of them. I don’t think these tools are often discussed together.
Drupal
I have been using Drupal (and other PHP CMS-es like Wordpress, Joomla, Typo3 and others that I can’t remember the names of anymore) for many years. I was even stupid enough at one point to write my own CMS in PHP. In the end Drupal floated to the surface as my favorite (although Wordpress has it’s uses too, that are just different from Drupal’s). As a developer I don’t like PHP at all. When I started with PHP it made it easier for you to make a mess of things than to write good code. Later with the newer incarnations the lack of structure has become less of a problem with a decent implementation of Object Oriented Programming, but as such it is moving more and more in the direction that Java is already occupying. Still, PHP and MySQL run on almost every web server in the world, and as such are used by millions of people. So naturally, there are some awesome developers out there that made really cool tools, also in PHP. Drupal is one of them.
As a CMS it is often badly understood though. Many web designers are frustrated with Drupal, and talk about the steep learning curve, resulting in hilarious images like these: 
.
If you are a graphical designer or web designer that just wants to create a website for a company, find and change an existing theme, including all it’s added functionality, do the SEO and get it over with, you might be better off looking at Wordpress. Although, maybe Drupal 8 might have changed that quite a bit. Drupal on the other hand is great for situations where you want to create different content types with custom fields and forms, and represent those in different ways on different locations on your website without writing a single line of code or duplicating content. Drupal accomplishes this with it’s fields, entities, views, blocks, etc. It is incredibly flexible and allows you to create content heavy sites with strict separation of form (design) and function. If you know Drupal, it is great for any website. If you don’t know it yet, but need to create content heavy sites with content that is more than just a blog post or page, it pays to go through the learning curve. With it’s enormous list of modules, you can create so many different types of websites it often is the only hammer you need. Personally I have used it to create intranet sites, simple project management tools, an internal Evernote alternative, a scientific literature library, wiki, web-shop and of course simple websites. To me Drupal is great for those situations when the functionality you need is already created by someone else. In that case you benefit from the huge set of pre-existing modules, allowing you to improve your site in ways you hadn’t even though of. You don’t need to develop a whole user interface, social media integration, CRUD interface, etc. Most of the drupal “sites” I have created have been done without ever writing a single line of (PHP) code.
If on the other hand, the web-application or site you need to develop mostly contains custom logic that isn’t directly covered by a Drupal module, and very little functionality is needed that is a standard part of most CMS-es, and/or your application/site is a purely internal one that is used by few people, you might be better off developing something from scratch. The reason is that any flexible CMS, development framework or other software tool that is meant to be used in many different situations and tries to take as much work from you as possible, tends to require a lot of boilerplate code to get started. Writing even a simple Drupal module requires a lot of lines. And then to create the separation between form and function that makes Drupal great, you need to work your way through a lot of API documentation and hooks to find out where your functionality should tie in to Drupals. All in all, it tends to get in your way of quickly writing code for some new functionality. This is not just the case for Drupal. Other CMS-es get in your way even more, so much so that their limited scope might prevent you from doing what you want. This is where for me Python and it’s web development frameworks come in.
Python and Flask
I have actively developed applications in about 5 different Python frameworks over the years and had a good look at quite a few more. Right now Flask is my favorite. There are multiple reasons for that choice. I will go over the most important considerations briefly, but if you want to know more, googling will turn up quite a lot of good articles on all of them.
For me the reason to choose a python web-development framework is that with very few lines of code you can accomplish a lot. You don’t need to read large amounts of documentation to get started. Web.py is a great example of this that really allows you to create an application with just one file and a few lines of code.
The downside of this is that it doesn’t offer much in the way of structure for your code, so as a developer you need to know how you want to structure your code and be disciplined about it. Furthermore web.py doesn’t seem to be very actively developed anymore. This made me move away from it recently.
On the other side of the spectrum are Turbogears, Pylons and Pyramid. I used Turbogears and pylons a lot in the past for large amounts of customers. They do offer structure to the developer out-of-the-box which means they require quite a lot of boilerplate code to get started and have a lot of “magic” going on behind the scenes. This does mean they take work away from the developer which is great but if you need to deviate from “their” way of doing things, the framework might get in your way. Furthermore the developers seem to keep turning corners which means that Turbogears was merged with Pylons and later abandoned and Pylons is superseded by Pyramid. If your framework includes a lot of boilerplate code and framework specific magic this is quite annoying because you are left with the choice to either spend a lot of time on migrating or continue developing based on an abandoned framework. This problem didn’t exist with my recent move from web.py to Flask which both introduce relatively little “magic”, so most of my code could be moved without many problems.
From the beginning I have chosen not to use Django for a very specific reason and that is that Django takes an “our way or the highway” approach. They kind of force you to use everything as developed by Django. This means that you either use their templating system, their object-relational-mapper, etc. If you prefer another one for whatever reason, you can’t really use it. The other frameworks usually give you more freedom of choice. I especially like SQLAlchemy as an object-relational-mapper and Django uses its own. The second problem with Django’s approach is that if you ever have to move away from Django, you have to rewrite a lot of code. Don’t get me wrong though, I don’t think Django is a bad framework at all. “The Django way” is quite a good way actually and it works well for many people. I just like to be able to keep my options open.
So that left me with Flask as my first choice now (I can’t remember the reason for not choosing Bottle). It has very little magic going on (and is clear on where it does), doesn’t enforce a rigid structure but does suggest a proper way of doing things in the docs, which is easy to follow. When moving an application from web.py to Flask it took very little time as I could still use most of my code unmodified. Development has been a lot quicker since and it makes Test Driven Development easy.
There are disadvantages though of using any of the python web development frameworks though. For me the biggest one is spending a lot of time on the interface side. If you use a CMS like Drupal you just need to do some HTML/CSS theming to make your site/app look the way you want. The actual interface is already there and works great. When you develop things from scratch based on any development framework, you need to develop you interface from scratch as well. For me this means spending quite a lot of time on JQuery. I try to make the applications intuitive, which often means a lot of JavaScript and Ajax (well, usually using JSON instead of XML). Flask does make RESTful application development easy, which allows me to separate the interface development from the backend as much as possible. Still, it is not my favorite job.
So there you have it. This my two cents on choosing the right tool for the job.