UI5 in 2020 and beyond

[Margot]

It never ceases to amaze me how fast time is running! I must confess: I actually wanted to write this blog post already weeks ago at the beginning of this year. Well, the year is still quite young, so I hope you’ll enjoy what I am going to share about what UI5 had set out to do for 2020 and which other ideas we have to advance our framework ?

 

Foundation

The evolution of UI5, as many of you will know, has been the key mission of our development teams for some time now. Before that, we used to focus on new capabilities and controls to build highly sophisticated business applications. On the one hand, this ensured the maximum freedom a web developer might expect from a UI framework and made using UI5 as easy and efficiently as possible. On the other hand, this came at the expense of keeping pace with the innovations of the web.

With UI5 Evolution we strive to counteract this trend and already achieved an important goal by breaking down the core framework into independent usable modules and converting it to an AMD-like syntax. At the same time, we started to invest in our own build and development tool to support developers by providing a familiar development environment and the freedom to choose where and how they like to work.

Another area where we see further potential to streamline the framework and return to web standards are web components. They not only facilitate guaranteeing the consistency of UI elements because they fully encapsulate styling and behavior within custom HTML tags. They are also more future proof than any given JavaScript framework as they are based on web standards, which keep thriving and evolving. By creating our own UI5 Web Components library, we aim to utilize this potential primarily to share UI5 qualities with other popular frameworks.

But as the name indicates, evolution never stops. Consequently, UI5 Evolution continues to be a vital part of our road map for 2020 and beyond for the core, the rendering, and the programming model of the UI5 framework in synergy with the UI5 Tooling, which I would like to deal with in more detail.

 

The UI5 Core

As mentioned above, as a first step to transfer the core of UI5 towards a universal toolbox, it was essential to split the relevant pieces of the core into independent and consumable modules. This project is largely concluded. Based on this achievement, as a next step we aim for something we call the minimal core. The idea is to be able to start UI5 with the minimal possible core size and to “grow as you go” by loading additional modules like data binding, MVC, components, and validation only if and when they are really used or needed.

Another important point is the removal of jQuery from the foundation layer.jQuery had its merits and advantages in the early days of UI5 – and some of them are still valid – but today’s standard browser APIs make jQuery redundant in this layer.

 

The UI5 Rendering

One massive achievement in 2019 was the development of a new renderer syntax and enhanced rendering engine for our UI5 controls. It was announced last year at UI5con@SAP and presented by our architect cahit.guerguec. If you missed it, you should watch the recordings to get all the details (keynote at 1:05:34 or rather the full session “Rendering Evolution in UI5”). It forms the basis to integrate the UI5 Web Components as a new standard layer for building agnostic UI elements in UI5. But we are getting ahead of ourselves as I can imagine that not everyone is aware of this innovation and the switch to the new syntax will continue to occupy us in 2020.

We were often criticized for our string-based rendering being complicated, hard to maintain and slow. We have taken this feedback very seriously and worked hard on this. To deliver on promise to remain compatible with our releases, we did not come up with a completely new rendering engine, but enhanced the existing one with a new semantic rendering API that allows a more efficient in-place DOM patching. It adopts the rendering syntax to detect what has been changed in the control mark-up and updates only those parts instead of destroying and recreating the whole DOM tree. A further advantage is that with this new syntax it becomes much easier to write UI5 controls with no custom setters needed, and thus, leads to a great rendering performance. Major and fundamental UI5 controls had already been migrated to the semantic rendering syntax, the remaining controls will follow as soon as possible.

Another topic we’re currently working on is the usage of CSS variables for our themes. CSS variables enable theming across UI technologies and in our case allow theming of custom controls. Today, whenever a theme parameter is changed a theme build is needed to generate the corresponding CSS files. The CSS variables will help to overcome this build step. As a first step, we extended our controls (as well as the UI5 Web Components) to make use of CSS variables provided by the UI theme designer and exposed all our theming parameters as CSS variables. For the moment, this is still experimental but planned to be stabilized soon.

