A better web framework - Part 1

As I have mentioned before, design patterns are one of my favorite areas of computer science. Well, design patterns have a close association with web frameworks, so web frameworks are definitely another favorite area of mine. They both help speed up the development process by providing a structure for applications. Since Ruby on Rails took off a couple years ago, other web frameworks have sprung up in many other languages. None of these have met my needs at Webmail.us.

The webmail application I work on is very different than many other Web 2.0 applications, which is why most of the existing frameworks don’t work for us.

  • There are no page refreshes and therefore:
    • Most drawing is done by Javascript
    • All data transfered is JSON encoded
    • Email, Calendar, Tasks, Contacts, Settings are all combined into 1 application which means:
    • Large memory footprint
    • Javascript performance very important
    • On the fly loading of HTML, Javascript, and CSS is a must

For the past few months, I have been thinking about what I really need in a web framework. Just like Rails, an MVC framework would need to be the base. In Part 1, I will just talk about the MVC foundation for this framework.

Model

An ActiveRecord type object would provide the MySQL data abstraction. I have mentioned that I have been working on my own implementation for a while, so I won’t go into too much detail on this. Basically, for a complicated web application, most existing model abstractions don’t work very well. With complicated JOIN’s, WHERE’s, and subquerys, something different must be used.

View

A templating mechanism must exist to have a complete web framework. Current view abstractions won’t work in webmail. Since webmail never refreshes, going to the server every time we need to populate a template is troublesome. The templating mechanism in the better web framework would allow a template to be used in PHP or in Javascript.

If a template is used in Javascript, once it is downloaded once, it wouldn’t have to be downloaded again. The hard part about a Javascript template is the inability to have loops and the need for slow regular expression parsing.

If a template request in Javascript has to make a server request every time a template needs to be populated, speed becomes an issue. This is fine for large templates, but what about small widget templates? Making a server request for a small element increases 1. latency and 2. server load which in turn increases latency even more.

Controller

Controllers are the backbone of a web framework. I like how Rail works with a controller class where each data request is mapped to a function call. This seems effective to me and needs little modification.

Conclusion

I know what you must be thinking: Your MVC design isn’t that much different than Rails. Well, that’s true, but remember this is part 1. The MVC design is just the foundation of a better web framework. Rails is popular because it is useful, so it is definitely a good starting point for developing a new framework.

Shout out to Mike for his work on Javascript templates.