Dieser kleine Tweet-Austausch ist mir ziemlich im Gedächtnis geblieben.
1997: Lass uns eine Website erstellen!
*startet vi*2007: Lass uns eine Website erstellen!
*lädt jQuery herunter*
*startet vi*2017: Lass uns eine Website erstellen!
😵 pic.twitter.com/RT4VVnJjNS— Thomas Fuchs (@thomasfuchs) 22. Februar 2017
Hör auf mit dem Quatsch. Websites im Jahr 2007 waren schrecklich. UX treibt all das. https://#/k2akE8tjTU
— Colin Megill (@colinmegill) 24. Februar 2017
Obwohl ich denke, dass es generell ratsam ist, sich von schnippischen Twitter-Diskussionen fernzuhalten, berührt dies einige interessante Punkte, die meiner Meinung nach viele Leute empfinden.
Thomas hat Recht: Webentwicklung ist nur komplizierter geworden
Höre dir eine beliebige Q&A-Runde auf einer Entwicklerkonferenz an und du wirst das hören. Es ist gerade DAS vorherrschende Gesprächsthema.
Diese Komplexität darf nicht ignoriert werden. Die Leute *empfinden* sie. Super intelligente und kompetente Entwickler sind verständlicherweise nervös deswegen. Die Auswirkungen von super komplexen Entwicklungsumgebungen und Build-Prozessen sind wahrscheinlich noch nicht ganz absehbar.
Was bedeutet das für die Schulung neuer Entwickler? Schulung alter Entwickler? Wo sind die Grenzen dieser Komplexität?
Colin hat Recht: Diese Komplexität ist nicht umsonst
Zuerst einmal: Du *musst* keinen neumodischen, komplizierten Kram verwenden, um eine Website zu bauen, wenn du nicht willst. Das Web ist ein großer Ort. Was für den Erfolg einer bestimmten Website notwendig ist, ist so vielfältig wie die Menschen, die auf diesem Planeten leben.
Die Anforderungen einer Website könnten so sein, dass du mit reinem HTML und CSS eine wunderbare Arbeit leisten kannst. Das Web hat auch eine ziemlich gute Arbeit bei der Abwärtskompatibilität geleistet. Die Websites von 1997 und 2007 funktionieren, wenn sie noch existieren, wahrscheinlich genauso wie damals oder besser, auch wenn sich die Hardware, auf der sie angezeigt werden, verändert hat.
Worum geht es also bei der Komplexität?
Websites im Jahr 2017 werden im Vergleich zu 2007 und besonders 1997 nach viel mehr gefragt. Besser tun. Schneller tun. Überall funktionieren. Gut dabei aussehen.
Ich möchte nicht nur die Adresse des Flughafens sehen, ich möchte meinen Flug buchen, meinen Sitzplatz auswählen und ihn dann drei Tage später ändern, meine SkyMiles verwalten, meine Reiseroute ausdrucken, über alle Änderungen benachrichtigt werden und das alles auf mein Handy synchronisieren (um 20 % dessen zu nennen, was eine Fluggesellschaftswebsite bietet). Und das bitte in 3 Monaten liefern.
Entwickler, die mit dieser Anforderungsliste staunend konfrontiert sind, haben sich gemeldet und gesagt: *"Wir werden das tun, aber wir werden die Werkzeuge bauen und entwickeln, die dafür notwendig sind, es gut zu machen."* Ja, wir bauen Werkzeuge für die Entwicklerfreundlichkeit. Du kannst sie, wenn du willst, als Komplexität betrachten, und du liegst nicht falsch, aber das ist nicht die ganze Geschichte. Diese Werkzeuge ermöglichen es uns, das zu bauen, was du brauchst, ohne ein Chaos zu hinterlassen, von dem man sich nur schwer erholen könnte.
Die Nutzer des Webs wollen viel. UX treibt all das.
Aber dient dieser Boilerplate-Code zwangsläufig einer besseren Benutzererfahrung?
Was ich in der zunehmenden Komplexität von Tools und Build-Prozessen sehe, ist nicht unbedingt ein Fokus auf bessere Benutzererfahrung: vieles davon dient der Verbesserung der Erfahrung einer bestimmten Art von Entwickler.
Ich behaupte nicht, dass Dinge nicht komplexer sein sollten als 2007; ich habe damals nicht einmal Webentwicklung betrieben und habe daher kein Gefühl für irgendwelche "guten alten Zeiten". Aber die Start-Boilerplate in diesem Tweet ist ein Sinnbild für eine bestimmte Art von "alles in JavaScript"-Mentalität, die mir wirklich Sorgen macht, besonders wenn sie es Entwicklern ermöglicht, Probleme der Barrierefreiheit und des progressiven Enhancements zu ignorieren.
Ja, die Tatsache, dass diese Liste von Dingen jemals als "Boilerplate" betrachtet werden würde, ist... nicht gut.
Vielleicht könnten wir die Dinge ein wenig weiter destillieren.
„Diese Werkzeuge ermöglichen es uns, das zu bauen, was du brauchst, ohne ein Chaos zu hinterlassen, von dem man sich nur schwer erholen könnte.“
Solange du nicht jede Technologie, die du implementierst, verstehst, ist es sehr einfach, ein Chaos zu hinterlassen, von dem man sich nur schwer erholen kann. Deshalb sind Entwickler wie ich viel geduldiger, Werkzeuge zu ihrem Setup hinzuzufügen.
Danke, Chris.
Meine Sorge ist, dass wir diese zeiteffizienten Werkzeuge auf Entwicklungsprojekte anwenden, wo sie nicht benötigt werden. Einige von ihnen sind großartige Allzweckwerkzeuge, von denen jedes Projekt profitieren könnte. Einige scheinen sehr komplex zu sein und werden nur für bestimmte Arten von Projekten benötigt. Ob es sich um ein Build-Tool oder ein CMS handelt, es ist einfach nicht für *jedes* Projekt notwendig.
Komplizierte Aufgaben erfordern komplizierte Werkzeuge, um alles zusammenzuhalten, wie du gesagt hast. Ich denke, die eigentliche Frage ist, wann man komplexere Werkzeuge für komplexere Prozesse einsetzt und wann einfachere Werkzeuge. Ich bin der Meinung, dass man so einfach wie möglich beginnen und sich zur Komplexität hocharbeiten sollte. Wenn man das Komplexe zum Ausgangspunkt macht, führt das nur zu einer Überkomplizierung eines Großteils der Entwicklung. Viele Websites sind als langweilige alte HTML/CSS/JS-Websites großartig. Es gibt Build-Tools, die helfen, wenn das wächst und ein wenig komplexer wird. Wenn es zu unübersichtlich wird, bringt man die Website in ein CMS oder in ein größeres Framework zum Erstellen von Websites. Es ist jedoch eine Progression.
Ein gutes Beispiel ist, dass so viele Leute auf React als Allzwecklösung setzen. „Alles wird JS sein“, sagen sie. „Warum sich dagegen wehren?“ Nun, es ist einfach nicht die richtige Lösung für alles. Komplexe Werkzeuge sind oft die Antwort (häufig) auf komplexe Probleme oder Prozesse. Aber sie sind nicht die Lösung für jedes Problem.
Ich denke, die Schulung neuer Entwickler in einem großen Unternehmen unterscheidet sich von der Arbeit, die viele freiberufliche oder kleine Agenturentwickler täglich leisten. Wir sollten die Werkzeuge der Komplexität zusammen mit der Fähigkeit, zu unterscheiden, wann diese Werkzeuge einzusetzen sind, lehren. Kannst du es benutzen? Großartig. Weißt du, *wann* du es benutzen sollst? Das ist die größere Frage, meiner Meinung nach.
Es gibt Anwendungsentwickler, die Websites/Apps für den von dir im Artikel erwähnten Fluggesellschaftskunden erstellen. Aber es gibt viele Entwickler, die im Marketing oder mit kleinen Kunden arbeiten und wirklich nur eine gut gestaltete HTML/CSS/JS-Website benötigen. Wenn sie versuchen, mit den neuesten Trends Schritt zu halten, übernehmen diese Entwickler und Neulinge Prozesse, die komplizierter sind, als sie sein müssten. Sie erkennen nicht, dass ihre Arbeit sich stark von dem unterscheidet, was bei Google oder Apple oder sogar CSS-Tricks passiert. Ich denke, um Schritt zu halten, fühlen sich Entwickler unter Druck gesetzt, all diese neuen Build-Tools zu verwenden.
Übrigens, ich habe die neue Website meines Unternehmens mit der CSS-Tricks Projects IDE erstellt. Ich schätze Ihre Arbeit sehr und möchte sagen, dass Sie viele dieser Komplexitäten aufgegriffen und versucht haben, den Prozess der Erstellung einer Website zu vereinfachen. Ich finde es großartig, was Sie getan haben, und wünsche Ihnen weiteren Erfolg mit diesem Projekt. Ihre IDE ist ein Beispiel dafür, wie jemand versucht, den Entwicklungsprozess zu vereinfachen, anstatt ihn komplizierter zu machen. Ich denke, Sie haben ein System geschaffen, das es dem Entwickler ermöglicht, das Projekt *nach Bedarf* während des Prozesses zu skalieren. Wir müssen nicht mehr mit übermäßig komplexen Build-Systemen beginnen und dann etwas Überkomplexes erstellen, das durch die Komplexität des Build-Systems diktiert wurde.
Was die Schulung neuer Entwickler angeht: Könnte es eine bessere Abgrenzung zwischen normaler Entwicklung (HTML/CSS, Marketing, Landing Pages) und High-End-Entwicklung (Apps, Enterprise, Langzeitprojekte) geben? Ich denke, wenn ein Entwickler sehen könnte, wo er/sie sich auf diesem Spektrum befindet, würde das helfen, einige der Verwirrung über all die verschiedenen Build-Tools zu lindern. Ich arbeite für ein großes Unternehmen, und wir haben 1-2 Projekte, die die im ursprünglichen Tweet aufgeführten Technologien erfordern. Für viele der Projekte, an denen ich intern arbeite, reicht ein einfaches Build mit etwas Vorverarbeitung, Autoprefixer und Autorefresh völlig aus. Alles Komplexere würde alles nur ausbremsen und überkomplizieren.
Vielen Dank nochmals, dass Sie dieses Thema zur Sprache gebracht haben. Es ist eine gute Frage.
Thomas erwähnte nichts über die Menge an Code, die 1997 oder 2007 auf dem Server lag. Ich würde sagen, der Großteil davon wurde jetzt in den Browser verschoben.
Akzeptiert, aber das ist nicht das, worum es im ursprünglichen Tweet ging – es ging um Boilerplate, *dessen Zielgruppe Entwickler sind*. Meine Sorge ist, dass dies nicht *benutzerzentriert* ist, sondern übermäßig aufgeregt *entwicklerzentriert*. Technologiegetrieben, nicht nutzergetrieben. Ich akzeptiere, dass dein Flugbeispiel gültig ist, aber sicher gibt es ein Element der Selbstverstärkung und des blinden Wettlaufs, ganz zu schweigen von der Absicht des Ausschlusses, aus allen üblichen Gründen?
Ich bin irgendwie jemand, der sich leicht von der "Glamour"-Seite der Tools verführen lässt, aber tief im Inneren weiß ich, dass es wirklich, wirklich, wirklich (wirklich... okay, du verstehst) unnötig ist, es sei denn, es wird benötigt, und Posts wie dieser helfen mir, mein Gesicht aus diesem Tunnel der Werkzeuge zu ziehen, Zeit zu sparen und zu versuchen, großartige UIs zu bauen, die zu einer besseren UX führen.
Hör auf mit dem Quatsch, UX treibt sie alle. 2Daumen hoch.
Der Screenshot zeigt ein sehr meinungsintensives Setup, das du niemals brauchen wirst, wenn du eine einfache Website erstellst, also existiert das Dilemma des Tweets nicht.
Sicher, wenn du fortgeschrittene Anwendungsentwicklung betreibst, benötigst du ein Setup, das diesem ähnlich ist, aber wenn wir Äpfel mit Äpfeln vergleichen wollen, war die Entwicklung von Anwendungen gegen das Windows-Framework im Jahr 1997 einfacher? Ich glaube nicht.
Als alter Entwickler, der 2007 und früher Webanwendungen entwickelte, kann ich sagen, dass die Dinge schon immer kompliziert waren.
Wir als Branche hatten schon immer komplizierte Werkzeuge, um komplexe webbasierte Anwendungen zu liefern. Die frühen Tage des Bauens einer statischen Website nur mit HTML/CSS/JS in Dreamweaver sind bis 2002 gestorben. Und wenn mir jemand sagt, dass die .ASP/.NET-Werkzeuge weniger kompliziert waren als heutige JS-Frameworks, dann nenne ich ihn einen Lügner.
Mit der Entwicklung von Rails war es das erste Mal, dass wir als Branche wirklich zu verstehen begannen, was es bedeutet, echte webbasierte Software zu entwickeln. Und UX war ein großer Treiber dafür, da die Leute begannen, Desktop-App-ähnliche Erlebnisse in ihren Webanwendungen zu fordern. Heute ist das so alltäglich, dass ja, das Erstellen einer einfachen HTML/CSS/JS-Statik-Website mit etwas jQuery als Kinderspiel gilt.
Aber zu sagen, dass Dinge niemals so kompliziert sein sollten, ist so, als würde man sagen, dass alle Autos wie Ford Model T sein sollten und ich jeden Aspekt meines Autos mit einem Schraubenzieher und einem Hammer reparieren können sollte.
Das ist einfach lächerlich.
Fazit
Tooling ist schwer. Tooling war schon immer schwer. Web-Anwendungen zu bauen ist schwer und die Erwartungen sind hoch. Ein Teil des Problems ist, dass der Browser nie als Anwendungsrepository gedacht war, daher mussten wir die Werkzeuge bauen, die dies ermöglichen. DSLs, Frameworks und Meinungen sind alles, was wir in diesem jungen Ding haben, das wir das Internet nennen.
Gut gesagt! Fügt eine gute Perspektive auf den ursprünglichen Zweck des Browsers im Vergleich zu dem hinzu, was wir über die ersten Jahrzehnte des Internets damit versucht haben. Als neuer Entwickler schätze ich Ihre Gedanken!
Ich glaube, dem 2007er Beispiel fehlt etwas...
Ich glaube nicht, dass das Problem ist, dass all das verfügbar ist. Die Anzahl der Werkzeuge, die Webentwickler heutzutage haben, ist absolut wunderbar. Aber so viel in deinem einzigen Boilerplate zu haben? Das macht Komplexität zum Standard, selbst für Projekte, die einfach sein sollten.
Der erste Schritt zu jedem Build sollte darin bestehen, festzustellen, was der Kunde braucht. Häufig, besonders bei kleineren Kunden, brauchen sie WordPress, ein paar Seiten und ein Theme. So etwas wäre definitiv übertrieben.
Es ist nichts falsch an einem Boilerplate, das davon ausgeht, dass du eine Web-*App* und keine Web-*Seite* baust, aber es ist wahrscheinlich am besten, mehrere Boilerplates zu haben und das am besten geeignete am Anfang jedes Projekts auszuwählen, an dem du arbeitest.
Das ist nur die halbe Wahrheit. Diese Dinge werden nicht von der Benutzererfahrung, sondern von der Entwicklererfahrung angetrieben. Das ist aber nichts Schlechtes, denn es ermöglicht eine schnellere Implementierung von Features, die gut für die Benutzererfahrung sind, also wird sie indirekt von UX angetrieben.
Ich stelle fest, dass sich unser Entwicklungsteam mit zunehmender Komplexität von Boilerplate und Tools immer mehr abschottet. Ich konzentriere mich auf eine Sache, jemand anderes konzentriert sich auf das Toolset, jemand anderes konzentriert sich auf UX, und das nächste, was ich weiß, ist, dass wir ein riesiges Projekt am Laufen haben, das die meisten von uns nicht replizieren könnten, wenn wir müssten... und die Arbeit am eigentlichen UI-Teil wird zu einem Spagat auf Baumstämmen auf einem Fluss, weil sich die Infrastruktur ständig ändert. Ehrlich gesagt, die Hälfte der Komplexität ist da, weil die meisten des Teams aus einem Java-Hintergrund kamen... es "braucht" einen Build-Prozess. Ich bin der einzige altmodische Webentwickler im Team, und wir haben früher Dinge gebaut, die so kompliziert waren (vielleicht nicht so groß), immer ohne Build-Prozess und ohne andere Bibliotheken als die, die wir selbst geschrieben haben.
Entschuldigung, ich bin etwas widersprüchlich, aber...
Wenn du ein DevOps-Team hast, das diesen Boilerplate eingerichtet hat und es FUNKTIONIERT, oder wenn du ein Solo-Entwickler / kleiner Team-Entwickler bist, der diesen Boilerplate gebaut hat und es FUNKTIONIERT, gibt es nichts, was dich daran hindert, in reinem HTML/JS/CSS zu entwickeln, wenn das dein Ding ist. Aber die Werkzeuge sind *da*, wenn du sie brauchst.
„Oh, hallo, Scope Creep, ich denke, dieses Projekt braucht vielleicht doch React/Redux/Webpack... Oh schau, sie sind bereits konfiguriert. GEWONNEN! Entwickle weiter!“
(Das ist im Grunde das, was CodePen Projects getan hat. Vorkonfigurierte Entwicklungswerkzeuge, die per Knopfdruck bereit zum Deployment sind, aber dich nicht behindern, wenn du sie nicht brauchst. Ich sehe nicht wirklich, wie das eine Last für den Entwickler ist.)
Die Leute reden, als wären diese modernen Werkzeuge, die wir heute haben, nur in den komplexesten von komplexen Websites notwendig. Diese modernen Werkzeuge sind aber auch in den einfachsten von einfachen Websites nützlich.
Für eine super einfache HTML / CSS / JS-Website würde ich immer noch gerne einen Stack wie diesen verwenden, um meine Produktivität zu maximieren.
Pug zum schnelleren und einfacheren Schreiben von modularem HTML
Sass für CSS
autoprefixer für Präfixe
Babel für ES6 JS
Browserify/webpack für modulares JS
ESLint für JS-Konsistenz
Sass-Lint für Sass-Konsistenz
SVG-Autospriting
Customizr zur automatischen Generierung einer benutzerdefinierten Modernizr-Funktionserkennungsdatei (@supports wird in IE nicht unterstützt)
Gulp, um alles tatsächlich auszuführen
Sich über die Komplexität von Websites heute zu beschweren, ist wie sich über die Komplexität von Autos im Vergleich zu Fahrrädern zu beschweren.
Ja, Autos sind weitaus komplizierter als Fahrräder, aber Autos bringen dich auch in einem Bruchteil der Zeit zum Ziel, die du brauchen würdest, um mit einem Fahrrad dorthin zu gelangen.
Niemand muss sein eigenes Auto bauen, um die Werkzeuge zu benutzen. Es gibt Frameworks wie Yeogurt, die die meiste Arbeit für dich erledigt haben. Es braucht vielleicht ein wenig Anpassung, aber ansonsten ist es im Grunde so einfach wie der Kauf eines Autos bei einem Autohändler, nur dass das Auto kostenlos ist. Du musst nicht wissen, wie man ein Auto baut, du musst nur wissen, wie man eines fährt.
Also ja, sicher, all dieser Kram ist optional und es ist viel komplizierter, als Websites auf die alte Weise zu bauen. Wenn du dich einfach auf die Komplexität einlässt und diese neuen Werkzeuge nutzt, wirst du deine Arbeit viel schneller erledigen können, als wenn du sie nicht hättest.
Ein Hauptproblem (meiner Meinung nach) ist derzeit, dass die Leute die Werkzeuge, die sie verwenden, und ihre langfristigen Auswirkungen nicht verstehen.
Legacy-Systeme, die in einem Medium wie dem Web erstellt werden, sind so gut wie unvermeidlich, aber was wir jetzt sehen, ist, dass die Lebensdauer von etwas, das "Legacy" ist, etwa 3 Jahre beträgt – was lächerlich und ein Sinnbild für das größere Problem ist. Es ist noch gar nicht so lange her, da war Backbone "der heiße Scheiß" (sagen das Kinder noch, oder?), und jetzt, wenn du in diese Codebasis eintauchst, ist sie so gut wie ein Legacy-System.
Das Benutzerziel "Ich möchte einen Flug buchen" wird nicht von Angular, React, Ember, Backbone, Vue, Flight, Knockout oder (was auch immer) gelöst. Es *kann* sein... und in Situationen, in denen die Einsätze nicht sehr hoch sind, solltest du all die neuen Dinge ausprobieren, weil du sie wegwerfen oder neu konfigurieren kannst, aber in Risikosituationen, wenn das Leben und die Arbeitsplätze von Menschen an einem Produkt hängen, das in 3 Jahren "Legacy" sein wird, sollten wir zuverlässigere Technologien verwenden.
Ich glaube nicht, dass wir so schnell auf viele dieser neuen Systeme zurückgreifen würden, wenn wir uns Zeit nehmen würden, die potenziellen langfristigen Auswirkungen aus der Sicht von Produkt- und Personalmanagement zu überdenken.
Ich bin sicher, andere haben es hier gesagt (habe die meisten Kommentare nicht gelesen), aber das Problem ist nicht, dass wir mehr Werkzeuge haben, das Problem ist, dass die Leute nach diesen Werkzeugen greifen, wenn sie es nicht müssen.
Hört auf mit dem Wahnsinn, Leute! Benutzt die richtigen Werkzeuge für den richtigen Job.