Eine kurze Einführung in minimale Web­entwicklung

Artikel vom 28. November 2019. ISSN 1614-3124, #63. Schwerpunkt: (RSS-Feed für alle Themen).

Einfacher Frontend-Code hat was von Kunst und Zauberei. Mir persönlich gefällt es, einfachen Code zu erforschen, und einfachen Code zu schreiben und einfach zu halten – über verständlich-einfach hinaus, vielleicht nicht-so-verständlich-einfach und vielmehr minimal-einfach. Aus diesem Grund schreibe ich auch mal über »beste Templates« und rege an, optionale Tags und andere technisch nicht erforderliche Dinge wie unbenötigte Anführungszeichen auszulassen. Und ich habe irgendwie in Erwägung gezogen, darüber ein Büchlein zu schreiben.

Das Büchlein begann ich, 2017 zusammenzutragen, aber es nahm nicht die Struktur und Größe an, die ich mir dafür vorstellte. Ich war auch über das Material unsicher, dass ich so sammelte. Vielleicht wurde ich etwas faul. Und aus diesem Grund (und nicht zum ersten Mal) entschied ich mich, kein weiteres »kleines Buch« zu schreiben, sondern einfach das zu veröffentlichen, was ich so weit vorliegen hatte. All das, um laut nachzudenken, wie wir Webentwicklung lernen und lehren könnten, unabhängig vom gegenwärtigen Ansatz, alles immerfort als Angelegenheit für Apps und Tools zu verschreien.

Val und Aleta hatten zugesehen.

Abbildung: Darüber weiß ich leider nichts. (Copyright King Features Syndicate, Inc., vertrieben durch Bulls.)

Inhalt

  1. Beherrschen Sie die Kerntechnologien
    1. Lesen Sie die Spezifikationen
    2. Üben Sie
    3. Veröffentlichen Sie
  2. Machen Sie sich mit verwandten Feldern vertraut
    1. Primärthemen
    2. Sekundärthemen
  3. »Do It Yourself«
    1. Zu empfehlen
    2. Zu vermeiden
  4. Finden Sie den kürzesten Weg
    1. »Keep It Simple«
    2. Schneidern Sie zu
    3. Unterscheiden Sie zwischen »einfach« und »einfach«
  5. Automatisieren Sie
  6. Überprüfen Sie

Beherrschen Sie die Kerntechnologien

Anfänger erreichen Einfachheit, weil sie nicht alle Optionen und Möglichkeiten kennen. (Man kann das mit einer umgekehrten Normalparabel vergleichen.) Als Experten und Profis, wie es dieser Artikel will, können wir uns Minimalismus aber nicht über Unwissenheit annähern und uns auf die Schultern klopfen, wenn wir etwas einfaches entwickelt haben, allein deshalb, weil wir gar nichts anderes erarbeiten konnten.

Lesen Sie die Spezifikationen

Der erste Schritt zum Meistern der Webentwicklung scheint in einem genauen Blick auf die technischen Spezifikationen zu bestehen. Obwohl die Spezifikationen nicht immer nett und nicht unbedingt leicht zu verstehen sind, und dazu auch nicht gerade klein, bieten sie doch das größte Maß an Präzision und Detail. Da das Ziel ist, die Technologien zu beherrschen, sind Präzision und Detail wichtiger als der eigene Komfort.

Einige der durchzuarbeitenden Spezifikationen sind:

Persönlich habe ich mich nie durch die ECMAScript-Spezifikation gearbeitet – meine Skripte werden das bezeugen –, aber ich wollte sie auch zur eigenen Ermunterung unbedingt aufzählen. ES und WCAG verfügen über Versionsnummern, weil sie aktuell noch keine »lebenden« Spezifikationen wie HTML und CSS sind. Orientieren Sie sich an den jüngsten relevanten Fassungen dieser Standards.

Manche wichtige Themen wie Performance oder Wartbarkeit werden nicht von Standards und Spezifikationen abgedeckt, sondern sind nur durch gesonderte Literatur zugänglich. (Eine zukünftige Bearbeitung dieses Artikels mag Empfehlungen geben.)

Üben Sie

Nicht notwendigerweise nach sondern während dem Vertrautmachen mit den Spezifikationen ist es nützlich, das peu à peu erworbene Wissen in die Praxis umzusetzen. Das bedeutet: Entwickeln. Entwickeln so viel es geht.

