Machine Learning Authors: Yeshim Deniz, Liz McMillan, Elizabeth White, Pat Romanski, Corey Roth

Related Topics: Agile Computing, Machine Learning

Agile Computing: Article

Has Web Development Lost Its Way?

Introducing an open source Java AJAX component based web application development framework

To understand where web development is going, we need a brief review of web development history. Many years have gone since the old CGI bridge was invented, a quick hack to achieve the impossible, create server-based web applications. The first CGI based web applications were C (and Perl) programs based on a terrific mix of HTML and printf calls. This primitive approach was valid to build those "magic" dynamic web pages constructed with our data introduced with forms. This was the starting point of a race to improve the developer tools and the user experience. The live web starts here.

A bit later, Allaire's ColdFusion brought us a new way to build our primitive web applications, the HTML based templating (disclaimer: I'm not claiming Allaire invented web templating, but this technique was very popular thanks to ColdFusion). The HTML page was again the protagonist but mixed with a scripting language, the "Server Page" paradigm. Microsoft of course entered the web scene pressed by the Netscape and Allaire success, the fear of losing ground in business is a very strong reason to innovate, and they gave us ASP technology to compete with the successful ColdFusion, including the Visual Basic Script as the script language.

Years later the Java world put its foot in the server side with the expected logical path, servlets (a CGI Java version) and JSP (the ASP competitor) introducing Java in the web server. Model 1 was born.

Model 1 had a downside: too much code mixed with markup, so the custom-tag invention starts to shine. The custom-tag technique opens the door to two new protagonists, XML-based programming and expression languages (EL). XML + EL are the "weak" replacement of the typical strong full featured and verbose programming language used before to manage the dynamic parts of the markup, reducing (slightly) the impedance of both worlds and promoting an improved separation of business code and view. They brought a need to bridge page templates and business code... the "bindings."

The next step: why does the view decide the navigation, the target view? The answer to this question is the adaptation of the MVC pattern to the web. In Java the most popular MVC framework, Struts, defines the navigation rules using again XML, in this case the "XML metaprogramming" is not to develop the view, is the MVC glue.  Model 2 was born.

The Birth of the Event-Based Web

Model 2 introduced desktop culture in the web. The temptation is near, and the temptation is called "components". HTML form components are very basic and the HTML/W3C world is very conservative to welcome something new. But we need new desktop-like drag and drop components beyond form controls...now! The answer is HTML and JavaScript generated by tools. How to package? How to bind with the business code? The Java answer is JSF with more custom tags, more XML files, metaprogramming and Java bindings, and a "new kid on the block" in the server centric world, JavaScript. The server generates and sends to the client custom JavaScript, usually with support of client JavaScript libraries, as the way to add desktop-like behavior to the components and to drive user events to the server reloading the page with the new visual state of the component when necessary. The event-based web was born.

Now AJAX is here, what can we do? Umm... we can generate more custom JavaScript or XML, transporting the data from the server and render this data in the client using JavaScript centric components, or we can build the component view in the server and generate the necessary custom JavaScript from the server to change the appearance of the component in the client as response of user actions.

So what is wrong with this path?

1) Custom tags (with custom HTML and JavaScript generation): violates web development culture

In the desktop a program's appearance can be fully customized because the developer usually has a pixel-based level. You can build your custom controls from scratch but it is usually a hard task. The web space is very different, there is not so much power (for instance there is no API to draw on) but is not difficult to customize the visual appearance of your web application using tags, CSS, and JavaScript. For instance, almost all Swing applications use the default "boring" controls, in web applications every <table> is different and there is no steep learning curve.

Traditionally when a web developer fills a <table> with data the developer usually has full control of the <table> layout. This full control is being lost with so many intrusive custom-tag based tools. These custom tags usually "replace" the web designer, generating tons of obscure markup mixed with JavaScript. There are two problems: corporate style may be not fulfilled and complex components are not possible. With simple components this approach may be valid because the CSS has some control of the visual appearance, but with complex components like composite components you are in trouble.

2) XML based metaprogramming: disturbs the Object Oriented Programming paradigm

XML is very nice for custom configuration but it is verbose and very poor when used as a pseudo imperative language. The current tendency to use declarative programming underuses the power of OOP because this XML-based declarative programming is usually being used in an architectural manner (with a deep architectural impact). For instance, is very hard in XML to declare a feature applying to different levels (globally, locally) or to groups ("batch" configuration). Most of the time you need to repeat the same again and again because the XML format used impose it.

