I'm the father of ItsNat AJAX Java web framework, JNIEasy, LAMEOnJ, JEPLayer and JEPLDroid libraries (and very old stuff like XPDOM), supporter of the Single Page Interface (SPI) paradigm, writer of the SPI manifesto and currently Android native guy. Jose Maria has posted 28 posts at DZone. You can read more from them at their website. View Full User Profile

Web Framework Smackdown: ItsNat v0.3

06.18.2008
| 8594 views |
  • submit to reddit

Following the tradition started on TSSJS by Matt Raible and continued by Howard Lewis Ship about Tapestry, ItsNat v0.3 has been released a few days ago and is ready to begin to fight. (By the way, an introductory article about ItsNat can be found here.)

Background: ItsNat, “Natural AJAX”, is an innovative open source, server centric, Java AJAX Component based Web Framework. It offers a completely new way to the web development: TBITS, "The Browser Is The Server" approach. Basically ItsNat simulates a Universal W3C Java Browser in the server. ItsNat keeps a DOM tree in the server, the browser is basically a mirror of the server state, the UI of this server browser. If the DOM server tree changes using Java W3C DOM APIs by user code, the client DOM is automatically updated accordingly. Furthermore, client DOM events are sent to the server using AJAX as the transport and converted to Java W3C DOM Events if the server code has registered a DOM event listener to the same symmetric DOM element.

Q) What is the overall performance of your framework as it compares to others?

I don’t have any numbers to compare with others; I can talk about how ItsNat takes performance seriously.

The architecture is the key: as the server keeps a DOM tree the server knows exactly what is being to change in the client when the developer changes something. For instance, if server code changes an specific attribute in the server, ItsNat automatically generates the JavaScript code necessary to repeat this action in the client adapted to the specific browser, in this example a setAttribute call on the corresponding client element. This absolute fine grain control minimizes the code sent to the client with gains in bandwith and performance.

Under the hood ItsNat uses a custom XPath implementation to locate nodes in client and server (is not a standard implementation and is used internally). By using caches of frequently used nodes we can strongly reduce the need of absolute paths and avoid traversing the tree from the beginning.

InnerHTML is used in client when appropriated to update the state of the client (innerHTML is several orders more performant than DOM calls).

Finally the DOM tree is not ever parsed from scratch, ItsNat generates clones of the initial DOM tree of a page to the different page requests.

These features are internal and fully transparent to the developer.

Q) How does your web framework position themselves in relation to Web Beans?

I think this may sound a bit weird, but IMHO we are today living in an IoC fanatic trend. IoC fanaticism = BOP, Bureaucratic Oriented Programming. Let me explain, think for a minute you must to explain to your phone carrier when and to whom you call by phone, then your phone carrier calls you saying “hey, now you must to call this person”.

Are we going to produce this kind of software in a short future?

  @Component

public class OrderFactory

{

@Produces @ConversationScoped @Current

public Order getCurrentOrder(@New Order order, @Selected Product product)

{

order.setProduct(product);

return order;

}

}


This piece of code is taken from the Web Beans specification and an example of this kind of BOP: “I’m the container if you want to be called by me please fill this request form”.

IoC may reduce boiler plate but introduce another type of boiler plate in the form of rules, is the change of imperative programming to rule based/declarative programming. Following an analogy, in classic imperative programming we simply call A,B,C, in declarative programming we must to explain to the container “A must be ever called first”, “B cannot be the first call nor the last” and finally “C can be called in any order” and the container decides the calling order. I think IoC is like a spiced meal, a meal too spiced cannot be eaten (or in a risk of stomach pain). Is this the future? I don’t know but I must recognize is a current trend.

We could categorize web frameworks as IoC centric (JSF, Spring MVC…) and non-IoC centric (Wicket, GWT…). ItsNat is not an IoC/Declarative/Dependency injection centric framework. I understand IoC as complementary to DC (Direct Control), when a framework method does X,Y may be interesting to offer some optional hook in a form of a “classic” listener to be called when X finalize to fully avoid the Y action or to modify how Y is done. For instance, ItsNat uses optional listeners to redefine the structure of a component or how data is rendered as markup, they all are examples of “classic” IoC.

