Cross-Platform-Probleme?Massimo Parisi | shutterstock.com Plattformübergreifende Applikationen gehören heutzutage zum guten Ton. Das ist gut für die Benutzer, bedeutet für Softwareentwickler jedoch oft mehr Aufwand. Zum Beispiel werden folgende Fragen relevant, wenn es darum geht, Cross-Platform-Apps zu entwickeln: Wie ist mit Pfaden umzugehen? Wie erstellt man User Interfaces für Desktop-Anwendungen? Wie kompiliert man eine Binärdatei für eine andere Plattform? Die folgenden vier Tipps unterstützen Sie dabei, erfolgreich plattformübergreifende Anwendungen zu entwickeln. 1. Windows-Extrawürste machen Während Linux und macOS viele ähnliche Verhaltensweisen aufweisen und in weiten Teilen miteinander kompatibel sind, sieht es bei Windows anders aus. Das ist ein wesentlicher Faktor für die höhere Entwicklungskomplexität plattformübergreifender Anwendungen. Die Windows-Besonderheiten manifestieren sich insbesondere in den folgenden drei Bereichen. Zeilenumbrüche n ist unter Linux und macOS standardmäßig das Zeichen für den Zeilenumbruch in Textdateien. Unter Windows kommt dafür hingegen rn zum Einsatz. Glücklicherweise lassen sich diverse Editoren unter Windows auf den Linux- und macOS-Standard konfigurieren. Das ist aus Konsistenzgründen uneingeschränkt zu empfehlen. Für diese Line-Break Exception sind insbesondere Webformulare anfällig, die von Windows-Rechnern auf einen Server übertragen werden. Texteinträge, die über einen Browser unter Windows übermittelt werden, weisen rn am Zeilenende auf. Sie sollten deshalb sicherstellen, dass Ihr Web-Framework diese automatisch in n umwandelt. Dateipfad-Trennzeichen Windows kann den Backslash () als Pfadtrenner verwenden. Unter Linux und macOS ist er hingegen in jedem erwähnenswerten Kontext ein Escape-Zeichen. Diese Betriebssysteme verbinden Pfade mit dem Forward Slash (/). Die gute Nachricht: Die meisten neueren Windows-Versionen können letztgenannten ebenfalls als Pfadtrenner verwenden. Softwareentwickler sollten es nach Möglichkeit vermeiden, Pfade manuell aus Strings zu erstellen. Stattdessen empfiehlt es sich, eine objektorientierte Methode zu nutzen, um Pfade zu verarbeiten. Python verfügt beispielsweise im Rahmen seiner Standardbibliothek über das pathlib-Modul, das Pfade in Objekte anstelle von Strings umwandelt. Der richtige Pfadtrenner kann dann programmgesteuert angewendet werden – unabhängig davon, auf welchem Betriebssystem Sie arbeiten. Groß-/Kleinschreibung in Dateisystemen Windows selbst berücksichtigt zwar Groß-/Kleinschreibung, allerdings ignorieren die Dateisysteme FAT, FAT32 und NTFS unter Windows diese standardmäßig. Solange alle in Ihrer Anwendung verwendeten Dateinamen unabhängig von der Groß-/Kleinschreibung eindeutig sind, ist das kein großes Problem. Sehen Sie also unbedingt davon ab, myfile und MyFile im gleichen Verzeichnis abzulegen. 2. Web-Frontends nutzen Aller Kritik an Frameworks wie Electron zum Trotz, lösen diese ein bedeutendes Problem. Nämlich, Cross-Platform-Anwendungen einheitlich zu präsentieren. Electron beispielsweise nutzt Web-Technologie, um das Frontend einer App zu rendern. Dadurch werden Apps im Wesentlichen zu lokal gehosteten Webanwendungen. Argumente gegen Electron sind in der Regel: die Größe des Ergebnisses, die mehrere hundert Megabyte umfassen kann, dass ein Web-Frontend für spezifische Tasks nicht geeignet ist, sowie die übermäßige Abhängigkeit von HTML, CSS und JavaScript. Der erste Einwand ist völlig berechtigt. Electron-Builds sind in der Regel sehr groß, da Electron eine vollständige, eigenständige Webbrowser-Instanz erfordert, die mit dem Build gebündelt wird. Deshalb entstehen immer mehr Alternativen – etwa Tauri, das Rust verwendet und ein wesentlich kleineres Paket abliefert. Der Trend geht weg von monolithischen, Browser-basierten Ergebnissen und hin dazu, die vorhandenen Web-View-Komponenten des Betriebssystems zu nutzen, wann immer das möglich ist. Der Einwand, dass einige Apps mehr Performance benötigen, als ein Webbrowser bieten kann, dürfte im Zeitverlauf immer schwächer werden. Denn in vielen Fällen geht es weniger um die Fähigkeiten des Browsers an sich, sondern vielmehr darum, ein Frontend-Framework zu finden, mit dem man diese optimal nutzen kann. Für interaktive 3D-Grafiken liefert beispielsweise die three.js-Bibliothek beeindruckende Ergebnisse, die denen von vollständigen Desktop-Apps in nichts nachstehen. Auch der dritte Kritikpunkt – die übermäßige Abhängigkeit von HTML, CSS und JavaScript – hat seine Berechtigung. Webanwendungen zu schreiben, ist eine Kunst für sich und unterscheidet sich von anderen Spielarten der Anwendungsentwicklung. Gerade die überwältigende Anzahl an Frontend-Interaktivitätsoptionen (Angular, Vue, React, Vanilla JavaScript) kann angehende Entwickler verwirren. Die gute Nachricht: Es gibt eine riesige Auswahl an Tutorials, Tools, wiederverwendbaren Komponenten, dokumentierten Verfahren und Funktionsbeispielen, um Anwendungen mit Web-UIs zu erstellen. Tools wie HTMX erleichtern es, Apps zu schreiben, die gängige Verhaltsensmuster verwenden und einige Sprachen bieten auch Bibliotheken, die Frontend-Code programmgesteuert generieren – Anvil für Python beispielsweise. 3. Richtig cross-kompilieren Beim Cross-Compiling geht es darum, ein Programm auf einer Plattform so zu kompilieren, dass es auf einer anderen läuft. Es ist eines der komplexeren Unterfangen, wenn Applikationen plattformübergreifend bereitgestellt werden sollen. Unabhängig von der verwendeten Sprache lautet die wichtigste Regel dabei: Es ist immer einfacher, direkt auf der Zielplattform zu kompilieren. Die zweitwichtigste: Wenn Sie die Option haben, jemanden dafür zu bezahlen, diese Aufgabe für Sie zu übernehmen, lohnt sich das in den allermeisten Fällen. Zwar verfügen einige Programmiersprachen über Tools und Funktionen, um Cross-Compiling zu vereinfachen. So bietet zum Beispiel Rust eine entsprechende, semi-native Funktionalität innerhalb seiner Toolchain. Trotzdem müssen Sie jedoch noch einige zusätzliche Komponenten hinzufügen, um die Erfahrung zu vervollständigen – zum Beispiel einen geeigneten Linker. Ein weiteres, großes Problem bei der plattformübergreifenden Kompilierung ist die Asymmetrie: Wenn Sie ein macOS-Benutzer sind, ist es beispielsweise einfach, virtuelle Maschinen mit Windows oder Linux auf dem Mac einzurichten und zu warten. Verwenden Sie hingegen Linux oder Windows, ist es schon schwieriger, macOS auf diesen Plattformen zu emulieren. In diesem Fall können Tools wie osxcross helfen, um auf Linux-, FreeBSD- oder OpenBSD-Systemen plattformübergreifend zu kompilieren. Eine andere gängige Option besteht darin, Systeme wie GitHub Actions (über GitHub-gehostete Runner) oder Azure Pipelines zu nutzen, um Ihre Software auf einer der unterstützten Zielplattformen zu erstellen. 4. Neue Plattformen in Betracht ziehen Die Art und Weise, wie wir Apps schreiben und bereitstellen, unterliegt einem kontinuierlichen Wandel. Es lohnt sich deshalb, mit einem Auge immer in Richtung Zukunft zu schielen – in der plattformübergreifendes Deployment mehr und mehr zum Standard wird. Diesbezüglich lohnt sich vor allem der Blick auf WebAssembly (Wasm). Das ehemalige Browser-Tool entwickelt sich zu einer wichtigen plattformübergreifenden Laufzeitumgebung und bietet eine Möglichkeit, Portabilität zu erreichen, ohne dafür zu viel Performance zu opfern. Deshalb wird Wasm inzwischen sogar als potenzieller Ersatz für die Container-Technologie gehandelt. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
4 Tipps für bessere Cross-Platform-Apps
Cross-Platform-Probleme?Massimo Parisi | shutterstock.com Plattformübergreifende Applikationen gehören heutzutage zum guten Ton. Das ist gut für die Benutzer, bedeutet für Softwareentwickler jedoch oft mehr Aufwand. Zum Beispiel werden folgende Fragen relevant, wenn es darum geht, Cross-Platform-Apps zu entwickeln: Wie ist mit Pfaden umzugehen? Wie erstellt man User Interfaces für Desktop-Anwendungen? Wie kompiliert man eine Binärdatei für eine andere Plattform? Die folgenden vier Tipps unterstützen Sie dabei, erfolgreich plattformübergreifende Anwendungen zu entwickeln. 1. Windows-Extrawürste machen Während Linux und macOS viele ähnliche Verhaltensweisen aufweisen und in weiten Teilen miteinander kompatibel sind, sieht es bei Windows anders aus. Das ist ein wesentlicher Faktor für die höhere Entwicklungskomplexität plattformübergreifender Anwendungen. Die Windows-Besonderheiten manifestieren sich insbesondere in den folgenden drei Bereichen. Zeilenumbrüche n ist unter Linux und macOS standardmäßig das Zeichen für den Zeilenumbruch in Textdateien. Unter Windows kommt dafür hingegen rn zum Einsatz. Glücklicherweise lassen sich diverse Editoren unter Windows auf den Linux- und macOS-Standard konfigurieren. Das ist aus Konsistenzgründen uneingeschränkt zu empfehlen. Für diese Line-Break Exception sind insbesondere Webformulare anfällig, die von Windows-Rechnern auf einen Server übertragen werden. Texteinträge, die über einen Browser unter Windows übermittelt werden, weisen rn am Zeilenende auf. Sie sollten deshalb sicherstellen, dass Ihr Web-Framework diese automatisch in n umwandelt. Dateipfad-Trennzeichen Windows kann den Backslash () als Pfadtrenner verwenden. Unter Linux und macOS ist er hingegen in jedem erwähnenswerten Kontext ein Escape-Zeichen. Diese Betriebssysteme verbinden Pfade mit dem Forward Slash (/). Die gute Nachricht: Die meisten neueren Windows-Versionen können letztgenannten ebenfalls als Pfadtrenner verwenden. Softwareentwickler sollten es nach Möglichkeit vermeiden, Pfade manuell aus Strings zu erstellen. Stattdessen empfiehlt es sich, eine objektorientierte Methode zu nutzen, um Pfade zu verarbeiten. Python verfügt beispielsweise im Rahmen seiner Standardbibliothek über das pathlib-Modul, das Pfade in Objekte anstelle von Strings umwandelt. Der richtige Pfadtrenner kann dann programmgesteuert angewendet werden – unabhängig davon, auf welchem Betriebssystem Sie arbeiten. Groß-/Kleinschreibung in Dateisystemen Windows selbst berücksichtigt zwar Groß-/Kleinschreibung, allerdings ignorieren die Dateisysteme FAT, FAT32 und NTFS unter Windows diese standardmäßig. Solange alle in Ihrer Anwendung verwendeten Dateinamen unabhängig von der Groß-/Kleinschreibung eindeutig sind, ist das kein großes Problem. Sehen Sie also unbedingt davon ab, myfile und MyFile im gleichen Verzeichnis abzulegen. 2. Web-Frontends nutzen Aller Kritik an Frameworks wie Electron zum Trotz, lösen diese ein bedeutendes Problem. Nämlich, Cross-Platform-Anwendungen einheitlich zu präsentieren. Electron beispielsweise nutzt Web-Technologie, um das Frontend einer App zu rendern. Dadurch werden Apps im Wesentlichen zu lokal gehosteten Webanwendungen. Argumente gegen Electron sind in der Regel: die Größe des Ergebnisses, die mehrere hundert Megabyte umfassen kann, dass ein Web-Frontend für spezifische Tasks nicht geeignet ist, sowie die übermäßige Abhängigkeit von HTML, CSS und JavaScript. Der erste Einwand ist völlig berechtigt. Electron-Builds sind in der Regel sehr groß, da Electron eine vollständige, eigenständige Webbrowser-Instanz erfordert, die mit dem Build gebündelt wird. Deshalb entstehen immer mehr Alternativen – etwa Tauri, das Rust verwendet und ein wesentlich kleineres Paket abliefert. Der Trend geht weg von monolithischen, Browser-basierten Ergebnissen und hin dazu, die vorhandenen Web-View-Komponenten des Betriebssystems zu nutzen, wann immer das möglich ist. Der Einwand, dass einige Apps mehr Performance benötigen, als ein Webbrowser bieten kann, dürfte im Zeitverlauf immer schwächer werden. Denn in vielen Fällen geht es weniger um die Fähigkeiten des Browsers an sich, sondern vielmehr darum, ein Frontend-Framework zu finden, mit dem man diese optimal nutzen kann. Für interaktive 3D-Grafiken liefert beispielsweise die three.js-Bibliothek beeindruckende Ergebnisse, die denen von vollständigen Desktop-Apps in nichts nachstehen. Auch der dritte Kritikpunkt – die übermäßige Abhängigkeit von HTML, CSS und JavaScript – hat seine Berechtigung. Webanwendungen zu schreiben, ist eine Kunst für sich und unterscheidet sich von anderen Spielarten der Anwendungsentwicklung. Gerade die überwältigende Anzahl an Frontend-Interaktivitätsoptionen (Angular, Vue, React, Vanilla JavaScript) kann angehende Entwickler verwirren. Die gute Nachricht: Es gibt eine riesige Auswahl an Tutorials, Tools, wiederverwendbaren Komponenten, dokumentierten Verfahren und Funktionsbeispielen, um Anwendungen mit Web-UIs zu erstellen. Tools wie HTMX erleichtern es, Apps zu schreiben, die gängige Verhaltsensmuster verwenden und einige Sprachen bieten auch Bibliotheken, die Frontend-Code programmgesteuert generieren – Anvil für Python beispielsweise. 3. Richtig cross-kompilieren Beim Cross-Compiling geht es darum, ein Programm auf einer Plattform so zu kompilieren, dass es auf einer anderen läuft. Es ist eines der komplexeren Unterfangen, wenn Applikationen plattformübergreifend bereitgestellt werden sollen. Unabhängig von der verwendeten Sprache lautet die wichtigste Regel dabei: Es ist immer einfacher, direkt auf der Zielplattform zu kompilieren. Die zweitwichtigste: Wenn Sie die Option haben, jemanden dafür zu bezahlen, diese Aufgabe für Sie zu übernehmen, lohnt sich das in den allermeisten Fällen. Zwar verfügen einige Programmiersprachen über Tools und Funktionen, um Cross-Compiling zu vereinfachen. So bietet zum Beispiel Rust eine entsprechende, semi-native Funktionalität innerhalb seiner Toolchain. Trotzdem müssen Sie jedoch noch einige zusätzliche Komponenten hinzufügen, um die Erfahrung zu vervollständigen – zum Beispiel einen geeigneten Linker. Ein weiteres, großes Problem bei der plattformübergreifenden Kompilierung ist die Asymmetrie: Wenn Sie ein macOS-Benutzer sind, ist es beispielsweise einfach, virtuelle Maschinen mit Windows oder Linux auf dem Mac einzurichten und zu warten. Verwenden Sie hingegen Linux oder Windows, ist es schon schwieriger, macOS auf diesen Plattformen zu emulieren. In diesem Fall können Tools wie osxcross helfen, um auf Linux-, FreeBSD- oder OpenBSD-Systemen plattformübergreifend zu kompilieren. Eine andere gängige Option besteht darin, Systeme wie GitHub Actions (über GitHub-gehostete Runner) oder Azure Pipelines zu nutzen, um Ihre Software auf einer der unterstützten Zielplattformen zu erstellen. 4. Neue Plattformen in Betracht ziehen Die Art und Weise, wie wir Apps schreiben und bereitstellen, unterliegt einem kontinuierlichen Wandel. Es lohnt sich deshalb, mit einem Auge immer in Richtung Zukunft zu schielen – in der plattformübergreifendes Deployment mehr und mehr zum Standard wird. Diesbezüglich lohnt sich vor allem der Blick auf WebAssembly (Wasm). Das ehemalige Browser-Tool entwickelt sich zu einer wichtigen plattformübergreifenden Laufzeitumgebung und bietet eine Möglichkeit, Portabilität zu erreichen, ohne dafür zu viel Performance zu opfern. Deshalb wird Wasm inzwischen sogar als potenzieller Ersatz für die Container-Technologie gehandelt. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
4 Tipps für bessere Cross-Platform-Apps Cross-Platform-Probleme?Massimo Parisi | shutterstock.com Plattformübergreifende Applikationen gehören heutzutage zum guten Ton. Das ist gut für die Benutzer, bedeutet für Softwareentwickler jedoch oft mehr Aufwand. Zum Beispiel werden folgende Fragen relevant, wenn es darum geht, Cross-Platform-Apps zu entwickeln: Wie ist mit Pfaden umzugehen? Wie erstellt man User Interfaces für Desktop-Anwendungen? Wie kompiliert man eine Binärdatei für eine andere Plattform? Die folgenden vier Tipps unterstützen Sie dabei, erfolgreich plattformübergreifende Anwendungen zu entwickeln. 1. Windows-Extrawürste machen Während Linux und macOS viele ähnliche Verhaltensweisen aufweisen und in weiten Teilen miteinander kompatibel sind, sieht es bei Windows anders aus. Das ist ein wesentlicher Faktor für die höhere Entwicklungskomplexität plattformübergreifender Anwendungen. Die Windows-Besonderheiten manifestieren sich insbesondere in den folgenden drei Bereichen. Zeilenumbrüche n ist unter Linux und macOS standardmäßig das Zeichen für den Zeilenumbruch in Textdateien. Unter Windows kommt dafür hingegen rn zum Einsatz. Glücklicherweise lassen sich diverse Editoren unter Windows auf den Linux- und macOS-Standard konfigurieren. Das ist aus Konsistenzgründen uneingeschränkt zu empfehlen. Für diese Line-Break Exception sind insbesondere Webformulare anfällig, die von Windows-Rechnern auf einen Server übertragen werden. Texteinträge, die über einen Browser unter Windows übermittelt werden, weisen rn am Zeilenende auf. Sie sollten deshalb sicherstellen, dass Ihr Web-Framework diese automatisch in n umwandelt. Dateipfad-Trennzeichen Windows kann den Backslash () als Pfadtrenner verwenden. Unter Linux und macOS ist er hingegen in jedem erwähnenswerten Kontext ein Escape-Zeichen. Diese Betriebssysteme verbinden Pfade mit dem Forward Slash (/). Die gute Nachricht: Die meisten neueren Windows-Versionen können letztgenannten ebenfalls als Pfadtrenner verwenden. Softwareentwickler sollten es nach Möglichkeit vermeiden, Pfade manuell aus Strings zu erstellen. Stattdessen empfiehlt es sich, eine objektorientierte Methode zu nutzen, um Pfade zu verarbeiten. Python verfügt beispielsweise im Rahmen seiner Standardbibliothek über das pathlib-Modul, das Pfade in Objekte anstelle von Strings umwandelt. Der richtige Pfadtrenner kann dann programmgesteuert angewendet werden – unabhängig davon, auf welchem Betriebssystem Sie arbeiten. Groß-/Kleinschreibung in Dateisystemen Windows selbst berücksichtigt zwar Groß-/Kleinschreibung, allerdings ignorieren die Dateisysteme FAT, FAT32 und NTFS unter Windows diese standardmäßig. Solange alle in Ihrer Anwendung verwendeten Dateinamen unabhängig von der Groß-/Kleinschreibung eindeutig sind, ist das kein großes Problem. Sehen Sie also unbedingt davon ab, myfile und MyFile im gleichen Verzeichnis abzulegen. 2. Web-Frontends nutzen Aller Kritik an Frameworks wie Electron zum Trotz, lösen diese ein bedeutendes Problem. Nämlich, Cross-Platform-Anwendungen einheitlich zu präsentieren. Electron beispielsweise nutzt Web-Technologie, um das Frontend einer App zu rendern. Dadurch werden Apps im Wesentlichen zu lokal gehosteten Webanwendungen. Argumente gegen Electron sind in der Regel: die Größe des Ergebnisses, die mehrere hundert Megabyte umfassen kann, dass ein Web-Frontend für spezifische Tasks nicht geeignet ist, sowie die übermäßige Abhängigkeit von HTML, CSS und JavaScript. Der erste Einwand ist völlig berechtigt. Electron-Builds sind in der Regel sehr groß, da Electron eine vollständige, eigenständige Webbrowser-Instanz erfordert, die mit dem Build gebündelt wird. Deshalb entstehen immer mehr Alternativen – etwa Tauri, das Rust verwendet und ein wesentlich kleineres Paket abliefert. Der Trend geht weg von monolithischen, Browser-basierten Ergebnissen und hin dazu, die vorhandenen Web-View-Komponenten des Betriebssystems zu nutzen, wann immer das möglich ist. Der Einwand, dass einige Apps mehr Performance benötigen, als ein Webbrowser bieten kann, dürfte im Zeitverlauf immer schwächer werden. Denn in vielen Fällen geht es weniger um die Fähigkeiten des Browsers an sich, sondern vielmehr darum, ein Frontend-Framework zu finden, mit dem man diese optimal nutzen kann. Für interaktive 3D-Grafiken liefert beispielsweise die three.js-Bibliothek beeindruckende Ergebnisse, die denen von vollständigen Desktop-Apps in nichts nachstehen. Auch der dritte Kritikpunkt – die übermäßige Abhängigkeit von HTML, CSS und JavaScript – hat seine Berechtigung. Webanwendungen zu schreiben, ist eine Kunst für sich und unterscheidet sich von anderen Spielarten der Anwendungsentwicklung. Gerade die überwältigende Anzahl an Frontend-Interaktivitätsoptionen (Angular, Vue, React, Vanilla JavaScript) kann angehende Entwickler verwirren. Die gute Nachricht: Es gibt eine riesige Auswahl an Tutorials, Tools, wiederverwendbaren Komponenten, dokumentierten Verfahren und Funktionsbeispielen, um Anwendungen mit Web-UIs zu erstellen. Tools wie HTMX erleichtern es, Apps zu schreiben, die gängige Verhaltsensmuster verwenden und einige Sprachen bieten auch Bibliotheken, die Frontend-Code programmgesteuert generieren – Anvil für Python beispielsweise. 3. Richtig cross-kompilieren Beim Cross-Compiling geht es darum, ein Programm auf einer Plattform so zu kompilieren, dass es auf einer anderen läuft. Es ist eines der komplexeren Unterfangen, wenn Applikationen plattformübergreifend bereitgestellt werden sollen. Unabhängig von der verwendeten Sprache lautet die wichtigste Regel dabei: Es ist immer einfacher, direkt auf der Zielplattform zu kompilieren. Die zweitwichtigste: Wenn Sie die Option haben, jemanden dafür zu bezahlen, diese Aufgabe für Sie zu übernehmen, lohnt sich das in den allermeisten Fällen. Zwar verfügen einige Programmiersprachen über Tools und Funktionen, um Cross-Compiling zu vereinfachen. So bietet zum Beispiel Rust eine entsprechende, semi-native Funktionalität innerhalb seiner Toolchain. Trotzdem müssen Sie jedoch noch einige zusätzliche Komponenten hinzufügen, um die Erfahrung zu vervollständigen – zum Beispiel einen geeigneten Linker. Ein weiteres, großes Problem bei der plattformübergreifenden Kompilierung ist die Asymmetrie: Wenn Sie ein macOS-Benutzer sind, ist es beispielsweise einfach, virtuelle Maschinen mit Windows oder Linux auf dem Mac einzurichten und zu warten. Verwenden Sie hingegen Linux oder Windows, ist es schon schwieriger, macOS auf diesen Plattformen zu emulieren. In diesem Fall können Tools wie osxcross helfen, um auf Linux-, FreeBSD- oder OpenBSD-Systemen plattformübergreifend zu kompilieren. Eine andere gängige Option besteht darin, Systeme wie GitHub Actions (über GitHub-gehostete Runner) oder Azure Pipelines zu nutzen, um Ihre Software auf einer der unterstützten Zielplattformen zu erstellen. 4. Neue Plattformen in Betracht ziehen Die Art und Weise, wie wir Apps schreiben und bereitstellen, unterliegt einem kontinuierlichen Wandel. Es lohnt sich deshalb, mit einem Auge immer in Richtung Zukunft zu schielen – in der plattformübergreifendes Deployment mehr und mehr zum Standard wird. Diesbezüglich lohnt sich vor allem der Blick auf WebAssembly (Wasm). Das ehemalige Browser-Tool entwickelt sich zu einer wichtigen plattformübergreifenden Laufzeitumgebung und bietet eine Möglichkeit, Portabilität zu erreichen, ohne dafür zu viel Performance zu opfern. Deshalb wird Wasm inzwischen sogar als potenzieller Ersatz für die Container-Technologie gehandelt. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