Custom-tags and XML-centric frameworks are usually designed with tools in mind. Tools increase productivity of course, but the most productive tool is reuse, and OOP strongly promotes reusing easily, with XML-based components it is very hard to reuse your own work because you need to build your own XML-based components otherwise you will be repeating the same again and again.

3) Old tools do not fit with AJAX

Most of the server-based web frameworks were designed before the AJAX explosion. Many page-based frameworks are not very useful in the AJAX space, because a web application with 100 pages can be replaced with a new one with only 1 page, classical navigation utilities are underused with AJAX. This applies to the pre-AJAX component (or event) based frameworks too; these frameworks tried to simulate a desktop application using classical navigation with full page reload, the sophisticated techniques used to keep track of the component state while the user navigates, including back and forward button support, are now over-engineering.

Is there some other alternative?


The design problem of classical web application development is mainly in the view. The view is defined as plain text, this text is never exposed as a DOM tree to the developer, so any binding to business code, declarations, region marks etc are always done in the markup with special tags, regular expressions etc. Because the normal HTML is treated as plain text only the special tags and regular expressions are the live elements of the page. Components are usually defined with custom tags because it is extremely difficult to delegate the markup design to the developer because the developer needs to explain to the framework how the markup design fits in the expected component behavior defined by the framework.

The alternative is to repeat the nature of the client in the server, use again the old DOM in the server too, we are in the twenty-first century and in the AJAX era where there is no need to rebuild complete pages by any user click. Many years ago this approach had many problems, but these problems are gone; furthermore the problem of the expensive memory use of the DOM can be surpassed using serialization as plain text of the "static subtrees."

 ItsNat Simulates a Java W3C Browser in the Server

I am the author of ItsNat, an open source Java AJAX Component based web application development framework. ItsNat uses the approach described above. This approach is radically new but uses the old tools: the client DOM tree is repeated in the server as a Java W3C DOM tree, exactly the opposite, the client DOM is a clone of the server DOM, if the server DOM changes the client DOM is updated automatically by the framework usually as response of user action, this user action is received as a Java W3C DOM Event transported by AJAX. In short, ItsNat simulates a Java W3C browser in the server.

With this approach the starting page may be defined as a pure HTML template, and exposed to the developer as a DOM tree. With a DOM tree the developer has absolute control of the layout including minor changes as the response of an AJAX event. If an AJAX event requires a big change of the page a pure HTML fragment can be loaded converted to DOM and inserted in the document.

How to build components? Following the Wicket approach but with the DOM side, defining patterns and telling the framework what is the parent element of a list, table, tree etc what is the pattern of a list item, row, cell, tree node... what is the component structure, in short, attaching the developer defined view to the component. Then component will clone the pattern to create new list items, rows, cells and tree nodes.

Conclusion: returning to its roots may be the path to the future in web development.

More Stories By Jose M. Arranz

Jose M. Arranz, the author of ItsNat, is CEO and co-founder of Innowhere Software Services S.L.

Comments (3) View Comments

Share your thoughts on this story.

Add your comment


Most Recent Comments
Jose M. Arranz 11/26/07 03:58:15 AM EST

I agree with you Eelco. ItsNat has support of classical (page based) navigation, the pure HTML templating, and direct DOM manipulation and components (with no events) are valid too without AJAX events, but is not the framework focus. In fact AJAX may be used to assist classic navigation I named it "referrers", I think this technique may be used in any framework with AJAX support, of course... Wicket!

Thanks for your support :)

Note: there is a "bug" in the article (the bug is mine course) "regular expressions" should be "expression languages".

Eelco Hillenius 11/25/07 11:31:35 PM EST

I agree with a page-navigation centric approach being a bad fit with Ajax, at least sometimes. However, a framework like Wicket lets you build a single page web app even without Ajax if you want (using component replacement and panels). Also, pages aren't always bad. They can serve as units for bookmarking, and in general units to divide work/ functionality. I think the way you can mix the two approached together with Wicket works well.

You propose kind of the inverse of this, which sounds equally good to me. Good luck with the project :-)

backtothefuture 11/25/07 02:03:57 PM EST

> Conclusion: returning to its roots may be the
> path to the future in web development.


@CloudExpo Stories