Christian: AJAX vs WebStart?

[Alex Kravets]

Hi Christian,

AJAX is a very nice technique, no doubt about. I use it almost every day in my applications. However, I think that many people are too focused on solving rich client application problems with AJAX. There is a whole new rich application world out there using Java WebStart technology to run Swing, SWT and Eclipse RCP applications. In my opinion Java GUI is much more rich in GUI components than DHTML approach at this time.
Do you think that it's too early for AJAX to take on enterprise applications?

thanks,
Alex

[ February 21, 2006: Message edited by: Alex Kravets ]

[ February 21, 2006: Message edited by: Alex Kravets ]
[ February 21, 2006: Message edited by: Alex Kravets ]

[dema rogatkin]

Why don't use just both? I provide two interfaces for my application, one is pure web with AJAX elements and another one is Swing web started from login page. If your machine has JVM, just choose webstart, otherwise enjoy AJAX.

[Christian Gross]

There is a bigger issue here in my opinion. I feel that writing GUI's using technologies like Java or C# is passe. There are certain situations when it would be appropriate, but I feel those are few and far. One example of where it would be appropriate would be the creation of a wire frame model using by CAD programs.

Technologies like Ajax, and Flex are focused on making certain classes of GUI applications easy to create and manipulate. I like Dynamic HTML because I can dynamically inject and manipulate a GUI. What I dislike about GUI's coded using languages like Java, C#, etc is that they are relatively static in nature. If I want to generate a table have one element represented as a link, another as a push button, and another as a table within a table with Java or C# its very difficult. It is not impossible, but very difficult.

For a graphical intensive application technologies like Flex are ideally suited. Yahoo Games has several games that use Flash and Shockwave and are very impressive.

The productivity you have with either Ajax or Flex is very hard to achieve using a traditional GUI programming language. Overall my feeling is that Dynamic HTML is better, with the use of Java Applets for those GUI pieces that are impossible or difficult using either Dynamic HTML, or Flex.

[Alex Kravets]

Christian,

Can you elaborate on:

The productivity you have with either Ajax or Flex is very hard to achieve using a traditional GUI programming language.

and

There is a bigger issue here in my opinion. I feel that writing GUI's using technologies like Java or C# is passe

[Gerardo Tasistro]

Originally posted by Christian Gross:
There are certain situations when it would be appropriate, but I feel those are few and far.

I think scenarios that call for GUI are those that use hardwired hardware. For example some data adquisition hardware or maybe a " I hit F10 and this ticket prints" type of situations.

Most other scenarios (aside from the graphic intensive like you say) can be well satisfied by AJAX. Another benefit of JAVA/HTML/AJAX vs WebStart/Swing/AWT is that you don't need WebStart. So your footprint is really small. Just hook up to the server and run your app. So you require less to install and can run on lesser hardware (mobile).

[Christian Gross]

Gerardo: Good points I agree with you.

Alex:

1) Productivity and the likes. First some context I grew up with Microsoft and used Visual Basic 1.0 (my oh my the gray hair is showing ). Well, actually what happened is that I was on a workterm and my boss saw VB 1.0 and said, "The world will be revolutionized". My old boss was right. So I grew up writing GUI code using VB, Delphi, JBuilder, and Visual C++ (ugh!). These tools made it easy to create a GUI with the exception of Visual C++.

The pain of these tools was that if you manipulated a control in any way or form the chances of your code going screwy was pretty high. Or if you decided to redesign your form the chances that your code would go screwy is pretty high! So we developed strategies on how to design good GUI code, but still the code goes screwy! And please don't get me started when you started to integrate third parties components.

When I use Dynamic HTML what I like is that most HTML elements are very similar. Even if I create GUI components they act, behave pretty similar. In my Decoupled Navigation pattern I was stunned how easy it is to switch HTML components without having any of my code being affected. I suppose the reason is because Dynamic HTML is dynamic and things can wired dynamically. I think the other reason why its easier is because HTML at the end of the day is one big honking text stream. We have plenty of tools design time, and runtime that are very sophisticated at manipulating text.

I suppose overall I just don't feel the pain with Dynamic HTML when I start swapping GUI elements around and changing my mind.

To your second question. If you say, yes Dynamic HTML is the way to go then you need to follow through on the argument and say Java and C# are not the languages to use when coding Dynamic HTML. I have coded Dynamic HTML (or similar mechanism) GUI's using Java and C#, but its kludgy. Dynamic HTML is, for lack of a better word, dynamic. And to write dynamic code you need a dynamic language, which is JavaScript, or Python or Ruby. Therefore, if you accept the Dynamic HTML argument it means accepting Python, Ruby, or JavaScript as a language to write GUI's in.

