UI5ers Buzz #40: UI5 Evolution – The Modular Core

In this blog post, I’d like to give you some more insights into the fundamental piece of the UI5 Evolution project: the modular core. This is about transforming the core into future-proof foundation to organize the JavaScript modules and about enforcing proper dependency management which enables applications to run with just the minimum amount of resources.

Let me compare the situation of today with 2009, when UI5 was started: we developed module loader by ourselves based on Globals using synchronous requests to load the required JavaScript modules once needed. We overcame the synchronous loading by introducing the preload concepts. With the preloads, we tackled two issues: we reduced the number of files and enabled asynchronous loading. Especially in http/1.1 scenarios, loading fewer files is pretty essential to not run into the domain restriction. Loading asynchronously speaks for itself as the main thread of the browser remains unblocked. But all these improvements were just taping the core. We felt the need to re-innovate the core to make it future-proof and move it closer to standards.

In the modular core, we basically address the following topics: Collection of Bricks, Universal JavaScript, Asynchronous APIs and Asynchronous Loading.

Collection of Bricks & Universal JavaScript

The topics Collection of Bricks and Universal JavaScript are focusing on splitting the modules into fine-granular modules and free them of DOM and jQuery APIs to allow to use them for DOM-less environments.

Collection of Bricks enforces the AMD-like module syntax for the declaration of modules and their dependencies (AMD stands for Asynchronous Module Definition). This ensures that dependencies are properly declared and are not referenced as a Global anymore so that dependency analysis can retrieve the used modules. It also ensures that declaring the modules and resolving the dependencies can be done asynchronously.

Universal JavaScript enables to shift code execution from client runtime into the build-time or server runtime. Therefore, the former jQuery.sap modules have been refactored into standard AMD-like modules. For most of them, the dependency to jQuery has been removed. Many utility functions, like jQuery.sap.uid, have been externalized into separate modules, for example sap/base/uid.js.

The transformation of the core started with 1.54. For 1.56, the team worked hard to split the functionality of the jQuery.sap modules into several AMD-like modules. Until 1.58 the AMD-like modules were purely private and the jQuery.sap API still was the standard way to consume those functionalities. With 1.58 the new modules became public and were available for individual consumption by applications. For legacy applications, we introduced a stubbing layer. The duty of the stubbing layer is to avoid loading the full jQuery.sap module which has been established for compatibility reason. It acts as a façade by simulating the API of the jQuery.sap module and loads the fine-granular modules behind once needed.

Related UI5ers BUZZ #38:
https://blogs.sap.com/2018/11/19/ui5ers-buzz-38-modularization-of-the-sapui5-core/

Some more details about adapting to the Modularization of the Core can be read here:
https://sapui5.hana.ondemand.com/#/topic/b8fdf0c903424c9191f142842323ae22

The new modules API being the jQuery.sap API replacement can be read here:
https://sapui5.hana.ondemand.com/#/topic/a075ed88ef324261bca41813a6ac4a1c

Asynchronous Loading & APIs

The topics of Asynchronous Loading and APIs are about the innovation of the UI5 module loader and the related APIs to load Libraries, Components, Views, Fragments, i18n texts and many more. The goal here is to avoid a blocking behavior of UI5 applications.

Similar to the Collection of Bricks, Asynchronous Loading requires the introduction of the AMD-like module syntax which introduces an asynchronous break in between loading a module, loading its dependencies and the definition of the module. This allows the UI5 module loader to use asynchronous requests and load the dependencies behind the scenes.

The innovation of the module loader started with UI5 1.54 by separating the legacy module loader API’s (jQuery.sap.declare and jQuery.sap.define) and the AMD-like module loader API (sap.ui.define and sap.ui.require). The AMD-like module loader has been externalized into a new module called ui5loader. The ui5loader was still working synchronously in 1.54 and could be switched into an asynchronous mode via an experimental switch. With UI5 1.56, the ui5loader has been released. The UI5 loader can be configured to simulate standard AMD APIs (define and require) as well as enable the asynchronous loading by configuration. In the future, the asynchronous loading will become the default but requires that modules have been adopted to use the new AMD-like module syntax. Otherwise, legacy modules could still run but require loading the sync loader and fallback to synchronous loading for those modules and their dependencies.

Besides the module loader, UI5 also introduced new Asynchronous APIs. These are new factory functions for loading and creating Libraries, Components, Views, Fragments, i18n texts and many more. The new factories have been designed to explicitly require the factory functions and are work only asynchronous. This allows a proper dependency determination and that UI5 can introduce loading optimizations behind the scenes to improve the performance of applications.  The legacy factory functions are still available for compatibility reasons but have been deprecated.

A full list of legacy factory replacements can be found here:
https://sapui5.hana.ondemand.com/#/topic/491bd9c70b9f4c4d913c8c7b4a970833

Conclusion

In the last innovation cycle of UI5, the Modular Core has been significantly refactored to provide more fine-granular modules to allow creating minimalistic bundles for applications. This makes some of these modules available for DOM-less environments to support the shift from runtime execution to build time, establishing new asynchronous APIs to overcome blocking of the browser. This comes in handy when loading resources and an asynchronous loader which improves the performance of module loading. All these steps are preparing UI5 to move closer to web standards which allows to leverage the latest web features and all the great stuff developed in the open source communities.

We Need You!

Please help us to modernize existing UI5 applications to migrate the modules towards the AMD-like syntax, using the fine-granular modules of the core and the new factory functions. Your applications will benefit, and this will allow you to leverage the latest features of the UI5 Build & Development tooling to create minimalistic bundles for your standalone UI5 application. More to come soon… J

** AMD-like module syntax: it is a deviation of the AMD syntax since UI5 is using own API’s (sap.ui.define, sap.ui.require) to avoid conflicts and to manage slightly different behaviors.

Previous Post: UI5ers Buzz #39

Peter is one of the initiators who started the Phoenix project (a.k.a. OpenUI5/SAPUI5). Today he is working as Lead Architect for OpenUI5/SAPUI5. His focus topics are the UI5 Evolution project and the UI5 Web Components.