15. Dezember 2023
Am Mittwoch schien bei uns zur Abwechslung mal die Sonne. In homöopathischen Dosen zumindest. Dann sah es kurz in etwa so aus wie auf der Fotografie hier.
Das war dem Wetter dann offenbar bald selbst suspekt, ließ Wolken folgen und in den Abend erstmal heftigst regnen. So sind wir inzwischen wieder zurück bei diesem permanenten Grau in dunkel feuchtkalter Atmosphäre angelangt, das seinen Namen dem Ambiente spärlich beleuchteter Waschküchen verdankt.
Der Jahreszeit entsprechendes Wetter also, kein Grund zur Beunruhigung.
Mit einem Mal sind wieder solche Plattformen/Werkzeuge en vogue, die mit ein und demselben Quellcode auf verschiedene Laufzeitumgebungen abzielen. Flutter ist zum Beispiel so ein Kandidat. Und auch gerade erst wieder Kotlin Multiplatform, das neuerdings WebAssembly unterstützt.
So richtig vorteilhaft erscheint es bei näherem Hinsehen aber nicht.
Klar ist, dass es ganz hübsch wäre, man schriebe Code in einer vertrauten, guten Sprache, sagen wir z.B. in C. Oder Go. Oder Rust. Und das wird dann zu WebAssembly kompiliert, einem Bytecode, den der Browser ausführt, als wäre es JavaScript. Jener Code beinhaltet ja Operationen auf dem Client, also so etwas wie den Inhalt von Teilen einer Web-Seite zu verändern, so, wie es für eine Bedienoberfläche nötig ist: Zustandswechsel einzelner Bedienelemente.
Baut man so etwas in Go, Rust oder C, macht dieser Code im Grunde dasselbe, wie wenn es in JavaScript gebaut wird und sieht vor allem auch so aus. Da kann man für den Client auch gleich JavaScript nehmen. Der einzige Vorteil, der dabei ansonsten anfällt ist natürlich die bedeutend bessere Strukturierbarkeit von Code in C, Go oder Rust und eine einheitlichere Codebasis. Hm.
Aber auch auf der Seite der unterschiedlichen Clients ist nicht ganz klar, welchen Vorteil diese Multiplattform-Fähigkeit bietet. Wenn eine Bedienoberfläche im Browser läuft und zudem so gestaltet ist, dass sie mit großen und kleinen sowie berührungsempfindlichen Bildschirmen klarkommt, genügt es doch, dieses 'Target' zu bauen. Das läuft dann auf allen Geräten, ohne noch eine zusätzliche 'native' Bedienoberfläche zu benötigen, die bspw. wie iOS oder Android aussieht.
Sicherheitshalber bleibe ich da doch lieber einstweilen bei Anwendungen, die überall laufen und Java auf dem Server mit HTML, CSS und JavaScript auf dem Client kombinieren. Sollte jemand von JavaScript wegkommen wollen, muss es zum Ausprobieren von WebAssembly jedenfalls nicht Kotlin sein, Go oder selbst Java scheinen die bessere Wahl zu sein.
Was uns zu einem Thema führt, das auch einen Bezug zu Multiplattform-Anwendungen hat: Der Gestaltung der Bedienoberfläche. Wenn eine möglichst vielseitige Bedienoberfläche entstehen soll, ist eine aus HTML und CSS bestehende im Grunde überall verwendbar.
Bereits die App-Vorlage ist hierfür ein universelles Werkzeug, das ganz ohne zusätzliche Erfordernisse auskommt. Für komplexere Elemente und Funktionen allerdings muss auch sie erweitert werden. Da möchte man aber vielleicht nicht immer das Rad neu erfinden müssen und kann dann aus einer Vielzahl vorgefertigter Elemente schöpfen.
Eine Auswahl aus der schwer zu überschauenden Vielfalt in diesem Bereich:
Skeleton und Bootstrap habe ich selbst schon genutzt. Demnächst soll vielleicht einmal Vanilla für ein eigenes Projekt dran kommen.
Es kommt mir schon geraume Zeit so vor, als bestünde die IT nur noch aus Cloud und KI. Dabei ist und bleibt viel spannender, was wie warum funktioniert. Wollen wir das wirklich KI überlassen, sozusagen ohne zu wissen, was die KI auch nicht weiß?
Dann doch lieber weiter selbst mit anpacken beim Bau der passenden Lösungen. Die handwerkliche Seite sollte nicht so leichtfertig abgeschrieben werden, das gilt schließlich auch in anderen Bereichen.
Copyright © Ulrich Hilger, alle Rechte vorbehalten.