I agree with Peter Thomas (a Wicket fan) about declarative frameworks:

  • Surprisingly many Java web-frameworks move developers towards non-Java, non-OO work
  • Most development time is spent on the UI
  • DSL based / declarative approaches have limits
  • Java == power and expressiveness

Peter is referring to JSF and action based frameworks mainly Struts and Spring MVC.

Declarative frameworks usually need tons of artefacts, an alternative pure X/HTML, pure Java strongly simplify how a web application is developed. The following diagram of Peter Thomas is impressive:

http://ptrthomas.files.wordpress.com/2008/05/why_wicket.png

It was drawn to explain Wicket but is valid for ItsNat too. Wicket is like an eldest brother for ItsNat, the approach is different but both share many philosophical principles.

Q) How easy is it to create a re-useable component in your framework? Is it as easy as sub-classing an existing component?

First of all, what is a component? The component concept is a moving concept, for instance, any Java object is a component if we apply the component definition in the old days of C++.

May be we are talking about a visual web component as a Java object:

  • As the way to change the visual layout from Java: in ItsNat any DOM node is a component, UI can be changed using DOM APIs.
  • That binds some data to the UI: any DOM node is a component, using DOM APIs we can inject data to the UI.
  • Ready to receive UI events: a DOM node is a component because receives and dispatches DOM events to the registered events listeners.
  • A container of other components: any DOM node is a component; if a node is removed then any child node is removed too.

In ItsNat a component is a Java object binding a data model (and sometimes a selection model), a DOM subtree and a predefined behavior when an UI event is received. Yes, ItsNat provides the typical components like buttons, text boxes, lists, tables and trees.

In ItsNat inheritance is not the way to extend existing components. I think a framework must not expose classes to the developer, because internal methods are exposed to the developer too and classes prevent switching implementations, so ItsNat API is based almost fully on interfaces. Some time ago a high level technical guy at Sun said something like “the most important error in the Java API was… the classes” (of course this statement is a little exaggerated).

The simpler way to extend existing components is using listeners; ItsNat components provide many types of listeners: DOM event, data model change, selection, structural description, renderer listeners etc.

As any DOM node contains the basic features of a “component”, creating a new ItsNat component is amazingly simple, implementing ItsNatComponent in a class binding a DOM node/subtree, some data and some behaviour associated to some UI events.

The most interesting thing is that components are not strictly necessary to build complex AJAX applications with ItsNat, the basic level, the Core, is enough. We only need Java W3C DOM APIs and a very small subset of the ItsNat APIs (many interfaces of the Core are not really needed). In fact ItsNat components are fully based on the Core level; any developer can built the same components without relying on framework internals.

Q) What is the key differentiating characteristic of your framework that makes it better than the rest?

ItsNat is a completely new approach, the “The Browser Is The Server” is, at the time of writing, unique. Jaxer, a “JavaScript in the server” technology, doesn’t provide client/server DOM synchronization with AJAX, a basic feature of ItsNat.

  • Java and pure X/HTML (or SVG), no more artefacts like expression languages, XML files, custom tags etc.
  • AJAX a very basic feature not a forced add-on.
  • Absolute control of the page layout along the life of the page including on AJAX events.
  • Learning curve flat, plain: any developer with a basic background of JavaScript in the web (DHTML), plain Java and a very small subset of ItsNat interfaces and methods, knows enough to develop very complex AJAX applications.
  • Extreme separation of concerns: pure X/HTML templates with absolutely no logic. View logic in pure James Gosling-Java allows reusing code related with view management in Java. This view logic with some techniques (use of Document.getElementById, structural patterns, Node.cloneNode, optional use of ${} variables etc) can be highly independent of the concrete layout.
  • No special tools, not oriented to IDEs: any X/HTML editor and a decent Java editor are enough.
  • Out of the box remote view of pages opened by other users/browsers with any supported browser. An open door to uses like help desk, “legal spying” etc.
  • Comet amazingly simple with no special servers.
  • Server-sent events with no special browsers: from the server you can fire DOM events and send to the client simulating user actions. Server-sent events can be dispatched directly to the server without browser (again useful for functional testing). Both modes are very useful for functional testing driven by the server.
  • Beyond X/HTML: SVG elements embedded in XHTML can receive events, can be associated to components etc. Furthermore, ItsNat supports pure SVG pages with the same features of X/HTML pages (AJAX, COMET etc), for instance the server can receive DOM events from a client SVG page.
  • Referrers: this feature is based on AJAX but introduced for “classic navigation”. A page can automatically access to the server document of the previous page left behind, and can reuse (copying) data, pieces of markup etc.
  • Data models and selection models in components are based in Swing. A web application and the Swing counterpart can share very much code and the same structural design because an ItsNat application may be designed as the typical event based desktop application. ItsNat reuses Swing as possible but is not a forced Swing clone in web, for instance ItsNat is not pixel based.

