Skip to Content
Product Information
Author's profile photo Margot Wollny

UI5 in 2020 and beyond

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 ?



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 Volker Buzek 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.



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!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Volker Buzek
      Volker Buzek

      official DTDs for XML views would be excellent, further easing dev time experience (code completion for XML views!)

      also, providing API docs for doc tools like Dash (mac) and/or Zeal (Win) would be super handy

      keep on rockin'!

      Author's profile photo Margot Wollny
      Margot Wollny
      Blog Post Author

      Thanks Volker for your feedback and also your requirement. I like your requirement with regard to the API docs and will discuss this with the teams to check if something like this was already considered and if not to add it to the backlog. I'll keep your posted!

      Author's profile photo Peter Muessig
      Peter Muessig

      Regarding the XMLViews: I think we should drive the DTD stuff forward as a community project on the repository of Christian Schuff (the according blog post). We could also contribute the DTD generation there. Unfortunately, the DTD was never perfect and thus we finally dropped the support. Maybe as a community project there could be more drive on this topic…

      Author's profile photo Volker Buzek
      Volker Buzek

      (wanted to reply to this comment, but failed miserably, so please see comment below. argh. coffee.)

      Author's profile photo Volker Buzek
      Volker Buzek

      I'm aware of Christian's project and was wondering how we could proceed from on - if Frank could help with a way of extracting the XSDs, then we could probably "fork" Christian's WebStorm-only project in a more generic one, providing XSDs IDE-/Editor-agnositc

      Author's profile photo Jacek Wozniczak
      Jacek Wozniczak

      As a tool builder (UI5 in Brackets) I vote for rich XML schemas/whatever for pushing XML view completions to the max.

      As a developer - UI5 tooling and focus on testing extending (uiveri5!) and making more friendly (like recent OpaBuilder in the API) makes the greatest value for me; not interested in Typescript-friendly features, but fully agree that this might be valuable for developers.

      Author's profile photo Margot Wollny
      Margot Wollny
      Blog Post Author

      Thanks for your feedback Jacek. Indeed testing is an important component and for sure we'll further invest here also there are currently no groundbreaking innovations I can share.

      Also good to hear that not everyone in the community is waiting for TypeScript 😉 but got your point with regard to XML schema. Let's see what we can come up with if we join forces as Peter suggests.

      And by the way - great work you are doing with your tooling. Also I am not using brackets myself I am following your activities with a great deal of interest. Keep up the community spirit!

      Author's profile photo Jacek Wozniczak
      Jacek Wozniczak

      Thanks, looking forward to see next stuff you deliver!

      Author's profile photo Daniel Gent
      Daniel Gent

      Thanks for this information.

      Glad to hear TypeScript is on the horizon.

      One thing you also briefly mentioned is OData v4. Is there any information regarding Fiori Elements & OData v4? I know of the list report & object page in the sap.fe sub-tree in current versions of UI5, but compared to what's available for v2, it's just a fraction.

      I would assume, that with the push towards CAP and its focus on OData v4, the demand for OData v4 compatible "Smart" components will increase pretty quickly.

      Author's profile photo Margot Wollny
      Margot Wollny
      Blog Post Author

      I can tell that we are working with high pressure on OData V4 and especially on the new smart stack supporting OData V4. I know that for FE with OData V4 there is a beta planned (see this blog post here) but do not have the details as the responsibilities are with a different development department. Maybe Peter Spielvogel can give some information on this.

      Author's profile photo Helmut Tammen
      Helmut Tammen

      Thanks Margot for this valuable informations. Must say that the UI5 team really rocks. Even though other frameworks are a bit, in some case more than bit, further with their adoption of WEB (industry) standards you and your team did a great job so far and it’s great to see that you don’t stop.

      As you know I’m mostly interested in Typescript support but also have an eye on UI5 WebComponents and the tooling in general.

      Following I give you a use case which might be a motivation to keep on with supporting (industry) standards and open source.

      At the moment I’m discussing with a partner to develop some new applications and to convert old applications written for Microsoft Windows to a modern, future-oriented architecture. There are more than 30 man-years of development work in these applications. So a gradual change is necessary.
      My approach here is to use SAP Web/cloud technologies to offer the products independently of SAP infrastructure at first, but gradually also to offer them to SAP customers.
      With UI5, SAP has a product that is ideally suited for this. This is complemented by CAP, which hopefully can soon be used under an open source license.
      Your efforts regarding UI5 tooling make it much easier to attract non-SAP developers to SAP’s technologies, as they do not have to leave their familiar environments. Only a few more skills and the use of a few more tools are required.
      This example shows how the consistent pursuit of an open source and standards-driven approach is able to win new customer segments. This is a great benefit not only for me as a consultant, but also for SAP as a technology provider I think.
      Stay healthy and negative
      Author's profile photo Margot Wollny
      Margot Wollny
      Blog Post Author

      For us it is imperative to get these use cases as it helps us a lot also with internal discussions. So thanks a lot for sharing this with us and the community! Also thanks for your positive feedback on our strategy and to the team, this for sure is a great motivation for all us to continue the same way 🙂