Kolumne: Olis bunte Welt der IT

Moderne Webframeworks – zurück auf den Server?

Moderne Webframeworks – zurück auf den Server?

Kolumne: Olis bunte Welt der IT

Moderne Webframeworks – zurück auf den Server?


Letzte Woche war ich auf der iJS, der International JavaScript Conference in München. Für mich ging es da hauptsächlich um Svelte – natürlich auch ein modernes Webframework wie im Titel, aber nicht direkt zusammenhängend. Da gab es eine Menge Nostalgie, denn die Konferenz findet parallel zur IPC statt, der International PHP Conference. PHP … das habe ich in den letzten Jahren mal notgedrungen benutzt, um mit WordPress zu arbeiten, aber abgesehen davon nicht mehr seit den 90ern oder vielleicht den frühen 2000ern. PHP/FI hieß das, als ich es zum ersten Mal einsetzte, damals ganz begeistert … Erstaunlich, wie die Welt sich für mich in so viele andere Richtungen weiter gedreht hat, während offensichtlich mancher noch heute auf diese Plattform setzt.

Interessant an meinen Überlegungen zu PHP ist, dass manche aktuellen Bestrebungen neuer Webframeworks in eine ähnliche Richtung tendieren, wie sie PHP seinerzeit verfolgte: die dynamische Erzeugung gerenderter Inhalte auf dem Server. Möglicherweise, und je nachdem, welche Projekte zum Vergleich herangezogen werden, enden an dieser Stelle die Parallelen. Bemerkenswert ist diese Renaissance aber auf jeden Fall!

Auf der BASTA! vor ein paar Wochen hielt ich gemeinsam mit Manfred Steyer und Martina Kraus eine Keynote, in der es um die Zielstellungen verschiedener aktueller Frameworks ging, spezifisch Astro [1], Qwik [2] und, zu einem gewissen Grad, React Server Components. Auf der iJS hatte Manfred kurzfristig Gelegenheit, die Keynote noch einmal allein zu wiederholen, und natürlich mussten wir im Anschluss weiter über die wichtigsten Themen diskutieren.

Ich habe frische Gedanken, und auch die Überlegungen, die ich bereits auf der BASTA! umrissen hatte, sind nun etwas mehr gefestigt: Ich stehe den Ideen zur Rückkehr zum Server skeptisch gegenüber! Das soll nicht bedeuten, dass ich keinen Wert in den neuen Frameworks sehe, aber ich denke, dass in jedem Projekt eine detaillierte Betrachtung von Anforderungen und erwünschten sowie zufälligen Effekten notwendig ist, bevor bestimmte Strategien verfolgt werden können.

Als die Welt noch jung war

Irgendwann früher einmal war es so, dass der Client im Web dumm war. Da gab es gar kein JavaScript, oder etwas später war JavaScript nur für einfache Event Handler einsetzbar und wurde generell als Sicherheitsproblem betrachtet. Daher musste natürlich der Server, wenn eine Anwendung dynamische Informationen präsentieren wollte, diese entsprechend aufbereiten und sie fertig in Form von HTML an den Client liefern. Das taten die ersten Webseiten mit Hilfe von CGI-Skripten, die oft in Perl geschrieben waren, oder halt mit PHP oder anderen Sprachen, die später als Module im Webserver integriert werden konnten und so bessere Performance erreichten. Wer weiter optimieren wollte, musste strukturell denken, um das Volumen einzelner Datenübertragungen zu reduzieren. Wenn es etwa lange Listen von Daten zu rendern gab, wurde blockweise unterteilt, vielleicht alphabetisch oder nach Wertebereichen. Der bestmögliche Kompromiss musste her, zwischen einer vertretbaren Maximalgröße einer einzelnen HTML-Quelle und einer noch haltbaren Anzahl von notwendigen Requests für den Umgang mit einer Webseite, denn auch die Latenz wurde bei mehreren Requests schnell zum Problem. Da serverseitige Performance kritisch wurde, wenn viele parallele Anfragen bearbeitet werden mussten, optimierte man auch dadurch, dass dynamisches Rendern nur in den wichtigsten Fällen eingesetzt wurde.

Nun drehte sich die Welt ein wenig weiter, JavaScript gewann enorm an Relevanz, und um den Jahrtausendwechsel herum begann sich ein neues Konzept durchzusetzen: AJAX. Der Gedanke war, dass mit JavaScript das dynamische Nachladen von Inhalten...