What is so special about Web Dynpro?
From my point of view, there are several points that make Web Dynpro different from other known Web UI frameworks such as Struts(CX) or JSF (I am open to correction). I will discuss the most important of these below.
Web Dynpro supports model-driven software development
Model-driven software development is not really new, but is gaining in importance through the Model Driven Architecture Initiative of the OMG (Object Management Group). The aim is to generate executable code from abstract models (usually UML or XML). Parts that occur repeatedly are extracted from the applications so that they can be formed into a model, saving the developers Copy&Paste orgies. By generating code from a metadata model, it is (theoretically) sufficient to exchange the generators in order to use the applications in other runtime environments (such as .NET). Of course this is not true for runtime-specific code implemented by developers within the protected regions (everything between the //@begin .. //@end commands in case of classes generated by Web Dynpro). The runtime support for the development process in the NetWeaver Developer Studio is most impressive. The implementations are synchronized on the fly with declarative changes to the model. There is even a kind of code recycling; for example if a method is removed with a declaration, the implementation is not discarded, but sort of made inactive and copied back to the method when it is needed again!
Web Dynpro creates (reusable) real components
Well, at least it offers the prerequisites so that a WD component can be re-used. Of course it cannot guarantee that a component will really be re-usable. A well thought through design is required here. A tool(set) can only be as good as the person using it. Here, too, the developer is supported throughout the entire development process. A WD component is a special form of a development component. This makes it possible for related components to be built to be cascading if necessary, and in the correct order in the build process. You can imagine how much time is saved during this process, which you would have to use to create your own build scripts.
By definition, Web Dynpro applications can be integrated into SAP Enterprise Portal without changes
This could seem unimportant to those who do not currently access SAP EP. I, however, am glad to know that it works when needed. And: A WD application can use the available portal services without a single line of code being written.
Web Dynpro would not be what it is without the toolset
Definitely. The toolset is one of the greatest strengths of the framework. I estimate that at least as much effort went into implementing the toolset as into implementing the WD runtime environment. The effort invested in equaling or surpassing the broad functionality provided in the ABAP Workbench pays off for each developer, even if at the moment some developments may not appear to be completely mature.
After so much (well-earned) praise, a little criticism is also allowed:
Web Dynpro is still suffering from some childhood diseases
SAP shipped first pilot versions of the Web Application Server for Java at a very early date. Oh, when I look back at the first version of Web Dynpro! A lot of things did not work right. The situation has improved immensely in the meantime, but there are still a lot of problems, as you can see from the postings in the Web Dynpro forum.
Therefore my final request. With your criticism and suggestions, you can help to improve Web Dynpro. The SDN is the ideal platform for this purpose. Over the years, SAP has given up its mushroom policy; never before was such direct contact to SAP product managers and developers possible. Please take advantage of this opportunity.