Einer der bedeutendsten Aspekte der Webentwicklung ist wahrscheinlich, dass Ergebnisse sofort sichtbar sichtbar sind – eine .html-Datei speichern, sie im Browser öffnen, Inhalts-, Struktur-, Styling-, Scripting-Änderungen sofort prüfen.

Diese Leichtigkeit, Dinge auszuprobieren, ist ein Vorteil. Er ermöglicht uns, schnell Tests wie auch ganze Websites und -apps aufzusetzen, und damit Erfahrung zu sammeln.

Dieses Üben ist von großer Wichtigkeit für jeden Webentwickler. Die folgenden Angewohnheiten helfen dabei:

Veröffentlichen Sie

Übung führt so zum letzten Punkt der Technologiebeherrschung: das Veröffentlichen der eigenen Arbeit.

Dieses Aussetzen der Kritik (im ursprünglichen Sinne des Wortes), hat verschiedene nützliche Nebeneffekte. Untersuchung durch die Öffentlichkeit mag erst einschüchternd anmuten, aber ein Neuling sollte diese nicht fürchten, sondern willkommen heißen – sie bedeutet mit die beste und schnellste Möglichkeit, sich zu verbessern.

Der Vorteil besteht damit in großer zusätzlicher Motivation: Man wünscht sich, die eigene Arbeit gut darzustellen, und konzentriert sich mehr auf die Qualität der Ergebnisse; und diese Konzentration bildet dann einen Grundstock für die sämtliche eigene professionelle Arbeit. Man nimmt die Arbeit ernster und wendet größere Sorgfalt an. Oftmals hat man auch mehr Spaß an der Arbeit, weil Veröffentlichen Teilen heißt, und das, was man macht, so mehr als nur einem selbst nutzen kann.

Veröffentlichen als wichtiger Schritt zu Sichtbarkeit, für Feedback, zu Professionalität, hilft auch dabei, ein Portfolio aufzubauen: Jede veröffentlichte Arbeit kann die Glaubwürdigkeit der eigenen Arbeit stützen. Es ist wesentlich leichter, zu demonstrieren, was man tut und was man beherrscht. Es gibt einen deutlichen Unterschied in der Wahrnehmung zwischen Webentwicklern, die über eine Website (vor allem eine hochwertige) verfügen, und solchen, die keine haben (oder eine schlechte).

❧ Die Spezifikationen lesen, üben und veröffentlichen: Wenn dies beflissentlich ausgeübt wird – veranschlagt werden könnten 6–12 Monate –, kann man eine solide Basis aufbauen, der dann spezifische Themen folgen.

Webentwicklung ist kein kleines, isoliertes Thema. Damit Webentwickler gut in ihrer Arbeit werden können, um vor allem exzellent darin zu sein, müssen sie ein gutes Verständnis davon entwickeln, was um sie herum passiert.

Um einen Eindruck davon zu geben, welche Themen und Gebiete ebenfalls von Interesse sein sollten, aber auch um wiederzuspiegeln, dass nicht alles von gleicher Wichtigkeit ist, wollen wir diese Gebiete, mit denen wir uns ebenfalls auseinandersetzen sollten, in »primär« und »sekundär« unterteilen.

Die folgenden Themen dienen alle »dem großen Ganzen«, und dennoch sind sie nicht allumfassend.

Für kaum eins dieser Themen gibt es eine einzige Hauptquelle; die Liste mag jedoch ergänzt werden, um auf herausragende Literatur zu verweisen. Andere Themen wie Zeichensätze und -Encodings wurden ausgelassen, weil sich die Situation dort so weit entspannt hat, dass Webentwickler hier nicht mehr auf große Schwierigkeiten und Herausforderungen stoßen.

❧ An dieser Stelle muss das, was wir angeschnitten haben, eher wie maximale denn wie minimale Webentwicklung anmuten. Die Idee ist jedoch, dass wir nur dann sagen können, was für unsere Arbeit benötigt wird, wenn wir sagen können, was wichtig ist, und warum es wichtig ist. Und dafür müssen wir unser Feld und seine Umgebung verstehen.

»Do It Yourself«

Der Aufruf zu üben gab bereits das »Go«, zu arbeiten und zu – üben, aber dieses Üben bedarf der Erklärung. Das ist vor allem deshalb so, weil Üben bedeutet, dies selbst zu machen, ohne fremde Hilfe, ohne Werkzeuge, die uns die Arbeit erleichtern oder abnehmen.

