UI5 Web Components: the Beta is there!

[pmuessig]

UI5 Web Components – the enterprise-flavored sugar on top of native APIs!

Over the last months, we worked hard to create a new offering for you and get it on its way! We call this offering the UI5 Web Components. This is a key pillar of the UI5 Evolution project to enable a lightweight and independent consumption of the UI elements of UI5. As the name already suggests they are built using the Web Components standards.

The time has come, the web is ready! The Web Components work in all major browsers. They are based on a set of web standards like Custom Elements, Shadow DOM, HTML Templates and ES6 classes and modules. Web Components allow to create custom HTML tags, extending the browsers’ standard HTML tag vocabulary. Behind those custom HTML tags, they provide the visual appearance defined via HTML and CSS and also the behavior implemented with JavaScript. Finally, the great thing about Web Components is that they work with any web framework that uses HTML tags.



UI5 Web Components are the new offering of UI5 to provide basic and selected advanced UI elements as Web Components. Just like UI5 Controls, these UI elements are implemented in accordance with the SAP Fiori Design Guidelines and incorporate the SAP Fiori 3 design. Therefore, they are great to ensure visual and behavioral consistency for static web sites and web applications. UI5 Web Components appear and behave just like UI5 Controls. In addition, they come with the familiar enterprise-grade features such as stability, internationalization, accessibility and theming support. Compared to UI5 Controls, the footprint of UI5 Web Components is much smaller because UI5 Controls are embedded in an application programming model, whereas UI5 Web Components are not. And exactly this sets UI5 Web Components apart from UI5 Controls. They enable you to use our UI elements with any HTML based UI technology of your choice.

Classification

It is essential to understand what UI5 Web Components are and what they are not. The following statements will help you understand how they fit into UI5s offering:

UI5 Web Components…

• …are not built on top of UI5, but rather lightweight and independent UI elements 


• …are not a successor of UI5, but rather a complementary offering


• …bring the relevant UI5 qualities and SAP Fiori UX to the HTML level, usable with any web framework

UI5 Web Components are good for…

• …static web sites built without web frameworks, to just add a few interactive UI elements


• …web applications which already use a different web framework

UI5 remains what it is: the best choice for…

• …building complete enterprise-ready and responsive web applications

Get started

Finally, UI5 Web Components have become open source! They are available on GitHub. For now, they are released as Beta version as we want to get your feedback and keep the possibility to adapt. To get started we invite you to visit our home page:



Here, you can discover and get started with the UI5 Web Components. You can explore the code in our GitHub repository, the examples and documentation in the Playground and learn about the integration possibilities into other frameworks.



Conclusion

The UI5 Web Components are the new offering of UI5 to provide you with a set of reusable UI elements which can be used for your static web sites or for web application using any web framework of your choice with a minimal footprint. They allow you to create a consistent user experience aligned to the SAP Fiori Design Guidelines and you can expect an enterprise-grade UI element set which comes with a common look and feel and an aligned behavior. This makes the UI5 Web Components such a great opportunity.

What now?

It’s your turn now. We really would like to ask you to try out the UI5 Web Components on your own and use them. We kindly ask you to provide feedback: What do you miss? What do you like? What should we improve? Or just help us to improve! In any case, please create a GitHub issue to send us your feedback or open a GitHub pull request to send us your contribution or join our #webcomponents channel of the OpenUI5 Community Slack. to discuss the UI5 Web Components with us! We are looking forward to collaborating with you.

 

[amitcruz]

I have seen their usage in UI5Con Bangalore last year.

[alexs0uza]

That's great! The adoption of WebComponents will be an important step in the SAP community.

[former_member383720]

peter.muessig Thanks for sharing this. As you mentioned, UI5 Web Components are not successor to SAP UI5. May I know the long-term plan from SAP, are these going to be used parallely in future or will UI5 Web Components replace SAPUI5 later?

[pmuessig]

ankitgarg the plan is to make this the new foundation to write the UI elements for UI5 as Web Components. These UI elements can/should be wrapped as UI5 controls to use them together with all the well-known features of OpenUI5/SAPUI5 like databinding, MVC, ... UI5 and UI5 Web Components will be usable side-by-side and as mentioned above as foundation. More details to come here, stay tuned…

[david_lincourt]

This is great! Where can I find a simple and complete "Hello World!" tutorial?

[pmuessig]

Hi David,

a Hello World tutorial is in preparation. Stay tuned...

BR,

Peter

[i305675]

