2019 ist so gut wie zu Ende. Wir haben zwar keine Kristallkugel, anhand von Trends und mithilfe des Internets haben wir hier jedoch 3½ Vorhersagen für die Zukunft der Webentwicklung aufgeschrieben. Ob sie sich bewahrheiten, könnt ihr in einem beziehungsweise fünf Jahren gegenchecken – wir sind gespannt.

Prognosen zu treffen, ist sinnvoll, sagt dieser Entwickler – sein Talk bei der diesjährigen Reactive Conference in Prag inspirierte diesen Artikel. Entscheidungen anhand von Vorhersagen zu treffen, findet er sinnvoller, als blind der Masse zu folgen. Als Beispiel führt er Perl an. 2006 waren der sogenannte LAMP-Stack, Linux, Apache, MySQL und P für PHP, Python und Perl für Web-Entwickler so etwas wie ein Standard. Heute, 2019, finden Unternehmen, die es in den 13 Jahren dazwischen verpasst haben, zu wechseln, nur schwer neue Entwickler. Mit Perl will einfach (fast) niemand mehr arbeiten. Was damals aussah wie eine Safe Bet, ist heute quasi in der Versenkung verschwunden. In den Beliebtheitslisten auf Stackoverflow oder GitHub taucht Perl seit Jahren nicht einmal mehr auf.

Et voilà:

TypeScript wird noch wichtiger. Bekannte Frameworks wie React, Angular oder Vue unterstützen die Sprache. Neue Tools, Features oder Frameworks innerhalb des Webentwicklungs-Kosmos kommen mittlerweile oft von Beginn an mit TypeScript-Support. Mittlerweile hat TypeScript ähnliche Ansätze wie zum Beispiel CoffeeScript bei weitem überflügelt. Dass TypeScript nach einem kurzen Hype ähnlich wie CoffeeScript quasi in der Versenkung verschwindet, ist aber unwahrscheinlich: Entwicklerteams wechseln von JavaScript zu TypeScript und nach einer Testphase oft nicht wieder zurück.

Prognose: Für neue Projekte werden sich 2020 die meisten Teams für TypeScript entscheiden. Fünf Jahre später wird mehr TypeScript geschrieben werden als JavaScript ohne TypeScript.

JavaScript-Alternativen werden es auch in fünf Jahren nicht schaffen, JavaScript gefährlich zu werden. Wer früher kein JavaScript schreiben wollte, konnte auf Java-Applets ausweichen. Oder auf Flash. Heute werden Alternativen zu JavaScript genutzt, die zu JavaScript kompiliert werden. Die sind JavaScript aber allesamt ziemlich ähnlich. TypeScript zum Beispiel. Momentan außerdem sehr beliebt ist Svelte – ein Framework, das euren Code während der Laufzeit  kompiliert. Darin unterscheidet sich Svelte von React oder Vue, die das größtenteils im Browser ausführen. Auch Dart, die Programmiersprache aus dem Hause Google, kann (ohne Web-Assembly) zu JS kompiliert werden. Dart wird oft als eine Mischung aus JavaScript und C bezeichnet – die Lernkurve für JavaScript-kundige Entwickler ist relativ moderat. Außerdem natürlich Babel – keine Sprache, aber ein Compiler, der es ermöglicht, neue JavaScript-Versionen sofort nutzen zu können. Über Babel wird „zukünftiges JavaScript“ – also ES 2015+ – zu für heutige Browser lesbarem JavaScript.

Weniger bekannte Alternativen, die nicht so nah an JavaScript sind wie etwa TypeScript, sind Elm, ReasonML oder ClosureScript. Deren Nutzerbasis ist klein und wird wahrscheinlich klein bleiben – eine unbekannte, kleine Programmiersprache zu lernen, mit der ihr Dinge tun könnt, die ihr auch mit JavaScript – und JavaScript-näheren Sprachen – tun könnt, werden wahrscheinlich die wenigsten von euch in den nächsten Jahren in Erwägung ziehen.

Prognose: Keine davon wird – was die Popularität angeht – TypeScript bis 2025 das Wasser reichen können.

Web Assembly bietet einen Weg, um fast-Maschinencode im Browser laufen zu lassen. Damit lassen sich Applikationen bauen, die sehr viel schneller und performanter sind als welche in JS. Ein möglicher Use-Case für Web Assembly: Die Performanz von JS-Apps und -Bibliotheken zu verbessern. Existierende Frameworks sind allerdings auch ohne oft schon ausreichend schnell, so revolutionär wäre das wohl nicht.

Ein viel spannenderer Anwendungsfall sind Web-Apps. Zum Beispiel Figma. Figma ist eine browser-basierte Grafiksoftware – und wurde in C++ gebaut. Figmas Entwicklerteam macht von Webtechnologien nicht wirklich Gebrauch. Figma-Nutzer rufen einfach eine URL auf und nutzen die Software, dazwischen stehen kein App-Store, keine Permissions und kein Installer. Damit einher geht, dass sich Projekte in Figma super-einfach zwischen Usern teilen lassen: Wenn ihr wollt, dass jemand anders sich auf genau derselben Seite befindet wie ihr, schickt ihr einfach einen Link zu genau dieser Seite – gute Gründe, die eindeutig für die Verlagerung eigentlich nativer Apps in den Browser sprechen. Ein weiterer Vorteil: Native Apps sind oft sehr groß. Photoshop zum Beispiel ist ein Multi-Megabyte-Download. Zum Vergleich: React ist nur 77 Kilobyte groß. Bisher nahmen die Nutzer die Größe dieser Anwendungen in Kauf, mit dem Aufkommen von browser-basierten Alternativen könnte sich das aber ändern – dafür sprechen etwa Figmas wachsende Nutzerzahlen.

