Skip to Content

Caveat: All comparisons done here used a “pure browser,” basically a regular install of IE and Firefox

I recently read a AJAX @ SAP – an Old Hat!. That fact would seem to be true by date alone; I was able to find an article on SDN that talked about Web Dynpros back in 2003. However, the main point being made was that Web Dynpros did the same sort of thing as Ajax Applications. Let’s do a side-by-side comparison and you be the judge:

Web Dynpro Ajax
Client Rendered   X
Server Rendered X  
“Flicker Free”   X
Uses XML   X
Uses HTML X  
Uses XSLT   X
Asynchronous   X
Nice IDE X  
Direct Connection to SAP X  

Now that we see a snap-shot of each of their features, we can compare an application with a simple user interface containing two tabs and really only one function, searching for something and returning results.

image image

Ajax — The UI

To create this in Ajax I would probably have a static web page that had these two tabs on it. Probably just as two TDs in a table. I would probably have the html code for both the “Search” and the “Options” tab downloaded to the client, but with the “Options” one hidden. I would just make each of the words link to a javascript function that would simply flip the tab, changing the style of each td and hiding and unhiding the necessary pieces. So far, one download from the server, zero flicker.

Web Dynpro — The UI

I would create two views one for each of the tabs of the UI. I would then just drag and drop a tab strip onto a view and link the two views onto that tab strip. Each time the user clicks on the tab strip it makes a call back to the server and sends down the next “view” in this case the tab-strip along with the “Options” view. Some flicker, some extra server noise. Very little, if any custom development.

Ajax — The search

The button “Search” would again be implemented as a javascript function; this would grab all the values the user entered in, and Post a request back to the server. This could be an XML document, or it could be any lightweight protocol the developer wants. (By the way, it can use Https in Firefox at least.) Personally, I would use an XML document because I could then use an XSLT to transform that XML data into an HTML table. I would then use javascript again to append that HTML table to the screen with the list of users found that match that search criteria. Lots of custom development, javascript functions, XSLT sheets and the “service” the application will talk to.

Web-Dynpro — The Search

Assuming you have a function module for this “search,” creating the search is easy. Simply create a table on the main view of your web dynpro, attach an event handler to the find button, map all the inputs into the right inputs for the FM, then attach the FM’s output to the table you just created. Clicking find will cause your inputs to be submitted to the server, the browser waiting for the full HTML document is sent back, the screen will flicker, and the page will be displayed. A little more data carried over the wire, the same number of app turns but that pesky flicker is there again.


As you can see, Ajax and Web Dynpro applications both have their merits. Each one fits into a slightly different space in the spectrum of web-based applications. The one thing that should be clear is that Web Dynpros are not Ajax-esque, nor are Ajax applications as simple to create as Web Dynpros. About the only thing they have in common is they both use web browsers and web servers to deliver their user experience.

Executive Summary

  1. Does Ajax require more custom development?
    • Yes.
  2. Do Web Dynpros allow you to link to an SAP backend easily?
    • Yes.
  3. Is Javascript a very annoying language to be stuck programming?
    • Yes.
  4. Are Web Dynpros Ajax applications?
    • No.
  5. Could enterprise applications ever be created using Ajax?
    • Sure, would just require someone to create a reusable framework of xslt sheets and some time creating a SOAP package developers could use.
To report this post you need to login first.


