Schlagwort-Archive: appentwicklung

Was bedeutet WebAssembly für IT-Projekte?

Eine der jüngsten Entwicklungen in der Weblandschaft ist WebAssembly – ein Binärformat, das unter Web- und App-Entwicklern längst in aller Munde ist. Völlig zu Recht, denn es zeichnet sich ab, dass WebAssembly über kurz oder lang neue Maßstäbe in der Softwareentwicklung setzen wird. Doch was bedeutet das für zukünftige IT-Projekte?

Basics first: Was kann WebAssembly?

WebAssembly (Wasm) ist eine Low Level Assemblersprache, die nativ in Webbrowsern kompiliert werden kann. Im Vergleich zu JavaScript liegt das Format sehr viel näher am Maschinencode und unterscheidet sich in seiner Leistung kaum von nativen Apps. Es läuft in allen großen Browsern – Chrome, Firefox, Safari und Edge – und ist vom W3C als offizieller Web Standard anerkannt. Das Besondere an WebAssembly ist, dass man in der Regel nicht direkt damit programmiert, sondern dass es als Kompilierziel für andere Sprachen fungiert. Da es bereits im Binärformat vorliegt, erfolgt das Parsing deutlich schneller als bei JavaScript.

Konkret heißt das: WebAssembly bietet die Möglichkeit, gängige Hochsprachen (z.B. C, C++, Java, Python) in ein ladezeitoptimiertes Format zu kompilieren, das crossbrowser und crossplatform Einsätze möglich macht. Jede Desktop Anwendung, die sich in WebAssembly kompilieren lässt, können Sie auf diese Weise ohne Leistungseinbußen im Browser ausführen. Damit dient WebAssembly als ideale Ergänzung zu JavaScript, um dessen Overheads auszubügeln und auch komplexe, rechenintensive Anwendungen im Browser auszuführen.

Was bedeutet das für IT-Projekte?

Seit WebAssembly ist JavaScript nicht mehr einzige Option, um Code für den Browser zu schreiben. Und das hat Folgen: Denn statt sich auf die bisherigen Objektprototypen von JavaScript zu beschränken, haben Entwickler zum ersten Mal eine Auswahl. Im Grunde können Sie jede Funktion Ihrer Anwendung in einer beliebigen Sprache programmieren und diese im Anschluss zu Wasm kompilieren. Voraussetzung ist natürlich, dass die gewählte Sprache über einen WebAssembly-Compiler verfügt.

Ein weiterer Vorteil von WebAssembly: Sie können den Wasm Code wiederverwenden und damit eine Brücke zwischen C#-Backend (als Beispiel) und JS-Frontend bilden. Wenn Sie Ihre DLL mit WebAssembly als Ziel kompilieren, sparen Sie sich den Schritt sie in JavaScript zu implementieren – und das spart Entwicklungszeit.

IT-Projekte stehen damit vor ganz neuen Chancen, aber auch Herausforderungen. In Bereichen, in denen die Rechenleistung von JavaScript an ihre Grenzen stößt, kann zukünftig mit Wasm gearbeitet werden – zum Beispiel bei 3D Gaming, Image Editing oder Virtual Reality. Desktop und Mobile Apps, für die bisher keine webbasierte Variante geplant war, können mit Wasm problemlos im Browser kompiliert werden. Und ja, das betrifft auch Java Anwendungen und alle anderen „web-fernen“ Sprachen.

Wird zukünftig nur noch mit WebAssembly programmiert?

WebAssembly wurde mit dem primären Ziel entwickelt, leistungsstärkere Webanwendungen zu ermöglichen. Der Trend hin zu browserbasierten Applikationen wird dadurch natürlich verstärkt, denn der Vorteil ist: Web Apps haben ein breiteres Publikum. Gleichzeitig macht WebAssembly die Programmierung solcher Apps effizienter, schneller und günstiger. Da inzwischen alle großen Browser das Format unterstützen, ist es eigentlich nur eine Frage der Zeit, bis es sich komplett in der Webentwicklung etabliert hat – vor allem in jenen Bereichen, wo Performance eine große, wenn nicht sogar entscheidende Rolle spielt. Wiederum wird es JavaScript nicht ersetzen, allein schon deshalb, weil die Wasm Module mit JavaScript geladen werden. Es ist und bleibt daher eine Ergänzung, die die bisherigen bestehenden Grenzen in der Softwareentwicklung ein großes Stück aufbricht. 

Zusammenfassung

WebAssembly mag in erster Linie für Performancesteigerungen konzipiert worden sein, doch das Format kann weitaus mehr. Entwicklungsteams, die plattformübergreifend oder mit einer Client-Server-Aufteilung arbeiten, profitieren zum Beispiel von kürzeren Lieferzeiten und mehr Flexibilität beim Programmieren selbst. So ist man nicht mehr an die lose Typisierung von JavaScript gebunden, sondern kann jede Hochsprache, die in Wasm kompiliert werden kann, für die gewünschten Funktionen nutzen – von Rust und C bis hin zu Java. Das Web von morgen wird Apps der Desktop-Klasse mit nativer Leistung ausführen, und WebAssembly macht es möglich.

Entwickler schaffen sich ab: WebAssembly, jHipster und Low-Code – und das ist gut so

Wir machen uns überflüssig. Meine These: Und das ist gut so. Wir wollen es noch nicht wahr haben und genießen derzeit noch eine Art Schutzposition. Während es Mangel an IT-Kräften gibt und die Digitalisierung für viele Bereiche Stellenabbau bedeutet entwickeln sich die Technologien paradox. Paradox ist es aber nur auf den ersten Blick.
Die scheinbare Paradoxie: Entwickler werden durch ihre eigene Digitalisierung selbst von den Auswirkungen auf den minimierten Arbeitskräftebedarf betroffen sein. Nicht langfristig, sondern es steht kurz bevor! Wie kann das sein?

