Alternatives to Server-side Web Frameworks

Introduction:

Changing tack from previous posts, this article gives examples on how an application can be made without using Server-side Web Frameworks, thus reducing complexity and lowering costs.

I got many good replies to my recent post "The End Of Web Frameworks". In it I argued for the need to bypass all existing Web Frameworks on the server, to avoid their high complexity costs.

I realized the other day, on a related note, that Ajax in and of itself actually means not using Server-Side Web Frameworks. Think about it; Asynchronous JavaScript And XML which implements out-of-band channels where raw (XML) data is transferred between browser and server. Where in that proposal do you see the need to regenerate the client (again, and again) out of complex config files on the server?

Instead of just bashing though, I thought I should devote some time to explain what the alternative(s) are, and how one can go about designing an application without retorting to using Web Frameworks (WFs for short).

Proposal:

I have outlined fairly well the reasons for removing the web rendering from the server-side completely, and instead construct modular clients in JavaScript in my last post on this subject . The main points are the following:

1) Current server-side web framworks are very complex.
2) The reason that they are complex is because they try to generate a client out of the server.
3) If you remove the web client generation complexity from the server, the server becomes simpler.
4) If you program a client _on_ the client, using state of the art client frameworks, you get a simpler client (than the server-config-file client-in-parts, just add water, you had before).
5) This is a big win


The Client:

To begin with, on the client, nobody in his or hers right mind tries to reinvent the wheel and write hundreds of separate function supporting cross-browser oddities (read; IE) from scratch. Since several years ago there exists mature, well-tested cross-browser compatible "Ajax" libraries with copious documentation.

Good choices when coding your in-browser client;

1. Dojo 1.x
Url: http://dojotoolkit.org/
Reason: Dojo has a simple markup language, which the dojo 'runtime' will parse when loaded. It amounts to adding a tojoType="" tag to existing HTML markup, which make compact code.

Also, and more importantly, Dojo has very well designed data-binding structure, called dojo.data. Most high-end widgets such as Tree or Grid support reading their data (and sometimes writing as well) from a datastore, which can among other things be a csv file, an XML-generating service, or a custom component. This makes it easy to swap data sources, and presentations, without ever involving the server-side.

Dojo is also maybe the largest open "Ajax" framework in existence today, sporting encryption, Google Gears integration, cross-browser 2D and 3D graphics, charting, a powerful template-based, modularized and easily extensible widget system, complex Drag and Drop features (even in Trees), i18N support (currency, date, time, et.c.) for widgets and even support for widgets who have to display data right-to-left like Arabic, Japanese, et.c. Disclaimer: I'm a fanboy :).

2. Ext 2.0
Url: http://extjs.com/
Reason: Ext is perhaps the most polished "Ajax" framework, having very slick design and pixel-perfect looks. Ext also have powerful data bindings to its widgets, just like Dojo.

3. SmartClient.com (commercial but with LGPL client library).
Url; http://www.smartclient.com
Reason: The SmartClient guys have fairly covered all bases. They have about as much functionality as previously mentioned frameworks, but with the added twist of WSDL data bindings. This means that their widgets can read directly from a web service, or you can make a form which calls a web service directly. It is really quite a lot of stuff they're releasing as LGPL, so if you're missing anything from your current choice du jour, it might be a good idea to browse about the SDK. No, we're not affiliated, I just like what they're doing.

4. YUI (Yahoo User Interface)
Url: http://developer.yahoo.com/yui/
Reason: Very good data-binding widgets, such as their datatable (with good pagination examples), et.c.

5. TIBCO GI
Url: http://www.tibco.com/devnet/gi/
Reason: TIBCO has not only a very enterprise-y approach to building clients; Treetables (Matrices), extremely good support for WSDL Web services and a free visual GUI for creating browser-based clients.

The reason I'm not mentioning jQuery, Prototype or Mochikit and others is that I would like to emphasize the need for data binding and management as a key issue for a client-side framework, which is missing in the more basic ones, where the emphasis is more on design and effects.

The Server:

OK, we still need data from a server, of course. And if we place the client on the client, we don't need no client-code on the server, leaving us with a much more specific and "slim" server-side. Examples of servers which have well-defined interfaces to browser-based clients are;

1. DWR (Direct Web Remoting)
Url: http://getahead.org/dwr/overview/dwr
Reason: DWR is one of the slimmest offerings out there, which does the following, in their own words; "DWR is a RPC library which makes it easy to call Java functions from JavaScript and to call JavaScript functions from Java (a.k.a Reverse Ajax)". It is easy to get started with and fairly low on the configuration file department. It uses one XML file to map incoming queries to Java classes. It only returns data. Sweet. :)

2. Sling (RESTlike JCR implementation)
Url: http://incubator.apache.org/sling/site/project-information.html
Reason: Sling is a fairly young project which implements the Java Component API, which looks like a traditional web server, serving static pages from the outside, but where focus is on resource access and not page access. Each component can be implemented as a script (Rhino, Ruby, JSP or what have you). This means that Sling can be used as a stand-alone or servlet-droppable application which automatically maps requests for resources to specific scripts which generate data, thus making it more simple to focus on business-logic only on the server.

3. DIY (Because you're just serving yourself data anyway)
Url: http://localhost/yourapp
Reason: You get started in no time flat (if you're using scripting, like JSP or PHP). A little longer, perhaps, if you insist on compiling and bundling stuff up. You will not reinvent the wheel again and create yet another framework. Why? Because the client resides in a separate HTML file, which loads it's js libraries by itself. You will only implement security, business logic and serve data!

References;

The SOFEA team has a very detailed description of why server-side web frameworks are complex, in an excellent PDF.

Bob Bufone at rockstar apps has a very succinct and insightful post on client vs. server-side frameworks, which is a must-read. He ha a webinar on the subject with a downloadable PDF as well.

Per Olesen has also done some research into which server framework to choose for the development of Rich Internet Application apps, which is an interesting read.

Cheers,
PS