XML.com: Is AJAX Here to Stay?

Is AJAX Here to Stay?
by Jordan Frank | Pages: 1, 2

Other technologies that could be used to develop rich internet applications include XUL, XAML, Java, Flash, and SVG. XUL is a high-performance markup language for creating rich, dynamic user interfaces. It's part of the Mozilla browser and related applications, and is available in Mozilla browsers (like Firefox). XAML is a high-performance markup language for creating rich, dynamic user interfaces. It's part of the Windows Presentation Framework, Microsoft's next generation UI technology, and will be supported in future versions of the Internet Explorer browser. A Java Applet is a program written in JAVA that can be included on a web page. Applets are programs that require the proprietary JAVA plugin from Sun in order to run. Macromedia Flash is a powerful presentation-layer framework that comes preinstalled on most PCs and Macs. It's possible to use Flash to build web-based user interface components that are highly configurable. SVG is an XML-based graphics language that describes images with vector shapes, text, and embedded raster graphics. It can be integrated with XML data sources or SMIL (Synchronized Multimedia Integration Language). It has good interoperability with CSS and JavaScript. Therefore SVG will not compete with AJAX but complement it nicely once it matures.

AJAX in the Enterprise

Is AJAX ready for the Enterprise? The answer to this question may lie in its relationship to open standards, vendor lock-in, conformity to popular skill sets, and web services and service-oriented architectures.

Open standards are preferred by corporations who do not want to be tied to a specific vendor or plugin for their mission-critical systems. The building blocks of AJAX, (X)HTML, CSS, JavaScript, and XML, are all open standards supported widely across different browsers and platforms. Some alternatives to AJAX do not enjoy the same level of ubiquity. For example, XUL and XAML are both browser dependent, while Java, Flash, and SVG all require proprietary plugins.
Vendor lock-in has always been an issue for IT investment, and continues to be on the web. By avoiding proprietary technologies on which to build large-scale enterprise applications, firms are mitigating some long-term financial risk. AJAX is a set of technologies that are based on open standards and partially avoids the issue of vendor lock-in.
Another big selling point for AJAX is the way web developers who are familiar with the underlying technologies can begin developing with AJAX relatively quickly, while the learning curve for alternative technologies is comparatively steep. By leveraging the synergies of skill transference, firms do not have to invest in significant retraining of their developers.
Service-oriented architectures (SOA) have been gaining popularity in major enterprises around the world for several years now. SOA is an approach to building large distributed systems on a composite set of loosely coupled business services. Just about every major enterprise software vendor has an SOA strategy and product suite match. In many SOA models, business services are exposed through XML web services, and AJAX clients are ideal consumers of these services.