This is great for the framework adoption, additionally, the ui5 component modularity is a great in offering choice for responsive web apps. I cant wait for more components to be available!!

[MikeB]

Thanks for the update. There is one confusing statement: «UI5 Web Components are not a successor of UI5, but rather a complementary offering».

I used to assume, that one of the main purpose of UI5 Web Components is to replace the current heavily jQuery-based UI5 implementation.

Do you have any plans to get rid of jQuery in the next versions of UI5?

[AndreasKunz]

Hi Mike,

getting rid of jQuery is a big task because it is used in many places, but on the other hand it does not require any architectural changes, because UI5 is not conceptually depending on jQuery. So no change like introducing UI5 web components would be needed for getting rid of jQuery.

jQuery is only used as low-level library for abstracting from browser differences (this reason became more and more obsolete over the last years) and for making some frequent tasks a bit easier.

For the latter reason, check out these examples: http://youmightnotneedjquery.com/#json or http://youmightnotneedjquery.com/#deep_extend. Some shorthands in jQuery are just really nice to have and save writing lots of code. Using browser APIs to do what jQuery.extend() does adds ~300 bytes of code. In UI5, jQuery.extend() is used much more than 1000 times. Sure, we could create our own library containing such shorthands, but why re-create jQuery and not use what is already there and known by all web developers?

I totally get it that jQuery is really old and not needed anymore for most things, but personally I am a bit surprised by how important it seems to get rid of it: what is the actual benefit of not using jQuery anymore, beyond the pure "it's not hip any longer"? Sure, it does add code size, but it's only 30kB (min/gzip) and at least some of that code is helping the rest of the UI5 codebase to be smaller, so the net weight it adds is even less... 15kB? 20kB? Compared to the total data a UI5 app needs to start - we are talking about sizes like one Megabyte or more - these 20kB do not really contribute a lot. So what's the real reason to invest into removing jQuery?

Don't get me wrong: the code size loaded by UI5 on startup is a problem which needs to be worked on - and is being worked on in the UI5 evolution project. The new build tools can dramatically reduce the amount of code that needs to be loaded. We are talking about several hundreds kB of minified and gzipped JavaScript code here which no longer need to be loaded with the new "self-contained" build. My point is: when we have the choice to invest time in removing 500kB of code or removing 20kB of code, then it should be pretty clear where to invest first, right?

That said, work on removing the dependencies to jQuery is ongoing. I don't know the exact timelines and plans, though. The core is cleaned up first, with the control libraries following later. Some replacements can be automated, some not. However, even when this is completed, we cannot just "remove" jQuery, as this would break lots of apps which also rely on the presence of jQuery in their code. But at least apps could choose to use UI5 without jQuery, then.

This reply has become a bit lengthy, but I wanted to write down my complete view and thoughts, as this topic comes up every now and then. I would really like to understand the various reasons better why an investment in removing all jQuery should have higher priority than investing in other topics. Is it more about perception, or about measurable value?

 

 