[Alex Kravets]

All I am saying that AJAX does not yet have a stable platform/framework/api that would allow creation of enterprise applications. We know AJAX only by GoogleMaps, Gmail and such. There haven't been any major problems yet developing with AJAX. Once these problems will be faced, I'm betting many developers will look to other alternatives.
Look, as I said I am not against AJAX. I think it's a great technology and makes web applications more rich and responsive. The problem I am seeing with AJAX at this point is similar to that of Apache Struts. Struts was the first mature MVC solution and a lot of companies rushed into developing with it. Later other frameworks came out Tapestry, Wicket...but for many companies it was very hard to move to alternative because their solution was too dependant on particular framework.
I like what Eclipse is doing with their ATF Project, this will create some kind of standard for this technology. Right now all I see is many different takes on implementing AJAX in current applications, but no unified API.

[Alex Kravets]

To your second question. If you say, yes Dynamic HTML is the way to go then you need to follow through on the argument and say Java and C# are not the languages to use when coding Dynamic HTML.

Christian,

I am not saying that Java or C# are languages to use in DHTML, I am saying that WebStart application present alternative to AJAX. Just like you would not use DHTML/JavaScript to code Swing GUI, you would not use Java to code front-end web GUI.
I found these articles interesting:
http://www.theserverside.com/discussions/thread.tss?thread_id=2484
http://www.ajaxdevelopersjournal.com/read/167031.htm
[ February 22, 2006: Message edited by: Alex Kravets ]

[Eric Pascarello]

Originally posted by Alex Kravets:
All I am saying that AJAX does not yet have a stable platform/framework/api that would allow creation of enterprise applications.

Alex I would disagree with you.
There are frameworks out there that are being used in real world enviorments. There are a large amount of people using commercial tools that are tested, they are using frameworks like DWR, and .NET has it built into the framework now. (I am a C# guy)

I personally use my own custom code in my daily job. It gets hammered since it is a live site out on the web and it is up and running. I log my clientside errors to make sure that my code is not messing up. Surprising I get very little problems from the Ajax code.

The problem I see is people are not willing to put the time and effort making sure that it works on their system. If you are working for an intranet with set standards, you life is easier.

In my job it is on the web and I have seen people come with windows 3.1!
They will not run the Ajax, that is why I have another solution that avoids that which I hopefully will release.

Developers are getting used to the old way of doing things and are basically copy and pasting code from one application to the next. Implementing Ajax in an application does not mean you have to do it for every control. You can do it one at a time and see how well it performs.

Eric

[Alex Kravets]

Eric,

Yes I agree that DWR and other AJAX frameworks are great start toward rich client web application. But I still see them as trial and error projects.

Developers are getting used to the old way of doing things and are basically copy and pasting code from one application to the next.

Well that's their problem. If they want unmanagable system that is not scalable then let them copy-paste.

[Christian Gross]

I can understand your pain because the Enterprise works in longer cycles. However, I think the cause for concern is not warrented. Companies like Google, and map.search.ch create Ajax applications that scale at the world level. One could be cynical and say that scaling Ajax to Enterprise would be a scale down.

I also do not think Ajax has an API problem, because at the end of the day API of Ajax by and large is Dynamic HTML. The libraries that people keep thinking and referencing help you get things done quicker! For example in Prototype there is the function.bind helper function to get around the lost this reference. To accomodate for the lost this reference it is a simple piece of code, but Prototype is a convience.

I don't think Ajax and Struts can be compared because Struts is server based, and Ajax is client based. As one of the articles you referenced said,

"On the one hand, there are the aforementioned Tapestry, Wicket and JSF efforts underway to "AJAXify" the heavyweight presentation tiers, and arguably maintain the lock-in to one's server technology of choice. On the other hand, Java has been pretty active with web services and the whole SOA space, which plays very nicely with the independent JavaScript client approach. "

In an enterprise scenario I would use Web Services with Ajax. And wrt to Web Services there is plenty of standardization. I would even argue we have too much standardization and not enough implementation, but that is another discussion.

[Alex Kravets]

I don't think Ajax and Struts can be compared because Struts is server based, and Ajax is client based. As one of the articles you referenced said...

But you see I am not comparing them as technologies, I am comparing the way Struts gained support from developers and where AJAX is going. I just feel right AJAX has too much momentum to be a cool technology to use. If what is done now with AJAX is embedded into application without well thought out design considerations then down the road there could be price that will need to be paid for that.
Again, all I am saying is that we need to take the whole AJAX concept a little slower and not run with it like school boys.

[Christian Gross]

Alex: Ok, now I see where you are going with this.

[Stepping on soapbox]
It's going to sound corny, but my book, alongside with other books I might add, is focused on the concerns you mentioned. Let me go through the TOC and address how it focuses on sound development practices. BTW I do not mention it in this posting, but each pattern is explained with a context, why, theory and implementation.


1) Introduction to Ajax.
Introduces Ajax and illustrates the business case behind Ajax and REST.

