Abundance

One theme I've noticed in many large web applications is badly reinvented wheels. I suspect a lot of this is caused by the "not invented here" syndrome or by developers who want to avoid external dependencies (portability is nice). The problem is that virtually all web applications have a rather complex set of requirements and security needs that often are not implemented well (if at all). And, a lot of us who have been programming web applications for more than a decade might still be a bit mentally stuck in the 2000s, when a little HTML and some form fields were all you needed to make an "interactive" site that actually worked quite well. Conversely, I can't help but think newer programmers aren't aware of all the problems already discovered and solved in frameworks during the past decade and a half.

Why Frameworks?

One compelling reason to use frameworks is that they not only do a lot of the heavy lifting, the better frameworks do it properly. I say "better frameworks," because at this point there are literally thousands, and many are terrible. Additionally, the more popular frameworks, like Django and Ruby on Rails, have tens of thousands of add-ons (Ruby Gems, Django plugins, etc.) that can be used to provide functionality. Plus, someone else maintains the code for you: win-win! The downside of these frameworks is that you have to build your applications using their idioms and design patterns: If you haven't read Design Patterns [1], about designing object-oriented software, you might want to buy a copy.

MVC and REST

One popular design pattern with web frameworks is the MVC (Model, View, Controller) pattern (Figure 1). In a nutshell, you have a controller, which sends commands on the basis of either user actions or other external or internal events, like an order generation; a model, which represents the system, essentially a large state machine; and a view, which is output sent to the user or other systems. One reason this design pattern is popular is that it supports stateless protocols (like HTTP) rather well, whereas many traditional design patterns assume a fully stateful system.

[...]