Die Webentwicklung und das große Ganze

Artikel vom 18. Januar 2018. ISSN 1614-3124, #57. Schwerpunkt: Webentwicklung (RSS-Feed für alle Themen).

Als Googler (Google-Mitarbeiter) kommt man nicht umhin, mit »Big Thinking« konfrontiert zu werden, mit »großem Denken«, mit großen Ideen, mit großen Lösungen zu großen Problemen; Larry sprach hierbei gerne von »Moon Shots«. Als Schüler von Gary Keller’s The One Thing versuche ich mehr über solch großes Denken und klaren Fokus zu lernen (was nicht immer so war, und ich werde mehr über mein Dilemma schreiben). Aber hier, und das ganz bescheiden, will ich kurz über das große Ganze schreiben. Darüber, wie man über den Tellerrand hinausschaut. In der IT. Anhand von fünf Beispielen.

Selektoren-Performance

Ich mag dieses Beispiel sehr; ich hatte es auch schon in What We Should Teach Up-and-Coming Developers gebraucht.

Vor vielen Jahren haben Performance-Spezialisten – ganz besonders Steve Souders – die Geschwindigkeitsaspekte von Selektoren untersucht und herausgefunden, dass der universelle Selektor am teuersten ist. Die Antwort des Feldes folgte prompt in Form eines kollektiven Nervenzusammenbruchs und dem YouTube-artigen Trollen eines jeden, der solche Selektoren benutzte – um jeden komplizierteren, unverständlicheren CSS-Code schreiben zu lassen. Steve hatte das nicht angeregt – er hatte einfach wichtige Pionierarbeit geleistet – aber das Denken entsprach schnell »langsamer = schlecht«, ohne dabei zur berücksichtigen, dass niemand Stylesheets schrieb, die so groß waren, dass überhaupt ein Effekt wahrzunehmen war. Das sollte man einzelnen nicht anheften, aber man kann sagen, dass wir als erfahrenere Mitglieder des Feldes wohl früher hätten intervenieren und viel lautstärker betonen sollen, dass ja, Selektoren-Performance variiert, aber nein, ändern Sie nichts, opfern Sie gute CSS-Praktiken nicht einfach kaum wahrnehmbaren Performance-Gewinnen. Das große Ganze im Auge behalten.

Performance beeinflusst, wie wir CSS schreiben, und als solches ist es nützlich, hinzuschauen, wie dieser Einfluss genau aussieht.

Wartbarkeit

Wartung ist wichtig und um zu warten müssen wir sicherstellen, dass Code tatsächlich wartbar ist. Im »ersten Paradigma« der Webentwicklung hängt Wartbarkeit von schlankem HTML und strikter Separation of Concerns ab. Aber so strikt sein, wie man es als Wartbarkeitsspezialist gerne ist, verschiebt eine Menge Komplexität und Verantwortung und sogar Wartungsschuld in benachbarten Code – speziell Stylesheets und Skripte – und es muss damit sorgfältig abgewogen werden, mit einem Blick auf Kontext und großes Ganzes. Ein Beispiel? Ein Extremfall sogar (wobei heutzutage viel bekömmlicher) ist der, jeglichen Gebrauch von IDs und Klassen im Markup zu vermeiden (sogenanntes »idealistisches Markup«). Mit immer mächtigeren und immer besser unterstützten Selektoren ist dies eine wesentlich bessere Option geworden, aber die Simplizität, die dies auf HTML-Seite bringen kann, sorgt für einen superben (wenn auch jetzt weniger drastischen) Anstieg an Komplexität auf CSS-Seite.

Wartbarkeit ist teilweise asymmetrisch, dadurch werden Effekte guter Wartbarkeit manchmal woanders gefühlt, und deshalb müssen wir die Konsequenzen von Wartbarkeitsempfehlungen sorgfältig abwägen, bevor wie sie abgeben.

Designkonsistenz

Ich habe zuletzt mit niemand gearbeitet, der auf »pixel-perfekte« Umsetzung einer Website bestanden oder überhaupt darüber gesprochen hat. »Pixel-perfekt« bezog sich ehemals auf das gleiche Erscheinungsbild einer Website in in unterschiedlichen Browsern, es wurde kurzzeitig diskutiert, als die ganze »responsive« Mobiltauglichkeitsdebatte anhob und es kommt immer nochmal auf, wenn Designentwürfe in die Tat umgesetzt werden. Eine Website oder App ist dann pixel-perfekt, wenn sie des Designers Vorlagen und Ideen vollständig entspricht. Das große Ganze im Sinne von weitreichendem Verständnis bedeutet hier normalerweise eins: dass Konsistenz sowohl des Designers als auch des Entwicklers Freund ist. Konsistenz ist aus Usability-Sicht gut und ebenso aus Sicht von Code-Komplexität. Wenn pixel-perfekt bedeutet, dass ein Button auf einem Entwurf zufällig fünf Pixel niedriger hängt als auf einem anderen, aber genauso umgesetzt werden soll, anstatt über gleichartige Platzierung zugleich Designkonsistenz und einfacheren Code zu sichern, läuft etwas schief.