And now back to the UI5 Web Components: As already mentioned, our mid-term aim is to integrate the UI5 Web Components as the foundation for UI elements in UI5. The real controls will act as wrappers to connect the UI5 Web Components with the lifecycle and programming model features of the UI5 framework (like data binding, usage in XML views, …). If you want to get more details on the relation between the UI5 framework and the UI5 Web Components, check out the blog post UI5 Framework and UI5 Web Components by peter.muessig. The challenge here is that the UI5 Web Components are built with the latest JavaScript, whereas UI5 relies on AMD-like syntax. Thus, they need to be transpiled to be used in UI5 controls. One approach of doing this is described by vobu in his blog post UI5 with UI5 Web Components and corresponds with the implementation of the UI Integration Cards – the first UI5 control wrapping a UI5 Web Component (or is it a UI5 Web Component wrapped as a UI5 control? ?). We are still at the very beginning of addressing this conversion, so don’t expect miracles here., But there will be a number of new wrapped components in 2020, so stay curious about the progress.

 

The Programming Model

The programming model in UI5 is a hard nut to crack – and here I don’t refer to complexity. What I am implying is the fact that UI5 still needs to support Internet Explorer 11. We hope it won’t be long until we can announce when this support will end, but as this has to be aligned with the overall SAP browser strategy, you must wait a little longer. However, or perhaps exactly for that reason, we will no longer want to limit UI5 to ES5 syntax but plan to allow also the latest version syntax for writing class declarations and ES6 modules. However, given the above fact, we will have no alternative but to continue to transpile those modules back to the AMD-like syntax for a while. More about this when we come to the UI5 Tooling road map.

A further topic is – dare I say it – TypeScript! As this question has come up frequently for quite a while now, I am more than happy to tell that we started to work on a comprehensive support of TypeScript in UI5. As a first step you can produce TypeScript definition files for all SAPUI5 objects via the UI5 DTS Generator on npm. This is currently in beta and breaking changes are to be expected as it is not as generic as it should be.

We  have learnt that several groups within SAP are also working on their own solution to enable TypeScript in there UI5 projects and decided to join forces. As a first step we started to harmonize all approaches for generating the DTS files, especially those cases where the UI5 APIs cannot be mapped so easily to TypeScript. Another topic to explore is the best toolchain for working with TypeScript in Ui5. A possible approach we have in mind is to transform Typescript to ES6 to UI5.

 

The UI5 Tooling

In the tools area we have reached a key milestone earlier this month: With UI5 Tooling 2.0 you can download and handle OpenUI5 resources as well as resources that are only available in SAPUI5 in the same way to your project. A major prerequisite for achieving this goal was the availability of the SAPUI5 resources on npm. But there had been other obstacles as well. If you are interested in the whole story, I recommend the blog post The UI5 Tooling and SAPUI5 – The Next Step by merlin.beutlberger. He also explains how to get started with UI5 Tooling. Another blog post I would particularly point you to is UI5 tooling: a modern development experience for UI5!, again by peter.muessig. He explains step by step how to set up your local project with the UI5 Tooling. There you can also read about our Yeoman SAPUI5 Templates Generator for the first time. It creates an SAP Fiori application project for you based on the tried-and-true SAPUI5 template SAP Fiori Worklist Application (OData V2/V4) or SAP Fiori Master-Detail Application known from SAP Web IDE, but locally with the tool of your choice.

The foundations for developing SAPUI5 projects with your usual environment have thus been laid! We are looking forward to receiving your feedback and collaborating on ideas and contributions for further capabilities. We're currently considering to integrate the TypeScript to ES6 to UI5 toolchain once specified in the programming model. Further plans include the extension capabilities as for commands and build types, and the enablement of the UI5 Tooling to develop and build UI5 Web Component libraries.

With the Yeoman SAPUI5 Template Generator we also prepare several improvements for the project scaffolding and plan to enhance it with additional templates and options to add views or controllers.

 

Conclusion

As you can see, the evolution for UI5 hasn’t stopped yet and we do not plan to stop it in the near future. We still have a great deal of work to do, but we are excited to do it! For 2020, there is a great deal of emphasis on the evolution of the UI5 rendering and the integration of the UI5 Web Components. It will be not an easy thing to do. Especially the promise to remain compatible is a challenge, but luckily the relevant projects started as side topics like the TypeScript support and the UI5 Web Components and thus don’t need to keep the compatibility promise. Especially for the UI5 Web Components it turned out to be an easy way back into the UI5 framework due to their standard compliance. Moving closer to standards and also established de-facto standards already shows a lot of benefit and this indeed strengthens to continue this strategy with the UI5 Evolution project.

Nevertheless, I hope you appreciate the direction we’re heading in with UI5 and remain faithful to us. Of course I’m interested in your feedback – what are the things you’d love UI5 evolving to and what should we do first? Leave a comment and let’s discuss!