You must be Logged on to comment or reply to a post.

      1. Former Member
        Guys these are 2 different technologies, no comparison but definately WD has nothing to do with AJAX, just because they have some JS files which they use everywhere doesn’t mean they are AJAX. What I find disturbing is the inability to insert my own JS code in WD. That is really shooting your own feet, why the hell would someone block such a flexible language and not provide an alternative ? Also there are the claims that WD works in all client environments, I would really like to see that….
    1. Former Member
      AFAIK this document(a more recent one) says Web Dynpro uses XML for communication and that too in a delta mode.

      AJAX is not a standard and so there is no definition of what combination of technologies makes it AJAX and that includes XSLT , AJAX can be based on Javascript manipulating the DOM and there by rendering the UI using XML as the payload.

      Most clients have vouched that webdynpro is flickerfree ,compare it with conventional JSP /BSP based applications(not confusing browser requests with flickers).

      And for other points you will need to specify more details Eg: how webdynpro isnt asynchronous.

      And yes I agree web dynpro is definitely in another specturm, if you want to take advantage of the wide accessibility (but with a limited set of controls) across various client devices, and future proofed UI solution (remember since webdynpro is metadata driven it should be easy to fit in a processor and deliver true AJAX , Flash or any other upcoming UI technologies), then webdynpro is a safe bet.

    2. Benny Schaich-Lebek
      Hi Jo,

      the table has some proven faults.

      WD *is* using XML.
      WD *is* asynchronous.
      WD *is* flickerfree (I prefer reload free, that describes it much better)
      AJAX definition *nowhere* says it cannot use HTML


      1. Former Member Post author
        Benny –
        Do you mean WD uses XML on the server to save UI and deal with rendering the HTML or do you mean WD uses XML to communicate with the user’s web browser?


  1. Thomas Jung
    Are we really comparing apples and oranges here?  For anyone unfamilar with Ajax, a great place to start is the Wikipedia article:

    Quoting right from the article “Ajax is not a technology in itself, but a term that refers to the use of a group of technologies together”.  So is being “AJAX” defined by using the exact same set of technologies or by acheving the same end results. 

    I think you could even make a case that BSP with Delta Handling turned on is very close in spirt to AJAX.  You can achieve flicker free refreshes, Dom Infusion, and reduced transmission size.  Yet all this is done within the Runtime – not really requiring the developer to make any coding changes.

    1. Former Member Post author
      I would say the data format can be different meaning you can use XML or HTML or plain text to ferry data back and forth but, to be Ajax it is pretty much a given it uses the XMLHttpRequest object.
  2. Benny Schaich-Lebek
    Hi Daniel,
    as you found the “flicker” I have to tell the whole story. The original “flicker free” came from one of the early inventors of Web Dynpro and what he meant was the effect that you have with an html form – a complete reload of the page after a submit.
    I told him about the difference and he agreed – unfortunately the word was already spread to marketing. Though, the flickering you mention is not what we meant, and by the way does only appear in mozilla browsers. Side effect of our developers mostly working on the company wide used IE – where this does not appear!


  3. Former Member
    The comparison table given is quite strange.
    E.g. it is not true that Ajax has to be client side rendered. There are also Ajax frameworks rendering at server side.
    Furthermore the usage of HTML and XSLT is quite pointless.
    The one thing that makes Ajax different from classical web pages is the usage of asynchronous communication!
    It would have been more interesting to read something about how exactly Web Dynpro performs in this area.
    1. Former Member Post author
      Dieter –
      That table is based on what is considered by most in the industry to be the article the coined or at the very least popularized the term AJAX (  I see your point that AJAX has “bled” into other areas but this blog attempted to take the most commonly used definition of AJAX and compare it with Web Dynpro.  However, I do agree a more interesting article would be how Web Dynpro communicates at a network level.  I am currently writing just such a blog, so you can watch for that!

      Thanks for the comments.


  4. Former Member
    This discussion is much too undifferentiated. Please specify exactly what you want to compare.

    Web Dynpro (WD) is primarily a MVC “programming model” for business applications together with a set of modelling/development tools.

    What is the “AJAX” programming model for business applications?

    Web Dynpro is a “client-independent” programming model. This means, the same Web Dynpro application can be run without change on different “clients”, e.g. in a web browser.

    Are you comparing some Web Dynpro client implementation to this “AJAX” thing? If yes, which WD client implementation?

    There was the WD CSF client for Java, there is the WD HTML client for Java, there is the WD HTML client for ABAP, there is the Windows smart client , there is the Java smart client, there are different flavors of WD mobile clients, there will soon be the ***** client etc.

    If you take all these clients into account, you can make your “X” at “Client Rendered”, “Flicker-Free”, “Uses XML”. Not at “asynchronous”, in the “AJAX” sense of using XMLHttpRequest.

    But: Already the very first Web Dynpro client implementation back in 2001 provided flicker-free rendering, separation of layout and data in the transport protocol, “DOM-injection”, XML-like protocol (in fact we translated the XML already on the server to Javascript). So what?

    My very personal feeling about this Weblog is: “AJAX is hip and cool. SAP is uncool. And there is this SAP guy claiming that SAP has used most of this cool stuff already since years. This cannot be true.”


    1. Former Member Post author
      Armin –
      To respond to some of your points:

      There is currently no “programming model” for AJAX, it is only just a loosely coupled set of technologies.  This is certainly a huge weakness! 

      I’m using for my point of comparison this is simple: an IE and Firefox web browser with absolutely nothing else installed.  A web application should be able to run with no extra “client” installation.

      To your last point, I don’t doubt SAP has used all the technologies somewhere in the past, the only thing I called into question was are Web Dynpros AJAX-esque applications.

      Additionally, after reading everything I could find on SDN about this it turns out, WD don’t use XML at all, when communicating with “a pure browser.”  See “An Introduction to the Web Dynpro Protocol” page 10, section “Second Stage.”  Therefore, I added the caveat you can see at the top of the blog.

      Thanks for the comments, lively discussion is what SDN should be about!


  5. Whatever you wanted to point, it didn’t work out. Comparing to the title of your blog article this doesn’t relate anyhow to your executive summary.

    If you want to have an idea how MVC works great with AJAX, have a look on the Ruby on Rails framework. Here you can see, that using AJAX doesnt require much more work then Web Dynpro.

    Furthermore comments like “Javascript is a very annoying language to be stuck programming” without any context does not help. Take a look on how many JavaScript is used in the Enterprise Portal for example.

    Whenever one starts using a programming language, one should think about the pros and cons. And I will never try to build SAP R/3 adapter with JavaScript but for user interaction in web frontends it does a great job.

    If you need some hints on AJAX just try:


Leave a Reply