2) The Nuts and Bolts of Ajax.
Describes how to use the XMLHttpRequest for most development purposes (asynchronous mode). Explains the pitfalls of using asynchronous mode and same origin policy.

3) Content Chunking Pattern.
Illustrates how to build HTML pages incrementally using content injection. Outlines how to separate the structure and content of an HTML page.

4) Cache Controller Pattern.
Illustrates how to implement a meaningful caching strategy thus reducing the load on a web server. The caching strategy involves using HTTP validation, and illustrated is how to cache dynamic content.

5) Permutations Pattern.
Illustrates how to implement the Rest philosphy of separating the resource from representation. Describes why cookies should be used for authorization and not representation generation. Most sites use cookies to associate a representation and that is REALLY bad!

6) Decoupled Navigation Pattern.
Illustrates how to embed more complicated web logic into an HTML page by separating it into its three aspects (input, processing, and output). Using the Decoupled Navigation pattern it is easier to alter an Ajax application without having the Ajax application fall apart.

7) Representation Morphing Pattern.
Illustrates how you want to embedd state into the HTML page (instead of the JavaScript) and then morph that state from one representation to another. If you have ever seen TwiddleWiky, that is an example of Representation Morphing.

8) Persistent Communications Pattern.
Persistent Communications fixes the server to client callback problem that we have on the Internet.

9) State Navigation Pattern.
Fixes the back button problem. Need I say more

10) Infinite Data Pattern.
Outlines how to navigate and process large amounts of data using asynchronous programming techniques.

11) REST-Based Model View Controller.
Originally was used to fix the same origin policy restriction, but was expanded into providing a general approach on how to integrate multiple data streams into a uniform data stream.

I don't want to knock other books because other books like Ajax in Action, and Foundations of Ajax are excellent books. The two I mentioned are well worth the read. I think mine is unique in that it attempts to make sense on how to develop sensible Ajax applications in the context of Web Services. I think most of you will have noticed every third word I write is Web Service or REST

[/stepping off soap box]
[ February 22, 2006: Message edited by: Christian Gross ]

[Alex Kravets]

See this already becomes a standard. If patterns are defined for a problem and those patterns are used it concrete standard implementation then there is already something tangable that everyone can use instead of relying on assumptions and guesses.
I guess I'll pickup a copy of your book to prove myself wrong
Or by luck get it from javaranch!
[ February 22, 2006: Message edited by: Alex Kravets ]

[Gerardo Tasistro]

Originally posted by Alex Kravets:

But you see I am not comparing them as technologies, I am comparing the way Struts gained support from developers and where AJAX is going. I just feel right AJAX has too much momentum to be a cool technology to use. If what is done now with AJAX is embedded into application without well thought out design considerations then down the road there could be price that will need to be paid for that.

But who cares? Did we stop using JSP and servlets before Struts or JSF of Spring existed? Nope. Did we wait on them? Nope. There's a space in this forum for JDBC and another for object relational mapping. Did one wait on the other? Nope.

I don't think you can hold yourself on a new HOT technology just because there is no clear API or design criteria etc. How do you think those "design considerations" come about? My guess: trial and error.

Originally posted by Alex Kravets:

Again, all I am saying is that we need to take the whole AJAX concept a little slower and not run with it like school boys.

I've had a lot of heat on that line from a friend. He kept saying I was just adding more and more to my project. When I came to him and commented my recent experiences with AJAX. How I had just included some AJAX usage in some forms to accelerate user capture he just said I was trying to add everything I could find into this project.

It took me quite a while (weeks) to get him to understand what AJAX was all about. That AJAX was not some nice DHTML gadget to move input lines around and change background color. That it is a way to use the server while the user is interacting with one view (page) of your application.

This was particularly so because I'm using JSF which is very picky on the structure of the HTML. A change in a tag can hinder the whole validation process and mess up the lifecycle. I really don't know an integrated AJAX-JSF framework. I don't know how to change the state of the faces servlet so it knows my page changed (inputs turned into selects) and adjust accordingly. Yet a quick work around solved the issue.

