cancel
Showing results for 
Search instead for 
Did you mean: 

Should UI5 be rewritten based on react.js?

Former Member
0 Kudos

As Title.

Accepted Solutions (0)

Answers (9)

Answers (9)

Former Member
0 Kudos

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.

Former Member
0 Kudos

Some good arguments by R. van het Hof however it would be very interesting to have a discussion between the architects of the React with Flux (Facebook) and the architects of OpenUI5 perhaps SAP can arrange something here? This could give a good insight in the pro's & con's of the different frameworks.

Former Member
0 Kudos

React offers better performance. Due to its virtual DOM.

Former Member
0 Kudos

I believe React is the future of the frontend technology, for the following reasons:

1) component-oriented. You create your reusable UI component, which can contain other components.

2) declarative. You describe how your UI would look like, and don't need to worry about how to update a previous screen, nor about UI rendering performance.

Qualiture
Active Contributor
0 Kudos

And how exactly is the component oriented and declarative approach from React any different to the component oriented and declarative approach of SAPUI5?

Former Member
0 Kudos

You can try to write a todo-list in React and in UI5 to see the difference.

In React, the only place that you draw the UI is in a component's render() function. It draws the complete UI for that component, including its sub-components (by spitting out the sub-components within HTML contents, for which the run-time will call its render() function). There is no need to just update a piece of UI fragment where the data changes.

In other words, there is no need to manipulate the DOM tree - insert something here, hide something there, etc. You just tell the browser what you want to draw.

Qualiture
Active Contributor
0 Kudos

Again, how is that different from UI5's declarative XMLView / HTMLView approach and data binding capabilities?

I *never* find myself updating the DOM, just simple declarative code like

<List items="{/}" mode="SingleSelectMaster" select="handleSelect">

    <items>

        <DisplayListItem label="{name}" value="{userid}"/>

    </items>

</List>

If my data changes, or items are added/removed from the model, the data binding automatically updates my UI and my list reflects the changes immediately. No need to do anything

Former Member
0 Kudos

You mentioned a key difference here. In React, data binding is only one-way, not two-way as in UI5.

stephen_kringas
Active Participant
0 Kudos

UI5 supports one-way, two-way, one time binding.

Former Member
0 Kudos

Well, let me put it another way. React only allows one-way data binding. UI5 allows one-way and two-way. There are pros and cons for two-way binding and Facebook found it does more harm than good (for complex applications).

Qualiture
Active Contributor
0 Kudos

Two-way databinding gives me waaaay more freedom -- if I update the model, I don't need to manually update the UI / if I update the UI, I don't need to manually update the model -- so two-way binding always wins in my book.

Especially with large, complex applications.

But since I don't know everything as well I would love to see some source why Facebook has abandoned it in favor of on-way binding.

Former Member
0 Kudos

https://www.youtube.com/watch?v=i__969noyAM

There is a youtub video that talks about uni-directional data flow.

Former Member
0 Kudos

Components in UI5 are much more complex than components in React. Complex in the sense that you need far more stuff to create a components in UI5. In React it can be all in one file that is just Js and JSX. Much more concise that the folder-based approach of UI5.

This stems from the fact that UI5 components serve a different purpose than React components. I personally find React-style components to be sufficient for everything. I prefer them because they are far simpler.

As for declarative, there is a large difference between using an extra XML or HTML file for your markup and using JSX directly in the JS code. JSX may seem messy but it is really not. And less context switching is easily worth it for me.

Reacts development style and code organization is generally just far simpler than that of UI5. Also the documentation is much better and more complete. And it's becoming and industry standard, everyone uses it. UI5 is only used in conjunction with SAP. Why not make use of achiements others have already made?

Former Member
0 Kudos

OK, I know the front-end frameworks and libraries are changing crazy fast. But I think react is not just "another" framework like angular or UI5. To me, react is like a huge step forward. A step from imperative to declarative. It's a big change for my mindset. When the first time I learned the concept behind react, I was like, oh my god, it's the way I always want to build component and structure my application. That is how a component should be.

Just like Dennis said, "UI framework has to evolve", changing from jQuery to Angular is not evolve, but moving from jQuery to React( imperative to declarative) is evolve IMHO.

Apart from the idea about building component, with server side rendering, virtual dom and diff algorithm, react is claiming performance is super fast. Performance is critical to enterprise application I think you would all agree.

I haven't been very deep into react, just learning the basic concept leads me to ask this question. I know as a company, SAP has to consider a lot more than just a technology preference. But as a developer I really would like to make a bold vision and discuss with you guys.

Qualiture
Active Contributor
0 Kudos

Although I'm not well-versed in reactjs either, to me it is indeed "just another framework"

UI5, just like reactjs, recommends you to use a declarative approach, not only with view creation (XMLView and HTMLView types)

And as for writing UI5 javascript, you can perfectly use the imperative way, but a seasoned Javascript developer would probably go for a more imperative coding style anyway. That is not something limited to reactjs, UI5, or any other JS framework

As for serverside rendering, we all remember Web Dynpro's umptillion requests to the server to update the tiniest screen element, so I'm all in favor for browser rendering (IMO that's what browsers are for anyway)

The bootstrapping process may be slow initially, but I found the rendering (and updating!) of UI5 views blazingly fast

former_member182862
Active Contributor
0 Kudos

It is kind of interesting to ask a one liner question and then what am I suppose to "react* 🙂

I do not know how much you have learned about FB react.js. Personally, I spend about 6 months looking at different UI technologies and browser capabilities. From Google Angular.js and Polymer, FB react.js and back to SAPUI5. Looking at shadow DOM and other new HTML5 features across different browsers.

The bottomline is "What are we building?"

SAPUI5 is good for building enterprise application. It is not only the set of controls and binding functionalities. It  also has the tools that it provides to bundle the javascript, css and properties files. The goal is to keep the design of UI framework library clean so that it can be evolved over time. And UI framework has to evolve. We cannot have SAP partners and customers having YahooUI and then AngularJS. And know what? Google is moving to Polymer (like at Google Inbox and Doc). We need to focus on our core business domain and use a stabile UI framework that have APIs that shed us from future changes.

I have shared my thoughts. You? Please be generous 🙂

Former Member
0 Kudos

Will be interesting to see where this goes...

On my personal journey to explore and learn more about JavaScript, in a non-SAP perspective, I'm getting overloaded by all of the frameworks, libraries, etc. that supposedly make things easier for the developer...

That may be well and good, however what happens when the project developer disappears and the support team take over but they are familiar with a different JS library/framework/whatever?

You can level all sorts of negatives at past SAP technology but at least there was some consistency, and you knew if you wanted a BSP/WD4J/ABAP/ITS developer, they'd all pretty much understand the same tools, libraries and features.

It's a brave new world (and probably one that I should reserve for a blog post instead of derailing this discussion any further...)

Cheers,

G.

0 Kudos

Hi Aaron,

Is there a particular reason that you ask this question?  Some outline of your situation would be a bit more helpful in understanding.  In Robin's succinct question, Why?

Thanks, Mike

Qualiture
Active Contributor
0 Kudos

Why?