The ideal web framework
Over the five or so days since RailsConf, I've spent a lot of time reflecting on what the ideal web framework would be. Throughout the years, I've used a lot of frameworks: PHP (homegrown solutions and off-the-shelf CMS solutions), ASP.NET, Perl, and now I'm working on my first ever Ruby on Rails app. That's not to mention some of the others I've just looked at, such as Django or Web.py.
I think I'm finally understanding what would make for the ideal web application framework (at least for general/80% case). Most of this came from a lot of what I learned at RailsConf and how I think it should be extracted even further.
First I should define what "ideal" means to me. Ideal means extremely productive, extremely easy to understand, and extremely maintainable. These three qualities would lead to other, more tangible qualities, such as: easily testable, easily deployable, DRY, and easily extendible.
The key thing to realize here is to follow a lot of Rails principles and take them to the next level. For example, what is the architecture of 80%+ of web applications? Simple: CRUD. You virtually never need more actions than what is available from create, read, update, and delete. Rails knows this, and attempts to embody it. Soon (Rails v.1.2+), we'll see vast improvements in this, as well.
However, they're not taking it far enough. They have a great concept going with scaffolding. But, it can be taken further.
The ideal web framework would be as simple as defining your database schema (i.e. provide a Rails migration file) and running a single command, like "./script/create_web_application" which would run your migration file, then create the appropriate models, views, controllers, and test stubs.
After this single command, the application would work completely. Because you could allow your migration file to know relations between models, this would already be done within your application. For the same reason scaffolding can do most everything within CRUD, the ideal web framework would include this.
However, if you instead moved the scaffolding HTML code into the views themselves, you would literally be programming just HTML for your entire CRUD application. You could just write templates for the scaffolding and be done with your application.
If you wanted fancier controller methods, the ./script/create_web_application would have already created the stubs for you, so you'll just fill in what you're missing.
And, of course, RESTful web services would be built in. Heck, split the Rails views directory to views/html and views/mobile so that you can create views for both web browsers and mobile browsers.
That would be the ideal web framework, in my opinion. And what does it boil down to? Essentially a very CRUD-y Rails with some helper applications. I just love the idea of an entire web application built with essentially one command and some HTML.
I think I'm finally understanding what would make for the ideal web application framework (at least for general/80% case). Most of this came from a lot of what I learned at RailsConf and how I think it should be extracted even further.
First I should define what "ideal" means to me. Ideal means extremely productive, extremely easy to understand, and extremely maintainable. These three qualities would lead to other, more tangible qualities, such as: easily testable, easily deployable, DRY, and easily extendible.
The key thing to realize here is to follow a lot of Rails principles and take them to the next level. For example, what is the architecture of 80%+ of web applications? Simple: CRUD. You virtually never need more actions than what is available from create, read, update, and delete. Rails knows this, and attempts to embody it. Soon (Rails v.1.2+), we'll see vast improvements in this, as well.
However, they're not taking it far enough. They have a great concept going with scaffolding. But, it can be taken further.
The ideal web framework would be as simple as defining your database schema (i.e. provide a Rails migration file) and running a single command, like "./script/create_web_application" which would run your migration file, then create the appropriate models, views, controllers, and test stubs.
After this single command, the application would work completely. Because you could allow your migration file to know relations between models, this would already be done within your application. For the same reason scaffolding can do most everything within CRUD, the ideal web framework would include this.
However, if you instead moved the scaffolding HTML code into the views themselves, you would literally be programming just HTML for your entire CRUD application. You could just write templates for the scaffolding and be done with your application.
If you wanted fancier controller methods, the ./script/create_web_application would have already created the stubs for you, so you'll just fill in what you're missing.
And, of course, RESTful web services would be built in. Heck, split the Rails views directory to views/html and views/mobile so that you can create views for both web browsers and mobile browsers.
That would be the ideal web framework, in my opinion. And what does it boil down to? Essentially a very CRUD-y Rails with some helper applications. I just love the idea of an entire web application built with essentially one command and some HTML.
