Anmelden
(Bild: FotoDuets/Shutterstock.com)
Die Entwicklung von Web-UIs erfordert zu viele Frameworks und Tools, die zudem aufwendig und komplex zu integrieren sind. Könnte sich das im Jahr 2024 ändern?
Stellen Sie sich vor, Sie planen die Entwicklung einer neuen Web- oder Cloud-basierten Anwendung. Dabei haben Sie für das Backend bereits alle Technologien festgelegt, doch bei der Auswahl für das Frontend herrscht noch Unsicherheit: Sollten Sie auf bewährte Frameworks wie React, Angular oder Vue setzen, oder wäre ein jüngeres, weniger etabliertes Framework wie Svelte oder Solid.js die bessere Wahl?
Diese Frage ist keineswegs neu, und es gibt keine eindeutige Antwort. Doch unabhängig von Ihrer Entscheidung gehen Sie stets eine Bindung ein, was einen sogenannten "Vendor-Lock-in" zur Folge hat, ohne die Garantie, dass das gewählte Framework auch in Zukunft noch unterstützt wird.
Darüber hinaus gibt es immer noch keinen allgemeingültig etablierten Ansatz für die Web-UI-Entwicklung, was die regelmäßige Veröffentlichung neuer Frameworks belegt. Zusätzlich zur Framework-Auswahl benötigen Sie allerdings auch noch eine Vielzahl von Werkzeugen: vom TypeScript-Compiler über SASS- oder LESS-Precompiler bis hin zu Package-Managern wie npm oder Yarn, Build-Tools wie Vite und eventuell speziellen Bundlern. Viele Entwicklerinnen und Entwickler verlieren angesichts dieser stetig wachsenden Komplexität und der Flut neuer Tools die Freude an der Webentwicklung, deren Merkmal vor vielen Jahren einmal Einfachheit und Leichtigkeit waren.
Angesichts dieser Entwicklung stellt sich die Frage, wohin der Trend führt und ob es nicht an der Zeit ist, innezuhalten und zu überlegen, ob die Branche möglicherweise seit Jahren in die falsche Richtung läuft. Gibt es vielleicht einen Weg, die Dinge grundlegend zu verbessern?
Tatsächlich war die Webentwicklung früher grundlegend anders als heute: Sie war unkompliziert und direkt. Ein einfacher Texteditor, ein paar Änderungen an HTML, CSS oder JavaScript und ein Speichern und Neuladen im Browser genügten, ohne jegliche Notwendigkeit für Compiler oder spezielle Werkzeuge. Diese Einfachheit, die vor etwa 25 Jahren bestand, stand im starken Kontrast zur damaligen Desktop-Entwicklung, die praktisch immer einen Compiler erforderte und dadurch Wartezeiten bis zur Ausführung mit sich brachte. Diese reduzierte und unmittelbare Art der Webentwicklung war faszinierend und stellte einen ihrer größten Reize dar.
Heute hat sich das Bild jedoch gewandelt. Die Entwicklung ist nicht mehr so intuitiv. Für das Schreiben von HTML ist beispielsweise oft JSX oder eine ähnliche Abstraktion erforderlich, was wiederum einen Precompiler voraussetzt. Dieser muss über npm installiert werden, wofür Node.js notwendig ist, das idealerweise über den Node Version Manager (nvm) installiert wird. Bereits diese Kette aus Technologien, die lediglich für das Schreiben von HTML benötigt wird, verdeutlicht die Komplexität. Nicht einmal berücksichtigt sind hierbei CSS oder JavaScript, geschweige denn das umfassende Ökosystem mit Tools für Linting, Formatting und weiteren Funktionen. Kurz gesagt: Die Freude an der Frontend-Webentwicklung ist durch diese Komplexitätssteigerung merklich gesunken.
Das Bedauerliche an der heutigen Webentwicklung ist, dass viele der verwendeten Praktiken und Tools eigentlich gar nicht mehr zwingend notwendig wären, da moderne Webbrowser inzwischen eine Vielzahl von Funktionen nativ unterstützen. Im Laufe der Jahre haben wir den eigentlichen Zweck hinter der Nutzung all dieser Frameworks und Werkzeuge jedoch aus den Augen verloren. Es hat sich eine Gewohnheit etabliert, bei der stets die Eignung des eingesetzten Tools hinterfragt wird, ohne je zu überprüfen, ob ein Werkzeug an sich noch erforderlich ist.
Doch zumindest mir scheint es so, als könnte sich das im Jahr 2024 allmählich ändern. Es zeichnet sich ein Momentum ab, das darauf hindeutet, dass die Webentwicklung als solche in den nächsten zwölf Monaten eine grundlegende Wandlung erfahren könnte. Das Ergebnis könnte ein wesentlich stabilerer und zuverlässiger Technologie-Stack sein, der uns langfristig begleiten wird. Im Folgenden möchte ich daher einen Ausblick darauf geben, wie diese Entwicklung aussehen könnte.
Wenn man Entwicklerinnen und Entwickler nach dem Hauptgrund für die Nutzung von Frameworks wie React oder Angular fragt, beschreibt die am häufigsten gegebene Antwort die Möglichkeit, eigene Komponenten definieren und orchestrieren zu können. Dabei geht es um das Erstellen autonomer, in sich geschlossener und insbesondere wiederverwendbarer Codeeinheiten, die modular zu einer umfassenderen Einheit, sei es eine Webseite oder eine Webanwendung, zusammengesetzt werden können. Das Wesentliche dabei ist, dass das Orchestrieren dieser Elemente eigentlich eine Grundfunktion von HTML darstellt – es bedürfte also lediglich einer Methode zur Definition eigener HTML-Elemente, um die nativen Möglichkeiten von HTML um benutzerdefinierte Komponenten zu erweitern.
Genau hier kommen die sogenannten Custom Elements [2] ins Spiel. Ein Custom Element ist ein durch JavaScript definiertes, eigenständiges HTML-Element, das anschließend wie jedes standardmäßige HTML-Element genutzt werden kann. Das bedeutet, dass zur Erstellung wiederverwendbarer HTML-Komponenten grundsätzlich kein spezielles Framework erforderlich ist: HTML selbst bietet bereits diese Flexibilität.
Nun könnte der Einwand erhoben werden, dass HTML allein nicht ausreiche, da Komponenten in der Regel auch individuell gestaltet werden sollen. Dabei ist es oft ein Anliegen, sicherzustellen, dass die Stile verschiedener Komponenten sich nicht gegenseitig beeinflussen. Mit anderen Worten: Man wünscht sich für jede Komponente einen eigenen, klar abgegrenzten Bereich für CSS. In vielen Frameworks hat sich dafür das Konzept der CSS-Module durchgesetzt. Dies erfordert jedoch in der Regel einen Bundler, der diese CSS-Module auch entsprechend unterstützt.
Doch auch hier ist eine solche Komplexität nicht zwingend erforderlich, da Webbrowser nativ in der Lage sind, eigene CSS-Bereiche zu verwalten. Dies ermöglicht es, jedem Custom Element einen abgeschotteten CSS-Bereich zuzuweisen, was durch die Verwendung des Shadow DOM [3] erreicht wird. Die Kombination aus Custom Elements und dem Shadow DOM bildet die Grundlage für das, was gemeinhin als Web Components bekannt ist. Streng genommen gehört dazu auch das HTML-Template-Element [4], aber im Kern erlauben Web Components genau das, wofür häufig zusätzliche Frameworks eingesetzt werden: das Definieren von wiederverwendbaren Komponenten mit einem eigenen CSS-Bereich.
Man könnte nun argumentieren, dass Web Components, obwohl sie bereits seit 2011 existieren und durchaus ihre Vorzüge haben, in der Praxis oft wenig Freude bereiten, da ihre APIs als altbacken empfunden werden können. Ich stimme dieser Ansicht vollkommen zu. Glücklicherweise existieren jedoch elegante Abstraktionen für Web Components, die ihre Nutzung erheblich erleichtern. Ein Beispiel hierfür ist das Framework Lit [5].
Hier könnte der Einwand folgen, dass die Verwendung solcher Abstraktionen dem eigentlichen Zweck zuwiderläuft, da man dadurch wieder auf ein Framework angewiesen ist. Das ist grundsätzlich korrekt, doch im Gegensatz zu Frameworks wie React oder Angular erzeugt man mit Lit Komponenten, die nicht an ein spezifisches Framework gebunden sind. Diese Komponenten sind universell einsetzbar, egal ob mit anderen Frameworks oder ganz ohne. Dieser Aspekt stellt für mich persönlich eine deutliche Verbesserung dar.
Zu Beginn habe ich meine Vorbehalte gegenüber dem Build-Schritt in der Entwicklung erwähnt. Die Annahme, dass die Nutzung von Lit als Framework zwangsläufig einen solchen Schritt nach sich zieht, hielt ich lange für gegeben. Doch diese Annahme ist nicht korrekt: Lit kann bei Bedarf tatsächlich vollständig zur Laufzeit ausgeführt werden, ohne die Notwendigkeit eines Compilers, was den Entwicklungsprozess erheblich vereinfacht. Noch bequemer wird es, wenn man erkennt, dass Lit nicht einmal über npm installiert werden muss, sondern direkt über einen Import aus einem Content Delivery Network (CDN) eingebunden werden kann.
Gegen den Einwand, dass dies zu einer Abhängigkeit von Versionsnummern in der Import-URL führen würde, gibt es eine elegante Lösung: das Verwenden einer Import Map [6]. Dieses weitere Feature moderner Browser ermöglicht es, einmalig und zentral zu definieren, dass es beispielsweise einen Import namens "lit" geben und auf welche URL dieser verweisen soll. Anschließend kann in jedem Skript mit Lit gearbeitet werden, als wäre es lokal via npm installiert. Damit ist das Problem gelöst – ganz ohne npm und ohne Build-Schritt.
Die Möglichkeit, JavaScript-Code als ES-Module dynamisch zur Laufzeit nachzuladen, hat in den letzten Jahren die Tür für flexiblere Entwicklungsansätze geöffnet. Ein häufiger Einwand hierbei ist die Befürchtung, dass die Anwendung letztlich aus vielen kleinen Dateien bestehen und dadurch unnötiger HTTP-Overhead beim Laden entstehen könnte. Ich erkenne diesen Punkt grundsätzlich an, doch stellt sich die Frage nach der tatsächlichen Relevanz dieses Overheads (insbesondere in Zeiten von HTTP/2). Ist für die Webseite oder die Webanwendung, an der gearbeitet wird, wirklich jede Millisekunde Ladezeit entscheidend, oder spielt dies eine untergeordnete Rolle?
Sicherlich gibt es Szenarien, beispielsweise im Bereich der Suchmaschinenoptimierung (SEO), bei denen eine schnelle Ladezeit mit möglichst wenigen Requests von großer Bedeutung sein kann. Andererseits existieren auch Fälle, in denen die Performance weniger kritisch ist, etwa bei Anwendungen, die nicht öffentlich zugänglich sind und nur einem begrenzten Nutzerkreis dienen. In solchen Situationen könnte der zusätzliche Overhead vernachlässigbar sein. Es lohnt sich, diese Aspekte zumindest einmal in Betracht zu ziehen und zu überdenken.
Bis zu diesem Punkt haben wir gesehen, dass es möglich ist, Komponenten zu definieren und zu orchestrieren, dies mit einer benutzerfreundlichen API zu tun, CSS zu scopen, eine zentrale Importverwaltung zu haben und all das ohne einen Compile- oder Build-Schritt zu benötigen. Doch was, wenn Sie CSS nicht direkt innerhalb einer Webkomponente definieren möchten? Nicht alle Entwicklerinnen und Entwickler bevorzugen es, HTML, CSS und JavaScript in einer einzigen Datei zu kombinieren. Viele ziehen es stattdessen vor, CSS in externe Dateien auszulagern, ein Ansatz, der einer der Vorzüge von CSS-Modules ist, und der dort anstandslos funktioniert.
Das Interessante ist, dass dies mit CSS Module Scripts [7] tatsächlich auch nativ möglich ist, ohne die Notwendigkeit von CSS-Modulen und dem entsprechenden Tooling (wobei dieses Feature derzeit nur von Chrome-basierten Webbrowsern unterstützt wird). Das Konstrukt stützt sich auf die sogenannten Constructable Stylesheets [8]. Denn in Kombination bieten diese beiden Technologien genau das, was viele sich wünschen: gescopetes CSS innerhalb eines Shadow DOM, jedoch in einer separaten CSS-Datei.
Bezüglich CSS könnte man sich fragen, ob der Einsatz von Präprozessoren wie SASS oder LESS wirklich notwendig ist. Oftmals wird als Hauptgrund für deren Verwendung die Fähigkeit genannt, CSS-Anweisungen verschachteln zu können. Interessanterweise bietet CSS mittlerweile jedoch native Unterstützung für das Nesting, wodurch eine der wesentlichen Funktionen, die bisher Präprozessoren vorbehalten war, direkt verfügbar wird. Dies macht den Einsatz solcher Tools weitgehend überflüssig.
Darüber hinaus sind viele weitere Features, die einst den Einsatz von SASS oder ähnlichen erforderlich machten, nun Teil des CSS-Standards, einschließlich, aber nicht beschränkt auf, das Theming. Letzteres lässt sich effektiv mit nativen CSS-Variablen bewerkstelligen, was den Bedarf an externen Präprozessoren weiter verringert.
Es ist klar, dass die native Webentwicklung nicht in jeder Hinsicht eine 1:1-Alternative zu Frameworks wie React oder Angular darstellt. Diese Frameworks geben schließlich auch eine gewisse Struktur für Anwendungen vor, die allerdings je nach Framework variieren kann. Dennoch ist es bemerkenswert, wie viel mittlerweile mit den nativen Funktionen von Webbrowsern erreicht werden kann, wodurch der Bedarf an Compilern, Bundlern und ähnlichen Tools entfällt oder zumindest deutlich reduziert wird. Der vollständige Verzicht wird gelegentlich als "Buildless" bezeichnet, was den Fokus allerdings zu sehr auf den Wegfall des Kompilierungsschrittes legt.
Ich persönlich würde es vorziehen, diesen Ansatz eher als "Vanilla-Web" zu bezeichnen, in Anlehnung an "Vanilla-JavaScript". Dies impliziert die Nutzung des Webs in seiner reinsten Form, ohne externe Bibliotheken und Frameworks, und stützt sich ausschließlich auf die standardmäßig verfügbaren Funktionen.
Möglicherweise ist alles bis hierhin beschriebene für Sie nichts oder zumindest kaum Neues, da viele der angesprochenen Technologien bereits seit einigen Jahren verfügbar sind. Der entscheidende Punkt ist jedoch, dass diese Technologien zwar existieren und greifbar sind, bislang aber nicht das Gefühl aufkommt, dass sie in größerem Maßstab effektiv kombiniert und im großen Stil eingesetzt werden. Stattdessen neigen viele Entwicklerinnen und Entwickler dazu, aus Gewohnheit bei den Frameworks zu bleiben, die ihnen vertraut sind.
Mein Eindruck ist jedoch, dass eine zunehmende Bereitschaft für Veränderungen in dieser Hinsicht entsteht. Natürlich würde eine solche Anpassung eine erneute Umstellung bedeuten, aber das Besondere daran wäre, dass es sich um die möglicherweise letzte Umstellung dieser Art handeln könnte. Dieser Ansatz könnte sich als zuverlässiger und nachhaltiger erweisen als einige der Web-UI-Frameworks, mit denen wir in den letzten Jahren konfrontiert waren.
Ein wesentlicher Faktor, der den Übergang zu einem vollständig Build-freien Entwicklungsprozess erschwert, ist der Einsatz von TypeScript. Zwar existiert der etwas unkonventionelle Vorschlag von Microsoft, Typ-Annotationen in TypeScript als Kommentare innerhalb von JavaScript zu behandeln [9], doch in der Praxis ist ein Compiler momentan noch unumgänglich. Dies muss zwar nicht zwingend der offizielle TypeScript-Compiler sein (Tools wie esbuild können diese Aufgabe ebenfalls übernehmen), aber ein Build-Schritt ist so oder so nach wie vor erforderlich.
Eine Alternative könnte darin bestehen, auf TypeScript-spezifische Typdefinitionen zu verzichten und stattdessen auf JSDoc sowie das manuelle Erstellen von .d.ts-Dateien zurückzugreifen. Das ermöglicht es, den TypeScript-Compiler zu umgehen und dennoch eine angemessene Typsicherheit zu gewährleisten. Das Svelte-Team ist ein prominenter Befürworter dieser Methode und hat für Svelte 4 die Implementierung dieses Ansatzes mit JSDoc umgesetzt. Es bleibt spannend zu beobachten, wie sich diese Entwicklung in der Praxis bewähren wird.
Für Sie bedeutet das vor allem, dass Ihr bevorzugtes JavaScript-Framework samt dem dazugehörigen Tooling möglicherweise nicht mehr so unverzichtbar ist, wie es in den vergangenen Jahren den Anschein hatte. Ich empfehle Ihnen daher, sich mit den erwähnten Technologien und Konzepten vertraut zu machen, eigene Experimente durchzuführen und kritisch zu hinterfragen, ob das von Ihnen genutzte Framework und Tooling tatsächlich den Mehrwert bietet, den Sie erwarten, oder ob es für bestimmte Aufgaben vielleicht überdimensioniert ist.
Ich vermute, dass sich im Laufe dieses Jahres in dieser Hinsicht einiges ändern könnte. Wenn Sie diesen Weg nicht allein beschreiten möchten, sondern Ihren Technologiestack gerne gemeinsam mit jemandem überprüfen und reflektieren möchten, können wir bei the native web [10] Sie dabei gerne unterstützen.
URL dieses Artikels:
https://www.heise.de/-9611002
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements
[3] https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM
[4] https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots
[5] https://lit.dev/
[6] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap
[7] https://web.dev/articles/css-module-scripts
[8] https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleSheet
[9] https://www.youtube.com/watch?v=7fNFbJDdDuA
[10] https://www.thenativeweb.io/
[11] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: Open Elements)
Für Java gibt es eine Fülle an verschiedenen Logging-Bibliotheken und Möglichkeiten, Log-Nachrichten auszugeben. Aber welche davon sind wirklich performant?
In den vorherigen Posts zum Thema Java Logging (Best Practices [1], Logging Facades [2]) habe ich bereits erwähnt, dass es eine Fülle an Java Libraries zum Thema Logging gibt. Nachdem wir im letzten Post geklärt haben, wie man mit einer Facade verschiedene Logger vereinen kann, wollen wir uns nun die Performance von Logging-Bibliotheken anschauen.
Um kleine Teile einer Java-Anwendung oder -Bibliothek mittels eines Benchmarks zu überprüfen, gibt es in Java das Tool Java Microbenchmark Harness (JMH) [3], das vom OpenJDK bereitgestellt wird, um Performance-Benchmarks durchzuführen. Es führt ähnlich wie bei Unit-Tests kleine Teile der Anwendung (Micro-Benchmarks) aus und analysiert sie. Hierbei kann man unter anderem einstellen, ob der Code zuvor mehrfach für ein paar Sekunden ohne Messung durchlaufen soll, um die JVM und JIT "warmzulaufen".
Diese und andere Parameter lassen sich bei JMH ähnlich wie bei JUnit einfach durch Annotations definieren. Ein simples Beispiel für einen Benchmark sieht folgendermaßen aus:
FreshRSS @Benchmark
@BenchmarkMode(Mode.Throughput)
@Warmup(iterations = 4, time = 4)
@Measurement(iterations = 4, time = 4)
public void runSingleSimpleLog() {
logger.log("Hello World");
}Das Beispiel führt vier Durchläufe zum Aufwärmen durch, gefolgt von vier Messdurchläufen. Jeder Durchlauf dauert vier Sekunden, und das Messergebnis zeigt an, wie viele Operationen pro Sekunde durchgeführt werden konnten. Konkret bedeutet das, wie oft "Hello World" geloggt werden konnte. Das Ganze bekommt man nach dem Durchlauf tabellarisch in der Kommandozeile ausgegeben, kann es aber auch beispielsweise als JSON- oder CSV-Datei speichern.
Mithilfe von JMH habe ich einen Open-Source-Benchmark für Logging-Frameworks erstellt, das bei GitHub einsehbar ist [4]. Er überprüft aktuell folgende Logging-Bibliotheken beziehungsweise Set-ups auf ihre Performance:
Für jede dieser Konstellation gibt es verschiedene Benchmarks, die die Performance vom Erstellen des Logger über das Loggen einer einfachen "Hello World"-Nachricht bis hin zu komplexen Logging-Aufrufen (Placeholder in Message, Marker, MDC Nutzung, etc.) messen.
Die Messungen zeigen, dass Logging-Frameworks generell sehr performant sind. Auf der anderen Seite führten sie aber auch ein paar Erkenntnisse zutage, die sicherlich nicht jedem direkt klar sind.
Im Folgenden findet sich eine Übersicht von Messergebnissen beim einfachen Loggen einer "Hello World" Nachricht:
Ein erstes Ergebnis der Messungen ist, dass ein Logging auf die Konsole immer deutlich langsamer ist als ein Logging ins Dateisystem. Während man beim Logging in eine Datei 200.000 bis 300.000 Aufrufe des Loggers pro Sekunde erreichen kann, sind es bei einer Ausgabe auf die Konsolen immer deutlich unter 100.000 Operationen die Sekunde gewesen. Da alle Logging-Libraries hier mit System.out bzw. System.err arbeiten, macht es auch kaum einen Unterschied in der Performance, welche Bibliothek man nutzt. Hier wird es in Zukunft spannend zu schauen, ob man durch Tricks oder Umbauten eine bessere Performance hinbekommen kann.
Einen weiteren großen Unterschied sieht man, wenn man die Messwerte von synchronen bzw. asynchronen Logging in eine Datei betrachtet. Hier wird sofort deutlich, dass asynchrones Logging deutlich schneller ist. Die folgenden Tabellen zeigen die Messwerte von asynchronen Logging im Vergleich zu synchronen Logging:
Die klar erkennbar höherer Performance liegt daran, dass die Schreiboperation der asynchronen Logger nicht blockiert. Die Logger Log4J2 und Chronicle Logger nutzen zwar intern unterschiedliche Bibliotheken intern, basieren aber beide auf einer "lock-free inter-thread communication library". Während bei Log4J hierbei LMAX Disruptor [5] als Bibliothek hinzugefügt werden muss, die intern über Ringbuffer das asynchrone Logging ermöglicht, basiert der Chronicle Logger direkt auf der Chronicle Queue Bibliothek [6].
Konkrete Beschreibung der intern genutzten Libraries und wie diese eine asynchrone Kommunikation beziehungsweise das Schreiben ins Dateisystem ermöglichen, lässt sich der Dokumentation entnehmen.
Wenn man die Performance von Log4J2 und Chronicle Logger vergleicht, kann man sehen, dass der Chronicle Logger noch einmal deutlich schneller ist. Dieser Performance-Vorteil kommt aber auch mit einem Nachteil, dem man sich bewusst sein muss: Während Log4J2 auch im asynchronen Modus weiterhin zeilenweise ein für den Menschen einfach lesbares Logging im Dateisystem erzeugt, schreibt der Chronicle Logger alle Nachrichten in einem Binärformat. Hier wird zum Lesen bzw. Parsen dann ein Tooling benötigt, das der Logger aber mitliefert. Darüber hinaus ist die Varianz der Testergebnisse des Chronicle Logger deutlich höher. Als Grund vermute ich, dass die genutzt Chronicle Queue die binären Daten zum Schreiben des Logging intern verwaltet und deren Größen immer dynamisch anpasst. Dies muss allerdings noch weiter untersucht werden. Die folgende Tabelle zeigt einmal eine Übersicht der Varianz:
Wie man sehen kann, ist nicht nur die Wahl einer Logging Bibliothek, sondern auch deren Konfiguration extrem wichtig für die Performance. Während das Logging auf die Konsole während der Entwicklung sicherlich sehr angenehm ist, kann man sich beispielsweise überlegen, ob die Nutzung des Konsolen-Logging im Live-Betrieb wirklich immer erforderlich ist. Auch zeigt sich, dass eine Nutzung von asynchronen Loggern sinnvoll sein kann, wenn die Performance des Systems wirklich kritisch ist. Das kommt aber natürlich mit einer höheren Komplexität und zusätzlichen transitiven Abhängigkeiten einher. Letztlich muss also jedes Projekt weiterhin selbst für sich entscheiden, welcher Logger am sinnvollsten ist. Durch die hier genannten Zahlen hat man aber nun eine weitere Basis, um das festzulegen.
URL dieses Artikels:
https://www.heise.de/-9278737
Links in diesem Artikel:
[1] https://www.heise.de/blog/Best-Practices-und-Anti-Pattern-beim-Logging-in-Java-und-anderen-Sprachen-7336005.html
[2] https://www.heise.de/blog/Logging-Facades-fuer-Java-7355974.html
[3] https://github.com/openjdk/jmh
[4] https://github.com/OpenElements/java-logger-benchmark
[5] https://github.com/LMAX-Exchange/disruptor
[6] https://github.com/OpenHFT/Chronicle-Queue
[7] mailto:rme@ix.de
Copyright © 2024 Heise Medien
Das Java Module System ist in der Entwicklung von Anwendungen und Bibliotheken noch immer eine selten genutzte Funktion. Dabei ist der Einstieg oft leicht.
In den letzten Jahren hat man immer wieder viele unterschiedliche Meinungen zum Java-Modulsystem gehört. Während viele Entwicklerinnen und Entwickler der standardisierten Möglichkeit zur Definition von Modulen positiv entgegenstehen, gibt es viele kritische Meinungen, die der Definition beispielsweise fehlende Features wie die Unterstützung von Versionen ankreiden. Diese Diskussion möchte ich hier allerdings überhaupt nicht aufmachen. Ich selber sehe viele Vorteile im Modulsystem und kann verstehen, dass vor allem Framework und Bibliotheksentwickler das Ganze nutzen (wollen).
Ein großer Nachteil ist hier allerdings, dass eine (transitive) Abhängigkeit, die in keiner Weise auf das Java Modulsystem angepasst ist, möglicherweise nicht zu den Definitionen und Einschränkungen des Modulsystems passt und somit nicht zum Modul-Path hinzugefügt werden kann. Das Java-Modulsystem erstellt automatisch ein Modul für jedes JAR, das es auf dem Modul Path findet. Hierbei kann es zu einigen Problemen kommen, die man allerdings oft durch kleine Anpassungen in einer Bibliothek beheben kann.
Diese Probleme möchte ich in mehreren Posts einmal genauer betrachten und mögliche Lösungen aufzeigen. Dieser Beitrag geht auf die Nutzung und Definition von automatischen Modulen einmal genauer ein.
Eine wichtige Definition des Modulsystems ist, dass jedes Modul einen eindeutigen Namen benötigt. Hierbei wird zwischen explizit deklarierten Modulen, die über eine module-info.java verfügen, und automatischen Modulen, die implizit deklariert werden, unterschieden. Weitere Infos lassen sich der JavaSE Spec [1] entnehmen. Wenn man in seinem Projekt nicht die Vorteile des Modulsystems durch die Nutzung einer module-info.java nutzen möchte, reicht es völlig aus, wenn man die eigene Bibliothek als automatisches Modul definiert.
Die einzige Voraussetzung hierfür ist, dass das Modul über einen eindeutigen Namen verfügt. Zwar kann Java für JARs auf dem Module Path zur Not sogar einen Namen aus dem Namen des JAR extrahieren, was aber ganz klar nicht empfohlen ist. Vor allem, da die Definition eines Namens für ein automatisches Modul wirklich sehr einfach ist. Es muss lediglich die Automatic-Module-Name Property in der MANIFEST.MF des JARs definiert werden. Wenn Maven oder Gradle als Buildtool genutzt werden, kann man dies über ein Plug-in sogar voll automatisiert erstellen.
Wie man im folgenden Beispiel sehen kann, muss bei einem Maven Build nur das maven-jar-plugin entsprechend konfiguriert werden:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.3.0</version>
<configuration>
<archive>
<manifestEntries>
<Automatic-Module-Name>com.example.lib</Automatic-Module-Name>
</manifestEntries>
</archive>
</configuration>
</plugin>
In Gradle lässt sich das Ganze einfach durch Nutzung des Java-Library-Plug-ins umsetzen, das Bestandteil jedes Java Builds sein sollte. Eine ausführliche Dokumentation zum Einsatz in Gradle kann man hier [2] finden, während der folgende Code eine einfache Einbindung in ein Projekt zeigt:
tasks.jar {
manifest {
attributes("Automatic-Module-Name" to "com.example.lib")
}
}
Da die Änderungen wirklich sehr einfach sind, eignen sie sich auch hervorragend, um das Ganze für Open Source Libraries als Pull Request anzubieten. In einem Beispiel [3] habe ich einen PR zur Definition eines Automatic-Module-Name zu einer Open Source-Java-Bibliothek hinzugefügt. Vielleicht liest ja eine oder ein Open Source Developer mit und erstellt für eine solche Umstellung der eigenen Bibliotheken ein „Good First Issue“, das beispielsweise zum Hacktoberfest [4] von Neulingen umgesetzt werden kann.
URL dieses Artikels:
https://www.heise.de/-7434695
Links in diesem Artikel:
[1] https://docs.oracle.com/javase/specs/jls/se16/html/jls-7.html#jls-7.7.1
[2] https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_modular_auto
[3] https://github.com/offbynull/portmapper/pull/48
[4] https://hacktoberfest.com
[5] https://heise-academy.de/schulungen/virtual-threads?wt_mc=intern.academy.ix.ws_virtualthreads.newsticker.link.link
[6] mailto:rme@ix.de
Copyright © 2024 Heise Medien
This is a bug-fix release for the 1.23.0 release, addressing several regressions.
This release has been made by @Alkarex, @andris155, @math-GH, @yzqzss, @zhzy0077
Full changelog:
base_url being cleared when saving settings #5992.dockerignore #5996A few highlights ✨:
Breaking changes 💥:
amd64, arm32v7, arm64v8 with automatic detection #5808
-arm suffix anymoreThis release has been made by several contributors: @Alkarex, @ColonelMoutarde, @FireFingers21, @Frenzie, @kasimircash, @andris155, @b-reich, @foux, @jaden, @jan-vandenberg, @joestump, @jtracey, @mark-monteiro, @martinrotter, @math-GH, @passbe
Full changelog:
VARCHAR) text fields length to maximum possible #5788CRON_MIN if any environment variable contains a single quote #5795TRUSTED_PROXY environment variable used in combination with trusted sources #5853
(Bild: Andrey Suslov/Shutterstock.com)
Electron ist nicht nur sprichwörtlich das Schwergewicht in der Cross-Plattform-Entwicklung. Kleiner und sicherer will Tauri sein, das im Backend auf Rust setzt.
Viele Anwendungen wie Signal, Slack, WhatsApp, Discord oder Visual Studio Code nutzen unter der Haube Electron [1], ein Framework zur plattformübergreifenden Ausführung von Anwendungen. Die App selbst wird dabei mithilfe von Webtechnologien wie HTML, CSS, JavaScript und WebAssembly [2] implementiert. Electron verpackt die Anwendungen gemeinsam mit dem Webbrowser Chromium und der Runtime Node.js in ein plattformspezifisches Bündel. Über das sogenannte Backend in Node.js kann die Webanwendung sämtliche Schnittstellen des Betriebssystems aufrufen.
Entwickler sparen bei diesem Ansatz viel Zeit, Geld und Aufwand, da sie ihre Anwendung nur einmal mit Webtechnologien entwickeln müssen und auf einer Vielzahl von Plattformen vertreiben können, Webbrowser eingeschlossen.
Allerdings sind Electron-Anwendungen aufgrund der Bündelung gleich zweier Laufzeitumgebungen leider auch sehr groß: Schon eine einfache Hello-World-Anwendung wird in Electron verpackt rund 100 MByte groß.
Jede ausgeführte Instanz führt zu einem Mehrverbrauch an Arbeitsspeicher, und veraltete Node.js- und Chromium-Versionen innerhalb eines Anwendungsbündels können zu Sicherheitsproblemen führen. Entwickler müssen Updates nicht nur bei Aktualisierungen ihrer App vertreiben, sondern auch, wenn sich Electron aktualisiert hat.
(Bild: Tauri.app)
Hier kommt Tauri [4] ins Spiel: Der Electron-Herausforderer erlaubt ebenfalls das Verpacken von Webanwendungen in Form eines plattformspezifischen Bündels. Allerdings fügt Tauri keinen eigenen Webbrowser hinzu, sondern nutzt die Web-View des Betriebssystems, auf dem die Anwendung ausgeführt wird: WebView2 auf Windows, WebKit unter macOS und WebKitGTK auf Linux.
In Tauri 2.0, das sich derzeit noch in der Alpha-Phase befindet, sollen sich iOS und Android zur Liste der unterstützten Plattformen hinzugesellen. Diese Plattformen können mit Electron nicht adressiert werden. Tauri würde damit auch Wrapper für mobile Betriebssysteme wie Cordova oder Capacitor [5] ersetzen.
Im Backend greift Tauri nicht auf JavaScript zurück, sondern auf Rust. Insofern muss auch Node.js nicht mit der Anwendung verpackt werden. Eine Hello-World-Anwendung ist mit Tauri gerade einmal 600 KByte groß. Mithilfe von Sidecars können Anwendungen mit externen Binärdateien ausgeliefert werden, die nochmal in anderen Sprachen verfasst sind.
Und auch das Thema Security nimmt bei Tauri einen hohen Stellenwert [6] ein: So können die benötigten Programmierschnittstellen gezielt aktiviert werden. Nur dann wird der dafür erforderliche Code überhaupt in das Bündel aufgenommen. Tauri bringt auch viele erweiterte Funktionen wie einen Auto-Updater oder die Integration in das Benachrichtigungssystem der Plattform mit.
Der Nachteil von Tauri besteht allerdings gerade darin, dass die Webanwendung nun in verschiedenen Ausführungsumgebungen ausgeführt wird: Die Unterstützung bestimmter Webschnittstellen oder CSS-Features variiert zwischen unterschiedlichen Web-Engines, sodass die Anwendung auf allen Zielumgebungen getestet werden muss.
Während Electron von GitHub herausgegeben wird, ist Tauri ein Community-getriebenes Projekt. Finanziell unterstützt wird Tauri etwa von 1Password, deren Passwortmanager zumindest derzeit noch auf Electron basiert.
Auch wenn die erste Version von Tauri schon länger erschienen ist, bleibt es noch das "New Kid on the Block". Große Namen finden sich unter den Tauri-Verwendern [7] derzeit noch nicht. Nicht nur aufgrund der deutlich geringeren Bundle-Größe sollte das Framework jedoch in Betracht gezogen werden, vielleicht sogar noch vor dem Platzhirsch Electron. Eine neue Tauri-App lässt sich über den npm-Befehl npm create tauri-app , auf der Bash mit sh <(curl https://create.tauri.app/sh oder auf der Powershell mit irm https://create.tauri.app/ps | iex erstellen.
URL dieses Artikels:
https://www.heise.de/-9538237
Links in diesem Artikel:
[1] https://www.electronjs.org/
[2] https://www.heise.de/blog/WebAssembly-Das-Web-wird-nativ-er-4023451.html
[3] http://paint.js.org/
[4] https://tauri.app/%E2%80%8B
[5] https://www.heise.de/blog/Capacitor-oder-Cordova-Welche-Plattform-sollten-Entwickler-webbasierter-Mobilapps-waehlen-4690975.html
[6] https://tauri.app/v1/references/architecture/security%E2%80%8B
[7] https://github.com/tauri-apps/awesome-tauri#applications%E2%80%8B
[8] mailto:rme@ix.de
Copyright © 2023 Heise Medien
(Bild: Pixelvario/Shutterstock.com)
Um eine Webanwendung in Chromium-basierten Browsern installieren zu können, musste diese ursprünglich offlinefähig sein. Diese Bedingung ist entfallen.
Progressive Web Apps [1] sind Webanwendungen, die auf dem Gerät des Anwenders installiert werden können. Voraussetzung dafür war in Google Chrome und Microsoft Edge lange Zeit, dass die Anwendung offlinefähig sein muss. Für die User Experience ist eine Bedienbarkeit auch dann wünschenswert, wenn der Anwender offline ist – zumindest im Rahmen der Möglichkeiten. Wer also den zusätzlichen Aufwand auf sich nahm, dies umzusetzen, wurde mit der Installierbarkeit der Anwendung belohnt.
Zur Implementierung der Offlinefähigkeit bei Webanwendungen kommen Service Worker [3] zum Einsatz. Dabei handelt es sich um ein durch die Website registriertes Stück JavaScript, das als Proxy zwischen Webanwendung und Netzwerk agiert und Zugriff auf einen clientseitigen, programmierbaren Cache besitzt. Speichert man die erforderlichen Quelldateien der Anwendung im Cache zwischen und liefert sie im Offline-Fall von dort aus, lässt sich die Anwendung auch ohne Internetverbindung betreiben.
Findige Webentwickler haben um diese Anforderung jedoch herummanövriert: Manche setzten einen leeren Service Worker ein, um die Bedingung zu erfüllen. Google zog daraufhin nach und erforderte einen fetch-Ereignishandler, sodass der Service Worker zumindest theoretisch in der Lage war, die Website offline verfügbar zu machen. Also setzten Seiten einfach diesen Ereignis-Handler ein und leiteten sämtliche Anfragen gegen das Netzwerk um. Folglich war das Ziel wieder nicht erreicht, und aufseiten des Browsers führte die zusätzliche Prüfung zu einem erheblichen Mehraufwand.
Mit Chromium 109 (mobil) und 110 (Desktop) wurden daher im Januar 2023 neue Offline-Fallbackansichten für installierte Webanwendungen [4] implementiert: Die Offlineerfahrung wird automatisch generiert, indem das Icon der Anwendung und der Hinweis "You're offline" angezeigt wird.
Die Notwendigkeit eines Service Worker und damit der Offlinefähigkeit ist seitdem komplett entfallen. Damit nähern sich Chrome und Edge auch an Safari an: Denn die Installation von Websites ist auf dem iPhone seit den frühen Tagen möglich, ganz ohne Bedingungen. Im Fall von Chrome und Edge wird zunächst jedoch auch weiterhin ein Web Application Manifest gefordert sowie die Übertragung der Website über HTTPS (siehe Installationskriterien [5]).
Service Worker haben den Nachteil, dass sie in JavaScript geschrieben und erst hochgefahren werden müssen, um Websites auszuliefern oder Pushbenachrichtigungen entgegenzunehmen. Um dem entgegenzuwirken, wurde für die Beschleunigung von Netzwerkabfragen beim Service-Worker-Start Navigation Preloads [6] entwickelt, während es für Pushbenachrichtigungen einen alternativen Vorschlag gibt, Declarative Web Push [7]. Für Webentwickler ist das Verfassen von solchem Infrastrukturcode zudem recht ungewohnt.
Die Implementierung einer sinnvoll bedienbaren Offlinevariante bleibt jedoch ein zentraler Baustein einer guten User Experience. PWA-Entwickler sollten diese daher auch in Zukunft anbieten, um ihre Anwender glücklich zu machen.
URL dieses Artikels:
https://www.heise.de/-9356942
Links in diesem Artikel:
[1] https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps
[2] http://pwapraxis.liebel.io/
[3] https://www.heise.de/blog/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Workers-3740464.html
[4] https://developer.chrome.com/blog/default-offline/
[5] https://web.dev/articles/install-criteria
[6] https://web.dev/blog/navigation-preload
[7] https://github.com/w3c/push-api/issues/360
[8] mailto:rme@ix.de
Copyright © 2023 Heise Medien
Für Apple so wichtig, dass es sogar in den Top-Neuerungen von macOS Sonoma erscheint: Die Installation von Webanwendungen aus Safari heraus.
(Bild: Apple)
Was auf dem iPhone seit der ersten Version funktioniert, geht nun endlich auch mit Safari unter macOS: Webanwendungen lassen sich auf dem Gerät installieren.
Mit der Veröffentlichung von Safari 17 [1] und macOS Sonoma sind Progressive Web Apps [2] nun auch unter Verwendung des Apple-Browsers unter macOS installierbar. Dies war unter macOS mit Chromium-basierten Browsern wie Google Chrome und Microsoft Edge schon seit einigen Jahren [3] möglich, mit Safari auf dem iPhone bereits seit Januar 2008, als iPhone OS 1.1.3 veröffentlicht wurde.
Bei der Installation wird eine Verknüpfung zur Website auf dem Dock (auf Mobilgeräten auf dem Home-Bildschirm) hinterlegt. Webentwickler können das Icon und den Namen der Verknüpfung vordefinieren und dabei auch festlegen, dass die von der Verknüpfung geöffnete Website im Standalone-Modus ausgeführt wird, also in einem eigenständigen Fenster (auf Mobilgeräten vollflächig, also ohne Browser-Steuerelemente). Dies wird über das Web Application Manifest [4] definiert. Ist kein Manifest vorhanden, werden Titel und Icon aus anderen Quellen bezogen.
Die Installation erfolgt analog zu iOS und iPadOS aus dem Teilen-Menü heraus, das sich neben der Adresszeile befindet. Darin muss der Eintrag "Add to Dock" ausgewählt werden. Als Beispiel soll hier die Produktivitäts-PWA [5] paint.js.org [6] dienen.
Die Installation müssen Anwender in einem separaten Dialog bestätigen. Safari erlaubt dabei das Ändern der Bezeichnung. Wer davon Gebrauch macht, kann mehr als eine Instanz der Anwendung auf dem Gerät installieren – etwa, um eine Anwendung mit unterschiedlichen Benutzerprofilen zu verwenden, denn Cookies werden zwischen den Instanzen nicht geteilt. Dies ist bei Chrome oder Edge in dieser Form so nicht möglich.
Beim Zustimmen zur Aufforderung wird die Verknüpfung dem Dock hinzugefügt und dort zugleich angeheftet. Außerdem erscheint die Anwendung auch im Launchpad und ist im Applications-Ordner des Benutzerverzeichnisses zu finden. Von dort kann die Webanwendung auch wieder gelöscht werden [7]. Von der Verknüpfung aus gestartet, erscheint die Webanwendung dann wie plattformspezifische Apps in einem eigenen Fenster.
Damit sind Webanwendungen nun unter Safari auf sämtlichen Plattformen offline-fähig, installierbar und können Pushbenachrichtigungen entgegennehmen: Installierte Anwendungen können wie auch unter iOS und iPadOS Pushbenachrichtigungen empfangen und Badges auf dem Anwendungs-Icon anzeigen [8]. Als einziger der großen Browser unterstützt Firefox keine Installation von Webanwendungen auf dem Desktop.
Der nächste logische Schritt wäre nun die Bereitstellung der File System Access API [9] in Safari. Diese Webschnittstelle, die bereits seit 2019 mit Chromium-basierten Browsern ausgeliefert wird, erlaubt die Bearbeitung von Dateien aus dem lokalen Dateisystem. Über die Erweiterung File Handling API können sich installierte Webanwendungen sogar als Bearbeitungsprogramm für bestimmte Dateitypen hinterlegen. Dass das interessant sein könnte, merkten Apple-Vertreter auf der vergangenen Jahreskonferenz des W3C [10] bereits an.
URL dieses Artikels:
https://www.heise.de/-9356873
Links in diesem Artikel:
[1] https://webkit.org/blog/14445/webkit-features-in-safari-17-0/#:~:text=and%20error%20handling.-,Web%20apps%20on%20Mac,-Safari%2017.0%20for
[2] https://www.heise.de/blog/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html
[3] https://www.heise.de/blog/Chrome-76-PWA-Installation-wird-einfacher-4481046.html
[4] https://www.heise.de/blog/Progressive-Web-Apps-Teil-3-Wie-die-Web-App-zur-App-App-wird-3464603.html
[5] https://www.heise.de/blog/paint-js-org-MS-Paint-Remake-als-PWA-mit-Web-Components-und-modernen-Web-Capabilities-6058723.html
[6] http://paint.js.org/
[7] https://support.apple.com/en-us/104996
[8] https://www.heise.de/blog/Web-Push-und-Badging-in-iOS-16-4-Beta-1-Mega-Update-fuer-Progressive-Web-Apps-7518359.html
[9] https://www.heise.de/blog/Produktivitaets-PWAs-auf-Desktop-Niveau-dank-File-System-Access-und-File-Handling-API-4963752.html
[10] https://blog.tomayac.com/2023/09/25/w3c-tpac-2023-trip-report/#:~:text=Apple%20noted%20that%20a%20launch%20handling%20feature%20is%20something%20that%20they%20would%20probably%20need.
[11] mailto:rme@ix.de
Copyright © 2023 Heise Medien
