Should UI5 be rewritten based on react.js?

[#1]

As Title.

[Former Member]

Hi,

It's been a long time I do think so. Mostly for four reasons:

1. Simplicity

In my opinion React's rendering philosophy is very close to the SAPGUI (and Web Dynpro ABAP). Everything is redrawn on every event. Not great performance you could ask? In fact, on the contrary. Even if every UI element is "redrawn" everytime, React managed to get excellent performance by updating the DOM only when it's required (due to the virtual DOM handled by the framework). I suppose that the SAPGUI works like this too.

So what's the advantage for us, the developers? It results in a great simplification of the development process. It just makes code easier to reason about.

2. Framework size.

SAPUI5 framework requires to upload to the client almost >= 10Mb (data excluded)! It's just too much. I know you have the ability to reduce the size, optimise the loading process... but in SAP enterprise perspective, we should not have to deal with that. Did you hear about a developer working on the optimisation of the SAP DIAG protocol?

React is a lightweight framework. But to be honest, if SAPUI5 is rewritten in React, the new version will be heavier than the simple framework itself, because of the rich UI library. But anyway, most of the overall binding related code should be removed (see next point).

3. Data binding.

When you need to go a little beyond the simple binding, you can finish with a headache because of the complex binding: formatters, parts, table/array data binding... With React it's way simpler. Since everything is redrawn, with simple code you just set the UI element value (or any other property). That's it.

4. oData.

After more than three years of active development on OpenUI5/SAPUI5 against SAP servers, it appears to me that the oData protocol, including its implementation in the Netweaver Gateway, is not adapted for business applications, as we expect to have in a SAP environment:

- No lock handling

- Useless complexity for deep structures manipulation (read with expand option, deep insert...)

- Stateless services (impossible to cache some data)

- Impossible to use metadata in the UI (like SAP DDIC). The annotations are just too ... to use.

oData may be a good option for reports or dashboard like applications. But when dealing with more "serious" applications, you could spend a lot of time just trying to make data communication "just" work properly. Things that are non-brainer in SAPGUI / Web Dynpro ABAP are just pain to do within the SAPUI5/Gateway environment. It's just not adapted for SAP applications.

Besides, loading multiple oData model entities could results in multiple server calls. As a result you may have to deal with multiple asynchronous calls that may be complex if you have some dependencies. And if you are thinking about "batch" request, it does not work all the time...

The "Flux" data framework (with a stateful service) seems a better fit to me.