Latest Developments in (and around) UI5
Internet Explorer 11 – hmm, what?
Evolution is a continuous and complicated process. Finally, it never ends. Browsers, frameworks, tools – all of them somehow influence the evolution of the UI5 framework. New features of the browsers or innovations of the tools open up new opportunities. The topology of UI5 is clustered in four different layers: the Modular Core, the Rendering & Controls, the Programming Model and the Tooling. All these layers need to be part of the evolution to stay competitive with other frameworks. UI5 shoulders a heavy burden. On the one hand side, developers expect compatibility over years/decades, on the other hand side they always expect new features and innovations. But this comes with a lot more effort to finally meet all these expectations and implement them with the known qualities. But we wouldn’t be UI5 if we couldn’t live up to those expectations. For 2021, more accurately for UI5con 2021 in June, we aim high. Last year, we promised the availability of UI5 Web Components in OpenUI5/SAPUI5 and TypeScript support for UI5 application development. Both topics are being worked on with full speed and I would like to share the current state with you now.
UI5 Web Components in OpenUI5/SAPUI5
The evolution of the Rendering & Controls Framework started in 2018 as part of the UI5 Evolution project. The goal of this project was to decouple the controls and the framework. In addition, we wanted to renovate the rendering engine to get rid of string-based rendering and move to DOM-based rendering. With the evolution of the browser stack and the need to also provide the UI5 controls for other programming models, this finally led us to investigate the latest web standards around Web Components. A long awaited dream come true: a native, browser built-in Control Framework without additional footprint just extending the standard HTML tags of the browser with custom ones, providing fully functional controls! And finally, on top of this we built UI5 Web Components to simplify and structure the development of enterprise-grade Web Components. UI5 Web Components are completely independent from OpenUI5/SAPUI5. With the UI5 Web Components we are able to provide the UI5 Controls as framework-agnostic UI elements. Therefore, the UI5 Controls have been rewritten as Web Components. The UI5 Web Components can now be easily used with any web framework like Svelte, Vue, React or Angular except OpenUI5/SAPUI5.
Finally, with the de-support of Internet Explorer 11, the rendering engine evolution to DOM-based rendering, the usage of CSS Variables and UI5 Tooling, we are now able to put the UI5 Web Components back into OpenUI5/SAPUI5. We will introduce new UI5 libraries which include the so-called wrapper controls for the corresponding UI5 Web Components. The wrapper controls are the connector between the Control Framework and the Web Components. A wrapper control ensures to forward the properties to the Web Component, to put the aggregated controls into slots and to delegate the events. The wrapper control also ensures a well-known paradigm to use the UI5 Web Components in the OpenUI5/SAPUI5 programming model. It allows to use databinding and enables the seamless usage in e.g. XML views.
As of today, the wrapper controls are tightly coupled to UI5 Web Components. The next stage will be to open the wrapper controls to support Web Components in general and to simplify the usage of other Web Components in OpenUI5/SAPUI5.
TypeScript support for UI5 application development
A long-awaited feature is the TypeScript support for UI5 application development. It was first announced at UI5con 2019 with the availability of the UI5 TypeScript project on GitHub. This project has been started to add code-completion support for UI5 for the SAP Web IDE. As this looked really promising, we committed to invest into the TypeScript support.
Supporting TypeScript for UI5 application development turned out to be more complicated than expected. The biggest effort is the clean-up of the JSDoc of the UI5 codebase. As the generation of the TypeScript definition is based on the JSDoc, it needs to contain all relevant information. This task is still in progress and we are pushing for a clean JSDoc for all UI5 libraries of OpenUI5 and the SAPUI5 distribution.
Another important aspect is to define the way UI5 applications should be written in TypeScript. While we have to use the AMD-like syntax (sap.ui.define) and the UI5 classes without TypeScript, we wanted to enable a really modern syntax to develop UI5 applications with TypeScript by using ES modules (import) and ES classes. Finally, we want to use TypeScript as a kind of segue which allows UI5 developers to use a really modern syntax for application development which also benefits from a better IDE support. That allows us to get rid of unwanted Globals and deprecated synchronous APIs. By moving to TypeScript we have somehow a win-win situation by getting rid of the legacy APIs and you can experience a modern development experience.
To achieve all this, we are reworking the tooling to enable TypeScript support for UI5 projects, or more concretely the generator of the TypeScript definitions. Right now, the generator creates TypeScript definitions for the classic syntax (Globals, AMD-like modules and UI5 classes) used in the SAP Web IDE / Business Application Studio development. As our goal is to enable application development with a modern syntax (no Globals, ES modules and ES classes), the generator needs to create those TypeScript defintions in addition to that. Finally, this will allow us to support both scenarios, the recommended scenario is the modern one for sure.
Hint: Be careful with using modern language features for UI5 development which require additional polyfills after transpiling. For standalone scenarios, you can easily embed the polyfills whereas for reuse components this is not possible. For UI5 1.88 (no IE11 support) onwards there should only be rare cases for which additional polyfills are needed.
UI5 Community – a joint GitHub organization
The UI5 Tooling laid the foundation of creating an Ecosystem for task and middleware extensions. With the inspiration of the UI5 Ecosystem, many developers in the UI5 community started to develop and share their own custom tasks and middlewares either as part of the UI5 Ecosystem Showcase project or in their own GitHub repositories.
Recently, as a side effect of a discussion about the location of the Ecosystem project, the repository was moved to into an independent UI5 Community GitHub organization to develop, maintain and host UI5 Community projects in a kind of shared responsibility of volunteer full-time UI5 developers and UI5 community developers.
This GitHub organization should become a place in which the generators/templates for creating all different kind of UI5 projects are hosted, like applications, libraries, controls, tasks, middlewares, … and the promise to keep them up-to-date. As we do this jointly, you will learn from the latest best practices from the UI5 development teams and we can also benefit from feedback and ideas of you.
This is just the start of a joint journey and there are some more ideas around the UI5 Community GitHub organization. If you also have ideas, feel free to reach out to us and discuss them in the UI5 Community Home GitHub project by filing an issue.
“We’re UI5, folks!” We can define the future together!
Yes, UI5 evolves consistently. The latest developments will take the UI5 development to the next level. Internet Explorer 11 is beyond the horizon. Web Components and CSS Variables will become part of your feature set. The UI5 Tooling is the foundation to benefit from a modern, open and extensible tool chain. TypeScript will power up the development of UI5 application. And the UI5 Community will be a place in which all kind of UI5 developers can work together to define an ecosystem around the UI5 Framework and the UI5 Tooling to get the most out of it. Next stop, UI5con 2021, the event to prove how well all those pieces finally fit together…
This is great news! And yeah, the death of IE11 is felt very painfully. Not. 😉
I remember having to maintain a UI5 (BSP) app in SAPGUI using IE11 through Citrix.. You don't know how much I like that image.
I can't wait to try out these new features
where's the frigging double-like button?!?
TypeScript support - can't wait 🙂
Can't wait for the future!
Good news at last !
Hi Peter Muessig
in the UI5 Community Call you showed a preview of the Web Components Retrofit. There you said that the controller code is the same as for the old controls and that it looks very similar.
Why do we need a completely new control library (sap.ui.webcomponents) for the Web Components?
So in the future there will be 2 implementations of a button (sap.m.Button & sap.ui.webcomponents.Button) and I as a developer have to take care which button from which library I use.
Is it not possible, as Volker Buzek has already described in a post, to change the existing controls if their API doesn't change?
sorry for my late reply, but this is really a good question and a tough one... 🙂
We discussed this and indeed this is really an issue which may need a few more discussion rounds. This is one of the reasons, why the Retrofit is not public yet.
The main question is: either we kick the compatibility rules and exchange the sap/m/Button with the sap/ui/webcomponents/Button and may break existing applications (some reasons why it doesn't work easily to exchange 1:1 are: the API differs, the internal lifecycle functions are different and the DOM structure is different) or we have two separate libraries which include a Button each and you need to decide which one to use. If we go for the latter option IMO, this would mean that the newer applications should try to use the Web Components libraries instead of the classic UI5 controls. Future controls will nevertheless be developed as Web Components and then retrofitted into UI5.
But it is not a clear decision yet, it is mainly how I personally see it right now and we need further rounds on this.
I will keep you posted on this and till UI5con we should have a clear messaging, how it finally looks like and which option to choose when.
Hi Peter Muessig
Thank you very much for your answer.
From a developer's point of view, I would prefer a new major version 2 with possible breaking changes.
Of course I understand the compatibility argument, but with a completely new library comes other challenges.
Every developer has to adapt the new library and the transition to the new library (which will probably be the more important one in the future) has to be pushed. Furthermore, this adds another, possibly even redundant, codeline.
And if all controls are to be converted to the Web Components in the future, the new library will certainly become as large and powerful as the existing sap/m library at some point.
So yes, for sure a huge and important topic.