Backbase, a company specializing in rich internet applications, has published a whitepaper entitled "AJAX and Beyond" to explain their Backbase Presentation Client, designed to interact with their Presentation Server. They also have a Backbase Development Environment for Java and .NET. All of the products are expected to be available around the end of May 2005, with a current download being available in their developer section.

BPC leverages many of the more recent W3C standards as well as AJAX and a custom UI declaration language called BXML (Backbase eXtensible Markup Language) to create highly interactive web sites. There are a number of demos available that show Backbase Presentation Client in action.

The Backbase RIA solution has the following differentiators:

• Full commitment to web and internet standards (XHML, CSS, JS)
• Cross-browser and cross-OS compatible.
• No proprietary plug-ins or runtime virtual machines required
• Layout and look-and-feel can be fully tailored to your wishes
• Fast to learn: developers can reuse existing web (HTML) development skills

AJAX looks like a great tool to bring rich internet applications out. With companies like Backbase beginning to actively support rich client development, how will the future of enterprise development be shaped?

Wow, the demos are really impressive :)

What junk! :-)

Looks good though.

It actually has pricing on the website. That's a good sign. A bit expensive though.

This is very nice looking technology but I'm a bit of a cynic when it comes to rich internet web sites. I've taken far too many clever web applications (developed using applets or Flash mostly) through usability testing. The weird thing is that it is almost invariably the case that the none applet, none Flash site is the one that users can actually use.

The thing about a web browser it that it basically has four things you need to know how to do in order to be productive:

1) Click on a link.
2) Scroll
3) Using the back button.
4) Fill in a form

As soon as you start adding rich content the amount of learning a user has to do increases considerably. Now you can cover this off for enterprise applications with user training in a lot of cases but this does rather get you away from the joy of internet applications in the first place (that they are really, really easy to use).

You forgot the fifth thing one must do when using a web browser:

5) wait the whole page to refresh.

IMO, getting rid of whole page refreshes is the main benefit AJAX will bring us. Anything else is just "icing on the cake".

This is very nice looking technology but I'm a bit of a cynic when it comes to rich internet web sites. I've taken far too many clever web applications (developed using applets or Flash mostly) through usability testing. The weird thing is that it is almost invariably the case that the none applet, none Flash site is the one that users can actually use.

Completely agree. Where AJAX is applicable is when it's being used without the user's knowledge. Dragging and dropping HTML elements around on the page is unnatural within the context of a 'web page'. Auto-complete features (google beta), sorting tables, paging tables, etc, can be very natural to users since it doesn't require any additional premonitions to complete the task.

No one wants to use an application that is just a series of clever tasks thought up by some programmer. Click, type, click type-- easy :-)

Richness of the user interface should be reasonable. Excepting the cases where 'cool' interfaces is only reason of the appication, customers usual pay for implementing the business functionality first of all. It does not make sense if developing user interface takes 10x times more than developing the business functions. Writing and debugging JavaScript code is pretty time-consuming thing. The technology should be extremely easiest to become popular.

--
Sergey : jsfTutorials.net

...It does not make sense if developing user interface takes 10x times more than developing the business functions. Writing and debugging JavaScript code is pretty time-consuming thing. The technology should be extremely easiest to become popular.--Sergey : jsfTutorials.net

I think that's the whole point of commercial RIA providers like Backbase. They've done all the PITA JavaScript work and provided easy to use components.

I think that's the whole point of commercial RIA providers like Backbase. They've done all the PITA JavaScript work and provided easy to use components.
Check out www.innuvo.com.

I have no stake in this company, but I worked with their technology for a year before politics killed our use of it, and I know the guys who developed it.

It rocks. It is *everything* that AJAX and Backbase wants to be, but more....

GJB

The thing about a web browser it that it basically has four things you need to know how to do in order to be productive:1) Click on a link.2) Scroll3) Using the back button.4) Fill in a formAs soon as you start adding rich content the amount of learning a user has to do increases considerably.

