Web-programmer Eric Harrison talks about the unmet promises of frameworks:
These frameworks all promise rapid development through pre-built methods and APIs that take me from Point A (the idea of the app I have to build) to Point B (the finished product). The problem I’ve found is that in the applications I need to build, Point B is never where I need to go. For example, let’s say that I’m building a Content Management System for work. The application flow looks something like this:
- User views a page that has tabular data retrieved from the database.
- User clicks on a record in that table to pull up a form to edit that data.
- Application retrieves data from database, displays it in a form.
- User edits the data, clicks Save.
- Application takes the data from the request, checks the validity, then stores the data in the database.
- [Repeat as needed]
Pretty simple workflow, and is often one of the things that these frameworks are built to handle. They’ll have ActiveRecord interfaces to automatically understand the data in the database. The framework will have a magic tabular output mechanism to take the list of records and make a large HTML table and display all of the data. The framework will also have some magic methods to create a form that is linked to the ActiveRecord entity and handle all the data validation and processing.
This all works great… as long as your application has a single table with a very strict set of rules. As soon as you add relationships between multiple tables and crazy business logic (which exists in every single application I’ve ever built), these frameworks start to fall apart. You then spend hours poring through documentation figuring out how to extend the ActiveRecord class with your own ActiveRecordSpecialTable class that handles the many-to-many relationships. Then you have to dive in to the output mechanisms and figure out how to trick the framework into displaying an edit form with data from multiple sources. And so on, and so forth. Forever.
Meanwhile, by merely applying your years of web development experience, you could have made two simple scripts. One to display tabular data and one to display a form. You could have quickly crafted a back end script to pull data from the database using an SQL statement like:
SELECT posts.id,
posts.title,
posts.dtg,
users.firstname,
users.lastname
FROM posts
LEFT JOIN users
ON posts.user_id = users.idNice, simple, and easy to maintain.
The problem I noticed is that these frameworks are very good at taking my application from Point A to Point B, but very bad at taking my application from Point B to Point C.