Entwickler sind derzeit noch in einer Position, dass die Digitalisierung so langsam akzeptiert ist, in manchen Bereichen bereits Fahrt aufnimmt, aber so richtig verankert in vielen Bereichen noch nicht ist. Auch mit dem Pandemieschub ist im Allgemeinen die Führungskraft abhängig von ihren Technologieberatern, meist Entwickler, die Aufgaben planen und Aufwände einschätzen. Überliche Muster dabei sind: Backendentwicklung ist sehr aufwändig im Vergleich zur Frontendentwicklung, native Appentwicklung ist keine einfache Webentwicklung und zu einem gegeben Design benötigt es grafikaffine Entwickler, die dies auch Umsetzen können. Die Entwicklung verrät dem Management natürlich nur zögerlich, dass diese Aufgaben heute zu einem Bruchteil des Aufwandes zu erledigen sind.
Die drei Kernbereiche, aus denen die Aufwände für die Entwicklung entstehen, sind kurz davor zu fallen.

Kernbereich 1: Backendentwicklung wird durch Standgeneratoren ersetzt

Die Backendentwicklung hat den Ruf, das eigentliche Feld des hochspezialisierten Entwicklers zu sein. Das ist historisch so gewachsen. Betriebssystementwicklung (Linux-Kernel, etc.), Algorithmenentwicklung (Facebook, Google) sind das Herzstück der jeweiligen Innovationen. Und in der Tat, überall dort, wo es viel neue Businesslogik zu entwickeln gibt, werden auch in Zukunft noch die spezialisierten Entwickler benötigt. Doch für die meisten Geschäftsmodelle gibt es heute Frameworks, die in dem Backendbereich eingesetzt wird. Dazu kommen Generatoren, wie jHipster, die nicht nur große Teile des Backends einfach auf Basis von standardisierten Diagrammen automatisiert erzeugen können. Auch Swagger geht nach dem Konzept „Interface-First“ vor. Gar nicht so unglaublich aber wahr: Eigentlich braucht man nur beschreiben, welche Daten ausgetauscht werden sollen und schon steht fast das gesamte Backend. Und das ist ein sinnvoller Fortschritt, der dort vollzogen wird. Warum sollen die immerselben Businesslogiken von der Backendtruppe immer wieder auf neue händisch eingetippt werden? Oder warum soll der Entwickler sich Stunden aufschreiben, in denen er eigentlich nur Altes kopiert und sich ansonsten auf die faule Haut legt?

Da wir bereits von Businesslogik sprechen, die früher üblicherweise im Backend angesiedelt war, so kommt der eine oder andere vielleicht auf die Idee, dass diese nun einfach in die Frontendentwicklung abwandert und dann eben dort stattfindet. Das ist nicht richtig. Sie wandert zwar im Zuge der ebenfalls richtigen Evolution von klassischen, serverabhängigen, mehrseitigen Anwendungen in richtung Singlepage-Application oder PWA (Progressive Web Apps) also Anwendungen, die eher unabhängig von einem Server funktionieren und deshalb viel Businesslogik in der Anwedung selbst und nicht im Server haben. Doch diese wird bereits von den entsprechenden Generator wie jHipster gleich mitgeneriert.

Kernbereich 2: Spezialisten für native Appentwicklung

Derzeit ist es sinnvoll für Innovationen, mit einem plattformunabhängigen Framework App für mobile Geräte zu entwickeln. Einfach weil es günstiger ist, gleich für mehrere Plattformen zu entwickeln. Besser und hochwertiger allerdings ist die native Entwicklung für jede Plattform im Speziellen. Also eigens für Apple (iOS) und eigens für Android. Dafür benötigt man spezielle Swift oder Java-Entwickler. WebAssambly ist die nächste Evolutionsstufe: So wie Website einfach von eine Domain geladen werden, können mit WebAssembly schon heute native Apps entwickelt werden, die nicht über einen AppStore geladen werden müssen, sondern einfach über eine Domain abgerufen werden können. Und diese werden, sobald es die entsprechenden Phones dafür gibt, gleichmaßen gut auf dem Phone, dem Tablet und dem Desktop laufen. Schnell, nativ entwickelt.

Kernbereich 3: Frontendentwickler ablösen

Zu meiner Anfangszeit gab es Microsoft Frontend. Wer mit diesem Tool glaubte, Webentwicklung betreiben zu können, wurde schnell eines besseren belehrt. Das Tool wurde praktisch zu einem Witz unter allen Menschen, die sich mit der Entwicklung von Software oder auch nur einfachen Webseiten im Web beschätigten. Auch andere Tools, die Frontends irgendwie grafisch entwickeln lassen wollten, erreicht nie den Wartbarkeits und Erweiterbarkeits und Sauberkeitsanspruch echter Softwareentwickler. Heute gibt es allerdings die ersten Tools, wie WebFlow, die einen Grafiker in die Lage versetzen, seine Designs quasi direkt in diesem Tool umzusetzen, mit den üblichen Werkzeugen, mit leicht ungewohnter Herangehensweise. Ist diese Herangehensweise in gewissen Blöcken zu denken, allerdings akzeptiert, so generiert der Design gleich das gesamt Frontend. Ein Entwickler stöpselt bloß noch die Details zusammen. So ein Tools ist beispielsweise WebFlow.

Was für den Entwickler bleibt ist Zusammenstöpseln: Das werden die Waldundwiesenentwickler übernehmen. Davon wird der Bedarf dann in Zukunft gewaltig abnehmen. Und neue Businesslogik für echte Innovationen wird weiterhin benötigt. Das wiederum werden die besten Spezialisten auf ihrem Gebiet ausführen.