Wanted - a web design framework/pattern/library

Wednesday, May 27, 2009
These days I have been thinking of why there is no framework which helps me develop a web application in its “natural state of being”.

Let me explain the natural state of being for a web application. First the browser is no more just a html display engine. Instead the browser has emerged to include user interaction (read javascript) and html display engine. No more is it taboo to have javascript in web applications. In fact web applications say good bye to anyone who has not turned on javascript. Even the html display features have upped the ante. No more table wrangling and poor UI design. The DOM has matured and CSS can do wonders. Grid based CSS frameworks have put web design on par (at least notionally) with print based design.

What about web frameworks? Have they acknowledged the fact that html and javascript have matured. That, it is no more the forgotten child in the family of enterprise frameworks from Java and .NET or web oriented frameworks from LAMP, with P fulfilled by Python, PHP, Ruby! I would say yes and no. Yes, because many frameworks natively support and integrate with a javascript framework, or provide components based UI, etc. But mainly No, because all the action is in the rear (no pun intended). Html generation, UI interaction is all in the web application logic which is never executed by the browser but executed by the server. You might point out GWT and its ilk, but I have a mixed feeling about GWT. I like the concept and architecture of GWT. It is one of the rare breeds which acknowledge the power of the browser. However I don’t like the fact that everything is java.

So what do I want from a new age web app framework? Here is my wish list
  1. Allow development of html in ahem html. Yes, no fancy wrappers frameworks. Plain html is good enough.
  2. Allow layout definition, color and fonts in CSS. Web designers like CSS. There are javascript frameworks which do layout management, CSS, etc, but doing it is CSS's raison d’être , and does a good job.
  3. Allow development of user interaction using javascript. User interaction includes visual interaction like drag-drop, open-close, etc. It should also include functional user interaction (which we come to next).
  4. Allow integration of functional user interaction with the server using javascript. I don’t want a component tree to be manipulated on the server. The UI is on the browser, let the browser take care of handing UI.
  5. Allow development of the html, css and js as we saw in 1,2,3 in an easy to understand manner. Maybe go back to VB, Swing or even Small talk. Designing a UI and interaction for the web should be no different from designing it for a desktop application. I shudder at the thought of developing a tree table control using only server logic.
  6. Allow development of business logic on the server using insert java, python, ruby, etc. No brainer. Javascript from the browser requests something from the server, and the server dispatches it.
  7. Have features which can glue the disconnected html, js, css and backend server. For e.g. login state management, history, etc.

One might think that my wish list is a manifestation of NIH or even Can your language/framework do this syndrome. It is not. A web application is created by several thinking hats. First is the graphic designer hat where you do not care about the interaction or functionality. Second is the user interaction designer hat where your intent is to do both visual interaction and functional interaction. Third is the business logic designer hat where your intent is to fulfill business requests in the form of an API. My wish list is to
  • Let each hat use the language best suited for the purpose. Do not force a new language and framework unless it is a DSL.
  • Let simple things be simple and complex things possible.
  • A web applications’ UI is on the browser. So, let the VC (capital C) of MVC be on the browser and let Mc (a small C) be on the server.
Should we build a new framework or stack to support such kind of development? I don’t think so. There are tons of libraries. A nifty way to glue them is what we need. We need to do what Maven did to Ant build scripts (I know I will be flamed for that). Eliminate ctrl-c ctrl-v and introduce macro'ish way of doing things.

Html and CSS do not need anything new. CSS frameworks are the new kids on the block, but I don’t know much about graphic design to comment on them.

jQuery and other DOM manipulation libraries can provide the user interaction we want. Yes, DOM manipulation libraries have a lot more features; they can create the whole html, CSS etc. But like I said let html be done in html, CSS in CSS.

Functionally user interaction is fulfilled by Ajax modules in DOM manipulation libraries.I feel that Ajax API do not have good semantics. For e.g. in relational theory and SQL, a SELECT does projection, FROM does joins and WHERE does selection (sic!). Something akin to that is needed in Ajax APIs (I hope I explained what I mean). Also, I don’t think you need to hide the fact that the server is remote. EJB did that for many years and then introduced local and remote interfaces. Programming to an interface and not an implementation is always better.

Server frameworks are dime a dozen. A simple one which functions like an API sending only data in the form of json, xml, yaml, is more than sufficient. Almost all the frameworks qualify, but they need to be stripped of all the excess fat.

The biggest job is creating a neat pattern which can glue all these different components, provide necessary and sufficient (i.e. orthogonal) helpers, provide a good set of defaults and extension points. I consider documentation to be as important as the framework. Documentation should teach usage of the framework and provide details on the design of the framework.

I love programming. I hope that someone (or me) develops something which brings the same joy to web programming.

5 comments:

Anonymous said...

Try wicket. The html side is html.


Script Uncle said...

I hear you loud and clear. I have the same setniments, which made me write this;
http://unclescript.blogspot.com/2008/01/end-of-web-frameworks.html

and then this;

http://unclescript.blogspot.com/2008/02/end-of-web-server-frameworks-part-ii.html

I am happy to say that I can now call you a fellow RESTafarian. REST is beside the point though - the important thing is that you have (and we're in a minority here) understood that a proper separation of concerns between client (browser) and server lead to a dramatic decrease in project complexity.

Cheers,
PS


web design India said...

very cool post


Website Designing said...

Learning programming languages or Tools required a lot of logical sense.

- J.
Web Designing


Web Solutions said...

To understand a programming language the person need to be know about the syntax of the languages!


Post a Comment