Frank Chimero hat einen neuen Vortrag als Essay veröffentlicht, Alles Einfache ist wieder Schwer.
Mögen wir alle eines Tages so wunderbar selbstreflektierend und eloquent sein wie Frank. Da gibt es viel zu lesen, also bitte lesen Sie es. Ein Teil des Themas ist, dass Webdesign und -entwicklung scheinbar repetitive Zyklen haben, die selbst recht erfahrene Leute die Leiter wieder nach unten stoßen können.
Ich fühle mich nach 20 Jahren nicht viel besser darin, [Websites] zu erstellen. Mein Wissen und meine Fähigkeiten entwickeln sich ein wenig, dann ändern sich die Dinge und die Hälfte meines Wissens wird zu tote Last. Das passiert bei keiner meiner anderen Arbeiten.
Und die Komplexität ist schuld.
Komplexität ist gerade eines dieser im Wasser Themen. Kevin Ball schrieb, „wir befinden uns inmitten einer massiven und schnellen Periode des Wandels der Komplexität vom Backend zum Frontend.“ Roneesh hat gerade das Entwirren all dieser Frontend-Komplexität in seinem Kopf gefeiert und seine Gedanken geteilt.
Ich habe auch eine gute Anzahl von Antworten auf Franks Artikel gelesen. Besonders gut gefallen hat mir die von unserem eigenen Robin Rendle aus dem Newsletter
Ich glaube, der Grund für all diese Komplexität und Nuancen in der Arbeit liegt darin, dass wir das Web nicht mehr als eine Reihe von einfachen, hyperverlinkten Dokumenten erwarten.
Unsere Erwartungen als Nutzer des Webs haben sich inzwischen vollständig geändert.
Websites sind an sich schon Maschinen; sie haben Zustände, Benachrichtigungen, Warnungen und Hinweise, Komponenten, die unter bestimmten Umständen erscheinen, standortbezogene Funktionen und eine Komplexität, die alles übersteigt, was wir vor fünfzehn Jahren gebaut haben. Es gibt mehr Geräte und Viewport-Breiten, die unsere Websites mit zunehmend schwierigen Leistungsanforderungen rendern.
Das fühlt sich für mich richtig an. Das ist genau das, was ich fühlte, als ich What is the Future of Front End Web Development? schrieb.
Die Anforderungen an Websites steigen. Entwickler werden gebeten, sehr komplizierte Dinge sehr schnell zu bauen und sie sehr gut und sehr schnell funktionieren zu lassen.
Frank weist jedoch darauf hin, dass selbst Layout, Schriftarten und Bilder in ihrer Komplexität explodiert sind. Die Ursache dafür ist meiner Meinung nach der richtige Fokus (und wirklich die Nachfrage nach) Performance. Aber Reaktionen auf Komplexität sind meist diese Dinge plus ein Dutzend oder zwei andere Dinge.
Vielleicht sind die Dinge nicht ohne Grund kompliziert geworden, sondern stattdessen, um zu konkurrieren. Das Web kann mehr, also bitten wir es, mehr zu tun.
Es ist verlockend zu glauben, dass die Komplexität vollständig aus diesem Mehr herrührt. Mehr vom Potenzial des Webs annehmen, mit nativen Apps Schritt halten und leistungsfähigere Werkzeuge für die Menschen bauen. Aber ich bin sicher, die ganze Geschichte ist (hüstel) komplizierter. Jemand sagte mir einmal, der Grund, warum sich die Entwicklertools weiterentwickelt und komplizierter geworden sind, sei, dass Entwickler im Allgemeinen nicht gebeten werden, auf der Geschäfts- und Produktseite zu innovieren. Sie bauen, was ihnen gesagt wird, also nutzen sie ihren Verstand, um an *ihren eigenen* Werkzeugen zu innovieren.
Es kommt darauf an aber. Ein paar persönliche Beispiele.
Ich betreibe CSS-Tricks seit über einem Jahrzehnt. Es ist eine Standard-WordPress-Seite, und obwohl sie sich sicherlich weiterentwickelt hat, ist sie heute nicht viel komplizierter als in den ersten Jahren. Ich bin besser darin geworden, daran zu arbeiten, auch weil sie sich so wenig verändert hat, dass ich mich bei dieser Arbeit wohler fühle. Ich weiß meistens, was all die sich drehenden Zahnräder tun und wo das Öl hingehört.
Auf der anderen Seite habe ich durch CodePen eine lange Produktentwicklung erlebt, die ziemlich einfach begann und zu extremer Komplexität geführt hat. Wir hinterfragen manchmal, ob wir es mit der Komplexität übertrieben haben, aber meistens war jeder Schritt in diese Richtung eine Reaktion, um etwas anderes, ironischerweise, weniger kompliziert zu machen. Ein Beispiel dafür war die Einführung von React'n'Redux'n'Friends, was einen Schritt nach oben in der Komplexität des Entwicklungsworkflows, des Builds und der Deploymentschritte darstellte, aber, glauben Sie es oder nicht, ein Schritt nach unten in der Komplexität der Codebasis war. Diese Werkzeuge helfen uns, schneller zu bauen, einfacher zu debuggen, gut getestet zu bleiben und eine performante Erfahrung zu bieten, um nur einige der Vorteile zu nennen. Wir haben keine Tools nur zum Spaß hinzugefügt; wir haben Tools hinzugefügt, weil wir wachsende Probleme zu lösen hatten.
Nicht jeder hat die gleichen Probleme. Das Web ist ein großer Ort ist ein Satz, den ich manchmal höre und der mir gefällt. Über eine Milliarde Websites, sagen sie. Ein großer Ort in der Tat.
Schauen Sie sich Dan Cederholms Lieblingswebsite an
Sie ist nicht responsiv. Sie ist nicht für das iPhone optimiert. Sie sieht auf einem Retina-Display unscharf aus. Sie verwendet nicht das neueste HTML5/CSS3-Framework. Sie hat keinen durchdachten vertikalen Rhythmus. Die Schriftarten sind nichts Besonderes. Sie ist weder skeumorph noch flach. Sie hat kein eigenes Favicon. Sie hat keine native App oder Twitter oder Instagram. Sie verwendet weder AJAX noch SCRUM noch node.js noch Sinatra. Sie hat keine API oder einen RSS-Feed oder VC-Finanzierung. Sie wurde nicht auf einem prominenten Tech-Blog vorgestellt oder hat einen Preis gewonnen.
Sie erzählt mir die Tagesgerichte.
Ich vermute, sie braucht keine weitere Komplexität, und buchstäblich niemand plädiert dafür. Deshalb ist dieses Gefühl von das Web ist ein großer Ort so nützlich. Wir reden über Komplexität, aber sie ist optional. Eine wunderbar nützliche (und einfache) Website von vor einem Jahrzehnt bleibt wunderbar nützlich und einfach. Glücklicherweise für alle Beteiligten hat das Web bisher die Kompatibilität sehr ernst genommen. Alte Websites brechen nicht einfach so.
Ich wette, die Teile in Franks Aufsatz über Web-Layout werden bei vielen Lesern dieser Seite Anklang finden. Frank zieht die Verbindung zwischen Tabellenlayout und Grid-Layout. Das ist kein seltenes Gefühl. Zum Beispiel
Machen wir uns nichts vor. CSS-Grid = <Tabelle> und das weißt du / #100daysofcode
— JavaScript Teacher (@js_tut) 13. Februar 2018
Ich bin sicher, Frank versteht die Vorteile des neuen Grid-Layouts (z. B. versuchen Sie, eine <table> an einem Media-Query-Breakpoint neu anzuordnen), aber die Stimmung war mehr auf Zyklen als auf eine tiefe technische Analyse gerichtet.
Ich würde sagen, man könnte vernünftigerweise argumentieren, dass, insbesondere mit CSS, die Dinge heutzutage einfacher sind. CSS früher ließ uns die Nägel abkauen wegen Cross-Browser-Unterstützung, verteilten Vendor-Präfixen in unserem Code und (lol) beteten zum Box-Modell.
Eric Meyer sagt, trotz der Veröffentlichung eines schweren Kompendiums über CSS-Wissen dazu
CSS hat weitaus mehr Fähigkeiten als je zuvor, das stimmt. Im Sinne von „wie viel es potenziell zu wissen gibt“, ja, CSS ist eine größere Herausforderung.
Aber die Kernprinzipien und Mechanismen sind nicht komplizierter als vor einem oder sogar zwei Jahrzehnten. Wenn überhaupt, sind sie jetzt leichter zu verstehen, weil wir unsere Köpfe nicht mehr mit Float-Verhalten oder Inline-Layout belasten müssen, nur um eine Seite zu layouten.
Um auf die Entwickler zurückzukommen, die an ihren eigenen Werkzeugen innovieren, ist ein weiterer zu berücksichtigender Faktor der Einfluss von Website-Buildern auf unsere Branche. Ich werde unter den richtigen Umständen immer eine Website-Builder-App empfehlen. Benötigt Ihr Fotografiegeschäft eine Portfolio-Website? Ihre Bäckerei eine Homepage? Ihre benutzerdefinierte Schal-Website einen Blog und einen E-Commerce-Shop? Wenn es sich um einen Auftrag unter 10.000 US-Dollar handelt, würde ich eher empfehlen, ein spezialisiertes Website-Builder-Produkt zu verwenden, als den Auftrag an jemanden zu vergeben, der etwas komplett Individuelles baut. Ich möchte nicht zu weit in dieses Kaninchenloch abrutschen, aber soviel dazu: Da ich mit dieser Denkweise nicht allein bin, ist der Markt für Low-End-Custom-Design- und Entwicklungsarbeiten ziemlich verschwunden.
Es gibt heutzutage mehr Entwickler, die in Inhouse-Teams oder Agenturen mit großen Kunden arbeiten. Das heißt, immer mehr Entwickler an umfangreichen, langfristigen, hochkomplexen Jobs. Dort sind ihre Gedanken. Große komplizierte Probleme mit großen komplizierten Lösungen. Das wird besprochen. Das wird gebloggt. Darüber wird gestritten. Das ist das Thema auf vielen Konferenzen, auf denen ich war.
Obwohl man sicherlich eine Suppe-des-Tages-Website mit einer index.html-Datei und FTP erstellen kann, sind Blogbeiträge darüber seltener und bekommen nicht so viele Claps.
Ein Shout-out an Dave Rupert, meinen Freund und Co-Moderator von ShopTalk Show, der sich seit ich ihn kenne gegen Komplexität in all ihren Formen wehrt. Ich versuche immer noch aufzuholen.
Während es sicherlich Anwendungsfälle gibt, bei denen moderne Werkzeuge und Frameworks hilfreich sind, habe ich das Gefühl, dass die meisten Webanwendungen komplexer und aufgeblähter sind, als sie sein müssen.
Während es viele SPAs gibt, die langsam und aufgebläht sind, scheinen Werbenetzwerke das absolut Schlimmste zu sein.
Ich stimme dem zu und möchte Folgendes hinzufügen.
Es ist nicht so sehr, dass HTML oder CSS sehr schwer ist, es sind all die Tools/Frameworks, die es schwer machen. Wenn man darüber nachdenkt, haben wir einen Workflow geschaffen, der unseren Code kompilieren muss, um für eine Sprache zu funktionieren, die keine Kompilierung benötigt (schau dich um, SASS, LESS, HAML usw.).
Schauen Sie sich einfach an, was Sie auf Ihrem PC installieren müssen, um mit der Entwicklung zu beginnen, es ist irgendwie seltsam, finden Sie nicht?
Es beunruhigt mich, dass all die Hype-Züge herumfahren, die Probleme lösen, die nicht existieren (css-modules von postcss zum Beispiel).
Als junger freiberuflicher Webentwickler und frischgebackener Hochschulabsolvent habe ich das Gefühl, dass es viel zu viel Neues zu lernen gibt.
Du musst nicht alles lernen.
Konzentriere dich einfach auf die Fähigkeiten, die du lernen musst, um dein aktuelles Projekt abzuschließen. Dann gehe zum nächsten Projekt über :)
Als ich anfing, Frontend-Entwicklung zu lernen, gab es nur HTML und CSS. Die Herausforderung war, dass die Seite unter IE6 richtig aussah. Gute alte Zeiten. Ich danke IE6, weil er mir geholfen hat, CSS besser zu lernen. Jedenfalls wechselte ich dann zu JavaScript. Dann fand ich erstaunliche Bibliotheken wie jQuery, Underscore, Backbone. Nun, dann fand ich das mächtige Bootstrap, Foundation. Nach Jahren der Nutzung von CSS kam Less, dann Sass. Dann änderte sich plötzlich alles. Ich dachte: Was zum Teufel ist Kompass! Nachdem ich mich davon erholt hatte, gab es Grunt, dann Gulp, dann Webpack. Wow! Schnelle Workflow-Änderung. In CSS – Flex, dann Grid und viele weitere große Änderungen. In JS es6, React, Vue, Angular, Express. Ich will nicht sagen, dass ich müde bin. Aber es ist viel zu viel und wird von Tag zu Tag komplizierter.
Ich vermisse immer noch die alten Tage, alte pngfix, hoverhtc. Aber wir müssen mit neuen Technologien weitermachen, egal was passiert.
Ich habe Franks Aufsatz gelesen und genossen, und dies ist ein weiterer großartiger Beitrag, aber ein überwiegendes Gefühl, das mich gerade zu verfolgen beginnt, ist die Zufriedenheit. In dieser ständigen Jagd, Schritt zu halten, und dem unvermeidlichen Gefühl, dass Arbeit und Werkzeuge fast sofort veraltet sind, fällt es mir schwer, mich an das letzte Mal zu erinnern, als ich echte Zufriedenheit aus meiner Web-Arbeit gezogen habe. Ich kann mich nicht erinnern, mit irgendetwas glücklich gewesen zu sein, es kann immer verbessert, aktualisiert, besser gemacht werden, und es ist nie wirklich fertig. Ich bin mir nicht sicher, ob jemand anderes das Gleiche empfindet oder ob ich ein Ausreißer bin, aber das ist mir gerade eingefallen. Wenn ich andere Arbeiten mache, wie Grafikdesign, Kalligraphie oder die Arbeit an meinem Haus, fühlt es sich großartig an, Dinge abzuschließen, ich kann zurückblicken und sie bewundern, aber das gleiche Gefühl scheint bei dieser Sache nicht vorhanden zu sein.
Ich bin ein relativ neuer Webentwickler, der seine Karriere mit dem Erstellen von „Low-End-Websites“ mit selbst beigebrachten HTML, CSS und WordPress begann, gerade als Site-Builder den Horizont stürmten.
Ich habe mich neulich mit meinem Angular-Guru-Kumpel unterhalten, und er erwähnte beiläufig, dass jQuery „alte News“ sei. Mein Gehirn registrierte das als „ist tot“ und ich glaube, ich fühlte diese entmutigende Angst, über die erfahrene Webprofis zu klagen beginnen. Dann habe ich nach „React-Tutorials“ gegoogelt. Ich kann Leser kichern hören, dass ich schon zu weit zurückliege. Aber ich war beschäftigt, mich in einen neuen Job einzugewöhnen, zu lernen, wie die Dinge HIER funktionieren, und das ist erst sechs Monate her!
Mein liebster takeaway aus Kevins Ball-Artikel: „... man kann als API-Entwickler mit Ruby on Rails gut leben, ohne die Hälfte seiner Arbeitszeit damit zu verbringen, auf dem neuesten Stand zu bleiben.“ Hmm. Das könnte ich eine Weile machen.
Super wertvoll Chris, ich könnte nicht mehr zustimmen. Obwohl ich die Zeiten von spacer.gif nicht vermisse, ist die Erwartung des Geschäfts, mit dem „Bleeding-Edge“ Schritt zu halten und trotzdem eine nachhaltige Wartbarkeit im Code zu haben, ein schwieriger Balanceakt.
Es gibt noch einen weiteren Aspekt, der meiner Meinung nach erwähnenswert ist, und zwar, dass Ingenieure gerne Dinge entwickeln. Während es durchaus möglich ist, nur so viele Tools zu verwenden, wie das Projekt erfordert, tun das die Leute oft nicht. Es macht Spaß, Dinge zu automatisieren. Es macht Spaß, wirklich elegante und interessante Abstraktionen zu schreiben. So gibt es die Tendenz bei Webentwicklern – verstärkt durch die einfache Möglichkeit in JavaScript, Code zu „hacken“ und zu teilen und neue Abhängigkeiten zu installieren – Dinge zu überkonstruieren. Ich glaube, daher kommt ein Großteil dieses Gefühls von „die Dinge sind jetzt zu komplex“.
Einige Dinge sind einfacher geworden. Für den Bau einer einfachen Website kann man heutzutage mit weniger Werkzeugen mehr erreichen: Sobald man CSS Grid, CSS Variablen und grundlegende DOM-Manipulation über JS verstanden hat, kann man heutzutage viel ohne Frameworks, jQuery oder gar Sass-Installation erreichen.