The question then becomes, is the AJAX platform powerful enough to build enterprise-quality Rich Internet Applications (RIA). This issue is highly debated in the web development community (http://blogs.ebusiness-apps.com/dave/?p=32). Here are some of the arguments against AJAX for RIA:

There is a stigma attached to using JavaScript to accomplish any intensive processing tasks since JavaScript is an interpreted scripting language, and quite inefficient. That said, the average desktop computer is becoming more powerful. In the past, most JavaScript applications only performed very simple tasks where efficiency is not a concern, and so techniques for writing efficient JavaScript are not widely known. As AJAX matures, coding standards will improve and push the language to its limit. As this happens, the efficiency argument against using AJAX for Smart Client implementations will weaken.
As an interpreted language, JavaScript must be sent up to the client as source code. This causes problems for protecting intellectual property, since the source code must be distributed to anyone using the application. There are techniques for obfuscating the JavaScript, but like all copy protection they just make it a bit harder to steal, not impossible. This argument fails for a number of reasons, though.

First of all, Java suffers from a similar problem, with source code weakly protected in its distributed form. This, however, has not stopped businesses from deploying large Java-based applications. Another reason this argument fails in an SOA environment is that the AJAX application doesn't need to possess all the business secrets required for the program; they just need to orchestrate the business services that perform these activities.

This broad argument against using AJAX in the RIA realm may be somewhat short sighted. Within an enterprise, the need for interoperability may outweigh more fine-grained standards centering around performance, IP, and code inefficiencies. Consequently, looking into the future, approaches like AJAX which focus on platform independence and RIA will become important in the realm of enterprise applications.

Conclusion

The trend in web application development is towards open standards and vendor neutrality. Current HTML web applications don't provide the user experience users have come to expect, so the development community has long needed a viable technology suite to develop rich internet applications. AJAX fits all of these requirements and has experienced significant uptake by developers and enterprises over the last year. It's always challenging to predict technology trends, but if we look back at Java's evolution we can see that there are a number of similarities.

A decade ago, Java was going to revolutionize the way that developers built applications. Instead of building different versions of an application in order for them to run on different operating systems, developers could target the Java Virtual Machine, and then their software would run on Macs, Windows, and Unix-based platforms without any further customization. Huge corporate information systems are being built on the Java platform, and a number of large client applications are also built using Java. Java also suffered from performance and usability issues related to poor user-interface libraries, but overall it was quite successful.

As internet applications became more prevalent, we ran into the same problems of being forced to either write software to target a specific environment, or be very limited in the quality of the user experience. Technologies like HTML, CSS, and JavaScript gradually evolved with the promise of providing a platform on which very powerful applications could be based, but that promise was unfulfilled until now. Now that all the major web browsers have relatively consistent support for the technologies AJAX requires, AJAX will become a crucial piece in the RIA puzzle and will offer the potential for dramatically more powerful and user-friendly web applications.

Share your experience with AJAX in our forums.
(* You must be a member of XML.com to use this feature.)
Comment on this Article

Titles Only

Newest First

YES! Ajax is here to stay and changes Web
2006-03-12 03:06:19 jpop [Reply]

New innovations make it possible to build Ajax applications cheaper and better. For example Just look at a recent announcement from a startup, which demonstrated reusable Ajax GUI Components that are better than Java/Swing classes.

http://cbsdf.com/misc_docs/why-gui-api.htm

http://cbsdf.com/misc_docs/gui-api-brief.htm

Using the simple process outlined in the web site any programmer can create better reusable GUI Classes for Ajax components. The GUI Classes can be more flexible and easy to integrate, than the Classes in Windows/VB GUI API. The GUI Classes can be used to build graphics intensive applications.

What will stop any one from building the great Ajax applications? The process out lined in the web site is simple even to doubt if it works. Try it out and build your own Reusable Ajax Widget.

This is just the beginning and every one knows that there are many others hard at work and still in stealth mode. It is still too early to know, since Ajax became popular only in the past few months. It takes time even for real innovations to mature.

Do you really want to write all these code?
2005-10-09 09:53:23 Wai Yip Tung [Reply]

When people boast with the term 'ajax framework' I sneer. There is no framework in software development sense, no library, no API, no references. Ajax is primary a web applications look and feel. Part of it is a technique to overcome the page by page look and feel of regular web applications. Another part is a lot of client side coding to update the screen and simulate desktop widgets.

Before 'ajax' is coined, we have another term to describe these client side coding - DHTML, a collection of tools make up of HTML, javascript, dom, event, css, etc. As any DHTML partitioner can tell you, it is lots of hard work, trials and error, and hair pulling to get these trickery done. Ajax suggests we do this in a massive scale. Adding cross browser, cross platform support into the equation and you'll find it is not really for the faint of heart.

Now we have some very smart people pushing the envelope of existing primitives and built some very cool applications. Everybody else is trying to follow suit. What we really need is a higher level web application and widget framework to make this sustainable.

Two developments come into my radar screen. Both are browser independent. XForm poise to be the next generation of web forms and it could form the basis of richer user interface. The OpenLaszlo platform allows developers to create applications with the rich user interface (http://www.openlaszlo.org/). Although it currently requires Flash as the runtime engine.

As much as I like to see a rich user interface, it is also important to keep in the balance with simplicity. I'm rather weary of sending thousands of lines of javascript to be executed on client. It is not the efficiency as suggested in the article that concerns me. It is the complexity of those code that makes me feel uncomfortable.
- Do you really want to write all these code?
  2006-03-12 02:35:00 jpop [Reply]
  
  The Ajax is here to stay. New innovations make it possible to build Ajax applications cheaper and better. For example Just look at a recent announcement from a startup, which demonstrated reusable Ajax GUI Components that are better than Java/Swing classes.
  http://cbsdf.com/misc_docs/why-gui-api.htm
  http://cbsdf.com/misc_docs/gui-api-brief.htm
  
  Using the simple process outlined any one can create better GUI API, which is better than Windows/VB GUI API to build graphics intensive applications.
  
  What will stop any one from building the great Ajax applications?
- Do you really want to write all these code?
  2005-10-09 14:08:46 JordanFrank [Reply]
  
  You're right, there is no authoritative AJAX Framework, because there's really no consensus about what AJAX means exactly. AJAX isn't a standard, there's no reference implementation, or object model, or API, because it's really a vague term used to describe a set of patterns used to create web applications. These patterns tend to focus on the usability of web applications, and providing the user a rich, interactive experience that keeps the interested.
  You point out that adding cross browser and cross platform support into the mix increases the complexity of the problem, and you're right. That's where most of these AJAX frameworks come in handy. You can sneer at the name, but you'd just be joining in with a massive number of web developers who spend more time arguing semantics than producing anything of value. I suggest that you look at some of these AJAX frameworks, because a lot of the focus on providing wrappers around the idiosyncrasies of the various browsers and platforms, allowing you to write your code in a more straightforward, easy to understand and maintain manner. My current personal favourite, in so far as it is simplistic and doesn't try to do everything, is the Prototype library, used by the Ruby on Rails project. I've written up some really rough documentation on the library, seeing as the project itself is lacking good docs. I posted the documentation on my blog at http://blogs.ebusiness-apps.com/jordan/pages/Prototype%20Library%20Info.htm. I'm not actually affiliated with that project in any way, and the docs are just based on a read-through of the source code, so they may not be 100% accurate.
  Anyways, thanks for your insightful comments. I'll definitely have to check out that OpenLaszlo project.
  
  Cheers,
  Jordan Frank
  - Do you really want to write all these code?
    2005-10-10 07:55:03 Wai Yip Tung [Reply]
    
    By way I want to clarify why I'm bordered by the term 'ajax framework'. I don't mean everyone experimenting and building rich web applications are bonehead. I am bordered by some business and HR people claiming they are building on top of the ajax framework. They don't seems to understand ajax is not a concrete term and the technology is in early stage. Coupling it with the word 'framework' that usually mean something well established is somewhat contradictory.
    
    I believe that the DHTML tricks we are doing are too much toil for most people. And libraries like the Prototype you've mentioned would emerge to make this more manageable. Ideally we would have a standard higher level standard web application definition language to argument HTML and DOM. But that would face many politics and browser upgrade inertia. Two years ago I would worry it would be a Microsoft defined standard. Today plurality seems to back in the picture. I am very encouraged to see internet giants like Google and Yahoo are taking alternative browsers seriously.

s AJAX Here to Stay?, I certainly hope so.
2005-10-07 02:45:43 philip.fennell [Reply]

A useful article, thank you.

It seems that all the comments concerning SVG has rather taken the responses to this article off track. However, I would like to say that the whole XML/asynchronous server communication thing has been available in the Adobe SVG viewer via the getURL and postURL methods certainly since v3. There was an article covering it in XML.com's Sacré SVG coloumn entitled 'SVG Tips and Tricks: Adobe's SVG Viewer'. If SVG lovers don't know about it, they should!

I used this successfully about 3 years ago to develop an SVG based publication planning application. My exeriences then, lead me to believe that there should be no going back from AJAX.

P.S.

I don't necessarily believe that SVG is a good platform for web applications in general, as there are a lot of overheads in creating the various input controls, but as a rendering technology + decalrative animation (SMIL) I think it is superb!

Re: XSLT and SVG Plugin
2005-10-06 10:04:10 JordanFrank [Reply]

Hi Tim and Michael,
Thanks for your feedback. Tim, in regards to XSLT, you're absolutely right. Using XSLT to transform XML into various other formats is something that I work with on a daily basis, and its definitely a missing link of sorts. It is still not as well supported as the standard technologies that I mentioned, and the alternatives such as Google's XSLT.js file (which brings XSLT support to browsers that have JavaScript but not XSLT) just don't cut it as far as performance goes. That's really the beauty of XSLT as far as I'm concerned. You can do the same things in JavaScript as you can do in XSLT, but XSLT is screaming fast. A lot of AJAX toolkits have avoided using XSLT for the reasons I've mentioned above, but as browser support for XSLT grows, I'm sure we'll see more if it being used in the AJAX realm. My friend and co-worker, Dave Johnson has done a fair amount of really good benchmarking of XSLT and other similar technologies on his blog (http://blogs.ebusiness-apps.com/dave/). I'd recommend checking that out, as he's done a great job of backing up his performance claims with empirical data, and there's never enough empirical data if you ask me.

Michael, as far as SVG goes, until the day when Internet Explorer supports SVG natively, and you don't have to install a plugin to view SVG, I think it's perfectly fair to categorize SVG as I've done. Yes, Firefox and Opera both now support it natively, but I don't see it anywhere on the IE roadmap. I appreciate that it is an open standard, and believe me, I would love to see it get the attention it deserves, but it isn't going to get that attention if the most popular browser on the planet doesn't support it natively.

Thanks again for the feedback.
Cheers,
Jordan Frank
- Re: XSLT and SVG Plugin
  2005-10-08 15:54:43 michael_c_harris [Reply]
  
  JordanFrank wrote:
  "Michael, as far as SVG goes, until the day when Internet Explorer supports SVG natively, and you don't have to install a plugin to view SVG, I think it's perfectly fair to categorize SVG as I've done. Yes, Firefox and Opera both now support it natively, but I don't see it anywhere on the IE roadmap. I appreciate that it is an open standard, and believe me, I would love to see it get the attention it deserves, but it isn't going to get that attention if the most popular browser on the planet doesn't support it natively."
  
  I take your point. I'm being nitpicky (and perhaps my vision is clouded by wishful thinking :) but if IE implements SVG in the future, which as it's an open standard is entirely possible, a plugin will not be required. That can never be said for Java and Flash.
- Re: XSLT and SVG Plugin
  2005-10-06 10:49:32 xmlhacker [Reply]
  
  > Michael, as far as SVG goes, until the day when
  > Internet Explorer supports SVG natively, and you > don't have to install a plugin to view SVG, I
  > think it's perfectly fair to categorize SVG as
  > I've done.
  
  I don't think it would be possible for me to disagree more with that statement. The "installation" of Adobe SVG in brainless at best. And with a little auto-detection scripting its easily automated.
  
  Look at Flash. If a user doesn't have Flash installed which, given that Flash has always been a plugin and never a function of the browser itself, they have been required to visit the site to download and install it(read: If it shipped with the browser natively, requiring no effort by the end user, your point might have some validity.) What your suggesting could never happen with SVG in IE is exactly how Flash became embedded in 96% of the worlds browsers -- 95% of that 96 was IE.
  
  What makes Flash capable and yet Adobe SVG incabable? Whether or not Adobe agressively begins to push there SVG plugin, or stear more towards Flash is of no great concern or consequence. Its available, easy enough to write a script to detect for it and if not available, link or redirect to the download site. And with as many rendering engines that are coming from every direction you look, if Adobe decides to bail out on it you can rest assured someone else will take advantage of the bad press and become a household name overnight.
  
  In fact, for a small company who has a few investment dollars available I would recommend this as a fantastic strategy to gain some serious notice in a hurry. Even if they continue to waffle on SVG for the next couple of years like they have for the last, theres still plenty of opportunity to take advantage of their waffling by making sure that those with the ability to get the word out in a hurry know about your product such that when the pressures begin to mount over the next 6-12 months for Adobe to make a decision you can be recommend as an alternative which, as long as your solution ROCKS!!! will be just what the doctor ordered to push your company into hyperdrive.
  
  Don't know any developers capable of writing an SVG rendering engine? Don't worry, I know plenty... I don't have experience in this area and you would need someone with experience to do it right the very first time around. But like I said I know MANY developers in this area. If you're that company, let me know > m.david@xmlhacker.com < and I'll help get you in contact with the right person/people.
  
  ---
  
  One last point. The fact that XMLHTTP doesnt require a browser refresh to update content doesn't make it asyncronous. Try setting async to false and point it at a hefty XML file or even a regular web page with lots and lots of content and graphics and then try to work within your browser while that process is taking place. You can't. The browser will lock things up until the 'syncronous' operation is complete.
  - Re: XSLT and SVG Plugin
    2005-10-06 14:32:54 alexsaves [Reply]
    
    I don't think there is an argument here. It seems to me that the author is just saying that this is the current status of these technologies.
    
    Lets be honest, SVG is not a very pervasive or ubiquitous technology, and I know from experience that if you are in a large national or multinational firm and want to get end users to install plugins or other software, it's a logistical nightmare. To some degree you can control the browser platform they are using since those are well understood and trusted technologies, but beyond that.. forget it. (Am I wrong??)
    
    ok so my opinion is that Ajax appears to offer a middle of the road solution that circumvents the kinds of issues that face large corporations, and allows for some pretty powerful and creative solutions in the way that other technologies mentioned here (XUL, SVG) do.
  - Re: XSLT and SVG Plugin
    2005-10-06 14:14:37 JordanFrank [Reply]
    
    michael_c_harris wrote:
    "It's not really fair to lump SVG in with Java and Flash as requiring a the user to install a plugin"
    
    JordanFrank wrote:
    "Michael, as far as SVG goes, until the day when Internet Explorer supports SVG natively, and you don't have to install a plugin to view SVG, I think it's perfectly fair to categorize SVG as I've done."
    
    xmlhacker wrote:
    "I don't think it would be possible for me to disagree more with that statement."
    
    What could you possibly disagree with. Nothing that I wrote was subjective. I simply stated that Flash, Java, and SVG all require proprietary browser plugins in order to operate on all the major browsers. This is a fact. This is not something you can agree or disagree with.
    
    To address your point about what makes Flash capable but SVG incapable, I have the following to say. I don't think that SVG is not capable of gaining widespread traction. I never said that, and I wouldn't. When Flash came out though, it was the only major technology of the sort that had a huge, smart vendor behind it. I don't remember it facing any tough competition when it came out. If it did, it very quickly blew the competition out of the water. The same cannot be said about SVG. There's VML, which Microsoft has integrated into Internet Explorer, and there's XAML, which will also include the same capabilities. There's also XUL, and Canvas, and a bunch of technologies that can do similar things. SVG doesn't fill a niche that is currently unfilled. Flash did. And so SVG is going to have a much harder time gaining traction. Maybe it will, maybe it won't, but I wouldn't advise anyone to put all of their eggs in the SVG basket. Anyways, this may not be the best forum for debating the merits of SVG, but if you want to continue this conversation, then feel free to email me at jfrank@ebusiness-apps.com.
    
    As far as your point about the XMLHTTP Request object, you are correct. The object does allow for both synchronous and asynchronous behaviour via the async property.
    
    Cheers,
    Jordan Frank
    eBusiness Applications - http://developer.ebusiness-apps.com/
    - Re: XSLT and SVG Plugin
      2005-10-08 11:16:55 xmlhacker [Reply]
      
      My disagreement was with this statement:
      
      "Michael, as far as SVG goes, until the day when Internet Explorer supports SVG natively,<snip/>"
      
      My point is that I don't believe in any way that native support for SVG in IE is as important as you are making it seem. As I stated the ability to view SVG in IE exists and has existed for quite a while. The fact that in addition to the Adobe SVG plugin for IE both Mozilla/Firefox and Opera (Tiny SVG only) now have support will result in more sites offering SVG as a viewing option. While Moz/Fx may never take the majority share of the desktop market the impact that it has had and will continue to have on the development trends can not be taken for granted.
      
      I do agree that XAML is an important technology as well. I'm a HUGE proponent of XAML. But I'm a huge proponent of SVG as well. At the moment, all that SVG can do XAML can do as well + the added benefit of integration into the .NET Framework Class Libraries. But thats only part of the story. The fact that SVG has a degree of separation from any specific platform lends well to its credibility as a cross-browser/cross-platform solution. This is an important point. It really does matter. Add to this the fact that the Mozilla Foundation has put heavy emphasis at bringing SVG support to the Mozilla platform while at the same time making it *EXTREMELY* easy to mix and match XUL, SVG, HTML/XHTML and you have what can easily be seen as a fairly sophisticated cross-platform solution that is right in line with what XAML has to offer as far as functionality is concerned.
      
      What will result from this in the end? Well, with the impact that Moz/Fx has had thus far, I wouldn't turned a blind eye to what could very well become the defacto web-based standard for markup languages. XAML will still very much exist. With Mono's XAML implementation of courtesy of Google's Summer of Code this only makes XAML a stronger case as the basis for the defacto standard for cross-platform desktop applications. At the moment, while the line between web-based applications and desktop applications is becoming more and more transparent, its still exists, and probably will for at least another 3-5 years in one form or another. As such, its risky to say the least to underestimate the impact that the Moz/Fx XUL/XHTML/SVG/CSS solution can and more the likely will have on the future of web-based application development.
      
      Another point to consider is the number of mobile phones/devices that now offer SVG support (via Tiny SVG) [SEE: http://svg.org/special/svg_phones] which as of this post stands at Seventy Two(72). As the mobile market continues to expand their support of SVG this will become and even more appealing option for web developers who are looking to maximize their reach while minimizing their overall code base. This factor alone could have a greater impact than any of the other points made above. Combined.
      
      Time will tell.

XSLT
2005-10-06 00:30:26 TimWarwick [Reply]

How can mention AJAX and using XML in a browser without mentioning XSLT!

Using XSLT via Javascript is the magic to turn the XML into HTML/XUL/XAML/whatever on the client.

Its the missing link.

SVG plugin
2005-10-05 23:29:59 michael_c_harris [Reply]

It's not really fair to lump SVG in with Java and Flash as requiring a the user to install a plugin, though that may be the case for most users at the moment. SVG is also an open standard and it's only a matter of time before it's "standards supported widely across different browsers and platforms". Opera and Firefox 1.5 Beta (at least, I'm not sure about other browsers) already have native support for SVG.