Performance comparison of ABAP WebDynpro and SAPUI5 with Neptune Application Designer
EDIT: Disclaimer, I work as the CTO of Neptune Software. The comparison is viable for SAPUI5 in general tho.
It is difficult to set up a side by side comparison of different UI frameworks without having identical scenarios and backend coding. In this document we will use a common scenario which is to create a sales order. The applications used for comparison is the Lean Order for WebDynpro ABAP – lo_oif_main_app and the Neptune application nadui5_sales_order which is based on the SAPUI5 framework.
The first thing you will notice when comparing the two is a huge difference in perceived performance. Whereas the flow of the WDA Lean Order is constantly interrupted by the dreaded WDA spinning wheel when using the app, the SAPUI5 solution runs smoothly and gives you a native and fast user experience.
When we looked under the hood to find out why, the number of HTTP requests used by a single operation is staggeringly different. For one UI5 request the WDA solution (even when cached) used 30-40. Also a similar number of cached resources are fetched adding additional overhead.
This is illustrated here where the WDA enters the order page and loads 0.9 MB! For showing this screen:
If you look at the requests the sheer number is unbelievable and you quickly see where the UI layer performance overhead comes from.
You see calls here with up to 20 seconds response time, which is unacceptable in a modern application.
Now let’s look at the Neptune solution. The architecture is based on loading compressed native json through ajax calls into the SAPUI5 models.
The initial load of a single application fetches the entire user interface parts and includes the SAPUI5 library if it is not cached thus making subsequent calls extremely lean. But it is a fact that many people are not happy about the size of the SAPUI5 framework.
The ability to send multiple models in one ajax call reduces the number of requests drastically. The application is not directly comparable as I mentioned in the introduction but the functionality is identical. Here we see a response time of 55 ms and a mere 885 bytes received.
In conclusion we see that SAPUI5 used properly can boost performance and the framework should be a serious consideration for SAP desktop development, not only making your portal and Business Client look better, but adding the vital user experience factor – performance.
What exactly was your expectation here? I am not following.
I think it is fairly common knowledge that WDA apps are "heavy" due to the load of the framework itself. As WDA is device agnostic for developers, the "heavy lifting" really comes in with the unified rendering engine (which has to figure out what frontend the user is coming from and render appropriately). Also, keep in mind that standardized (I still use that loosely) options such as HTML5 were not around as WDA was released (largely in part to get folks off of WDJ and the dreaded NWDI complexity that BASIS folks ran screaming from! haha)
But yes, now we have HTML5 (which I have been developing in for a couple of years now...yes, I do development outside of SAP *gasp* and have enjoyed HTML5/CSS3).
HTML5 will alleviate a lot of the extra work the WDA framework was doing before. Keep in mind though....there is NO reason to make it a decision of "this" versus "that". Both HTML5 (SAPUI5) and WDA have their place and time. I think of it as more tools in my toolbox versus replacing one older hammer with a new, shiny hammer.
Just my opinion.Thanks for the blog and the testing you did.
Thank you for the feedback Christopher,
I am merely trying to show that new UI tools (Shiny Hammers) should be considered if a customer want to develop new applications or update existing ones. I was exited when WDA and FPM came out as the major pain point for SAP customers often is the UI. We saw opportunity to finally do something with the static SAP GUI but often got the feedback that the apps were slow.
With the adoption of HTML5 as the defacto standard for RIA's we can again offer a new UX and this time hopefully with high performance.
I suppose it will be fast until first customer check via BADI implemented. 😀 😀 😀
That is server side performance optimization, it should not result in extreme amounts of ajax requests killing UX - even for complex scenarios. Our dev team will take you up on this challenge and produce (hopefully 🙂 ) a fast complex desktop version of SAPUI5 that outperforms WDA with same functionality... stay tuned
why do you compare WDA App with tens (even hundreds) of fields and Server logic with UI only interface with a couple of fields?
I doubt this is true. It looks like "couple of indexed selects" ajax call.
Let's be honest.
DevGuide, 2,5 MB, 5 Seconds to load, and it has no business logic behind.
UI5 is a super solution for small apps, but it can never replace enterprise level apps with a complex business logic.
Nevertheless it's just my opinion.
5 stars for sharing this information.
Yes there is a difference in the amount of fields, but it is a fully functional sales order app (meant for tablet). But the ajax call is loading multiple models with sales statistics etc in one call. you can test the app here .
We have made some fairly advanced Applications (Even introduced search help as a standard component). I would then advice to use the desktop library of UI5 with great table controllers.
But, I think you are right that the low frequent users are the most in need of an easy to use UI and since their needs seldom are as complex as a professional user, those are the low hanging fruits.
Oh thx for those stars 🙂
The message from Teched is pretty clear, SAPUI5 is going to be the main UI technology going forward for all apps. The main focus at the start are "tasks" and not fully blown applications with the hundreds of fields hiding underneath all those tabs and subtabs but I wonder what technological limitations there are now or going to be in a couple of years in SAPUI5/HTML5 that stop SAPUI5 from covering everything and anything you might want to do?
It was pretty interesting to hear about the vision from SAP regarding the search box becoming the main entry point for end users (based on Hana). End users searching for anything inside the business, would receive numerous SAPUI5 "apps" containing relevant bits of information and tasks that could be carried out, effectively splitting up the monster of some of the current transactions into SAPUI5 pieces.
I didn't hear anyone say out loud at teched that further development of WDA has been stopped but did see numerous examples SAPUI5 apps being built to replace current WDA applications. These were not of the "tasks" type or simple apps but more complete apps with a lot of functionality so the writing is on the wall IMO.
I think you heard/saw the "vision". The "reality" will likely be much different....a mix of I think we will continue to see a mix of thin, medium and heavy apps/programs/transactions depending on the users (casual/power). The only real difference now from the past is "from where" the user is trying to access (mobile/online/networked/offline) and where the apps live (cloud vs. on-premise). That is just how it always plays out.
Could you add a disclaimer or "full disclosure" that you are the CTO/Co-Founder of Neptune software in your blogs, Njål? That would help and not make them come of as "hidden marketing".
I guess I overrated my own fame 😉