Es gibt immer die Möglichkeit, Werkzeuge für die Entwicklung zu verwenden, und solche Tools werden immer wichtiger – kritisch sogar in komplexen Projekten –, aber sie sind genauso nützlich, entwickeln zu lernen, wie es Fertigteig dafür ist, backen zu lernen. Dies bezieht sich dabei auf Werkzeuge, die Aufgaben für uns machen, da uns Editoren und ähnliches genauso erlaubt sind wie Öfen: Wir wollen nur nicht, dass Editoren auto-berichtigen, auto-entfernen oder auto-komprimieren, genauso wenig wie wir wollen würden, dass Öfen auto-kneten und auto-formen und auto-prüfen, um den Bäckergehilfen zur Hand zu gehen.

Um selbst zu üben und entwickeln, was ist erlaubt, und was nicht?

Diese Aufzählungen sind weder sortiert noch vollständig.

❧ Die Vorteile sind vielfältig, da der Ansatz darauf abzielt

Das Ziel ist letztendlich, das Handwerk der Webentwicklung zu erlernen. Im Laufe der Zeit, und weiter sollten mindestens 6–12 Monate veranschlagt werden, können wir Werkzeuge hinzufügen; aber genauso wie Werkzeuge und Tools wichtig, in großen Projekten sogar kritisch sind (in kleineren eben nicht so sehr), verlassen sie hier unsere Geschichte.

Finden Sie den kürzesten Weg

Nachdem wir einige Zeit gelernt und geübt und veröffentlicht haben, wird es Zeit, sich auf das eigentliche Ziel minimaler Webentwicklung zu konzentrieren: den kürzesten Weg zu finden, die geringste Menge an Code zu bestimmen, um das zu bauen, was wir uns vorgenommen haben zu bauen.

Dies an sich ist nicht einfach und, wie ich in CSS Optimization Basics ausführe, das Mindset, unsere Denkweise das eigentlich Interessante hier. Um zu zitieren:

Die Idee, es einfach zu halten (»keep it simple«) hat einen faulen Anstrich, und erfordert doch gute Fähigkeiten. Es einfach zu halten heißt eigentlich, sich zu konzentrieren, zu wissen, was wichtig ist, und dadurch effizient zu sein. Es einfach halten heißt nicht, lediglich weniger zu machen; es heißt, nur das zu tun, was zählt.

»Keep It Simple«

Fokus ist entsprechend am Herzen davon, es einfach zu halten.

Entgegensetzt der Idee von Einfachheit, die verständlich ist, dreht es sich hier jedoch um Einfachheit, die minimal ist. Einfachheit ist nämlich nicht gleich Einfachheit: Wenn wir es drauf anlegen, den wenigsten Code einzusetzen, der grundsätzlich möglich ist, werden die Ergebnisse sicher minimal sein, aber seitens der Verständlichkeit leiden. Deshalb die Unterscheidung zwischen minimal-einfach und verständlich-einfach.

Normalerweise wollen wir ein Gleichgewicht erzielen (und Gleichgewicht ist in vielen Angelegenheiten der Webentwicklung wichtig) – aber hier ist das Ziel erstmal, das anzustreben, was am »minimalsten« ist, was das Minimum ist, was zum Ergebnis führt und den Job erledigt: der kürzeste Weg.

Diese Aufgabe erfordert immer noch Verständlichkeit, aber nachdem man die Problemstellung durchdrungen hat. Um nochmal das Ziel dieses Aufsatzes zu wiederholen: Betonung liegt auf dem Erlernen minimaler Webentwicklung, um alles weitere darauf aufzubauen.

Es einfach zu halten heißt dementsprechend, erstmal auszulassen, was ausgelassen werden kann.

Schneidern Sie zu

Es einfach zu halten verlangt auch nach der Idee des Zu- und Maßschneiderns. Zuschneidern heißt, alles exakt auf die eigenen Bedürfnisse zu entwickeln und anzupassen. Dies lässt sich dabei gut in die reale Welt übersetzen: ein Anzug von der Stange mag uns zufällig passen, aber qualitätsseitig kommt er nie an den maßgeschneiderten heran; und selbst wenn wir uns für ein Kleidungsstück von der Stange entscheiden, passt es uns doch immer noch besser, wenn wir es nochmal anpassen lassen.

