Tag 1 der CodeConnect 2025, die UI5con

Web Components

Eines der am häufigsten erwähnten Themen an der UI5con waren sicherlich die UI5 Web Components. Diese existieren zwar schon länger, sie standen aber immer etwas im Schatten der offiziellen UI5-Controls. Die Web Components wurden aber in den letzten Jahren mehr und mehr ausgebaut, so dass mittlerweile schon viele UI5-Controls auch als Web Components verfügbar sind.

Vorteile

Der grösste Vorteil von Web Components ist, dass diese framework-agnostisch sind. Das bedeutet sie sind nicht spezifisch für das UI5-Framework gebaut, sondern können auch mit anderen Frameworks wie React, Svelte oder Vue verwendet werden. Dadurch wird es möglich Applikationen mit dem Framework seiner Wahl zu bauen, welche für die Anwender aber trotzdem im gewohnten SAPUI5-Look daherkommen.

Zudem basieren die UI5 Web Components auch auf der offiziellen Web Components HTML-Spezifikation. Dadurch kann man davon ausgehen, dass diese Komponenten auch in Zukunft ohne Probleme funktionieren werden, was für businesskritische Applikationen ein sehr wichtiger Punkt ist.

Bei einigen Talks und Workshops war auch die Templating-Sprache JSX (bzw. TSX) ein Thema mit welcher sich die Web Components natürlich sehr gut integrieren lassen. Dies kräftigt auch unsere Empfindung, dass die XML-Templating-Sprache eine der “Schwachstellen” von SAPUI5 vor allem bezüglich Developer Experience ist.

Nachteile

