Analyse

Web-Development jetzt und später: 3 ½ Vorhersagen, die du lesen solltest

(Foto: Shutterstock)

Lesezeit: 6 Min. Gerade keine Zeit? Jetzt speichern und später lesen

Das Jahr neigt sich dem Ende zu. Anstatt nur zu rekapitulieren, haben wir uns angeschaut, was die nahe Zukunft für die Webentwicklung bringen könnte und 3 ½ Vorhersagen aufgeschrieben.

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à:

Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Vorhersage Nr. 1½: TypeScript führt seinen Eroberungsfeldzug fort

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.

Vorhersage 2: Web Assembly wird den Web-App-Pie vergrößern

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.

Vorhersage 3: npm wird trotz Issues die unangefochtene Nummer 1 bleiben

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.

Zum Weiterlesen: Diese Programmiersprachen solltet ihr 2020 unbedingt lernen

Das könnte dich auch interessieren

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Ein Kommentar
K. Wegmeyer
K. Wegmeyer

Jein! Den LAMP Stack mit PHP würde ich noch nicht abschreiben. Da passiert gerade sehr viel. Viele Schwächen verschwinden immer mehr.

Typescript ist toll und auch ich sehe da die Zukunft. Dem Loblied auf Javascript kann ich (noch) nicht zustimmen. Private Attribute und Methoden fehlen mir z.B. In den verbreiteten engins. Aber das kommt; mir wäre aber ein Typescript im Browser lieber.

Es bleibt jedenfalls spannend!

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Digitales High Five
Holger Schellkopf (Chefredakteur t3n)

Anleitung zur Deaktivierung