Wie geht man an die Herausforderung heran, eine vollständig neue Website zu entwickeln? Was sind die Hürden, die einem auf dem Weg zum fertigen Produkt begegnen? Darüber wird der erste „Tag“ meines Website-Tagebuchs handeln.

Im Website-Tagebuch werde ich die zahlreichen Schritte durchleuchten, die von der Idee bis zur fertigen Website geführt haben. Dabei geht es um die Seite, auf der du dich gerade befindest: KingOfDog.de.

Dabei unterteile ich die Reise in imaginäre Tage, welche nicht zwangsläufig der tatsächlichen chronologischen Reihenfolge von Ereignissen entsprechen mag und fasse dem Verständnis wegen auch längere Zeiträume zu einzelnen Tagen zusammen. Diese Tage sollen möglichst abgeschlossen einen bestimmten Teilaspekt der Website-Entwicklung durchleuchten und dabei auch Einblicke in die allgemeine Webentwicklung bieten.

Meine Intention mit dem Website-Tagebuch ist also weniger die Erzählung meines eigenen Entwickungsprojekts, sondern viel mehr eine Hilfestellung. Ich möchte angeeignetes Wissen an Andere weitergeben, die eines Tages vielleicht vor einem ziemlich ähnlichen Problem standen wie ich. Wer zum Teil springen möchte, der sich darauf bezieht, kann zu „Etwas Neues muss her“ vorscrollen.

Der Rückblick auf die alte Website

Wichtig für jegliches Software-Projekt ist die initiale Zielsetzung, bei der man möglichst genau abgrenzt, was man vorhat zu erreichen. Und in meinem Fall handelte es sich bei dem Projekt um eine Neuentwicklung einer bestehenden Website, sodass ich im nullten Schritt meine Intention darlegen will, warum ich es für nötig erachtete, alles Dagewesene zu verwerfen und etwas neues zu schaffen.

Diese Webseite entstand ursprünglich aus meinem Verlangen, das Erstellen einer komplexeren Webseite zu erlernen. Da ich dabei sehr unwissend anfing, nahm ich immer das auf den ersten Blick einfachste, was ich finden konnte.

Das führte dazu, dass ich das Backend in PHP entwickelt habe. Was eine Sünde. Mit der Zeit habe ich auch angefangen, Frameworks einzusetzen, wie beispielsweise CodeIgniter. Das hat auch sehr viele Entwicklungsprozesse deutlich vereinfacht.

Auf der Frontend-Seite kam jQuery zum Einsatz. Wie ich heute besser weiß, ist es keinesfalls mehr eine gute Idee, jQuery für solche Zwecke anzuwenden. Dafür gibt es einfach zu viele Alternativen, die bessere Performance sowie Komfort beim Programmieren bieten.

Insgesamt ist die Struktur der Webseite grauenhaft. Zum Glück bin ich alleine zuständig für den Code, denn niemand anders könnte einen solchen Haufen verantworten. Das kam unter anderem auch daher, dass ich mit zunehmender Komplexität der Software zu einer asynchronen Struktur tendiert bin.

Mehr und mehr Anfragen von Daten liefen nicht mehr mit dem initialen Laden der Webseite ab, sondern wurden per Ajax in jQuery nachträglich durchgeführt. Dabei entstand eine extreme Unordnung in CodeIgniter, da die meisten Seiten aus mehreren Bestandteilen aufgebaut waren: Es gab eineseits den Endpoint für die endgültige Seite. Weiterhin gab es verschiedene Ressourcen für die dynamischen Daten innerhalb dieser Seite. Dementsprechend wurde es ziemlich unübersichtlich und immer schwieriger nachzuvollziehen, wozu eine Anfrage, eine URL, eine Seite gehört.