Web Components existieren in der Web-Welt schon sehr lange und werden auch schon von vielen Lösungen eingesetzt bzw. zur Verwendung angeboten. Trotzdem gibt es viele Stimmen dazu (zB. https://dev.to/ryansolid/web-components-are-not-the-future-48bh), dass diese nicht die Zukunft der Webentwicklung darstellen werden. Dafür gibt es einige Argumente:

Das grösste Problem von Web Components ist, dass diese nur client-seitig gerendert werden können, was bedeutet, dass Web Components welche in einer Webapplikation oder Webseite eingesetzt werden, sich immer erst nach dem Laden der Webseite aufbauen. Dies kann zu ungewollten Layout-Shifts führen, was die Benutzerfreundlichkeit der Webseite beeinträchtigt. Für diese Einschränkung gibt es aber in den aktuellsten Browsern eine Lösung im Standard: der sogenannte Declarative Shadow DOM. Damit wird es möglich serverseitig ein Template für die Darstellung der Komponente zu rendern, welche dann client-seitig mit dem “echten” Shadow DOM-Template ersetzt wird. Es gibt dafür auch schon eine Implementation des Lit-Frameworks (https://www.npmjs.com/package/@lit-labs/ssr), welche sich aber immer noch im “Lab”-Status befindet. Relativierend muss hier erwähnt werden, das UI5 Fiori Apps ausschliesslich Single Page Apps (SPA) sind, bei denen das Problem des server-seitigen Renderns keine Rolle spielt.

Die Anwendung dieses neuen Standards ist für komplexe Komponenten leider eher kompliziert, weshalb noch nicht viele Libraries und Frameworks diesen einsetzen. Dabei wären wir schon beim zweiten Problem von Web Components. Die Lernkurve für die Anwendung und Implementation von Web Components ist eher steil und benötigt einiges an Übung bevor man damit in vertretbarer Zeit Web-Komponenten bauen kann. Dies hat vor allem damit zu tun, dass sich der grösste Teil der Arbeit im sogenannten Shadow DOM abspielt. Mit dem Shadow DOM erreichen Web Components, dass diese komplett abgetrennt von der eingebetteten Webseite laufen und diese damit nicht beeinflussen (bzgl. Styling und Verhalten). Um diesen Abstraktion anzusprechen wurden viele neue Sprachkonzepte (CSS-Selektoren, JavaScript APIs) in HTML eingeführt, welche sich zu Beginn als Webentwickler eher fremd anfühlen.

Tooling

Nebst den Web Components war auch das Tooling sowie die Developer Experience bei UI5 ein grosses Thema. Es gab verschiedene Talks sowie auch eine sehr spannende Panel-Diskussion dazu.

VSCode wurde zum "Quasi-Standard" (siehe dazu unseren Blogpost zur SAPUI5-Entwicklung in VSCode) und auch MacBooks sind mittlerweile in der SAP Welt "erlaubt". Tech-Nerds könnten sogar den UI5 Language Server in NeoVIM verwenden. Das UI5 Team setzt beim Tooling konsequent auf JavaScript und versucht komplexe Abhängigkeiten bei Buildsystemen wie z.B. Vite zu vermeiden. Was auf den ersten Blick rückständig erscheint, hat jedoch eine feste Strategie: SAP hat so die Kontrolle über das Lifecycle Management seiner Tools ohne auf Dritte angewiesen zu sein. Smart!

TypeScript

TypeScript scheint in der UI5 Entwicklung mehr und mehr angekommen zu sein. In den meisten Talks waren die Code-Snipptes bereits in TypeScript geschrieben. Zudem gab es, im Gegensatz zu vergangenen UI5cons, keine Talks mehr, welche TypeScript spezifisch als Thema hatten. Das interpretieren wir so, dass TypeScript in der UI5-Welt angekommen ist und als Standard akzeptiert wurde.

Dies ist natürlich eine sehr gute Entwicklung, da dadurch die Qualität von JavaScript-Applikationen enorm gesteigert werden kann. Auch Code-Refactorings und -Erweiterungen sind durch den Einsatz von TypeScript sehr viel einfacher durchzuführen.

Trotzdem stehen im Web weiterhin sehr viele Ressourcen, wie Dokumentationen oder Tutorials noch nicht in TypeScript zur Verfügung. Dies wird sich vermutlich mit der Zeit mehr und mehr ändern.

Accessibility

Es gab auch verschiedene Talks und Workshops zum Thema Accessibility. Das Team dahinter hat in ihrem Figma Workspace (https://www.figma.com/community/file/1301101696020142882) einige Beispiele und Plugins bereitgestellt. Diese erleichtern es Designern Fiori Apps zu konzipieren und Verhalten von Tab-Order, Shortcuts, Key Commands und Text to Speech einheitlich in Figma Designs zu integrieren. Die Entwickler haben so klare Vorgaben und können Accessibility so umsetzen, wie es gedacht ist.

Es ist immer wieder schön zu sehen, dass bei Webapplikationen vermehrt auch Accessibility eine Rolle spielt. Man unterstützt, wenn diese konsequent umsetzt wird, neben Menschen mit Beeinträchtigungen auch die Power-User, was bei der Entwicklung von internen Applikationen sehr wichtig sein kann.

Design

Obwohl an dieser Konferenz technische Talks im Vordergrund stehen, wurde das Thema UX immer wieder angeschnitten. SAP möchte unbedingt die Altlasten von ihrem User Interface abwerfen und zielt mit verschiedenen Offensiven in die moderne Zukunft. Eine dieser Punkte ist auf jeden Fall die Vereinheitlichung des gesamten Auftritts von SAP. Sie vereinen nun das Nutzerinterface vom Kern der Applikation bis zur Marketingseite mit einem einzigen Design System. Neben diesem Thema durften wir erfahren, dass SAP im Moment User Experience Guidelines erarbeitet und intern extrem für eine optimale User Experience pushed. Ihr Ziel ist es, dass auch Zulieferer wie wir von diesem Know-how profitieren können.

Fazit

Alles in allem war es ein sehr spannender Tag mit vielen interessanten Themen. Hier nochmals unsere Erkenntnisse im Überblick:

• 🧩 Web Components gewinnen mehr und mehr an Bedeutung. Dies ist vor allem spannend im Bezug auf die Verwendung mit JSX/TSX als Templating-Sprache.

• 🏗️ Das Tooling für die UI5-Entwicklung wird immer besser. Mittlerweile ist der Einsatz von gängigen Editoren wie VSCode keine Hürde mehr.

• 🧑🏻‍💻 TypeScript ist in der UI5-Welt angekommen, immer mehr Ressourcen rund um UI5 sind in TypeScript vorhanden.

• 🎯 Accessibility ist auch bei UI5-Applikationen ein wichtiges Thema. Nebst Anwendern mit einer Einschränkung kann man damit auch Power-User unterstützen.

• 🎨 SAP arbeitet daran ihr Design über Plattformen hinweg zu vereinheitlichen und stellt auch unterstützende Ressourcen für die Entwicklung bereit.

Vielen Dank an SAP und alle Beteiligten für die gute Organisation, die Verpflegung und die Gespräche. Ebenfalls vielen Dank an die gesamte Community für die spannenden Talks und die interessanten Gespräche.

Weiter mit der re>≡CAP

Am zweiten Tag lag der Fokus auf CAP (BTP) und der Backend Entwicklung. Unsere Zusammenfassung vom re>≡CAP Tag folgt im nächsten Blogpost.