Programmiersprachen für Webseiten: Auswahl nach Projekttyp und Folgekosten

Die Frage “welche Programmiersprache für eine Webseite” hat keine allgemeine Antwort, weil sie zwei sehr verschiedene Entscheidungen vermischt. Die eine Entscheidung treffen Sie gar nicht: Was im Browser des Besuchers ausgeführt wird, ist technisch vorgegeben. Die andere treffen Sie sehr wohl, und sie kostet Sie über Jahre Geld: Was auf dem Server läuft, bestimmt Ihre Hosting-Anforderungen, Ihren Update-Rhythmus und die Frage, wie leicht Sie in fünf Jahren jemanden finden, der das Projekt weiterführt.

Diese Seite ordnet die Sprachen deshalb nicht alphabetisch, sondern nach der Situation, in der Sie sich befinden. Am Anfang steht die Frage, die am häufigsten übersprungen wird: ob Sie überhaupt eine Programmiersprache brauchen.

Die Vorfrage: Brauchen Sie überhaupt eine Programmiersprache?

Für einen großen Teil kleiner Webprojekte lautet die ehrliche Antwort: nein. Eine rein statische Webseite aus HTML- und CSS-Dateien benötigt serverseitig keine Programmiersprache, sondern nur einen Webserver, der Dateien ausliefert (MDN Web Docs, “What is a web server?”). Wer eine Visitenkartenseite, eine Veranstaltungsseite oder eine Produktdarstellung mit fünf bis zwanzig Unterseiten plant, deren Inhalte sich selten ändern, trifft mit dieser Variante die günstigste Entscheidung, die es gibt.

Dabei hilft eine Unterscheidung, die in der Praxis ständig verwischt wird. HTML ist eine Auszeichnungssprache und keine Programmiersprache: Es beschreibt Struktur, kennt aber keine Kontrollflusskonstrukte, also keine Bedingungen und keine Schleifen (WHATWG HTML Living Standard, Abschnitt “Introduction”). CSS ist eine Stylesheet-Sprache zur Beschreibung der Darstellung von in HTML oder XML ausgezeichneten Dokumenten (W3C, CSS Snapshot). Beide zusammen ergeben eine vollständige, funktionsfähige Webseite. Wenn Ihnen jemand sagt, dafür brauche man “mindestens PHP”, beschreibt das eine Gewohnheit, keine technische Notwendigkeit.

Der Punkt, an dem eine serverseitige Sprache tatsächlich unvermeidlich wird, lässt sich benennen. Sie brauchen sie, sobald der Server auf eine Anfrage hin etwas berechnen, speichern oder individuell zusammenstellen muss: Formulare, die Daten entgegennehmen und ablegen, Logins, Warenkörbe, Suchfunktionen über eine Datenbank, Inhalte, die Redakteure ohne Dateizugriff pflegen. Alles darunter ist eine Frage der Bequemlichkeit, nicht der Machbarkeit.

Was im Browser läuft, ist keine Auswahl

Auf der Client-Seite gibt es faktisch nur eine Option. JavaScript ist die einzige Programmiersprache, die alle gängigen Browser nativ ausführen; sie ist als ECMAScript standardisiert (Ecma International, ECMA-262). Damit ist die Frage “welche Sprache für die Interaktivität meiner Webseite” für die überwiegende Mehrheit der Projekte bereits beantwortet, bevor sie gestellt wird.

Zwei Ergänzungen ändern daran wenig, tauchen in Angeboten aber regelmäßig als vermeintliche Alternativen auf. TypeScript ist eine typisierte Obermenge von JavaScript und wird vor der Ausführung nach JavaScript kompiliert; im Browser läuft am Ende JavaScript (TypeScript Handbook, “The Basics”). Die Entscheidung für TypeScript ist also keine Sprachentscheidung im engeren Sinn, sondern eine Entscheidung über Ihren Entwicklungsprozess: mehr Aufwand beim Schreiben, weniger Klassen von Fehlern zur Laufzeit, ein zusätzlicher Build-Schritt in der Wartung.

WebAssembly ist seit dem 5. Dezember 2019 offizielle W3C-Recommendation und erlaubt es, in Sprachen wie C++ oder Rust geschriebenen Code im Browser auszuführen (W3C, “WebAssembly Core Specification”). Das ist relevant, wenn Sie rechenintensive Funktionen im Browser brauchen, etwa Bild- oder Videoverarbeitung oder eine Simulation. Für eine Unternehmenswebseite, einen Blog oder einen normalen Shop ist es keine Option, sondern ein Kostentreiber ohne Gegenwert.