Native Applikationen, die im Browser laufen und mit Sprachen wie zum Beispiel Rust entwickelt wurden, werden HTML, CSS und JS aber nicht ersetzen. Entwickler werden nicht die Art, wie sie Webanwendungen entwickeln, ändern, nur weil es eine andere Option gibt. Aber: Weil es Web Assembly gibt, wird sich das Spektrum dessen, was es alles als Web-App gibt, weiter vergrößern.

Zum Beispiel Spiele. Eine Szenerie, in der Leute sich frei bewegen können, baut ihr nicht einfach so in CSS – dafür braucht ihr diese hochperformanten Low-Level-Technologien, die ihr mit Web Assembly Browser-tauglich machen könnt.

Prognose: Bis 2020 wird sich die Zusammensetzung des Webs durch den Einfluss von Web Assembly nicht groß verändert haben, es ist aber sehr wahrscheinlich, dass es 2025 eine neue Nische sehr großer In-Browser-Apps geben wird.

Zu npm gibt es Alternativen wie zum Beispiel Entropic. Yarn ist keine alternatives Paketregister, sondern lediglich eine andere Art, auf das npm-Ökosystem und dessen Server-Hardware zuzugreifen. Yarn nutzt genau wie npm das npm-Package-Registry. Ob ihr also npm install x oder yarn install x nutzt – das Ergebnis ist dasselbe. Das GitHub Package Registry ist ein mit der npm Server-Umgebung in Konkurrenz stehendes Backend. GitHub Package Registry ist quasi das Gegenteil von yarn – es nutzt das npm CLI und greift so anstelle der npm-Server auf eine andere URL zu. Als Zeichen für npms Niedergang sind diese Alternativen aber absolut nicht zu werten, Koexistenz ist hier wahrscheinlich ein treffenderes Stichwort.

npm wird bleiben – auch wenn immer wieder Probleme auftreten werden. Wie zum Beispiel im Fall von left-pad, als 2016 jemand auf die Idee kam, das Package zu unpublishen und Tausende Projekte in der Folge nicht korrekt deployed werden konnten. npm behob diese Lücke, indem sie in der Folge festlegten, dass Packages zukünftig nicht mehr einfach so unpublished werden können. Oder, als über Eventstream Schadsoftware verteilt wurde. Es gab keine einzelne Root-Cause für die Lücke, die gefixed werden konnte – sie ist übrigens immer noch da. Überhaupt ist npm keine sichere Sache – und trotzdem greift die gesamte Web-Entwickler-Community laufend auf den Paketmanager zurück.

Installiert ihr etwas über bash install, ist das eine potenzielle Safety-Issue: Der Command führt Code auf eurem Rechner aus und ihr habt keinen Einfluss darauf. Installiert ihr etwas über npm install, führt der Command beliebigen Code auf eurem Rechner aus, der von Tausenden unterschiedlichen Packages kommt. Potenziell ist das ungefähr tausendfach gefährlicher.

Angenommen, in der package.json einer dieser Dependencies gibt es eine Sache, die sich „Post-Install-Hook“ nennt. Der Post-Install-Hook führt beliebigen, von euch nicht definierten Code auf eurem Gerät aus – und das jedes Mal, wenn dieses Paket installiert wird. Potenziell könnte dieser Code einen Virus enthalten – dann habt ihr einen Virus. Dass das noch nicht passiert ist, ist wahrscheinlich der einzige Grund, warum das noch nicht passiert ist.

2016 veröffentlichte npm einen Blogpost, in dem sie explizit auf genau diese Gefahr hinweisen. Im Blogpost findet ihr außerdem den Hinweis auf einen Command, der die Ausführung von post- und pre-Install-Hooks verhindert:

npm config set ignore-scripts true.

Das ist weniger bequem, manchmal behindert die Einstellung wohl die Ausführung von Code und ihr braucht an diesen Stellen einen Workaround – am Ende obliegt es aber eurer eigenen Entscheidung, ob ihr euch lieber manchmal etwas mehr anstrengen oder lieber anfällig für potenziell auftauchende Malware sein wollt. Wer darauf keine Lust hat, kann im Einzelfall auch den Command npm install --ignore-scripts nutzen.

Bottom-line: Auch wenn der Paketmanager Schwachstellen aufweist und finanzielle Probleme hat: npm wird bleiben. Allein wegen der starken Netzwerkeffekte. Was allerdings nicht ausschließt, dass es 2020 neue Security-Incidents geben könnte. Zudem ist denkbar – wenn auch nicht zu hoffen – dass bis 2025 ein Malware-infiziertes Package eine ganze Reihe von Geräten infiziert haben wird – wer’s bisher nicht wusste, weiß aber wenigstens spätestens jetzt, was zu tun ist, damit das eigene nicht dazugehören wird.