The real reason for the Web Components, from my perspective, is rather the following: I believe (otherwise I wouldn't work on it) that UI5 adds a lot of value for app developers. A big part of that value is in the hundreds of UI controls with not only consistent design, but also lots of functionality behind the scenes (actually the pure design is by far the lowest effort in implementing a control, 90% of the work is in the other parts). Another big part of that value is all the stuff in the core, the models, the Views and components, the extensibility, etc. - the programming model. While we of course love to see many people using the entire package (and also think it is the best choice for business web apps), there are people which prefer a different programming model, e.g. closer to HTML, or because they know that other framework X and have lower requirements, maybe don't need most of the UI5 features, maybe just write a web page with a few widgets, maybe have a running app built with framework X where they need to add more enterprise qualities and the Fiori design.

Web components are now well-supported by browsers and just look like plain HTML to web frameworks and hence work with any of them. So why not use Web Components as a vehicle to supply UI5 value - at least the part implemented in the controls - to all those people who do not use the entire framework? Plus, the web components can develop into a revolutionary new way of creating UI5 controls, so they can modernize this aspect of the full UI5 framework and bring it closer to today's standards. So to me, the UI5 Web Components are serving two purposes: modernizing the full UI5 framework and extending the reach of UI5 by tapping into use-cases where the full framework is not needed.

 

 

[MikeB]

Hi Andreas,

thanks for the detailed response.

For me, one of the main reason to get rid of jQuery is its support status rather than just hype, for instance, the latest jQuery version (3.3.1) is already older than 1 year, which is quite a lot in terms of modern Web, where JS is being actively developed and undergoes a permanent evolution and optimizations, e.g. callbacks → promises → await/async. UI5 is based even on an older version (2.2.3), which no longer receives patches, including security-related ones and this can be already critical.

One more thing is support by browsers, for instance, Chrome/V8 loves to deprecate features, and bearing in mind their six-week release roadmap, we can easily find out that sooner or later Chrome will state the end of jQuery support (especially of old versions such as 2.2.3) or introducing breaking changes in V8 JS APIs in the next 12-18-24-30 weeks and it is important to be ready for such scenario.

[former_member2289]

Hi Peter,

Thank you for the post, but I do have one question: How does Web Components relates to SAP Fiori Fundamentals?

Thank you

 

 

 

 

[AndreasKunz]

Hi Mike,

thanks for your explanation and thoughts.

I have to admit I am surprised to see how long ago the last jQuery release was, but then again, as they write, they are now focusing more on what they can remove, rather than adding more features, so with a very mature library like jQuery there is just not the need for many releases anymore.

Be assured that UI5 is closely monitoring the security status of not only jQuery but also those several dozens of other Open Source libraries we are using. So if there would be a security issue, we would react and could e.g. even apply a patch directly in our copy of jQuery in case the library itself is not fixed in time. As jQuery is certainly the most popular and widely used one of these libraries, it is likely to be the fastest in terms of security issues being spotted and communicated and hence not one to worry about, security-wise.

 

Regarding browser support you are right that the world is changing. E.g. when Chrome tried to deprecate and disable synchronous HTTP requests, this triggered quite some hectic activity around the world, including inside UI5, as we have been using this feature a lot for historic reasons. This became one driver of all the efforts to make things more asynchronous in the UI5 Evolution project, even though Chrome finally had to stop their plans because they would have broken way too many web pages and apps.

But it is not like a browser officially supports a certain library and at some time drops support for that library. Chrome never stated that it supports jQuery and there will never be the day when Chrome says it does no longer support jQuery version X. The dependency is the other way: JavaScript libraries depend on certain browser APIs and JS language features. They might indeed break when those features/APIs are removed, but then again, browsers would also break millions of web sites by removing these APIs and this is not what browsers like to do or what helps them being loved by users. It does occasionally happen with obscure experimental APIs, but not with the very fundamental ones jQuery is built upon.

The "sync AJAX requests" topic above was a notable exception where they tried to get rid of a popular API, but in the end they did not want to break like 20% of the entire web (guessed), so they had to revert those plans. And even if they had done it, jQuery itself would not have broken, only apps and frameworks using the "async=false" setting of jQuery.ajax() - but also those apps and frameworks using the same flag on the native XHR, which jQuery is wrapping, so it would not have mattered whether using jQuery or not.

I hope this addresses your concerns.

[MikeB]

Thanks again for a complete explanation. It’s good to realize that SAPUI5 team keeps a finger on the pulse.

P.S. Under «Chrome will state the end of jQuery support (especially of old versions such as 2.2.3) or introducing breaking changes» I meant exactly what you wrote, to bring a breaking change to the JS APIs.

[AndreasKunz]

I'm sure that Peter will give the official reply, but let me give my version:

Fundamentals as it is offered right now is a set of stylesheets (SCSS compiling into CSS) along with a recommendation how the HTML has to look in order to be styled correctly by that CSS. It is your task to write that HTML, it is your task to update the HTML as the user interacts with it.

UI5 Web Components, on the other hand, encapsulate not only the design, but also the structure and the functionality inside new HTML elements you can use like any other HTML elements without caring about how they work internally.

 

Taking the datepicker calendar popup as a drastic example: if you write an app which puts the correct html structure with all the tags for the single days etc. into a web page, then Fundamentals will make this HTML look according to the Fiori guidelines for displaying a calendar. But it's your task to provide the day/month names in the user's language and when the user clicks an arrow to skip to the next month, then it is your task to change the HTML, to fill in the new day numbers to the correct place, to only show 28 days when it is February (or sometimes 29, you have to check the year), and to know whether Sunday or Monday should be displayed in the first column according to the current user's locale. Once you have done all of this correctly, Fundamentals will make sure the result looks again like a real Fiori calendar, showing the next month. Oh, and opening this calendar in an overlay which appears at the correct location once the user clicks in the date input and to hide that overlay again once the user clicked on a day, is also your task. In case you want to enable users to use their keyboard, you might want to register event handlers on your HTML to react on cursor key presses and move the focus accordingly. In case you want this calendar to be usable by blind people, you have to make sure that screenreaders read helpful information, e.g. by changing aria attributes in the HTML, as the user interacts with the calendar. Etc.

 

So all in all, UI5 Web Components are fully functional UI controls, usable like regular HTML tags, while Fundamentals is focusing on the design and leaving you all the freedom to implement the functionality to the degree needed.

If you already have a fully working app which is functionally complete and can adapt its HTML according to the needs of Fundamentals' CSS, then Fundamentals may be a good choice to enable the official Fiori design for the app. If you prefer dropping in the new HTML tags instead of adapting the HTML or you need not only the design, but consistent behavior, or you create a new app (regardless of the framework you want to use), then UI5 Web Components may be a good choice.

[AndreasKunz]

By the way: I was referring to the plain Fundamentals only. I have seen some activity implementing Angular components and React components which take care of the behavioral part and producing the HTML. While I am not sure on their current status, they would of course ease the consumption when you use one of these frameworks. If new frameworks should arise, components for those frameworks could be created as well.

The UI5 Web Components, on the other hand, are independent of specific frameworks, so the one existing implementation can be used in any (also future) framework because what they all do in the end is: working with HTML.

[former_member2289]

Hi Andreas,

Thank you for that great answer. Is now clear to me the differences and the intended use cases.

[former_member194147]

Is there a way to bootstrap web components like jquery ui? How can I use web components by just bootstrapping it like:

<script src="<web components cdn>"></script>

 

[pmuessig]

A very lightweight (but not an official) example how to use the UI5 Web Components is the following:

<!DOCTYPE html>

<html>

<head>

  <meta charset="utf-8">

  <meta name="viewport" content="width=device-width">

  <title>Hello UI5 Web Components</title>

  <!-- bootstrap for modern browsers (ES6 module) -->

  <script type="module" src="https://sap.github.io/ui5-webcomponents/resources/sap/ui/webcomponents/main/bundle.esm.js"></script>

  <!-- bootstrap for IE11 -->

  <script nomodule src="https://sap.github.io/ui5-webcomponents/resources/sap/ui/webcomponents/main/bundle.es5.js"></script>

  <script>

    document.addEventListener("DOMContentLoaded", function() {

      document.getElementById("btn").addEventListener("press", function(oEvent) {

        alert(oEvent.srcElement.innerHTML);

      });

    });

  </script>

</head>

<body>

  <ui5-button id="btn">Hello World</ui5-button>

</body>

</html>

It uses the bootstrap script from our playground application including all UI5 Web Components. Whereas this can be used for testing purposes to get an impression on how using UI5 Web Components feel you should rather package your own bundle for productive scenarios by e.g. using rollup or webpack. I am preparing a blog for this and will share it soon (also here as a comment).

Keep in mind: this can stop working at any time... 

[pmuessig]

Fiori Fundamentals and UI5 Web Components are implementing and based on the SAP Fiori Design Guidelines and bring the SAP Fiori 3 design for web development. The main difference between both offerings are the way they transport the design. As Andreas explained it very detailed already Fundamentals share it on the HTML/CSS layer vs. UI5 Web Components using custom HTML tags which encapsulate the HTML/CSS and the JS behavior.

[former_member194147]

Thanks for your response. In my humble opinion, if the goal of ui5 web components is greater adoption by web developers then it needs to work in the fashion you demoed above i.e. by just bootstrapping it. The non sap world is still very oblivion to the greatness of ui5 and it would remain that way unless the learning curve and adoption is made easier. Having said that, is their a roadmap  or atleast the probability where what you showed above would be formally included ?

 

[former_member604013]

This is great peter.muessig !! Very keen to see how this mix with React+Redux and try to easily use them with websockets!! Excitement up up up!!

[pmuessig]

We are discussing right now, to make the UI5 Web Components also available via CDN. While this is a nice consumption, it is very coarse-grained. It will be one bundle containing the framework and all components. You would be more flexible by creating your own bundles which will also help you to reduce your size. Nevertheless, we are discussion the CDN availability and I will try to keep you posted...

[pmuessig]

Many thanks Rafael! 🙂

The sample applications to show-case the usage with React, Angular and Vue are also online on https://sap.github.io/ui5-webcomponents/ (just scroll a bit down; run them and check out the source code). You can already play around with it...

[ChrisSolomon]

Very cool! I am gonna go throw together a quick Vue.JS app to mess around with these (yes, I can say that now! hahaha)