Besonders unübersichtlich sind die unzähligen MySQL-Befehle die sich im Backend finden lassen. Meistens in eine Zeile gequetscht, mit zig Fragezeichen zum Einfügen von Daten und so weiter. Bei jedem Mal, wenn ein Datenbankfehler auftrat, hatte ich die wundervolle Ehre, diesen Dschungel zu durchqueren, um den einen Fehler wiederzufinden. Die Struktur des Backends lässt sehr zu wünschen übrig.

Datenstruktur

Überproportional viele Missgeschicke sind mir bei der Strukturierung der Daten und gleichzeitig bei der anschließenden Verarbeitung unterlaufen. Anfangs kam mir die Idee, einen Blog zu entwerfen, was ich dementsprechend auch getan habe.

Später wollte ich jedoch auch noch die als statisches HTML vorhandenen Projekte in eine ähnliche Speicherweise wie die Blog-Posts pressen, sodass ich im Grunde den gesamten Aufbau vom Blog dupliziert habe. Ein wundervolles Exemplar eines absoluten Verstoßes gegen das Prinzip von DRY („Don't Repeat Yourself“).

Praktischerweise habe ich natürlich nicht darauf geachtet, die Sachen, die ich kopiere, wenigstens auf die gleiche Weise zu erledigen.

Das führte dazu, dass ich später auf eine Reihe von Problemen gestoßen bin, als ich versuchte, die Website zu lokalisieren. Abgesehen von den Schwierigkeiten bei der Übersetzung der statischen Inhalte unterscheideten sich meine Lösungsansätze auch extrem beim Blog und beim Portfolio, welche in der Idee ja eigentlich ziemlich ähnlich wären.

Beim Blog griff ich darauf zurück, den Inhalt von den Metadaten zu trennen. Das heißt, es gab eine Tabelle mit Blog-Posts und jeder Blog-Post konnte mehrere Versionen haben, die den eigentlichen Inhalt verwalteten.

Hingegen bei den Projekten fügte ich einfach noch ein paar mehr Spalten zur Projekttabelle hinzu: neben den Feldern für Titel, Beschreibung und Inhalt gab es dann noch den englischen Titel, die englische Beschreibung sowie den englischen Inhalt und das Gleiche für Französisch. Für jede weitere Sprache, die ich potentiell hinzufügen wollte, hätte ich also wiederrum drei weitere Spalten hinzufügen müssen.

Und zog sich das ganze über die Zeit fort, sodass die Möglichkeit der Fusion von Projekten und Blog-Posts immer weiter schwindete.

Evaluation

Ich könnte bestimmt noch unendlich fortfahren mit diesem Rant über meine schlechten Code-Werke der Vergangenheit. Jedoch möchte ich das mir und euch nicht antun.

Und daher beende ich diese Übersicht über den aktuellen Stand der Webseite. Ich möchte hervorheben, dass ich mich nicht wirklich für diesen Code schäme. Ich habe das gesamte Projekt in erster Linie zum Lernen gestartet und aus diesem Blickwinkel sehe ich es immer noch.

Ich habe definitiv sehr viel über Datenbanken, Webentwicklung, Blogs, Nutzerverwaltung und mehr gelernt. Auch habe ich tiefe Einblicke in JavaScript und PHP erhalten, konnte meine HTML- und CSS-Kenntnisse enorm verbessern und hatte insgesamt einen schönen Zeitvertreib.

Auch habe ich Erfahrungen mit mehreren populären Frameworks gemacht. Dazu gehören CodeIgniter für PHP, Bootstrap für CSS und jQuey für JavaScript. Für meinen Gesamtüberblick über Web-Technologien hat das einen enormen Beitrag geleistet.

Allerdings zählt insbesondere jQuery nicht mehr zu den modernsten Möglichkeiten, eine performante Webanwendung zu entwickeln und ist an vielen Stellen umständlicher als notwendig.

Abgesehen von der technischen Betrachtung habe ich in puncto Projektplanung so ziemlich alles falsch gemacht, was überhaupt möglich ist. In erster Linie zu kritisieren ist die schlechte ursprüngliche Zielsetzung, welche sich mit der Zeit immer weiter ausgedehnt hat.

Insgesamt habe ich also gegen alle verbreiteten Standards der modernen Software-Entwickung verstoßen, sei es SOLID, DRY, Agile oder was es auch immer für Stichworte gibt.

Die Zeit geht weiter

Seit dem Projektstart hat sich Vieles verändert. Einerseits wandelte sich natürlich der Markt für Web-Entwicklung enorm und ist aus damaliger Sicht vermutlich nicht wiederzuerkennen. Andererseits haben sich meine Programmierskills seitdem vielseitig weiterentwickelt.

Vor allem auch, weil ich zahlreiche andere Projekte unternommen habe, wobei ich diverse Technologien ausprobiert und/oder intensiv kennengelernt habe. Als Beispiele ließen sich zum Beispiel die .10(Lern- und Nachhilfeplattform), basierend auf Node.js, LoopBack 4 und Angular; meine .11(Stundenplan-App) für Android; sowie zahlreiche kleinere Projekte nennen. Bei Interesse kann ich euch nur einen Blick in die Projekte-List auf dieser Website empfehlen.

Seit meinem holprigen Ansatz mit jQuery in 2015 hat sich, wie schon erwähnt, auch die Web-Branche unfassbar verändert. Mobile ist nochmals wichtiger geworden und macht mittlerweile den Großteil des Web-Traffics aus. Zwar hatte ich diesen Aspekt auch schon bei der ersten Version meiner Website im Hinterkopf, sonderlich viel Wert auf Mobiloptimierung habe ich jedoch nicht gelegt. Ohne große Probleme lassen sich Fehler bei der Darstellung auf Smartphones identifizieren, die ich nie richtig behoben habe.

Gleichzeitig gibt es unzählige mehr oder weniger neue Technologien, die in den letzten Jahren in den Web-Sektor Einzug gehalten haben. Es ist eine Diversifizierung der verwendeten Plattformen, Sprachen, Frameworks etc. festzustellen.

Dem hatte ich nichts mit meiner wackeligen PHP-jQuery-Konstruktion entgegenzustellen.

Mangel an Inhalten auf KingOfDog.de 1.0

Ein Kernproblem meiner alten Website war die Absenz von dynamischen Inhalten.

Am häufigsten hat sich die Anzeige meiner Social  Media-Posts aktualisiert, bis diese auch irgendwann ihren Geist aufgegeben hat. Dahingegen waren der Blog, das Portfolio und das eigens entwickelte soziale Netzwerk so still wie die Wüste von Nevada.

Hauptursache für diese Abstinenz von neuen Inhalten war nur indirekt mein Mangel an Motivation. Dieser war nämlich darin verwurzelt, dass es keinerlei Spaß machte, mit meinem Post-Editor zu arbeiten. Er war unübersichtlich, langsam, sperrig und funktionierte die meiste Zeit nicht einmal.

Das obenstehende Aussehen lädt nicht gerade zum kreativen und anhaltenden Schreiben ein, oder?

Etwas Neues muss her

Planung ist das A und O – so viel ist klar. Aber was muss man überhaupt beachten, wenn man eine Website plant?

Das hängt natürlich sehr stark von der angepeilten Website ab. Eine statische, einseitige Website hat vollkommen andere Anforderungen an die Planung als eine komplexe, interaktive Website mit Datenbank und API.

Daher ist der erste Schritt der Planung überhaupt festzulegen, was für eine Art von Website es werden soll.

Aber was? Eingrenzung der Anforderungen

Eine vollkommen statische Seite kam für mich nicht in Frage, da ich definitv weiterhin einen Blog haben wollte, der regelmäßig neue Einträge erhält. Für eine Website, die lediglich mich als Person vorstellen soll, würde es jedoch reichen, mit HTML und CSS zu arbeiten. In diesem Fall würden sich die Inhalte der Website nicht sonderlich häufig ändern und sie würde auch mit einer einzigen Seite auskommen.

Vorteile statischer Seiten

• Sehr gute Performance
• Einfach zu entwickeln, wenig Kenntnisse abseits von HTML- und CSS-Grundkenntnissen erforderlich
• Flexible Gestaltung
  

Static Side Generators

Ein Schritt darüber befände sich eine Konstruktion mithilfe eines Static Side Generators. Davon gibt es fast so viele wie Buchstaben im norwegischen Alphabet. Static Side Generators kombinieren die Vorteile einer statischen Seite mit einigermaßen dynamischen Inhalten.

Beispiele für solche Static Side Generators wären:

• Hugo
• Hexo
• Jekyll
• Gatsby
• Eleventy

Die allgemeine Funktionsweise basiert darauf, dynamische Inhalte in eine statische Layout-Vorlage einzubetten. Exemplarisch hätte man eine HTML-Artikelseite (inklusive Styling etc.) sowie einen Ordner mit Markdown-Dateien, die jeweils einen Artikel enthalten. Der Static Side Generator übernimmt die Aufgabe, für jede dieser Markdown-Artikel eine HTML-Version basierend auf dem angegebenen HTML-Template zu erstellen. Nach jedem Durchlauf des Static Side Generators (bzw. nach jeder Änderung der Artikel) erhält man also neue statische Seiten, die genauso wie normale statische Seiten gehostet werden können.

Vorteile von Static Side Generators

• Sehr gute Performance (da letztlich eigentlich statische Seiten bereitgestellt werden)
• Flexibler als statische Seiten, dynamische Inhalte, vor allem bei selten geänderten Inhalten
• Schnell ein fertiges Produkt
  

Out of the box CMS

Von Static Side Generators zu einem Content Management System (CMS) ist es ein ganz schöner Sprung. Content Management Systems ermöglichen – frei übersetzt – die Verwaltung von Inhalten. Dabei sind natürlich insbesondere dynamische Inhalte von Interesse; statische Inhalte wären genauso gut über einzelne Dateien zu verwalten.

Zu sehr auf die Funktionsweise von CMS im Allgemeinen sowie verschiedene Produkte aus diesem Bereich möchte ich an dieser Stelle nicht eingehen, da es ansonsten den Rahmen eines lesbaren Blog-Posts mehr als sprengen würde. Jedoch gibt es unzählige CMS, die sich an unterschiedliche Zielgruppen, Aufrufzahlen und Inhaltstypen richten.

Bekannte Exemplare von Content Management Systems sind:

• WordPress
• Joomla
• Drupal
• TYPO3
• Ghost

Diese unterscheiden sich auch erheblich in der Bedienbarkeit und nehmen verschieden viel Zeit in Anspruch, um sich mit ihren Besonderheiten vertraut zu machen. Dementsprechend treffen nicht alle der nachfolgenden Vorteile auf alle existierenden CMS gleich zu.

Vorteile von fertigen CMS

• Einfache Benutzung, keine HTML- oder Programmierkenntnisse erforderlich
• Simple Einrichtung, da die meisten CMS eine graphische Oberfläche bieten und im Hintergrund die schwierigsten Aufgaben übernehmen (noch einfacher durch Hosting-Anbieter, die solche CMS-Instanzen direkt vertreiben)
  
• Weit verbreitet und eine große Hilfecommunity vorhanden

Individuallösung

Zwar sind bestehende CMS-Lösungen ausgesprochen einfach zu nutzen. Allerdings können Fertiglösungen niemals den Grad der Anpassung erreichen, wie ihn Individuallösungen bieten.

Nachteilig von Individuallösungen ist offenkundig der hohe Entwicklungsaufwand, da man  alles nach eigenen Wünschen konfigurieren kann aber eben auch muss. Somit ist die Dauer von Projektbeginn bis Veröffentlichung deutlich größer als bei den vorangegangenen Lösungen.

Vorteile einer Individuallösung

• Optimale Abdeckung der eigenen Vorstellungen
• Beliebig erweiterbar
• Hohe Kontrolle über jeglichen Bestandteil der Software, kein Vertrauen in Drittanbieter nötig
  

Wie allerdings schon gesagt, gehen diese Vorteile zu Kosten der Entwicklungszeit und erfordern zudem sehr gute Kenntnisse (oder zumindest Lernbereitschaft) in unzähligen Bereichen der Web-Enticklung, je nachdem was die Anforderungen sind.

Und der Gewinner ist…

Für mich fiel die Entscheidung auf eine vollständige Individuallösung. Ob das empfehlenswert ist? Ich glaube eher kaum.

Einzelpersonen sind deutlich besser bedient mit einer der anderen, simpleren Möglichkeiten, zumindest solange das Hauptziel eine schnell funktionsfähige Website ist.

Bei mir kommt jedoch hinzu, dass die Neuentwicklung meiner Website auch als Lernerfahrung gedacht ist. Ich wollte einen tieferen Einblick in moderne Webentwicklung im Allgemeinen bekommen und spezifischer über Nutzersysteme, Sicherheit, APIs und Go.

Somit zählt also der Nachteil einer Individuallösung in meinem ungewöhnlichen Fall ebenfalls als weiterer Vorteil.

Wahl der Technologien

Bei einer individuellen Seite kommt erschwerend die Wahl der einzusetzenden Technologien hinzu. Dieser Schritt entfällt bei einem CMS wie WordPress oder einem Static Side Generator wie Hugo vollkommen, da die gewählte Plattform eine recht klare Struktur vorgibt.

Wenn man jedoch auf die Idee kommt, in 2020 eine Website von Grund auf neu zu entwickeln, hat man die Qual der Wahl. Es gibt unzählige mögliche Frameworks und Libraries allein auf Frontend-Seite, die um die Aufmerksamkeit der Entwickler buhlen.

Beispielsweise wären da die sehr weit verbreiteten Kandidaten Angular, React und Vue.js. Alles drei sind im Grunde JavaScript-Frameworks, die die Entwicklung von interaktiven Webapps ermöglichen bzw. vereinfachen. Bei genauerer Betrachtung fallen allerdings sehr starke Unterschiede in der Herangehensweise der drei Frameworks auf.

Und das möchte ich als Anlass nehmen, den ersten (oder nullten) Eintrag im Website-Tagebuch an dieser Stelle zu beenden. Die differenzierte Betrachtung der drei Web-Technologien Angular, React und Vue.js würde definitiv den Artikel zu sehr strecken, sodass ich sie in einen zukünftigen Blog-Post verlagere.

Fazit

Beim Entwickeln einer neuen Website gibt es unfassbar viel zu beachten – in 2020 mehr denn je. Daher bedarf es einer eingehenden Analyse des erwünschten Ziels, was ich in diesem Artikel anhand der vorhergehenden Website getan habe.

Meine neue Website KingOfDog.de soll performant, mobilfreundlich und modern sein. Weiterhin soll es einen Blog und ein Portfolio geben, deren Einträge sich über ein Admin-Panel hinzufügen und bearbeiten lassen. Bei der Entwicklung setze ich auf eine Individuallösung, mit dem Nebenziel, neue Programmiersprachen und Technologien kennenzulernen.

Und damit steht eine recht allgemeine Definition meines Ziels fest. Im nächsten Schritt bedarf es einer Strukturierung der Daten im Backend und die Wahl der passenden Technologien steht auf dem Tagesplan. Danach werden wir einzelne Implementierungsschritte unter die Lupe nehmen und bestimmte Probleme sowie deren Lösungen analysieren. So näheren wir uns immer weiter der veröffentlichten „Version 2020“ von KingOfDog.de.