Analyse

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

(Foto: Shutterstock)

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

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.

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

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!

Hey du! Schön, dass du hier bist. 😊

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

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

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung