User:Aleksandar Šušnjar/RIA and AJAX
This page contains my own opinions on Ajax (programming) and Rich Internet Application. If you have any comments or would like to discuss something please use this article's talk page - do not edit this one. If my opinion changes I will update it myself.
One more thing - Here I only write about issues that appear to be contentious to some.
Naming and meaning
Personally - I don't like name "AJAX". It is too strict for what people think of it. When I ask people about Ajax or listen to presentations (e.g. Sun Tech Days) what people really think is Asynchronous JavaScript and a method of communication. They don't really restrict it to XML or XMLHTTP. This restriction, though, is perfectly valid for some purposes - it is just that the name does not reflect what most people happen to think.
The name Rich Internet Application is better but rather vague. "Internet applications" are those that use Internet in any way, including those not based on HTTP at all. "Rich Application" essentially has the same meaning as Rich client. Combining these two gives an impression that applications like Microsoft Internet Explorer or Skype are Rich Internet Applications. They actually are if you really look at what the name means. It’s just the established custom to think of RIAs as something more specific. Some people think of it as restricted to Macromedia Flash because of the company who coined the term - Macromedia. If that should have been the case then I think they should have called it Rich Flash Application, Flash Internet Application, or something like that.
I've also seen a mention of Athletic client, which instantly reminded me of something I felt about this type of applications but never really worded it - progressive client - it starts small but grows as it is used. My employer, Hummingbird Ltd decided to name the first product we released in this technology (presented February 2002) a DM "Webtop", to indicate similarity to "Desktop" - in terms of functionality. The name stuck, but is not descriptive. I, nevertheless, still like it.
Last but not least, I don't care who coined the term. Rich Internet Application was coined by Macromedia in March 2002. Ajax was coined much later, in 2005 by another company. Neither one is a trade mark, as far as I know, so it’s OK to use them. If people come up with good idea we should not have to force inventing a different one just because it’s "theirs".
About “AJAX” vs. “Ajax”... all uppercase indicates that it may be an acronym. Titlecase indicates that it is a word on its own, which in many ways it is becoming. Similar to BASIC and Basic - just that many people think that BASIC got its name because it is basic (base, simple) which is not so far from the truth (Beginners' ...).
AJAX is a special form of RIA
Well, if you read the above section you'll see what I think Ajax and RIA are. To summarize, I think that a Rich Internet Application is actually an application that "gets delivered to the client by the piece and as needed and can asynchronously communicate with the server it came from". Let's keep delivery method at HTTP, although I'm not entirely sure this requirement needs to stick. Now what is Ajax? Well ... it gets delivered by the piece, it can asynchronously communicate with the server, and it has client side intelligence. It also just happens to define the details - client side intelligence is implemented using JavaScript and, depending how strict you are, communicates with the server using XML or also allows alternative approaches.
I've been told that RIA has Macromedia Flash connotations. I happen to disagree. It is just one way of doing it.
Power
I've been told that Ajax is for "lightweight mini-applications only". I disagree. It is a technology. What (can) you do with it is a different story. At Hummingbird Ltd we have created (in 2001, long before any of these terms have been coined) something that can be described as Ajax and/or RIA. Without violating non-disclosure agreement I can say that the requirements were to make the web application as close as possible in functionality to a desktop application - with all bells and whistles (context/selection sensitive menus and toolbars, drag and drop, etc) and have it customizable. After a lot of thinking the conclusion was that the technology actually exists. One just has to look at how regular desktop (not web) applications are built today (IDEs, ready-made UI controls, just drag-and-drop them and tie event handlers kind of thing) and do it in a different language - JavaScript. I had the proof that this can be done - from Desktop.com (do read about it).
The rest is history. We've made an app that (almost) looks like, smell like and feels like a desktop application. And we gained a lot of experience in the process. So if someone tells me that "you can't do that with Ajax" I can actually show them that they're wrong. Just not online, I'm sorry. It is, after all, a commercial product.
One more thing. It seems that (too?) many developers out there have experience in either developing web or desktop applications, but not both. Knowing the way things work in both "campuses" is a very good thing and can help in these matters as well.
Pros
Interactivity
Based on my comments in "power" section (just above) you can see that there are no limits to interactivity other than performance and slight security limitations of selected language and platform (e.g. JavaScript).
Load distribution and performance
Remember dumb terminals and mainframes? Then remember client-server and n-tier architecture … those that shifted the load away from the mainframes? You do? OK. Now unremember that. We're back at dumb terminals. New ones look much better and are called browsers but are, given improvements in technology just as dumb. The only notable difference is that they can jump from one "mainframe" to another. Not mainframes you say? What are those web server out there - ordinary toasters? No, I didn't think you would agree with that.
Well RIA and Ajax allow us to essentially do client-server and n-tier "things" over the web and without installation. With such smart client-side code the number and complexity of requests left for servers to handle can be greatly reduced. In well-architected clients:
- Servers get fewer requests per time per user.
- Servers do not need to render HTML, therefore reducing number of CPU cycles needed for each request.
- Indirectly this means that the same server can either support more concurrent user sessions, serve the same number of user sessions faster or that less powerful servers are needed.
Want real world examples? Here are some - navigation tree does not need to be regenerated on every click nor needs entire data to be sent. Data already received can be cached at the client, therefore reducing the need for subsequent requests. Client can also ask for some data ahead of time, combining it with other requests, further optimizing the performance. Need more? OK. Search results. When desktop apps handle them they get result data and show them as users scroll the list (for example). If users scroll back they don't need to re-fetch those results - they have them. Can Ajax do it? Well, I say that it is already happening, at least since 2001.
Network utilization
Raw data transferred over the network is significantly smaller than full HTML representation, especially heavily decorated one. This results in faster response data transfers and greatly reduced network traffic. Less traffic on the network increases perceived bandwidth for any particular session, further reducing response data transfer times.
Is that it? No. RIA/AJAX apps have client-side intelligence. They can do a lot without having to contact the server at all. Now, that reduces the traffic! They send server requests less frequently. Then we have that good side-effect again - less traffic on the network increases perceived bandwidth for any particular session, further reducing response data transfer times...
Smaller but more frequent communication?
I've been told I'm wrong here. Specifically that AJAX apps balance out gains in smaller data by more frequent requests. Are there really such apps out there. Absolutely. I've seen some. Some of them do it for good reasons, but many for bad reasons. Let me explain...
Is the feature that needs frequent requests crucial?
YES: If it is then stop whining about it. You could only do it worse without RIA/AJAX (e.g. server would have to render entire HTML every time instead of just sending data). So we're still better with RIA/AJAX.
NO: Then why is it there? Would it be there without AJAX/RIA? Is it pure comfort? If it isn't worth the price then it is wrong to put it there in the first place - for ANY type of application (even for fat desktop apps). If it is then there you go - see reasoning for "YES" answer.
Unfortunately this is not where it stops. Some apps do need frequent communication. That is their core business. Many others I've seen are just very badly designed. Typical example I've seen many times is the auto completion for text input boxes - most commonly related to some user directory. The scenario goes:
- User types the first letter.
- RIA/AJAX app goes to the server and gets the list of all options starting with that letter.
- User types the second letter.
- RIA/AJAX app goes to the server and gets the list of all options starting with letters entered.
- User types the third letter.
- RIA/AJAX app goes to the server and gets the list of all options starting with letters entered.
- User types the fourth letter.
- RIA/AJAX app goes to the server and gets the list of all options starting with letters entered.
- ...
Do you see my point? How dumb is the client in this example? After the very first trip to the server (step 2) it receives the entire list needed for subsequent operations. The list only gets shorter and does not see new items. That filtering can easily be achieved on the client side. Another trip to the server may be required only when the first letter changes - assuming that the client did not load that list earlier.
Of course, there are examples where the lists are extremely long and the server returns only best suggestions or something related. But, not only are those examples extremely rare when compared to everything else that can be done, they may also be treated as "crucial" (remember my question?) and, therefore, not to be compared. Don't compare apples and oranges! Apps of any kind that do more are easily beaten by those that do very little. Compare only the same functionality.
Cons
Lack of development tools
If you haven't read the section on "Power", please read it. With RIA and Ajax we can build applications that are just as powerful as desktop ones. Its just time consuming as a lot of stuff "desktop guys" take for granted simply does not exist for RIA and AJAX. Think of desktop application development IDEs. Now imagine if you could have essentially the same-looking tool but generating RIA/AJAX and not, for example a C++ or VB application.
This is where my "lack of development tools" comes from. RIA and AJAX didn't even start playing catch-up yet for all I know (I may be horribly wrong here, please DO tell me if I am). All I've seen so far are few libraries, some comparatively simple frameworks (when compared to desktop ones) and IDEs that don't help as much as stay out of the way. Prove me wrong. Please! I would like to know.
Performance
Well, didn't I mention performance in the "Pros" section? Yes I did. But there are other performance related issues. Client-side intelligence in JavaScript is not as fast as the compiled one that runs anywhere (for example on the server). This limits how much processing can be transferred to the client. It is as simple as that. Technically, one could write everything in client-side JavaScript but that would go against the desire to appropriately distribute the CPU load and optimize network traffic.
Measuring Performance
I was contacted by a number of great people thinking how to measure the performance of RIA/Ajax apps. The end result is Performance Matters blog written by Chris Loosley. Read it - there is a lot of useful information there. No need to repeat it here.
Layout issues
Strictly speaking, neither Rich Internet Application nor AJAX require pixel-precise layout. Just some approaches do (e.g. Macromedia Flash, but I am not an authority on this one). Those apps are all about client-side intelligence. Those that run within a browser and work on HTML DOM most of the time use that HTML DOM as very high-level flexible/dynamic layout equivalent of a display device driver. Sometimes pixel-precise positioning is required, of course, but this is not generally the case nor it has to be. RIA/Ajax apps "happily" delegate the layout responsibility to the browser.
Browser support
What are the browsers that support RIA? Essentially those that have the ability to run some client-side code delivered on-demand from the server and to facilitate asynchronous communication with the server. I must not forget that the browser must allow sufficient DOM manipulation as well - not just have it as mostly read-only.
Now, this can be done in a variety of ways and I have seen it done even in Internet Explore 4 and Netscape Navigator 4 using IFRAME/ILAYER approaches.
What about AJAX? Well, AJAX is RIA based on JavaScript and (optionally) XML. Guess what - IE4 and NN4 both support JavaScript, don't they? They also support XML. One can deliver XML even through IFRAME/ILAYER (in a wide variety of ways). Oh... you wonder about that XmlHttpRequest thing? Well - that is not a requirement - it just makes things easier.
So which browsers support RIA/Ajax? You try to answer that one. What I can tell you is that there is something else important yet omitted. RIA and AJAX as approaches, if you will, and you can have many different and incompatible ways of doing them. Recently, since about IE 6 and NN 6 (yes, SIX, not 7) we started seeing some significant convergence (re JavaScript/DOM method, not others) that makes writing cross-browser RIA/AJAX apps a whole lot easier. So it’s not the answer that is the problem - it’s the question. We should be asking ourselves "If one wants to make cross-browser compatible RIA/AJAX apps with reasonable effort which browsers should be considered?".
History, Credits, Spamming and Links
This is a hard one. Go read Wikipedia articles Ajax (programming) and/or Rich Internet Application article(s). Do you see some companies listed there? Which ones? Now think of what did they actually do? Some of them just "coined the term" many years after the technology started appearing. Some of them released whitepapers describing the technology (again, late) and not much else. Some made small and occasional enhancements to their products.
Where are the true pioneers who actually did something significant? For example, Desktop.com, if I remember correctly (and I think I do) came at least very close. In 1999! … With Internet Explorer 4 (four, not a mistake) and announced support for Netscape Navigator 4 (yes, four again). I didn't see whether Netscape support actually came out. We at Hummingbird Ltd came up with the idea in 2001 for a full-features app that, as I said earlier, looks, smells and feels almost like a desktop app.
Where is the official line between historical credits and spamming? Well, maybe it can be a very large gray area but seems that there is either inversion or some extra rules. Microsoft, Macromedia and Google did some very publicly visible work on this issue. But this work is either much later or a lot smaller (or both) than what Desktop.com or Hummingbird Ltd did. Are there other pioneers? There may be - I know of these two. Desktop.com provided its services online, for free (at least as a DEMO) - hence was visible. Hummingbird Ltd announced it at its Summit 2002. All customers and partners get very detailed customization guide describing the architecture. Not as much public as Microsoft or Google - I grant that but (I'll go a little too far to illustrate the point) since when we're crediting news reporters for inventions they are reporting on?
I think pioneers deserve their credits. If you feel they will benefit from this you'll probably be entirely wrong. Why? Desktop.com no longer exists. Hummingbird Ltd customers don't buy technology - they buy products and, furthermore, probably don't read extremely technical descriptions of what Ajax or RIA are supposed to be.
Who is a pioneer and who is not? That is a hard question to answer. Maybe they can go indefinitely as long as they come up with something significantly better yet related. Deciding who that might be is also very difficult when many contenders are available. However, in the early years there weren't many contenders - just many "talkers". We're just seeing the renaissance now. That does not mean that we should ignore Middle ages, especially because it resulted in products still more advanced than anything publicly offered today.
For one I'd like to see pioneers' links in those articles - so that I can learn about them. I personally wouldn't even mind having them stored some of my user pages if that is necessary (if someone wants it I'll do it - just ask first). But I think that would pretty much benefit only me.