1. In simple applications, you can merge the view and controller on the client and use the database and stored applications on the server side. Have two people

1. In simple applications, you can merge the view and controller on the client and use the database and stored applications on the server side. Have two people who know two languages, and you're done. In web applications, you have HTML + CSS + Javascript for the view. While AJAX can talk to databases, it's slow for parsing out data that would be better handled in a faster interpreter. Thus, you have the "controller," or at least what is called a controller in webland, as a code generator for HTML and sometimes even javascript. Then, you have to interface with the database already, so you have to make the decision whether to have a database specialist, or just to treat it like a dumb store and do all of your business logic next to your controller. This is where we see the wonderful JDO, EJB, Hibernate, Activerecord, etc. Rails makes it less painful, so long as you don't have a legacy database. For large applications, the overhead is negligible. however, small and medium business-hosted web applications are still more difficult than the old client-server model. And Access is easier yet. We still haven't come close to that with web apps.