I agree. This is why I believe that the promise of 'rich internet applications' will never materialize. The good old web apps will beat the crap out of them, regradless of their shortcomings. Using good old web applications is simple, and people are used to them, and know what to expect. With rich applications this is not the case.

.. and graphical browsers will never replace Lynx.. ;)

I guess you haven't checked out google maps or gmail. IMO these are actually quite easy to use and intuitive.

The value add that they provide runs circles around the the good old "click->render entire page->click again-> re-render-entire-page..etc" process.

Go to:
http://maps.google.com/

Type in your home town (town, st) and hit search.. Now reposition the map by clicking on the map, holding down the button, then drag the map.. Cool huh?

You'll notice this UI did not "require any additional amount of learning"..

Point is, rich internet apps can be poorly designed or they can rock and be just as easy to use as traditional web apps. But this is the case with any app, old fashioned webapps included.

Hi,

I've been doing a Backbase introduction course (one day) last week. Just to see if the Backbase technology is easy to integrate with current technologies.

I agree that that there are some things that are very important when one is usin a webbrowser and RIA. The trouble thing might be the Single Page Interface instead of the Multi Page Interface we normally use in Web Site (Applications).

I've noticed the following:
- Clicking on a link is very easy. One doesn't even have to use the a-tag the handle actions, every html-tag can be used for this. This doesn't say the a-tag cannot be used anymore, it still can be used.
- Scrolling is very well still possible.
- Using the backbutton is also possible. Even though the use of a single page interface actually means one never leaves the 'page', you still have controll of the back and forward button. It is also possible to disable the back-button use. So within the SPI the backbutton means going back to where one was before entering the SPI.
- Filling in forms is very rich in Backbase. To get your own forms this rich you will have to write a lot of javascript. Backbase hides all the javascript for you. It uses declarative backbase-tags.

Also very nice is the not needed VM. You do not need to have a JVM or Flash client installed. It just works on the browsers supporting Javascript (although they are still working on support of Opera and Safari).

I'm very enthousiastic. The costs aren't that high at all. When you are building a small webapplication for a client it does cost somewhere between € 50.000,- and € 100.000,- euro. The license for Backbase is just a small fee in case of such applications.

Regards,

Mark Monster

For a pure Java solution, consider Canoo's UltraLightClient:

http://www.canoo.com/ulc/index.html

UltraLightClient is a lean library that delegates tasks to the standard J2EE/J2SE infrastructure whenever possible. It uses Swing on the client, standard communication protocols set by the J2EE container, and standard lifecycle management on the server. UltraLightClient is an add-on library for Swing and J2EE and can be easily integrated into existing web platforms.


regards,
Sandra

AJAX Matters has several articles and resources available on the topic of AJAX.

JavaRSS.com - The Award Winning Java website - is also using AJAX as well. Check out the settings page to enable AJAX code.

Here is how AJAX is used on JavaRSS.com.

http://www.javarss.com/ajax/j2ee-ajax.html

- Jay

Cross-browser and cross-OS compatible.

Hmmm. Backbase.com doesn't work on Opera 8.0, nothing but a blank white page.

- Jay

Hmmm. Backbase.com doesn't work on Opera 8.0, nothing but a blank white page.- Jay

Doesn't work with Apple's Safari, either.

What I really liked about Backbase was that in addition to being plugin free, its architecture was similar to JavaServer Faces. They make a point of compairing BPC and JSF and point out that while JSF provides components they're largely server based and still require typical request/response/reload processing. JSF supports JavaScript, however it is still mainly for decoration as far as I've seen.

I like the JavaScript client engine idea. JavaScript is a "plugin" that everyone already has. And as Backbase has shown can be pretty performant. There may be pitfalls to adoption due to the differences in JS support in various browsers. I however would rather use this pain to improve JS on these browsers rather than be required to ship my own client plugin to ensure that the client interpreter works consistantly.