Webdesign betrifft, wie wir HTML und CSS schreiben, und somit ist es beim Entwurf von Websites nützlich, zu verstehen, wie mit HTML und CSS gearbeitet wird, zumindest wenn man Websites für Produktion und Launch abnimmt.

Barrierefreiheit

Barrierefreiheit hat einen besonderen Status, weil es hierzu nicht nur eine moralische Seite gibt, sondern auch eine rechtliche; und mit dieser »Einseitigkeit« (eine Beobachtung, kein Urteil) gibt es kaum ein Gegengewicht in dem Sinne, Zugänglichkeitsnormen und -techniken auch aus Sicht anderer technischer Gebiete zu betrachten – also das große Ganze zu betrachten. Barrierefreiheit ist so stark aufgeladen, dass oftmals nur technische Nicht-Machbarkeit als irgendein Argument akzeptiert wird. Dies soll nur die spezielle Situation betonen, obwohl ich meine, dass die Barrierefreiheit bereits starken Einfluss auf unsere Entwicklungspraktiken genommen hat. Der Zweck mag die Mittel rechtfertigen (zumindest hier), aber Barrierefreiheit ist ein besonderes Thema.

Barrierefreiheit ist kritisch, um jedem Zugang zu Informationen und Diensten zu gewähren, aber es betrifft viele Teile professionellen Webdesigns, von Inhalten zu Design zu Code; und auch wenn wir Barrierefreiheit bei unserer Arbeit zur absoluten Priorität machen wollen, brauchen wir ein solides Verständnis der Folgen, die Zugänglichkeitsnormen und -methoden nach sich ziehen.

Vision

Vision soll sich hier auf unsere Idee von Webentwicklung beziehen, wenn wir denn eine haben: »es erledigen« oder »zum Laufen bringen« sind keine Visionen – sie sind bloßer Pragmatismus. Ich will mich nicht an einer kugelsicheren Definition von »Vision« probieren, aber diese sollte doch langfristige Richtung bieten. Die Idee, Websites zu bauen, die von hoher Qualität sind, Websites zu bauen, die überdauern, Websites zu bauen, die mit einem geringen Risiko unnötiger Änderungen daherkommen scheint mir beispielsweise nützlich zu sein; und sie mag schon andeuten, dass wir dabei nicht alles andere vergessen dürfen, wenn jemand mit technischem Fokus, der bei Änderungen zögerlich ist (um des hohen Ziels und der Vision von Einfachheit und Stabilität Willen) gleich jeglicher Designanpassung skeptisch gegenüber steht (ist mir auch schon passiert). Was wir dann beobachten mögen ist ein seltsamer Twist von jemand, der tatsächlich eine Vorstellung oder Vision hat, aber für sich und isoliert arbeitet, von jemand der: nicht das große Ganze sieht.

Unsere Ideen und unsere Vision von Webentwicklung beeinflussen unausweichlich nicht nur Code, und als solches erfordern sie Aufmerksamkeit, um die anderen Bereiche unserer Arbeit und damit das große Ganze nicht zu behindern.

❧ Ich wünsche, dass diese fünf Beispiele einen Eindruck davon geben, wie sehr unterschiedliche Herausforderungen, generische wie auch spezifische, alle über ihren Bereich hinausreichen können. Aber auch wenn ich diese als so problematisch beschrieben habe, nicht nur ein gutes Verständnis der ganzen Bandbreite der Webentwicklung zu erfordern, sondern auch einen feinen, diplomatischen Sinn für Prioritäten und Kompromisse zu entwickeln, fordere ich nicht, dass wir diesen Sinn auch immer zeigen – dass Webentwicklung sich nun nur noch um Diplomatie, Konsens und Kompromiss drehe. Nein: Aus meiner Sicht fängt alles mit Bewusstsein an, und ein Bewusstsein, dass unsere Entscheidungen in andere Bereiche hineinbluten, zusammen mit einem gesunden Interesse, die Konsequenzen und Alternativen zu kennen, klingen nach guten Erfolgen. Webentwicklung ist ein fortwährend mächtigeres und immer komplexeres Feld, und ich glaube, dass wir die Möglichkeiten und die Verantwortung, die das mit sich zieht, besser würdigen können.

Ich schreibe regelmäßig über konzeptionelle und Meta-Aspekte von Webentwicklung und -design. Schauen Sie sich weitere deutsch- und englischsprachige Artikel an – oder eins meiner Bücher über Webentwicklung.

Über mich

Jens Oliver Meiert, am 30. September 2021.

Ich bin Jens, und ich bin ein Engineering Lead und Autor. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin W3C und WHATWG verbunden und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Mit meinem aktuellen Umzug nach Spanien bin ich offen für eine neue Führungsposition im Frontend-Bereich. Beachte und empfehle gerne meinen Lebenslauf oder mein LinkedIn-Profil.

Ich experimentiere gerne, nicht nur in der Webentwicklung, sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Ansichten und Erfahrungen.