Eine Namensverwechslung sei hier abgeräumt, weil sie in Ausschreibungen echte Fehlentscheidungen produziert: Java und JavaScript sind trotz des Namens unterschiedliche Sprachen mit getrennter Herkunft und Spezifikation (MDN Web Docs, “JavaScript basics”). Wer “Java” in ein Lastenheft schreibt und “JavaScript” meint, bekommt Angebote für ein völlig anderes Projekt.

Vier Projekttypen und was sie tatsächlich verlangen

Die brauchbare Sortierung verläuft entlang des Projekttyps. Vier Fälle decken den größten Teil dessen ab, was in der Praxis gebaut wird.

Statische Seite. Inhalte ändern sich selten, es gibt keine Nutzerkonten, kein Formular außer vielleicht einem Kontaktformular über einen externen Dienst. Serverseitig ist keine Programmiersprache nötig. JavaScript kommt nur punktuell dazu, etwa für ein Menü oder eine Bildergalerie. Das Hosting ist entsprechend anspruchslos, weil nur Dateien ausgeliefert werden. Der wichtigste Nebeneffekt: Es gibt keine serverseitige Laufzeit, die veralten und zum Sicherheitsrisiko werden kann.

CMS-Website. Redakteure sollen Inhalte pflegen, ohne Dateien anzufassen. Hier dominiert PHP, und zwar deutlich. PHP ist die mit Abstand am häufigsten eingesetzte serverseitige Programmiersprache im Web; W3Techs weist einen Anteil im Bereich von rund drei Vierteln der Websites mit bekannter serverseitiger Sprache aus (W3Techs, “Usage statistics of server-side programming languages for websites”). Der praktische Grund dahinter ist meist WordPress: WordPress ist in PHP geschrieben und benötigt neben PHP eine MySQL- oder MariaDB-Datenbank (wordpress.org, “Requirements”). Wenn Ihre Anforderung “Redaktionssystem” heißt, wählen Sie in aller Regel kein Sprache aus, sondern ein System, und die Sprache folgt daraus.

Onlineshop. Ein Shop ist eine CMS-Website plus Zahlungsabwicklung, Bestandsführung, Steuerlogik und rechtlich verbindlichen Prozessen. Auch hier ist die Sprache nachrangig gegenüber der Frage, welche Shop-Software Sie einsetzen und welche Anbindungen Sie brauchen. Die Sprache wird erst dann wieder zum Thema, wenn Sie eigene Erweiterungen bauen lassen: Dann bestimmt sie, wer diese Erweiterungen später warten kann.

Webanwendung. Ein Kundenportal, ein Buchungssystem, ein internes Werkzeug. Hier treffen Sie zum ersten Mal eine echte, freie Sprachentscheidung, und hier lohnt sich das Nachdenken. Üblich sind Frameworks, die Ihnen die immer gleichen Grundfunktionen abnehmen: Django ist ein in Python geschriebenes Web-Framework, Laravel ein in PHP geschriebenes, Ruby on Rails ein in Ruby geschriebenes (jeweils Projektdokumentation). Serverseitiges JavaScript ist ebenfalls verbreitet: Node.js ist eine Laufzeitumgebung auf Basis der V8-Engine, mit der JavaScript serverseitig ausgeführt wird (nodejs.org, “About Node.js”). Der Vorteil, den letztere Variante ausspielt, ist organisatorisch: ein Team, eine Sprache auf beiden Seiten.

Entscheidungsmatrix

Die letzte Spalte ist die einzige, die nach der Inbetriebnahme noch eine Rolle spielt. Angebote werden über die dritte Spalte verglichen, Ärger entsteht in der fünften.

Folgekosten: die vier Posten, die den Unterschied machen

Hosting-Anforderungen. Eine statische Seite braucht einen Server, der Dateien ausliefert. Eine PHP-Anwendung braucht eine PHP-Laufzeit in einer passenden Version, meist eine Datenbank und einen Anbieter, der beides aktuell hält. Eine Anwendung auf Basis von Python, Ruby oder Node.js braucht in der Regel mehr als einfaches Webhosting, nämlich eine Umgebung, in der ein Prozess dauerhaft läuft. Das ist selten das teuerste Element, aber es entscheidet darüber, wie viele Anbieter überhaupt für Sie in Frage kommen.

Versionssupport. Das ist der Posten, der am häufigsten unterschätzt wird, und für PHP lässt er sich präzise beziffern. Eine PHP-Hauptversion erhält zwei Jahre aktiven Support und danach ein weiteres Jahr ausschließlich Sicherheitsfixes; danach endet der offizielle Support (php.net, “Supported Versions”). Daraus folgt eine harte Planungsgröße: Spätestens alle drei Jahre steht ein Wechsel der PHP-Version an, und dieser Wechsel bricht erfahrungsgemäß Erweiterungen, die niemand mehr pflegt. Wer heute ein Projekt beauftragt, sollte im Vertrag stehen haben, wer diesen Wechsel durchführt und was er kostet. Vergleichbare Zyklen existieren für andere Laufzeiten ebenfalls; entscheidend ist, dass Sie den Ihres Stacks kennen, bevor Sie unterschreiben.