In the end I see something like Backbase's JS client engine and JSF's server side engine playing together to develop some truly powerful apps.

That being said. AJAX is a pretty nice method for RIA implementation. But AJAX isn't a standard, and there isn't a standard RIA architecture that I'm aware of that employs AJAX. With commercial AJAX toolkits, tags and libraries coming out, will lack of standarization hurt sales? I was burned by the early Portal craze. I definitely see promise in AJAX, but will save my investment until all these commercial providers are able to standardize and play nice together.

Backbase, any plans to take your work to the JCP?

In reading over this thread and having played with building rich client applications using a variety of technologies, I totally agree with the notion that an rich client/AJAX type application is the way of the future for Web interface development... as long as it has the following qualities:

1) Easy to code
2) Cross browser compliant
3) Should adhere to standards
4) Nice visual design env wouldn't hurt

When looking at different technologies, I think JavaServer Faces really stands a great chance of fulfilling these goals in that because the JSF API offers very flexible client rendering capabilities, rendering client side code to improve the end user's experience is totally doable. Also having client code encapsulated in a component allows the Web developer not to have to get his/her hands dirty with messy client specific DHTML/Javascript code.


For req 1, JSF provides a simple tag based invocation capability so you can simply refer to a single component such as <myfacestaglib:table ..> and it will render a nice AJAX table in your page this making it easy to code with for the Web developer.

Requirement #2 is solvable by the JSF component developer. As long as the JSF component renders browser neutral or client side script tailored specifically to the specific browser, the end user using the component will have the same superior rich experience. This is an advantage of the JSF API in that it is a "pluggable renderer" architecture making it easy to apply multiple renderers to for different clients to the same component.

For requirement #3, obviously since JSF is coming from the Java Community process and was built to work with standard J2EE Web technology, this definitely fulfills this requirement. So no proprietary runtimes, or browser plugins would be needed.

Also, because JSF is a standard, vendors and open source contributors are now meeting requirement #4 by providing visual design environments for JSF development. This includes venders such as Oracle JDeveloper (10.1.3), Sun Creator Studio, IBM Websphere App Dev, and Exadel JSF Studio not to mention a number of various Web/JSP/JSF related plugins for Eclipse.

The challenge in the near future is for the vendors and community to seize the opportunity and provide some great AJAX enabled JSF components and we are starting to see that now.
Oracle has recently been demoing a new set of new components in it's "ADF Faces" technology where it renders a fully rich client UI for the user. A cool fact is that it is completely coded to the standard JSF API..

So in short I think the near future is bright for JSF rich client Web interface development..
-Chris

In the end I see something like Backbase's JS client engine and JSF's server side engine playing together to develop some truly powerful apps.

The JSF EG has been working on incorporating AJAX/JS features into the framework. Currently Oracle's ADF Framework uses Faces and JavaScript together to do conversions/validations/dialogs/etc.

In summary, we are working on some ideas that go beyond simply adding remoting to JSF. Ed Burns, the co-spec lead is prototyping some additional functionality so the difference between an full page submission and a remoted request becomes agnostic to the JSF developer. He can probably comment more, but it's something the group is actively pursuing.

Jacob (JSR 252 EG)
JSF Facelets

It will never be on JCP because BackBase use PHP ;)

Take a look: http://www.ajaxfaces.com.
Also http://swforum.sun.com/jive/thread.jspa?threadID=53143&tstart=75 from Sun Java Studio Creator Community Forum

As mentioned above, usability can be improved very much with AJAX, but it might also be just too much. At Backbase we don't have a strong opinion on this: depending on the application and the audience, just choose an appropriate interaction design. We support both very flashy, but also very boring and functional sites (including desktop-like applications).

