Das Erstellen einer webbasierten Applikation erfordert immer mehr Wissen. Als die Internet-Ära gerade begann, hat man sich erst einmal mit HTML beschäftigt. Wie der Name „Hypertext Markup Language“ schon besagt, ging es nur um die „Markierung“ von Text. Man war schon sehr froh, dass man weltweit zwischen verschiedenen Seiten verlinken konnte. Mit zunehmender Verbreitung stiegen aber auch die Ansprüche an das Aussehen der Webseiten. Zunächst wurde dann, besonders durch Microsoft, HTML um ein paar „gimmicks“ erweitert. Die Folge waren auf den ersten Blick interessante, aber dann doch eher nervige Webseiten, die blinkende und scrollende Schriften als neueste Innovation anpriesen.
Dann kam aber, zum Glück, sehr schnell CSS („Cascading Style Sheets“) hinzu, das sich nun tatsächlich um die grafische Gestaltung von Websites kümmerte. Endlich wurde klar, dass Auszeichnung, also z.B. die Deklaration eines Textes als „Header, Wichtigkeit 1“ etwas ganz Anderes ist als die Beschreibung des tatsächlichen Aussehens, wie es CSS mit z.B. „h1 { font-size:24px;color:green }“ erlaubt und für den Header mit der Wichtigkeit eins eine Fontgröße von 24 Pixeln und eine Schriftfarbe „grün“ definiert.
Anfangs glich eine webbasierte Applikation eher einer solchen, die einem Mainframe entsprungen ist. Eingaben wurden auf einer Seite getätigt und abgeschickt. Dann wurde eine neue Webseite angezeigt.
Javascript, als Programmiersprache, die innerhalb einer Webseite ausgeführt wird, hat das grundsätzlich geändert. AJAX erlaubt die Kommunikation zwischen Browser und Webserver ohne den Aufbau einer neuen Webseite. Damit war der Entwicklung wirklich interaktiver Webapplikationen Tür und Tor geöffnet. Google Mail hat als eine der ersten Applikationen gezeigt, was mit diesen Technologien möglich war. Viele Andere sind seitdem gefolgt.
Es entstanden anfangs noch wenige Frameworks, die einerseits die vielfältigen Möglichkeiten von CSS und andererseits die enorme Bandbreite von Javascript in, möglichst browserunabhängige, leicht handhabbare Pakete packten. So langsam setzte sich die Erkenntnis durch, dass es kein verlässliches. allgemeingültiges Bildschirmformat für die Entwicklung von Webseiten geben würde. Smartphones kamen auf und überboten sich immer wieder selbst in Bildschirmgröße und -auflösung. „responsive“ mussten seitdem alle Webseiten sein. Hier boten sich bei den Frameworks zuerst JQuery und Bootstrap als erste Lösungen an. Beide haben bis heute Bestand.
Spätestens als Google „Geschwindigkeit“ als Bewertungskriterium für die Einstufung von Webseiten bekannt gab, kamen Frameworks auf, die mittels „shadow DOM“ einen großen Geschwindigkeitsnachteil der althergebrachten Frameworks beseitigten. Man konnte z.B. in JQuery Tausende von Änderungen programmatisch durchführen. Tat man das auf ungeschickte Weise, hatte das aber enorme Performanznachteile weil der Broser dann bei jeder Änderung im ungünstigsten Fall die komplette Webseite neu berechnet hat. Frameworks wie React, Angular oder Vue bauen, um diese Nachteile zu umgehen, eine eigene, interne Darstellung der Objekte einer Webseite auf und führen dann die an dieser internen Darstellung durchgeführten Änderungen auf einen Schlag im Browser durch. Der dadurch erzielte Performanzgewinn hat zur sehr schnellen Verbreitung dieser Frameworks geführt.
Für jede Technologie werden weitere Technologien entwickelt, die entweder der einfacheren Programmierung oder der Geschwindigkeitserhöhung dienen. SASS erlaubt z.B. eine einfachere Entwicklung von CSS. CSS tendiert sehr schnell dazu, unübersichtlich und nur schwer wartbar zu werden. Hat man sich z.B. für ein Farbschema seiner Webseite entschieden, tauchen die einzelnen Farben bei ganz vielen, einzelnen Elementen in der CSS-Beschreibung auf. Möchte man dann die Farben ändern, wird das schnell sehr aufwendig. Tools wie SASS erlauben, die Farben als Variablen zu definieren und nur an einer Stelle zu ändern um die gewünschten Anpassungen zu erreichen.
Komprimierung von HTML, Javascript und CSS dienen der Geschwindigkeitserhöhung. Auch dafür gibt es mehrere Tools, die dies, eingebettet in einen durchgängig automatisierten Prozess, erledigen.
Auf dem Webserver hat die Entwicklung ähnlich viele Fortschritte gemacht. Anfangs hat man perl bemüht um Anfragen des Webbrowsers zu beantworten und Seiten dynamisch zu gestalten. PHP wurde als speziell für Webserver definierte Programmiersprache entwickelt. Irgendwann kam jemand darauf, dass es doch sinnvoll wäre, die im Webbrowser verwendete Sprache Javascript auch auf der Serverseite zu verwenden. So wurde Node oder Node.js geboren.
Zu einer Programmiersprache gehören immer auch Tools, die Erweiterungen, Paketierung, Dokumentation und Versionsverwaltung umfassen.
Erweiterungen werden in Perl aus CPAN installiert, PHP kennt PEAR, Node nutzt npm um aus nahezu beliebigen Quellen Erweiterungen zu installieren.
Die Paketierung bzw. Verwaltung der genutzten Bibliotheken ersieht man bei Perl aus dem Quellcode, hat man bei PHP in einer composer.json Datei hinterlegt, die vom Tool „Composer“ genutzt wird oder wird bei Node eben mittels npm verwaltet.
Versionsverwaltung ging von VCS über PVCS über zu SVM und steht aktuell bei git. Will man seinen Code nicht öffentlich bzw. kostenpflichtig uneinsehbar bei einem amerikanischen Konzern speichern, muss man sich z.B. mit gitbucket anfreunden und es auf einem eigenen Server installieren.
Apropos Server. Apache ist Stand der Technik. Caddy ist „lightweight“ und war mal eine gute Alternative, wenn man „Let’s encrypt“ für Zertifikate, die ein „https“ statt eines „http“ vor der eigenen Webadresse erlauben, nutzen wollte. Aktuell hat da Apache wieder die Nase vorne und Caddy erhebt relativ unverschämte Gebühren für seine Nutzung.
Jede Webapplikation basiert auf Daten. Diese liegen am Besten gut sortiert in einer Datenbank vor. Hier bieten sich SQLite, MySQL oder dessen Pendant MariaDB an. Diese Datenbanken sind erstaunlich leistungsfähig und bieten auch Replizierung und damit Hochverfügbarkeit für wirklich unternehmenskritische Applikationen an.
Die grafische Gestaltung einer Webseite ist hierbei nur „angekratzt“. Meine Herangehensweise besteht darin, eine der reichlich vorhandenen Vorlagen zu nutzen, mit eigenen Bildern auszustatten und knackige Texte einzufügen. Damit sollte man eine Webseite haben, die mindestens 80% aller anderen Webseiten übertrifft. Will man die letzten 20% übertreffen, muss ein sehr guter Designer Hand anlegen.
Aber auch ohne einen solchen bleiben noch genügend Tätigkeiten im grafischen Bereich übrig. Die Optimierung der Größe von Bilddateien ist z.B. ein solcher Punkt. Ein Designer achtet auf den hervorragenden optischen Eindruck. Der Fullstack Developer muss auch die Dateigröße der verwendeten Bilder im Blick behalten da übergroße Bilder seine gesamten Optimierungsarbeiten obsolet machen können. ImageMagick ist z.B. eine umfangreiche Programmsammlung, die die Bildverarbeitung auf Kommandozeilenebene erlaubt. Damit kann es in Skripte eingebaut werden, die die immer gleiche Anwendung automatisieren können.
Das sind, ohne Anspruch auf Vollständigkeit, ein paar grundlegende Technologien, die ein Fullstack Developer beherrschen muss, um eine Webapplikation zu erstellen, wenn er nicht auf jede Menge Zuarbeiter zurückgreifen kann. Es muss nicht immer die neuste Technologie sein. Neue Frameworks erscheinen fast im Wochenrhythmus. Es kommt auf die Auswahl der richtigen Komponenten an.
So werden Ihrem Kunden Downloads zur Verfügung gestellt. Das Dokument kann angezeigt und heruntergeladen werden. Falls eine Verwendungsbeschreibung konfiguriert ist, wird die Möglichkeit zum Upload angeboten.