Q) What do you think about the various scopes introduced by Seam, e.g. conversation vs request or session? If you support these additional scopes, do you also provide some sort of concurrency control?

Conversation, request, sessions… this way to think a web application will be obsolete any time soon. When you develop a desktop application you never think in conversations and sessions, you only distinguishes “load time” and event requests. The same is in ItsNat, with ItsNat you can develop classic applications but is not the strong point, ItsNat is strongly focused in AJAX and is highly event based.

You only need a single page as in a desktop application (main frame), including rewriting big parts of the page, because ItsNat provides “markup fragments”. Markup fragments are pure X/HTML (or SVG) documents where only the markup below <body> (or <head>) counts; these fragments can be loaded in any time as DOM and inserted in any part of the DOM tree of the main page usually as the response of a client event.

About synchronization: ItsNat automatically synchronizes the document object for instance when an event is received, if other event with the same target document is received, as the document is locked this second event will wait its turn. In this way server code called by ItsNat in a context of a document load or event request is executed as single-threaded. Wherefore server code can access any server document (to access to the DOM, components etc) with no problem if the document target is synchronized first.

Q) Why can't we, the Java Community, come together and adopt the best application framework and settle the web development subject?

No, we can’t.

Because there are several development styles, any style have strong points and shortcomings. For instance, JSF, GWT, ItsNat or “your JS Lib + DWR” are three very different styles of programming a web application. For instance if you want drag-drop bloated closed components in a framework highly intrusive like JSF, then ItsNat is not for you. If you need a client centric application with tons of JavaScript and “special effects”, ItsNat is not for you (in spite of ItsNat may be mixed with JavaScript libraries, ItsNat offers a pull and push-Comet communication with the server similar to DWR).

Q) What are you doing to help with developer productivity?

A tool for reusing, reusing and reusing… did I say reusing? Typical approach of web frameworks is to offer closed, bloated and impressive visual components tightly bound to view logic, outside those components there is no hope, developing custom components (beyond composition) is impossible or very hard. ItsNat doesn’t follow this route, ItsNat components are highly customizable, furthermore, ItsNat components don’t have X/HTML view, the view is designed as pure X/HTML by the developer and attached to the component in Java. This promotes reusable components highly configurable not attached to a specific aesthetic and layout, and as the view logic is done in Java, this code is open to the goodness of the Object Oriented Programming.

Q) 2008 is a huge year for the mobile web. How do you help developers build great mobile web applications?

ItsNat brings AJAX, COMET, server-sent events, remote views etc to the following mobile browsers:

Opera Mini 4, Opera Mobile 8.6, NetFront 3.5, Minimo 0.2, IE Mobile 6 (Windows Mobile 6), iPhone/iPod Touch, Android, S60WebKit (S60 3rd, Nokia phones), Iris browser 1.0.8 and QtWebKit embedded (Qt 4.4)

And to the following desktop browsers: MSIE 6+, FireFox 1+, Safari 3+, Opera 9+ and QtWebKit (Qt 4.4).

The server centric nature of ItsNat is especially interesting on mobile browsers because the browser is not bloated with tons of JavaScript code.