Das Ziel ist Qualität, nein: Exzellenz; und dieses Ziel ist wichtig, im Auge zu behalten. Wenn Qualität und Exzellenz nicht das Ziel sind, dann wird als Kleidungsstück ein Kartoffelsack genauso gut herhalten wie Bootstrap ideal für die lokale Kirchen-Website ist. (In der Tat.)

Wenn das Ziel jedoch Qualität ist, und ebenso Exzellenz, dann ist Maßschneidern Pflicht, und bedeutet eine wichtige Bedingung, einen wichtigen praktischen Aspekt:

Die Bedingung ist, unsere Bedürfnisse zu kennen, weil wir ohne diese nichts entwickeln können, was genau auf uns zugeschnitten ist.

Der praktische Aspekt ist, bei Customization aufzupassen, weil ja, wir profitieren davon fürs Zuschneiden, und nein, sie ist auch eine Last für unsere Ressourcen, Last, die in Entwicklungszeit besteht. Die meisten Menschen reagieren, indem sie nichts anpassen – ein gutes Beispiel sind generell fragwürdige Reset-Stylesheets, die in 99,9% aller Fälle unmodifiziert eingesetzt werden, genau weil dies Arbeit macht –, aber: dies hat dann den Preis schlechterer Gesamtqualität.

Unterscheiden Sie zwischen »einfach« und »einfach«

Der Anfang dieses Beitrags hat es bereits verraten: minimal-einfach ist das Hauptziel, nicht sofort verständlich-einfach. Da die Hauptgedanken hierfür auch in Understandable-Simple vs. Minimal-Simple Code erklärt werden, springen wir zur Konklusion: 

<!DOCTYPE html>
<title>Foo</title>

Dies ist zum Beispiel das absolute Minimum für ein (valides) HTML-Dokument. Das ist wahrer Minimalismus. Das ist auch wahres minimal-einfach: verständlich-einfach ist es nämlich nicht, nicht für jeden und wirklich jeden Entwickler.

Das Beispiel soll daran erinnern, wohin wir Minimalismus führen wollen, und auch eine mögliche Problemstelle im Hinblick auf besagtes Gleichgewicht aufzeigen: Es ist äußerst lehrreich und eindrucksvoll, wenn wir absolute Minima erkunden – und genau das, wozu hier ermutigt wird –, aber es gibt auch noch eine andere Dimension in dem Sinne, dass wir später, sobald wir den ganzen Weg hin zum Minimalismus beschritten haben, unsere gewonnene Erfahrung benutzen, um die Stellen zu identifizieren, die in unseren Teams ein angemessenes Maß an Verständlichkeit und damit Zusammenarbeit erlauben.

Minimal, ja, aber nicht um jeden Preis. Einfach und einfach.

Automatisieren Sie

Die Ambition ein professioneller Webentwickler zu werden, ein Experte der Webentwicklung, der sein Handwerk versteht, um effektive aber einfache Lösungen zu finden, hat noch ein anderes erstrebenswertes Gleichgewicht im Schlepptau. Dises Gleichgewicht besteht darin, so viel zu automatisieren wie möglich ohne dabei, zumindest in der aktuellen Phase unseres Feldes, bequem zu werden und das Handwerk an sich zu vernachlässigen.

Das klingt schwammiger und schwieriger, als es ist.

Erstens, die Empfehlung für jeden bereits kenntnisreichen Entwickler ist, zu automatisieren: Jede Tätigkeit, die wiederholt wird, sollte auf Automatisierbarkeit durch Skripte und Tools geprüft werden. Dieses Gespür, diese Fähigkeit ist wert, entwickelt und geschärft zu werden, und ist eine unschätzbare Eigenschaft vor allem in Unternehmen mit mehr als einer Person (dem Entwickler selbst).

Zweitens, das Erstreben des Gleichgewichts muss dann geschehen, wenn einer der folgenden Faktoren vorliegt:

  1. Automatisierung kostet mehr als die manuelle Erledigung der Aufgabe (der genaue Faktor ist jedem selbst überlassen);
  2. Die Aufgabe kann nur zulasten der Gesamtqualität automatisiert werden;
  3. Die ursprüngliche Aufgabe hat (selbst temporären) unterrichtenden Wert.

Der erste Faktor bedeutet, dass es wirtschaftlich unklug ist, zu automatisieren; der zweite erachtet Qualität für wichtiger als Effizienz; der dritte sieht einen größeren Wert im Handwerk und seiner Lehre als in Effizienzsteigerung durch Automatisierung. Diese Faktoren wollen alle berücksichtigt werden, wenn es um Automatisierung geht.