The usage of AJAX and JSF scored me quite a gain with my client since it really accelerates information capture and project develpoment. Is the integration flaky? Sure it is. But I wasn't about to wait for the final great implementation of the JSF-o-AJAX-ian framework to start using AJAX.

There is also a price to pay for being late to the market.

[dema rogatkin]

Generally I do not see why Ajax UI is more dynamic than built using Java. You can use a framework when all your UI coded as XML messages. In this case you have completely dynamic UI and do not deal with Swing, MFC, ATL or other library. You just feed your UI engine with UI frames descriptors. Using WebStart gives certain benefits for an end user:
1. possible managing object on a user machine
2. possibility working offline
For example I have an application to upload songs to my iPod. When I use pure Ajax UI it looks great, however I can upload songs one by one, I can't do it just point a directory.
Revolutional part of Ajax is that it's trully SOA technology, you can forget about servlets, JSP, ASPx, PHP and other heavy server side technologies. A good thing that SOA is also fit desktop UI app perfectly when used mentioned approach above.

[Christian Gross]

Yes you are right you can use XML files to dynamically generate a Swing UI.

It's not the initial layout that is hard to do. It's the modification's, and updates that is hard. Let's say I want to merge two XML UI's? Let's say I want to take pieces from one UI and merge it into the other? I am not doing a sink point type merge. I am referring to a generic, inject here, and then there?

Most of the dynamic rendering solutions I have seen take a container approach.

new SwingEngine(this).render("ActionTest.xml").setVisible(true);

For what I am about to say, please correct me if I am wrong. The returned object is a container that contains a number of XML descriptors that have been transformed into Java UI objects. During the execution of the program I decide that I want to replace a couple of the objects with other layouts. Which elements I append and replace are decided dynamically during the execution of the program. To do that in Java is difficult because you need to figure out how to reference a container and modify the layout. Most dynamic rendering solutions are not equipped to do this.

Now, let's say I want to do this in Dynamic HTML.

document.getElementById( "elementtobefound").innerHTML = "some HTML";

It's a one liner! With Dynamic HTML this is only the starting point. I don't need to use the innerHTML property, but it illustrates the ease of manipulating a Dynamic HTML user interface.

I think the main reason why Dynamic HTML is so powerful is because every GUI element is a container. This usually is not the case with dynamic rendering in languages like Java and C#. In those cases the rendering is the process of converting one format into another.

OK?

Christian

[Gerardo Tasistro]

Originally posted by Christian Gross:
Yes you are right you can use XML files to dynamically generate a Swing UI.

Theoretically it should be possible to use XML file to dynamically generate a UI that can be generated as Swing,AWT and HTML. That could be run locally or remotely. Be it through RMI or AJAX.

The way I see it every component has two clear sets of things: attributes that describe it and methods that act on actions performed on them. Being the HTML actions a bit more limited than their Swing counterparts.

Take a button for example. I can establish it size and text to display. That would be the attribute part. Then I can say onClick call com.gerardo.wildidea.SimpleClickController.goClickStart. Finally I can set all the values from the GUI fields that should be used on the call (namely values to update in the model).

Now this theoretical framework should build different code depending on the deployment strategy. If I want Swing it would build a button and set the goClickStart as a eventListener. Reading all the needed values form the GUI and setting them in the model-controller. If I wanted a JSF type solution it should create a commandButton type component and link the action to the method. Creating a form with the fields required in the call. If I wanted an AJAX-HTML solution it should build a form with fields and all the proper javascript call to do a remote call (through AJAX) to goClickStart and getting the return value in the callback function. It could build a Swing RMI app just the same way.

It would be a trully monumental undertaking, but if achieved it would decouple the view from the model and controller in a way not seen before(and maybe it has and I just don't know about it). SOA apps would grow like mushrooms.

[dema rogatkin]

I'm pretty sure that somebody is working on this approach or about to start working. Concepts of GUI design are mature now, so it's the time to generalize them.

Regarding dynamic behavior of XML feeding Swing, I think gadgets or other GUI elements can have a list of XML descriptors connected to certain user actions, so for example every tab of JTab can be connected to certain XML to render tab content. So I'd say parent XML doesn't merge with some others, it has just a set of XML includes used for re-render areas upon a user action. Yes, it looks quite similar used for DHTML UI.

Again, I like HTML based UI more since it looks more standard and intuitive. However certain security limitations do not allow to create certain type of applications yet.