I’m specially proud of IE Mobile 6 support, IE Mobile is poor and buggy. ItsNat leverages this browser to similar level of any other (of course with many limitations); using Java W3C APIs ItsNat can provide DHTML behaviour never seen before in Redmon and “almost impossible” using direct JavaScript code.

Q) If you couldn't use your framework, what would you use and why?

GWT is a brilliant technology highly focused for desktop-like applications with some serious problems to develop web sites. And Wicket for web sites.

Q) How do you enable rich Ajax applications?

ItsNat is strongly based on AJAX, is not an add-on. Client events are transported using AJAX. AJAX is the base of COMET (using long-polling), server-sent events (based on COMET), timers (scheduled AJAX events) and remote views (using timers or COMET).

Q) Can a developer make a change to source, and hit RELOAD in the browser to see the change? If not, why not?

ItsNat supports hot update of pure X/HTML and SVG templates (pages and fragments); when you change a template (page or fragment) on the filesystem any new page requested or fragment inserted uses the new version automatically. This feature is very useful in production too for instance in web sites with many static parts.

Of course you can change dynamic parts of the template, if your view-logic in Java is tolerant to layout changes you don’t need to change the Java code. For instance the layout of a tree can be changed from a UL/LI based layout to a TABLE based with no code changes.

ItsNat doesn’t offer hot reload of Java code, a tool like JavaRebel may be useful in this case. Of course we are talking about Java code, nothing prevents you of using a JVM based scripting language for your view logic and/or business logic.

Anyway ItsNat offers some interesting techniques to bring your application to a desired state with a direct path. Imaging a very complex AJAX based web application, to navigate to the current development zone you need to fill a login form and 5 clicks; you can use server-sent events coded in Java with or without browser intervention (easier) to simulate user actions to bring your application to the desired state after an application reload. This feature is very useful for functional testing and bookmarking too.

Q) What do you think about the whole Flex revolution, and do you think you are competitors to this technology?

If we are talking about Flex as a new web based technology… we don’t need another web engine. Flex seen as a new client side technology… Flex is nice but it has some serious shortcomings: a proprietary technology, a non-typed language, client centric nature (return to the flat client), Google/search engines don’t like Flex, ActionScript is not a low level language (ever limited by Adobe), is not ubiquitous like standard web technology is (including low end devices) and finally is not the only kid on the block (Silverlight, JavaFX/Consumer JRE).

We have web for many years. AJAX, COMET, SVG, canvas and native support of video will reduce the “feature mismatch” with Flash/Flex/AIR technologies. I must recognize that Internet Explorer is a problem, the necessary plug-in we really need is an easy to install ActiveX, wrapping the FireFox engine, for Internet Explorer!

Q) How easy is it to create a module and plug it into a bigger application, complete with configuration, code, and view?

ItsNat is fully configured in pure Java. In the same way you can add cool visual DHTML components including a JavaScript file, you can add new visual components using pure Java (may be in a jar) because the method ItsNatDocument.toDOM(String) allows to convert an string with markup to DOM on the fly ready be inserted (this is not the recommended practice, big pieces of markup should be put in HTML files and registered into the framework). As you have full control of the markup you can invent new custom tags and replace them when you want with your custom markup.

In summary: ItsNat offers a solid foundation to build your own super custom amazing high level web framework.


Published at DZone with permission of its author, Jose Maria Arranz.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Steven Baker replied on Wed, 2008/06/18 - 1:42am

epic fail

Jose Maria Arranz replied on Wed, 2008/06/18 - 1:49am in response to: Steven Baker

Can you explain?

 

peter svensson replied on Wed, 2008/06/18 - 12:52pm in response to: Steven Baker

Could you be less precise, please? :)

 

As for me, I like ItsNat. It's not my style, but I'd definitely prefer it to GWT, for instance. It's well thought through and has dozens of features. I'd bet that Steven doesn't like it because it dares to acknowledge that there is a client. He'd rather be looking for the car keys where there's a light, I'd guess.

 

Cheers,

PS 

Jose Maria Arranz replied on Wed, 2008/06/18 - 1:12pm in response to: peter svensson