Was gibt es zu automatisieren? Ich bin mir selbst vorweg gelaufen, als ich sagte, dass »jede Aufgabe« automatisiert werden solle, und man kann die Angelegenheit vermutlich wirklich verallgemeinern und sagen, dass so viel wie möglich automatisiert werden sollte (sofern kein anderes Gleichgewicht wichtig ist). In der ursprünglichen Struktur von Buch und Beitrag habe ich das Thema in Entwicklung, Testen und Kontrolle unterteilt – jeder Punkt mit seinen eigenen Überlegungen und Werkzeugen. Eine Anmerkung für später.

Überprüfen Sie

Es gibt noch einen anderen, wobei vermutlich nicht endgültigen Aspekt der Webentwicklung, und dieser besteht in Überprüfung und Reviews. Unsere Arbeit zu prüfen – was nicht ausschließt, anderer Leute Arbeit zu verstehen und unterstützen – ist das Gegenstück zu den eher zufälligen Gelegenheiten zur Verbesserung, die wir erhalten, wenn unsere Kollegen unsere Arbeit kommentieren oder sichten oder Tickets für schreiben.

Die eigene Arbeit zu überprüfen, auditieren, kritisieren (im Sinne von untersuchen) ist wichtig: Wir wollen die Angewohnheit kultivieren, uns auf gesunde Art und Weise selbst zu überdenken und zu hinterfragen, um unsere Arbeit und ihre Früchte zu verbessern.

Die Möglichkeiten sind auch hier vielfältig, weil man Code-Schnipsel ebenso wie vollständige Repositories begutachten kann; man kann, wenn niemand anderes verfügbar ist, für sich selbst die Praxis einführen, den eigenen Code mehrmals, mindestens noch einmal zu prüfen; Reviews können einmalig stattfinden oder regelmäßig wiederholt und eingeplant werden.

Automatisierte Tests sind hierbei Teil des Überprüfungs- und Review-Prozesses genauso wie es solche durch externe Fachleute sind. Die Idee ist, die Gesundheit und Qualität unseres Codes möglichst konstant im Blick zu haben – denn während unsere Projekte und Unternehmen davon gar abhängen mögen, ist dies auch etwas, das uns selbst zu Fachleuten, zu Profis macht.

❧ Dies ist eine Skizze. Eine Skizze minimaler Webentwicklung – was dafür am wichtigsten ist. Aber auch eine Skizze dafür, wie man ein Webentwickler wird, etwas, das ich persönlich eigentlich so nicht geplant hatte, zu beschreiben, denn die einzigen Versuche waren basal, oder zumindest deutlich anders, wie zum Beispiel mein Webentwickler-Vortrag auf der beyond tellerrand.

Als Skizze fehlen hier Details, fehlt die Vollständigkeit. Vielleicht werde ich noch ergänzen mögen, vielleicht mögen Sie. Aber sie beinhaltet auch einige Ideen, wie man es angehen sollte, ein Webentwickler zu werden, und sich nicht nur auf das nackte Minimum, sondern das Minimum konzentrieren will, das zugeschnitten und hochwertig ist. (Diese Vorstellung von Webentwicklung habe ich immer gerne gemocht.)

Was sind dafür die Schlüssel? Die Technologien zu verstehen, indem man sich durch Standards und Spezifikationen arbeitet, übt und publiziert; sich mit den verwandten Themen vertraut zu machen; es selbst zu machen; nach dem kürzesten Weg zu schauen, indem man sich auf Einfachheit, Maßschneidern und den Unterschied zwischen »einfach« und »einfach« besinnt; zu automatisieren; und zu überprüfen.

Das mag dann ein unkomplizierter und vielleicht etwas anderer Ansatz sein – für minimale Webentwicklung.

War dies nützlich oder interessant? Teile diesen Beitrag, werde Nanosponsor oder unterstütze meine Arbeit, indem du mit meinen E-Books lernst.

Über mich

Jens Oliver Meiert, am 9. November 2024.

Ich bin Jens (lang: Jens Oliver Meiert), und ich bin ein Frontend-Engineering-Leiter und technischer Autor/Verleger. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin Mitwirkender an verschiedenen Webstandards und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Ich experimentiere gerne, nicht nur in der Webentwicklung (und im Engineering Management), sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Erfahrungen und Ansichten. (Bitte sei kritisch, interpretiere wohlwollend und gib Feedback.)