code Archive - Looped Learning

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.

Disclaimer for german readers: Dieser Artikel beschäftigt sich mit technischen Details. Falls sie auf der Suche nach Heigh-Level-Erklärungen sind, werden Sie in andern Artikeln eher fündig.

It shouldn’t take a rebuild to reconfigure an app for a certain environment. It should be build once and in each deployed state (test, nightly, demo, pre-prod, staging, prod, etc) have the configuration that applies on the server, respectivly environment.

The most common way to configure an app in a certain environment is by using environment variables. You can easily set them through .env files in Docker, Vagrant, AWS and other service providers.

To archive that, let’s start at the server side: A JavaScript-application runs on a webserver. It consists out of plain text files. While running on a client’s browser, there is now way for the JavaScript to access server values such as environment variables during runtime.

We need to inject the values, that life inside our server into the text files of our JavaScript application.

First, prepare a file called env.template.js with the environment variables you expect.

(function (window) {
    window["env"] = window["env"] || {};

    // Environment variables TEMPLATE
    window["env"]["title"] = "${TITLE}"; 
})(this);

And again, there is no pre-existing mechanism. Here we can see, we prepare that file with placeholders ${XYZ} as strings. To inject the environment variables, that live on the server and thus can be differ from one environment to another.

To create a mechanism we need to run the following command on the server (this can be done during the deployment process to a certain environment, e.g. in an CI/CD-pipeline.

envsubst < /home/nonroot/htdocs/assets/env.template.js > /home/nonroot/htdocs/assets/env.js

What this does is, it takes all the environment variables, set to a certain value currently on the machine, and replaces all the placeholders ${XYZ} that match.

For example if there was an environment variable TITLE set to "This is a title", then any occurance of ${TITLE} inside the file would be replaced by „This is a title“ (without the quotes). After that the new resulting file is written into a new file, here

/home/nonroot/htdocs/assets/env.js

The contents of the new file would look like the following snippet shows.

(function (window) {
    window["env"] = window["env"] || {};

    // Environment variables TEMPLATE
    window["env"]["title"] = "This is a title"; 
})(this);

That is what we wanted to have. We had no pre-existing mechanism, that lets us access the environment variables on the server inside a certain environment. Now we have injected them very clean into our application.

We have them available, how to process them in our application?

There is nothing wrong with simply including the env.js file in our index.html, right into the header (of course you can export and import it, which would be slightly cleaner).

<!-- Load environment variables -->
<script src="assets/env.js"></script>

Now, if the environemnt variable TITLE was declared on the machine the scripts are running on, window['env']['title'] should hold the value, in our case "This is a title" as string. Globaly, everywhere in our application (maybe some kind of anti-pattern, you have the force. Seal it with dependency injection and so on) Easy?

Use the environment variable inside the environment files

The environment file in angular are a bit misleading. The implay, that you should have one file for each environment. I just look at environment.ts and environment.prod.ts. In the latter we can use our window[„env“] variable now.

export const environment = {
  production: true,
  title: window['env']['title'] || 'A default value for a title',
};

That’s it. Comment if you like.

Looped Learning

#innovation, #newWork, #agile, #validatedLearning

Schlagwort-Archive: code

Was bedeutet WebAssembly für IT-Projekte?