From a technical perspective, Backbase is indeed putting a lot of effort in simplifying AJAX development: if you use a BXML tag, it's guaranteed to work in all supported browsers. You write no or very little JavaScript. Take a look at the source of www.backbase.com to see an example (use View Source and ten follow the b:link, b:include and b:buffer tags).

Our engine has to work around all kinds of browser quirks, so you don't have worry about them. The consequence is that it takes uw some time to support new browser versions, such as Opera and Safari. But we will support both of them, it's just a matter of time.

The Backbase client-side technology is server-agnostic. To speed up development, we started integrating with Java on the server first, but it now also works very well with .NET and PHP. Don't be fooled by the file extension though: our website actually has a full Java architecture, except for the index page which is PHP: it's easy to mix and match server languages with Backbase.

Regarding JSF: we believe we are not competing with JSF, but can offer a powerful extension on top of JSF. JSF is server-centric, and the Backbase engine can move more intelligence to the client, while synchronizing events between client and server. Looking at the discussion above, it seems that many of you prefer JSF: are there other Java GUI technologies that you like to have supported? How would you feel about declarative development, ie. defining the GUI in XML, like in XUL, XForms or XAML?

Looking forward to your input.

Jep Castelein
Backbase

I've a lot of time experimenting with EcmaScript.
I even used self-made toy language "Ceylon(tm)" compiled to js (java like class definitions, inheritance, interfaces, innerclasses in JS). One step of compilation was gluing many obfuscated classes together.
Did BackBase used some kind of language for js (as i did) or obfuscator works with native js?

We indeed use custom extentions in the javascript code that get resolved by a pre-processor that also obfuscates the code.
This also helps us in compiling optimized builds for specific browser/os combinations.
We also build many little 'plugins' that only get loaded if you need them. So if you never use for example 'drag' it never gets loaded.

G. Kaandorp

All modern browsers (ie, mz, ff, op) have a long standing js memory leak bug. Althought plain js objects as well as dom tree objects finely cleaned up by garbage collector problem arise when js object are binded to (exists as properties of) dom tree and vise versa. In that case gc cannot properly detect which objects are in use, and which can be safely collected. Some manual cleanup must be used (or coding so objects have low coupling).
The actual memory leaks can be seen in complex script (or badly written). Even if BackBase's framework uses minumum (-> 0) page refreshing (when old obj tree not properly cleaned), question still remains "Are backBase scripts aware of this problem?"

We have used Backbase 2.0 and 2.2 and both suffer from the memory leak problem in IE. Depending on your application, it can consume an enormous amount of memory.

A major concern in this respect is the fact that the Backbase thechnology is not extentable. You cannot create your own widgets, as you can with for example Flex.

Memory management is indeed a very complicated topic in javascript development. Different browsers show different problems with automated garbage collection. However, with our 3.0 release we feel confident that we have solved these issues.

Also new in our 3.0 release is the ability to create 'custom tags' that you can use for building your own widgets. ie. you can define how a tag is rendered and specify the events that it can handle. All in a declarative XML format and extensible through JS.

Gerbert Kaandorp
(Backbase)

Of course we are aware :), and although troublesome it can be worked around.

With regard to Opera compatibility: internally, we’ve more or less got it working. So we’re working on that.

Laurens Holst
Backbase

Jep Castelein, do you do a background check or something when people register on your site? I promise I did not attempt to kill anyone so far, please, may I register in a little less than two days?

There's minor typo on page 3

'http:/www.backbase.com' instead of 'http://www.backbase.com'

Major one considering the content ;)

Please read,

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/dnwebgen/ie_leak_patterns.asp

http://codeproject.com/useritems/LeakPatterns.asp

JavaScript is not mature yet.

Improper JavaScript causes memory leaks. So are C, C# and Java.

Fortunately, there are several frameworks that could save your time from not coding in JavaScript at all. Backbase is one of them. ZK is yet another.

AJAX does make memory leaks worse due to Single-Page-Interface. AJAX frameworks are no exception. However, the more people test and use, the more stable they become.