Hi Peter, nice to meet you again.

You know our love is impossible, because you love SOFEA (Sofea is similar to "Sofia" a mediterranean typical name of woman) and I'm in love with the Server, but if you think a bit we develop web applications using the same tools: DOM APIs (or any other on top).

 

peter svensson replied on Wed, 2008/06/18 - 1:17pm in response to: Jose Maria Arranz

Hi José :) Yes, I'm in love with SOFEA, but I still respect the work you do, and I think it is a very good path forward for someone who needs to do complex client stuff but don't have the time or inclination to fully separate concerns. It _is_ a good alternative, and frankly my alternative won't be fashionable for years to come (if ever :), so I'd give it a good chance.

 

Agnostic godspeed to you until we meet again.

Cheers,

PS 

Sam Barnum replied on Mon, 2008/06/23 - 3:16pm

I am pretty skeptical when the phrase "a whole new way of..." gets thrown out, but this is a pretty interesting approach.

What are the implications as far as back button support?  What sort of application do you envision developing using ItsNat?

 

By handling all events on the server it seems like you're heading towards responsiveness issues in cases where the client (browser) can do things on its own, like javascript drag & drop, e.g. 

Jose Maria Arranz replied on Tue, 2008/06/24 - 2:48am in response to: Sam Barnum

Hi Sam

ItsNat strongly promotes AJAX based applications running on the same window/page like in a desktop application. In this scenario no back button is needed/processed.  

As the client page is a "clone" of the server state when the user leaves the page the server page/document is lost. Back and forward buttons are considered as special "links", when you click back or forward the target page is ever a new fresh page, is not a cached version, ItsNat makes a strong effort to avoid client caching (including form autofill).

Think this example: a page shows a list of products, then you add a new one filling a form in another page, then you come back to the product list by clicking the "back" button, ItsNat reloads the page with the updated product list avoiding the client cache.

If you are going to use "classic" navigation, ItsNat provides a feature called "referrers", when you leave a page and navigate to any other (ItsNat based) page, the target page can access the "server document" of the previous page, this previous "dead" document can be used to copy any data and pieces of markup useful to the target avoiding parameter passing.

About UI events: 

I agree with you, sending to the server some types of events (mouse over etc) have no sense. ItsNat can coexist with no problem with client JavaScript code because you have absolute full control of the markup layout, in fact client JavaScript code can be injected from server. For instance this Java call in server elem.setAttribute("onmouseover","some JS code") adds some custom behaviour to the desired element (onXXX methods are not used by ItsNat), ItsNatDocument.addCodeToSend("JS code") can be used to send custom JavaScript code to the client, and ScriptUtil.getNodeReference(Node) returns a JavaScript reference of the specified server node in client useful to build and send custom JavaScript code cooked on server. And of course JavaScript code can be directly declared in X/HTML templates including components because ItsNat uses a pattern approach, for instance if the cell pattern of a table has an onclick attribute, this handler will be present in any cell of the final rederered table with data.

Furthermore, with some care ItsNat can be mixed with client DHTML JavaScript libraries, static zones in server can be dynamic zones in client. For instance the ItsNat Feature Showcase uses the famous Syntax Highlighter controlled by the server. Finally, ItsNat provides special "user defined events" to comunicate client with server, these user events are fired in client using JavaScript.

I hope this explanation has been helpful. 

Peter Schubert replied on Tue, 2008/10/07 - 4:08am in response to: Jose Maria Arranz

Hi Sam,

 

How does ItsNat support bookmarking (permalinks) , or search engine indexing?

 

Thanks,

Peter 

Jose Maria Arranz replied on Tue, 2008/10/07 - 12:00pm

Hi Peter

I invite you to look at this example (the Feature Showcase is a pure AJAX, single page, ItsNat application):

http://www.innowhere.com:8080/itsnat/feashow_servlet?itsnat_doc_name=feashow.main&feature=feashow.core.bookmarking.ex

Click the "Source Code" and "Explanation" too.

See how the Feature Showcase is indexed by Google and others:

This example answers both questions, if not try to explain your doubts again.

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.