CHARP Philosophy - pupitetris/charp GitHub Wiki

CHARP follows a very clear vision, of allowing web application code to reside mainly on the database as stored procedures, and on the browser for layout, behaviour and control. This is its background:

Early web pages and still many today follow the "mainframe" phylosophy; that is, that a web server renders a page that the client receives and displays in a "dumb" fashion: the role of the client is only to allow the user to fill-in a form, just to be sent to the server for processing. Data validation and processing would then take place on the server and it would restart a new cycle by sending the client a new page with the results, and optionally a new form to fill out. We can see this round trip still present and pretty much integrated into today's web frameworks. From Drupal to Plone to GlassFish, they all work in the same fashion: fat on the waist and thin on the ends; the web server takes most of the workload and the complexity, leaving the database for interactions with SQL primitives (SELECT, INSERT, UPDATE), and Javascript only for what it was conceived years ago; mainly user-friendly validation and the eventual AJAX/DOM manipulation.

The main problem with this kind of web applications is that they react to the user in a strange way, and many tricks have to be implemented for them to work as a normal desktop application. Also, performance is usually bad, requiring large amounts of resources or multiple caching layers, because the web service layer is too busy dealing with layout construction, on-the-fly image rendering and so on, and this for even the most minute interactions that the user may have with the system.

For some time now, web browsers have been increasing in intelligence, performance and complexity, allowing for the rise of new methods of web application development. These days, we can forget about the "mainframe" cycle and finally bring the application programmer into the web application scene. These days, it is possible to rescue Javascript from the validation/AJAX pit and use it to write complex client-side applications where the user never or very seldomly leaves the entry point page. Using current HTML5 technology, we can use CSS and the DOM to control the interface layout and transfromation through the application's life cycle. We can save user preferences and other information the user may want to retrieve on future sessions using LocalStorage, and we can keep session information on normal memory, knowing that this information will be unloaded as soon as the user leaves the page. If we allow all these smart web applications to do the server interaction through a thin HTTP/CGI-level message relayer and let the business logic take place on the database server, we can reduce the number of layers that we have to take into account when programming, reduce the languages that we need to integrate for our project, and reduce the load on our servers and the their configuration difficulty (have you tried to configure and fine-tune Plone lately?). More work on the client means less work on the server; we distribute the computing effort through all of our web clients. If a given client wants to do heavy operations, we try to code those operations so that they slow others down as little as possible.

Why hasn't this change taken place in a generlized way? We have had rich web applications for years now, from GMail and Yahoo Mail to Google Maps, and recently Twitter, but this doesn't seem to be catching on that quick. On the other hand, traditional web application frameworks abound, and new ones are coming all the time. One possible answer is in the developers. You see, "mainframe" development is quite elegant and simple; you send a form, the user fills it out, and you process it and send the next step back. I have seen developers grow on this interaction cycle exclusively, oblivious of more traditional application programming. Now, the problem is that the web industry is full of this kind of programmer, who may even come to understand object-oriented programming or the Model-View-Controller pattern, but they don't feel comfortable at all with asynchronous, event-driven cycles. Mainframe programming is quite synchronous, and that's how they like their soup. So you may have a team of well-versed PHP/Cake hackers, or your JSP/Beans javvers, and they are going to frown quite a bit when they see hundred-plus Javascript modules full of callback registering and DOM manipulations (probably more frowning coming from the PHP/Cake ones, btw). So yes, it's kind of hard because the hacker profile for these techniques changes quite a bit; you will probably need more of those C++/Qt or C/GTK+ programmers, or make your mainframe hackers upgrade to event-driven, async GUI developers.