Wartung. Wartungsaufwand skaliert nicht mit der Sprache, sondern mit der Anzahl beweglicher Teile. Eine statische Seite hat keine, eine WordPress-Installation mit zwanzig Erweiterungen hat einundzwanzig, jede mit eigenem Update-Rhythmus und eigenem Risiko. Die Sprachwahl beeinflusst diesen Posten nur indirekt, über die Frage, wie viel fertige Bausteine Sie einsetzen und wie viel eigener Code entsteht.

Entwicklerverfügbarkeit. Der Posten, der am spätesten sichtbar wird und am teuersten ist, wenn er zuschlägt. Hier hilft ein Blick auf die Verbreitung: In der Stack Overflow Developer Survey ist JavaScript seit mehreren aufeinanderfolgenden Jahren die von Entwicklern am häufigsten genutzte Programmiersprache (Stack Overflow Developer Survey, “Most popular technologies: Programming languages”), und die oben genannte Verbreitung von PHP im Web bedeutet praktisch, dass es für PHP-Projekte einen breiten Markt an Dienstleistern gibt. Eine seltenere Sprache ist deshalb nicht schlechter, aber sie verengt Ihre Auswahl bei einem Anbieterwechsel, und genau in diesem Moment brauchen Sie die Auswahl.

Eine Bestandsseite einordnen

Wenn Sie eine bestehende Seite übernehmen und wissen wollen, worauf sie läuft, gilt eine Einschränkung, die Ihnen Zeit spart: Der eingesetzte Technologie-Stack einer Website lässt sich nicht zuverlässig aus dem HTML ablesen. Hinweise liefern HTTP-Header, Dateiendungen und Framework-typische Artefakte, aber alle davon sind unterdrückbar (MDN Web Docs, HTTP-Header “Server” und “X-Powered-By”). Erkennungsdienste im Netz liefern deshalb Vermutungen, keine Befunde.

Verlässlich ist nur der Zugriff auf den Server oder auf das Repository mit dem Quellcode. Wer eine Seite übernimmt, sollte deshalb nicht nach der Sprache fragen, sondern nach dem Zugang: Server, Datenbank, Quellcode, Domain-Verwaltung. Aus diesen vier Dingen ergibt sich die Sprache von selbst, und ohne sie hilft Ihnen die Antwort auf die Sprachfrage ohnehin nicht weiter.

Drei Fehlentscheidungen, die sich vermeiden lassen

Eine Sprache wählen, bevor der Projekttyp feststeht. Die Reihenfolge ist umgekehrt: Erst steht fest, ob Redakteure Inhalte pflegen, ob es Nutzerkonten gibt und ob Daten verarbeitet werden. Danach ist die Auswahl meist auf ein oder zwei sinnvolle Varianten geschrumpft.

Eine dynamische Lösung für statische Inhalte kaufen. Ein Redaktionssystem für zwölf Seiten, die einmal im Jahr geändert werden, bedeutet, dass Sie dauerhaft Updates, eine Datenbank und eine Angriffsfläche pflegen, um jährlich einen Absatz zu tauschen. Das ist der häufigste vermeidbare Fixkosten-Posten kleiner Webprojekte.

Die Sprache nach ihrer Modernität wählen. Für die Frage, was eine Webseite in fünf Jahren kostet, ist der Support-Zyklus der eingesetzten Version wichtiger als das Erscheinungsjahr der Sprache, und die Zahl erreichbarer Dienstleister wichtiger als beides zusammen.

Die Entscheidung in vier Fragen

1. Ändern sich Inhalte häufig, und soll das jemand ohne Dateizugriff tun? Wenn nein: statische Seite, keine serverseitige Sprache.
2. Muss der Server Daten entgegennehmen, speichern oder Nutzer unterscheiden? Wenn ja: serverseitige Sprache nötig, andernfalls nicht.
3. Gibt es ein etabliertes System für Ihren Fall, also CMS oder Shop? Wenn ja, wählen Sie das System, und die Sprache ergibt sich daraus.
4. Nur wenn Sie eine echte Anwendung bauen: Welche Sprache können die Menschen, die das Projekt in drei Jahren betreuen sollen, und wie lange erhält die gewählte Version noch Sicherheitsupdates?

Wer diese vier Fragen beantwortet, hat die Sprachwahl bereits getroffen, ohne je einen Sprachvergleich gelesen zu haben. Das ist kein Umweg, sondern die Reihenfolge, in der die Entscheidung tatsächlich fällt.