Smashing Podcast Folge 21 mit Chris Ferdinandi: Sind moderne Best Practices schlecht für das Web?

Heute fragen wir uns, ob moderne Best Practices schlecht für das Web sind. Führen uns moderne Frameworks auf den falschen Weg? Ich habe mit dem Lean-Web-Experten Chris Ferdinandi gesprochen, um das herauszufinden.

Notizen anzeigen

• Chris' Seite mit Links und Hinweisen zum Podcast
• Das Lean-Web-Buch
• Chris Ferdinandi im Internet
• Chris auf Twitter
• Der Vanilla-JavaScript-Podcast

Wöchentliches Update

• „Design Wireframes in barrierefreies HTML/CSS übersetzen“
  von Harris Schneidermann
• „Desktop-Apps mit Electron und Vue erstellen“
  von Timi Omoyeni
• „Moderne CSS-Techniken zur Verbesserung der Lesbarkeit“
  von Edoardo Cavazza
• „So verwenden Sie gestylte Komponenten in React“
  von Adebiyi Adedotun Lukman
• „So erstellen Sie einen Porsche 911 mit Skizze“
  von Nikola Lazarevic

Abschrift

Drew McLellan: Er ist Autor der Vanilla JS Pocket Guide Series, Schöpfer des Vanilla JS Academy Training Program und Moderator des Vanilla JS Podcast. Er hat einen Tipps-Newsletter entwickelt, der jeden Wochentag von fast 10.000 Entwicklern gelesen wird. Er hat Entwickler bei Organisationen wie Chobani und The Boston Globe unterrichtet. Und seine JavaScript-Plugins wurden von Organisationen wie Apple und der Harvard Business School verwendet. Vor allem liebt er es, Menschen beim Erlernen von Vanilla JavaScript zu helfen. Wir wissen also, dass er Vanilla JavaScript einem Framework vorziehen würde, aber wussten Sie, dass er einmal in einer Polizeiaufstellung als die Person ausgewählt wurde, die am wenigsten wahrscheinlich das Verbrechen begangen hat? Meine Smashing-Freunde, bitte heißen Sie Chris Ferdinandi willkommen. Hallo Chris. Wie geht es dir?

Chris Ferdinandi: Oh, ich bin umwerfend. Danke für die Einladung.

Drew: Ich wollte heute mit Ihnen über dieses Konzept eines Lean Web sprechen, das für Sie so etwas wie eine Leidenschaft ist, nicht wahr?

Chris: Ja, sehr sogar.

Drew: Warum setzt du uns nicht in Szene? Wenn wir über ein Lean Web sprechen, welches Problem versuchen wir zu lösen?

Chris: Ja, gute Frage. Nur als Einschränkung für alle Zuhörer, diese Episode könnte einen kleinen alten Mann dazu bringen, Cloud anzuschreien. Ich werde versuchen, das zu vermeiden. Wenn ich mir ansehe, wie wir heute für das Web bauen, fühlt es sich ein bisschen wie ein aufgeblähtes, übertechnisiertes Durcheinander an. Ich bin zu der Überzeugung gelangt, dass vieles, was wir heute als Best Practices betrachten, das Web tatsächlich schlechter machen könnte.

Chris: Das Lean Web ist ein Ansatz für die Webentwicklung, der sich auf Einfachheit, Leistung und die Entwicklererfahrung konzentriert … Entschuldigung, nicht die Entwicklererfahrung. Eher die Benutzererfahrung als die Entwicklererfahrung und die Leichtigkeit, Dinge aus der Teamperspektive zu erstellen, worauf wir meiner Meinung nach heute viel Wert legen und auf die wir wahrscheinlich in unserem Gespräch eingehen werden.

Chris: Ich habe tatsächlich festgestellt, dass viele dieser Dinge, die wir als Verbesserung der Entwicklererfahrung betrachten, dies für eine Untergruppe von Entwicklern tun, aber nicht unbedingt für alle, die an dem arbeiten, was Sie bauen. Es gibt also auch eine ganze Reihe von Problemen, denen wir nachgehen können. Aber eigentlich geht es beim Lean Web darum, sich auf Einfachheit und Leistung für den Benutzer zu konzentrieren und wirklich Prioritäten zu setzen oder den Fokus auf die Menschen zu legen, die die von uns hergestellten Dinge verwenden, und nicht auf uns, die Menschen, die sie herstellen.

Drew: Während das Web als Entwicklungsplattform heranreift, scheint es diesen immer stärker werdenden Drang zur Spezialisierung zu geben.

Chris: Ja.

Drew: Leute, die früher Full Stack abgedeckt haben, und dann haben wir uns in Front-End und Back-End aufgeteilt. Und dann teilte sich dieses Front-End in Leute auf, die CSS- oder JavaScript-Entwicklung machen. Und innerhalb von JavaScript wird es dann zunehmend spezialisierter. Jemand könnte sich als React-Entwickler oder Angular-Entwickler betrachten und vermarkten, und seine gesamte Identität und Sichtweise basiert auf einem bestimmten Framework, in dem er hochqualifiziert ist. Ist diese Abhängigkeit von Frameworks, dem Kern unserer Arbeit im Web, Eine schlechte Sache?

Chris: Es ist nuanciert. Früher war ich sehr stark im Ja-immer-Lager. Ich denke, im Großen und Ganzen habe ich immer noch das Gefühl, ja, unsere Besessenheit als Branche von Frameworks und Tools im Allgemeinen ist möglicherweise ein wenig zu unserem Nachteil. Ich glaube nicht, dass Frameworks von Natur aus schlecht sind. Ich denke, sie sind für eine sehr enge Untergruppe von Anwendungsfällen nützlich. Und am Ende verwenden wir sie für fast alles, einschließlich vieler Situationen, in denen sie wirklich nicht unbedingt die beste Wahl für Sie oder das Projekt sind.

Chris: Wenn ich an viele der Probleme denke, die wir heute im Internet haben, beginnt der Kern dieser Probleme wirklich damit, dass wir uns zu sehr auf Frameworks verlassen. Alles andere, was danach kommt, ist in vielerlei Hinsicht so, weil wir so viel nicht nur Frameworks, das ist JavaScript im Allgemeinen, ins Web werfen. Ich sage das als jemand, der Menschen professionell beibringt, wie man JavaScript schreibt und verwendet. So verdiene ich mein Geld. Und ich sage hier, dass wir meiner Meinung nach zu viel JavaScript verwenden, was manchmal etwas seltsam ist.

Drew: In der Zeit, bevor die großen Frameworks aufkamen, haben wir Benutzeroberflächen und andere Dinge mit jQuery oder was auch immer erstellt. Und dann kamen Frameworks und sie gaben uns mehr von diesem Konzept einer zustandsbasierten Benutzeroberfläche.

Chris: Ja.

Drew: Nun, das ist ein ziemlich komplexes Stück Technik, das Sie an Ort und Stelle bringen müssen. Schließt die Arbeit mit weniger JavaScript aus, so etwas zu verwenden, oder müssen Sie es selbst neu implementieren? Erstellen Sie gerade eine geladene Boilerplate?

Chris: Vieles hängt davon ab, was man tut. Wenn Sie eine sich nicht ändernde Schnittstelle haben, können Sie eine zustandsbasierte Benutzeroberfläche mit … ich weiß nicht, vielleicht einem Dutzend oder so Codezeilen erstellen. Wenn Sie eine sich nicht ändernde Benutzeroberfläche haben, würde ich ehrlich gesagt wahrscheinlich eine zustandsbasierte Benutzeroberfläche sagen. Es ist nicht unbedingt der richtige Ansatz. Es gibt wahrscheinlich andere Dinge, die Sie stattdessen tun können. Denken Sie an statische Website-Generatoren, einige vorgerenderte Markups, sogar eine WordPress- oder PHP-gesteuerte Website der alten Schule.

Chris: Aber interessant wird es erst, wenn man sich mit dynamischeren und interaktiveren Interfaces beschäftigt. Nicht nur Apps. Ich weiß, dass die Leute es lieben, diese Grenze zwischen Websites und Apps zu ziehen, und ich denke, es gibt diese seltsame Mischung zwischen den beiden und die Grenze ist nicht immer so klar. Wenn Sie anfangen, sich mehr mit dem Benutzer zu befassen, ändert sich etwas. State-based UI wird etwas wichtiger. Aber Sie brauchen immer noch nicht jede Menge Code, um das zu erreichen.

Chris: Ich schaue mir so etwas wie React oder Vue an, die absolut erstaunliche Ingenieurskunst sind. Ich möchte den Leuten, die daran arbeiten, nichts wegnehmen. Ich endete als Lernübung und baute mein eigenes Mini-Framework, nur um ein besseres Gefühl dafür zu bekommen, wie diese Dinge unter der Haube funktionieren. Es ist wirklich schwierig, all die verschiedenen beweglichen Teile zu berücksichtigen. Daher habe ich großen Respekt vor den Menschen, die diese Tools entwickeln und daran arbeiten. Aber React und Vue sind beide etwa 30 Kilobyte nach dem Minimieren und Gzipping. Sobald Sie sie auspacken, sind sie also wesentlich größer.

Chris: Nicht alles, aber ein guter Teil dieses Gewichts wird diesem Ding gewidmet, das virtuelles DOM genannt wird. Es gibt Alternativen, die ähnliche APIs oder Ansätze verwenden. Für React haben Sie Preact, das 2,5 Kilobyte oder etwa 3 Kilobyte statt 30 umfasst. Es ist ein Zehntel der Größe. Für Vue haben Sie stattdessen Alpine JS, das ungefähr 7 Kilobyte groß ist. Trotzdem deutlich kleiner. Der große Unterschied zwischen diesen und ihren großen Brüdern besteht darin, dass sie das virtuelle DOM abgelegt haben. Sie können eine oder zwei Methoden fallen lassen. Aber im Allgemeinen ist es der gleiche Ansatz und die gleiche Art von API bei der Arbeit mit Code, und sie sind wesentlich kleiner.

Chris: Ich denke, viele der Tools, die wir verwenden, sind für die Dinge, die wir versuchen zu tun, möglicherweise überfordert. Wenn Sie eine zustandsbasierte Benutzeroberfläche und reaktive Daten und diese dynamischen Schnittstellen benötigen, ist das großartig. Ich denke, eines der großen Dinge, über die ich heute zu sprechen versuche, ist nicht … niemals Werkzeuge zu verwenden. Für mich bedeutet Vanilla JS nicht, dass Sie jede einzelne Codezeile und jedes einzelne Projekt, das Sie durchführen, von Hand schreiben. Das ist Wahnsinn. Das könnte ich nicht, das mache ich nicht. Aber es geht darum, selektiver mit den Tools umzugehen, die wir verwenden. Wir entscheiden uns immer für das Multitool, das Schweizer Taschenmesser, das all diese Dinge in sich hat. Und manchmal braucht man wirklich nur eine Schere. All die anderen Sachen braucht man nicht, aber wir haben sie trotzdem.

Chris: Was ein wirklich langer Weg ist, um … Es tut mir leid, dass ich deine Frage beantworte. Das heißt, manchmal ist es mehr Code, als Sie selbst schreiben könnten oder wollen, aber es ist nicht annähernd so viel Code, wie ich denke, dass es erforderlich ist. Wenn ich sage, dass Sie kein Framework brauchen, bekomme ich viel Gegenwind für diese Idee: „Nun, wenn Sie kein Framework verwenden, schreiben Sie im Grunde Ihr eigenes.“ Das bringt dann seine eigenen Probleme mit sich. Ich denke, es gibt einen Platz zwischen der Verwendung von React oder Vue und dem Schreiben Ihres eigenen Frameworks, und es geht vielleicht darum, etwas Kleineres auszuwählen. Es gibt manchmal Gründe, warum das Schreiben eines eigenen Frameworks tatsächlich der richtige Weg sein könnte, je nachdem, was Sie zu tun versuchen. Es ist alles sehr flüssig und subjektiv.

Drew: Es ist ziemlich interessant, dass Sie als Lernübung Ihr eigenes zustandsbasiertes Framework implementiert haben. Ich erinnere mich, dass ich früher dachte, dass ich jedes Mal, wenn ich nach einer Bibliothek oder so griff, gerne dachte, dass ich es selbst implementieren könnte.

Chris: Sicher, sicher.

Drew: Aber die Suche nach der Bibliothek hat mir den Aufwand erspart. Ich wusste, wenn ich diesen Code selbst schreiben müsste, wusste ich, welchen Ansatz ich dafür wählen würde. Und das galt bis hin zur Verwendung von Dingen wie jQuery und so. Wenn ich heutzutage meine eigene Version von Vue oder React schreiben müsste, hätte ich fast keine Ahnung, was jetzt in dieser Bibliothek passiert, in all diesem Code.

Drew: Für diejenigen von uns, die nicht vertraut sind, wenn Sie sagen, dass Preact das virtuelle DOM fallen lässt und alles viel kleiner macht, was gibt uns dieses virtuelle DOM?

Chris: Um diese Frage zu beantworten, möchte ich nur einen kleinen Schritt zurücktreten. Eines der besten Dinge, die Ihnen Frameworks und andere zustandsbasierte Bibliotheken bieten, ist DOM-Diffing. Wenn Sie die Benutzeroberfläche nicht wirklich sehr aktualisieren, könnten Sie damit auskommen, zu sagen: „Hier ist eine Zeichenfolge, wie das Markup aussehen soll. In HTML füge ich einfach all dieses Markup in dieses Element ein.“ Wenn Sie etwas ändern müssen, tun Sie es erneut. Das ist etwas teuer für Browser, weil es ein Repaint auslöst.

Chris: Aber ich denke, möglicherweise noch wichtiger ist, dass eines der Probleme dabei ist, dass Sie irgendeine Art von interaktivem Element darin haben, ein Formularfeld, einen Link, auf den sich jemand konzentriert hat. Dieser Fokus geht verloren, weil das Element … obwohl Sie ein neues Ding haben, das ähnlich aussieht, ist es nicht dasselbe buchstäbliche Element. Wenn also der Fokus verloren geht, kann dies bei Benutzern von Screenreadern zu Verwirrung führen. Es gibt nur eine ganze Reihe von Problemen damit.

Chris: Jedes zustandsbasierte UI-Ding, das sein Gewicht wert ist, wird einige DOM-Unterschiede implementieren, bei denen es heißt: „So sollte die UI aussehen. So sieht es jetzt im DOM aus. Was ist unterschiedlich?" Und es wird gehen und diese Dinge ändern. Es erledigt effektiv die Dinge, die Sie tun würden, indem Sie die Benutzeroberfläche selbst manuell aktualisieren, aber es erledigt es für Sie unter der Haube. Sie können also einfach sagen: „So soll es aussehen.“ Und dann findet die Bibliothek oder das Framework es heraus.

Chris: Die kleineren Dinge wie Preact oder Alpine machen das eigentlich direkt. Sie konvertieren die Zeichenfolge, die Sie ihnen mitteilen, wie die Benutzeroberfläche aussehen soll, in HTML-Elemente. Und dann vergleichen sie jedes Element mit seinem entsprechenden Teil im wörtlichen DOM. Wenn die Benutzeroberflächen immer größer und größer werden, kann dies Auswirkungen auf die Leistung haben, da das ständige Abfragen des DOM teuer wird. Wenn Sie ein Gefühl für die Art der Schnittstelle bekommen möchten, bei der dies zu einem Problem wird, klicken Sie mit der rechten Maustaste und überprüfen Sie das Element auf der Schaltfläche „Favoriten“ auf Twitter oder der Schaltfläche „Gefällt mir“ auf Facebook. Und werfen Sie einen Blick auf die Verschachtelung von divs, die Sie zu diesem Element bringt. Es ist sehr, sehr tief. Es ist wie etwa ein Dutzend Divs, die nur für diesen einen Tweet ineinander verschachtelt sind.

Chris: Wenn Sie anfangen, so viele Ebenen nach unten zu gehen, wirkt sich das wirklich auf die Leistung aus. Das virtuelle DOM überprüft nicht jedes Mal das echte DOM, sondern erstellt eine objektbasierte Karte, wie die Benutzeroberfläche in JavaScript aussieht. Und macht dann dasselbe für die Benutzeroberfläche, durch die Sie die vorhandene ersetzen möchten, und vergleicht diese beiden. Theoretisch ist das viel mehr Leistung als im echten DOM. Sobald es eine Liste der Dinge erhält, die geändert werden müssen, läuft es einfach los und nimmt diese Änderungen vor. Aber es muss das DOM nur einmal angreifen. Es wird nicht jedes einzelne Element jedes Mal überprüft. Wenn Sie Schnittstellen wie Twitter oder Facebook oder QuickBooks oder ähnliches haben, ist virtuelles DOM wahrscheinlich sehr sinnvoll.

Chris: Die Herausforderung dabei ist… der Unterschied zwischen Preact und React beträgt 27 Kilobyte, bevor man das Ganze in seine eigentliche Codewave entpackt. Allein die reine Download- und Entpackungs- und Kompilierungszeit kann das anfängliche Laden auf einer Benutzeroberfläche erheblich verzögern. Das wird noch deutlicher, wenn Ihre Benutzer nicht die neuesten Geräte von Apple verwenden. Sogar ein Android-Gerät von vor ein paar Jahren oder ein Feature-Phone oder wenn Sie Leute in Entwicklungsländern haben, es ist einfach wirklich … die Zeit, um loszulegen, ist langsamer. Und obendrein ist die tatsächliche interaktive Zeit aufgrund der zusätzlichen Abstraktion langsamer.

Chris: Du lädst es also nicht nur und sie sind in der Geschwindigkeit vergleichbar. Jede Mikrointeraktion, die jemand vornimmt, und die erforderlichen Änderungen können auch etwas langsamer sein, nur weil all der zusätzliche Code darin enthalten ist. Wenn Sie eine sehr, sehr komplexe Benutzeroberfläche mit vielen verschachtelten Elementen und vielen Daten haben, überwiegen die Leistungssteigerungen des virtuellen DOM dieses zusätzliche Codegewicht. Aber jede typische Benutzeroberfläche für eine typische App, für die die meisten Entwickler React oder Vue verwenden, ist der Vorteil, den Sie aus dem virtuellen DOM ziehen, einfach nicht da und sie wären besser dran. Auch wenn Sie den gleichen Komfort von React beibehalten möchten, verwenden Sie Preact. Es ist nur ein Bruchteil der Größe, funktioniert genauso und ist leistungsstärker. Das ist die Art von Sache, für die ich tendenziell argumentiere.

Chris: Wir müssen besser darin sein, das richtige Werkzeug für den Job auszuwählen. Wenn Sie sich für einen solchen Ansatz entscheiden und an einem Punkt angelangt sind, an dem ein virtuelles DOM tatsächlich Sinn macht, ist es viel einfacher, Preact in React zu portieren, als wenn Sie Ihr eigenes rollen würden. Das ist die Situation. Wenn Sie sich darüber wirklich Sorgen machen, erhalten Sie auch eine eingebaute Zukunftssicherheit.

Drew: Einige mögen sagen, sie könnten argumentieren, dass diese Frameworks, Dinge wie Vue, React, so stark auf Leistung optimiert sind, dass Sie dort so viele Vorteile haben, dass Sie dies sicherlich nur mit einem Paketmanager in einem Bundler kombinieren müssen, um sicherzustellen, dass Sie Senden Sie nur den Code, den Sie möchten. Damit sind Sie doch sicher schon weit voraus?

Chris: Ja. Ich bin nicht einverstanden. Ich habe nicht wirklich viel mehr darüber zu erzählen, außer… Ich schätze, vielleicht, aber nicht wirklich. Selbst mit einem Bundler benötigen Sie immer noch diesen React-Kern. Selbst mit der Bündelung wird das immer noch größer sein als die Verwendung von etwas wie Preact.

Chris: Drew, ich weiß es wirklich zu schätzen, dass du die Frage dazu gestellt hast. Denn eines der anderen Dinge, über die ich in meinem Buch The Lean Web und meinem gleichnamigen Vortrag spreche, ist, wie diese Tools … Sie haben zum Beispiel die Bündelung erwähnt. Eines der Dinge, die wir tun, um den Leistungseinbruch zu umgehen, den wir durch die Verwendung von all diesem JavaScript erleiden, ist, dass wir noch mehr JavaScript auf das Front-End werfen, um dies zu berücksichtigen. Eine Möglichkeit, dies zu tun, sind Paketmanager und Modulbündler.

Chris: Wie Sie schon angedeutet haben … für diejenigen unter Ihnen, die es nicht wissen, sind dies Tools, die … alle Ihre kleinen individuellen JavaScript-Bits in eine große Datei kompilieren. Die neueren und die mehr… Ich möchte sie nicht als nachdenklich bezeichnen. Die neueren verwenden jedoch eine Funktion namens Tree Shaking, bei der sie Code entfernen, der nicht wirklich benötigt wird. Wenn dieser Code einige Abhängigkeiten hat, die für das, was Sie tatsächlich getan haben, nicht verwendet werden, werden einige dieser Dinge weggelassen, um Ihre Pakete so klein wie möglich zu machen. Es ist eigentlich keine schlechte Idee, aber es führt zu dieser Sache, die ich normalerweise Abhängigkeitsgesundheit nenne, wo Sie dieses wirklich heikle Kartenhaus von Abhängigkeiten über Abhängigkeiten über Abhängigkeiten haben.

Chris: Die Einrichtung Ihres Prozesses braucht Zeit. Und jeder, der jemals eine NPM-Installation ausgeführt und dann festgestellt hat, dass eine Reihe von Abhängigkeiten veraltet waren, und eine Stunde damit verbringen musste, herauszufinden, welche repariert werden mussten, und oh, es ist tatsächlich eine Abhängigkeit in einer Abhängigkeit, und Sie ziehen es an nicht die Möglichkeit haben, es selbst zu reparieren. Es ist eine ganze Sache. Vielleicht funktioniert es für Sie, aber ich würde meine Zeit lieber damit verbringen, nicht herumzuspielen und zu versuchen, meine Abhängigkeiten zusammenzubringen.

Chris: Ich habe angefangen, Tweets von Leuten zu sammeln, in denen sie sich über Zeitverschwendung bei ihrem Arbeitsablauf beschweren. Einer meiner Favoriten, Brad Frost, sprach vor ein paar Jahren über die deprimierende Erkenntnis, dass das, was Sie in modernem JS durchgepflügt haben, Sie in jQuery 10 Minuten hätte brauchen können. Ich bin nicht wirklich ein jQuery-Fan, aber ich fühle diesen Schmerz, wenn es um die Arbeit mit Frameworks geht.

Chris: Das andere Problem bei vielen dieser Tools ist, dass sie anfangen, zu Gatekeepern zu werden. Ich weiß nicht, wie sehr du wirklich darauf eingehen willst oder nicht, Drew. Aber einer meiner großen Push-Backs gegen JS, all die Dinge in einem Workflow. Vor allem, wenn Sie dann anfangen zu sagen: „Nun, wenn wir JS bereits für HTML verwenden, warum verwenden Sie es dann nicht auch für CSS?“ Sie fangen an, viele wirklich talentierte Leute aus dem Entwicklungsprozess auszuschließen. Es ist einfach ein wirklich großer Verlust für das Projekt und für die Gemeinschaft als Ganzes.

Drew: Nun, das bin ich auf jeden Fall … Ich habe Anfang 2020 angefangen, React zu lernen und es zu meinen Fähigkeiten hinzuzufügen. Ich mache das jetzt seit fast sieben Monaten. Ich muss sagen, ein Teil, in dem ich am wenigsten zuversichtlich bin, ist das Einrichten der Werkzeuge, um ein Projekt zu starten.

Drew: Es scheint, als gäbe es eine Menge Arbeit, um etwas zu Hello World zu bringen, und es gibt noch mehr, was man wissen muss, um es produktionsreif zu machen. Das muss den Einstieg in die Entwicklung erschweren, wenn dies als das vorgeschlagen wird, was Sie im Jahr 2020 tun sollten, um Webentwickler zu werden. Jemand, der neu dazukommt, wird ein echtes Problem haben. Es wird eine echte Eintrittsbarriere sein, nicht wahr?

Chris: Absolut. Der andere Teil hier ist, dass JavaScript-Entwickler nicht immer die einzigen Personen sind, die an einer Codebasis arbeiten oder auf sinnvolle Weise zu dieser Codebasis beitragen. Je mehr wir JavaScript-Kenntnisse zur Voraussetzung für die Arbeit mit einer Codebasis machen, desto unwahrscheinlicher ist es, dass diese Personen tatsächlich an dem Projekt teilnehmen können.

Chris: Ein Beispiel dafür, über das ich gerne spreche, ist WordPress, das seit kurzem … ich sollte an dieser Stelle nicht sagen, vor kurzem. Es ist jetzt ein paar Jahre her. Aber sie haben ihren Back-End-Stack immer mehr auf JavaScript verlagert, weg von PHP, was an sich keine schlechte Sache ist. Ihr neuer Editor, Gutenburg, basiert auf React.

Chris: Im Jahr 2018 trat Rian Rietveld, die führende Beraterin für Barrierefreiheit von WordPress, deren Namen ich mit ziemlicher Sicherheit niedergemetzelt habe, sehr öffentlich von ihrer Position zurück und dokumentierte in einem wirklich ausführlichen Artikel, warum. Der Kern des Problems bestand darin, dass sie und ihr Team damit beauftragt wurden, diesen Editor zu prüfen, um sicherzustellen, dass er zugänglich sein würde. WordPress umfasst jetzt 30% des Webs. Ihr Ziel ist es, das Publizieren zu demokratisieren, daher ist Barrierefreiheit ein wirklich wichtiger Teil davon. Es sollte ein wichtiger Bestandteil eines jeden Webprojekts sein. Aber gerade für sie ist es akut wichtig. Die ganze Aufgabe ihres Teams bestand darin, dafür zu sorgen … die ganze Aufgabe ihres Teams bestand darin, dafür zu sorgen, dass dieser Editor zugänglich ist. Aber weil weder sie noch irgendjemand in ihrem Team React-Erfahrung hatte und weil sie in der Barrierefreiheits-Community keine Freiwilligen mit dieser Erfahrung finden konnten, machte es ihr und ihrem Team wirklich schwer, ihre Arbeit zu erledigen.

Chris: Früher konnten sie Fehler identifizieren und sie dann beheben. Aber mit dem neuen React-basierten Workflow wurden sie darauf reduziert, Fehler zu identifizieren und dann Tickets einzureichen. Sie wurden zusammen mit all den anderen Funktionsentwicklungsanfragen, an denen die JavaScript-Entwickler arbeiteten, zu einem Rückstand hinzugefügt. Eine Menge Dinge, die leicht hätten behoben werden können, schafften es nicht in die erste Version.

Chris: Im Mai 2019, etwa ein Jahr nach dem Rücktritt von Rian, wurde Gutenburg einer detaillierten Prüfung der Barrierefreiheit unterzogen. Der vollständige Bericht umfasste 329 Seiten. Allein die Zusammenfassung umfasste 34 Seiten. Es dokumentiert 91 Fehler im Zusammenhang mit der Barrierefreiheit ziemlich detailliert. Viele davon waren wirklich … ich möchte sie nicht als einfache, niedrig hängende Früchte bezeichnen, aber viele von ihnen waren grundlegende Dinge, die Rians Team hätte beheben können, und es hätte die Entwickler befreit, sich auf die Entwicklung von Funktionen zu konzentrieren. Letztendlich scheint es so, als hätten sie viel Zeit mit der Entwicklung von Funktionen verbracht und diese Dinge auf später verschoben. Aber dieses Team ist für das Projekt sehr wichtig und wurde plötzlich wegen einer technischen Entscheidung aus dem Prozess ausgeschlossen.

Chris: Alex Russell ist Entwickler im Chrome-Team. Er schrieb vor ein paar Jahren diesen Artikel mit dem Titel The Developer Bait and Switch, in dem er über das Strohmann-Argument von Frameworks sprach. Diese Idee, dass Sie mit diesen Tools schneller vorankommen und dadurch schneller iterieren und bessere Erfahrungen liefern können. Es ist diese Idee, dass eine bessere Entwicklererfahrung eine bessere Benutzererfahrung bedeutet. Ich denke, dies ist ein sehr deutliches Beispiel dafür, dass dieses Argument nicht immer so funktioniert, wie die Leute glauben, dass es funktioniert. Es ist vielleicht für manche Menschen eine bessere Erfahrung, nicht für alle.

Chris: CSS-Entwickler, Menschen, die an Designsystemen arbeiten, ihre Fähigkeit, Tools zu erstellen, die andere verwenden können, wird manchmal auch durch diese Tool-Auswahl eingeschränkt. Meiner Erfahrung nach war ich früher besser in CSS. Es hat sich in den letzten Jahren sehr verändert und ich bin bei weitem nicht mehr so ​​gut wie früher. Meiner Erfahrung nach sind das Leute, die wirklich fortgeschrittene CSS-Entwickler sind… und das meine ich im wahrsten Sinne des Wortes. Menschen, die an CSS arbeiten, sind richtige Webentwickler, die an einer Programmiersprache arbeiten. Es ist etwas ganz Besonderes oder kann etwas ganz Besonderes sein. Die Leute, die darin außergewöhnlich gut sind, sind meiner Erfahrung nach nicht immer auch sehr gut in JavaScript, weil man am Ende wirklich tief in eine Sache eintaucht und bei anderen Sachen ein bisschen abrutscht. Ihre Fähigkeit, mit diesen Technologien zu arbeiten, wird ebenfalls behindert, was schade ist, da dies früher nicht der Fall war.

Chris: Als der Stack einfacher war, war es einfacher für Menschen aus mehreren Disziplinen, am Entwicklungsprozess teilzunehmen. Ich denke, das schadet sowohl den Dingen, die wir bauen, als auch der Community insgesamt, wenn das nicht mehr der Fall ist.

Drew: Ich habe kürzlich in einem Projekt nach Wegen gesucht, um mit einigen der CSS-Probleme umzugehen, Workflow-Probleme, wir haben mehrere Arbeiten an dem Projekt und die Bundle-Größe nimmt zu und das alte CSS wird nie entfernt. Es war ein React-Projekt, also haben wir uns einige dieser CSS-in-JavaScript-Ansätze angesehen, um zu sehen, was für uns am besten wäre, um die Probleme zu lösen, die wir hatten. Sehr schnell wurde klar, dass es dafür nicht nur eine Lösung gibt. Es gibt Dutzende von verschiedenen Möglichkeiten, wie Sie dies tun können.

Drew: CSS in JS ist ein allgemeiner Ansatz, aber man kann von einem Projekt zum nächsten gehen und es wird auf ganz andere Weise komplett beeinflusst. Selbst wenn Sie ein CSS-Experte sind und einen bestimmten Ansatz für ein Projekt lernen, sind diese Fähigkeiten möglicherweise sowieso nicht übertragbar. Es ist sehr schwer zu verstehen, wie jemand zu viel Zeit investieren sollte, um das zu lernen, wenn er mit JavaScript nicht besonders vertraut ist.

Chris: Ja. Die andere interessante Sache, die Sie meiner Meinung nach gerade ein wenig herausgefunden haben, ist, wenn ich darüber spreche, ist einer der größten Widerstände, die ich bekomme, dass Frameworks Konventionen erzwingen. Du arbeitest mit Vanilla JavaScript, du hast dieses grüne Feld, blauer Himmel, du kannst alles machen, was du willst, Art von Projekt. Mit React gibt es einen React-Weg, Dinge zu tun.

Chris: Aber eines der Dinge, die ich herausgefunden habe, ist, dass es Reacty-Ansätze gibt, aber es gibt keinen strikt richtigen Weg, Dinge mit React zu tun. Es ist eines der Dinge, die die Leute daran lieben. Es ist ein bisschen flexibler, Sie können die Dinge auf verschiedene Arten tun, wenn Sie möchten. Dasselbe gilt für Vue. Sie können dieses HTML-basierte Ding verwenden, bei dem Sie Ihre Eigenschaften direkt im HTML-Code haben und Vue sie ersetzt, aber Sie können auch eine eher JSX-ähnliche Vorlagensyntax verwenden, wenn Sie dies bevorzugen.

Chris: Ich habe gehört, dass sich mehrere Leute beschweren, wenn sie React lernen, eines der großen Probleme ist, dass Sie googeln, wie man X in React macht, und Sie erhalten ein Dutzend Artikel, in denen Ihnen ein Dutzend verschiedene Möglichkeiten beschrieben werden, wie Sie das tun können. Das heißt nicht, dass sie einem Projekt keine Leitplanken auferlegen. Ich denke nicht, dass es so eindeutig ist wie: „Ich habe einen Rahmen gewählt. So baue ich jetzt damit.“ Ehrlich gesagt weiß ich auch nicht, ob ich das unbedingt haben möchte. Ich glaube nicht, dass Sie diese eng eingesperrt haben wollen … manche Leute wollen das vielleicht. Aber wenn Sie das als Vorteil anpreisen, denke ich, dass es nicht ganz so ausgeprägt ist, wie die Leute es manchmal darstellen.

Chris: Sie sind jedoch gerade dort auf eine interessante Sache gestoßen, als Sie das CSS erwähnt haben, das nicht mehr benötigt wird. Ich denke, das ist eines der recht interessanten Dinge, die etwas wie CSS und JS… oder das Binden Ihres CSS an JavaScript-Komponenten auf irgendeine Weise bringen kann, wenn diese Komponente ausfällt, verschwindet das CSS theoretisch auch damit. Vieles davon fühlt sich für mich so an, als würde man die Technik auf die Probleme der Menschen werfen. Ausnahmslos sind Sie immer noch von Menschen irgendwo entlang der Linie abhängig. Das heißt nicht, dass Sie diese Ansätze niemals verwenden sollten, aber sie sind sicherlich nicht der einzige Weg, um dieses Problem zu lösen.

Chris: Es gibt Tools, die Sie verwenden können, um Ihren HTML-Code zu überprüfen und Stile herauszufiltern, die nicht verwendet werden, auch ohne Verwendung von CSS und JavaScript. Sie können CSS „auf die altmodische Art“ schreiben und trotzdem ungenutzte Stile linten. Es gibt Authoring-Ansätze für CSS, die Ihnen ein CSS in JS-ähnlicher Ausgabe liefern und Ihr Stylesheet klein halten, ohne diese unverständlichen, für Menschen unlesbaren Klassennamen auszuspucken, die Sie manchmal mit CSS und JS erhalten. Wie X2354ABC oder einfach diese unsinnigen Worte, die ausgespuckt werden.

Chris: Hier fange ich an, mich wirklich auf das Geschrei des alten Mannes in der Cloud einzulassen. Ich zeige hier wirklich mein Entwickleralter. Aber ja, es ist nicht unbedingt so, dass diese Dinge schlecht sind, und sie wurden gebaut, um legitime Probleme zu lösen. Ich habe manchmal das Gefühl, dass da ein bisschen … wenn es gut genug für Facebook ist, ist es gut genug für uns, was mit diesen passiert. Nun, Facebook verwendet dieses Tool. Wenn wir ein echtes Engineering-Programm sind … Team, Abteilung, Organisation, dann sollten wir das auch. Ich glaube nicht unbedingt, dass das der richtige Weg ist, darüber nachzudenken. Das liegt daran, dass Facebook sich mit Problemen befasst, die Sie nicht haben, und umgekehrt. Die Größe und der Umfang dessen, woran sie arbeiten, ist einfach anders, und das ist in Ordnung.

Draw: Genau. Ich sehe einige dieser Dinge wie CSS und JavaScript fast wie Polyfill. Wir haben legitime Probleme, wir brauchen einen Weg, sie zu lösen. Die Technologie bietet uns noch keine Möglichkeit, es zu lösen. Während wir darauf warten, dass sich die Webplattform weiterentwickelt und dieses Problem angeht, wird uns vielleicht diese Sache, die wir jetzt mit JavaScript machen, irgendwie durchstehen und wir werden in Ordnung sein. Wir wissen, dass es schlecht ist. Wir wissen, dass es keine großartige Lösung ist, aber es hilft uns gerade jetzt. Und hoffentlich können wir es in der Zwischenzeit herausziehen und die native Lösung verwenden.

Chris: Es ist wirklich lustig, dass du das ansprichst. Denn buchstäblich letzte Nacht habe ich mir einen Vortrag von Jeremy Keith aus dem letzten Jahr über progressive Web-Apps angesehen. Aber er sprach darüber, wie er vor ein paar Jahrzehnten versuchte, die Leute davon zu überzeugen, JavaScript zu verwenden. Was damals lächerlich erscheint, aber JavaScript war dieses neue Ding. Er zeigte den Leuten, wie man mit diesem neuen coole Dinge machen kann, wie zum Beispiel die Farbe eines Links beim Hover ändern… Es scheint absurd, dass Sie dafür jetzt JavaScript brauchen würden, denn das ist es, was CSS für Sie erledigt. Aber Dinge wie das Fokusattribut oder die Eigenschaft existierten damals einfach nicht.

Chris: Eines der Dinge, die er in seinem Vortrag gesagt hat und von denen ich glaube, dass sie wirklich bei mir angekommen sind, ist, dass JavaScript in vielerlei Hinsicht diese Kuhpfade ebnet. Es ist diese sehr flexible und offene Sprache, die wir verwenden können, um Funktionen zu erstellen oder einzufügen, die noch nicht existieren. Und schließlich holen die Browser auf und implementieren diese Funktionen auf nativere Weise. Aber es braucht Zeit. Ich verstehe vollkommen, was Sie dazu sagen. Es ist nicht die perfekte Lösung, aber es ist das, was wir gerade haben.

Chris: Ich denke, für mich besteht der größte Unterschied zwischen Polyfills und einigen dieser Lösungen darin, dass Polyfills so konzipiert sind, dass sie herausgerissen werden können. Wenn ich ein Feature implementieren möchte, das der Browser noch nicht unterstützt, aber es eine Art Spezifikation dafür gibt und ich eine Polyfill schreibe … sobald die Browser aufholen, kann ich diese Polyfill herausreißen, ohne dass ich das tun muss etwas ändern. Aber wenn Sie einige dieser Tools verwenden, bedeutet das Herausreißen, dass Sie Ihre gesamte Codebasis neu schreiben. Das ist sehr teuer und problematisch. Das heißt nicht, dass Sie sie niemals verwenden sollten, aber ich bin der festen Überzeugung, dass wir uns Gedanken über die Auswahl von Werkzeugen machen sollten, die später leicht herausgezogen werden können. Wenn wir sie nicht mehr brauchen oder die Plattform aufholt, bedarf es keiner großen Umschreibung, um sie herauszuziehen.

Chris: Um das zu erreichen, haben wir eine ganze Reihe von Stilen, die wir nicht mehr verwenden. Deshalb würde ich persönlich eine Build-Tool-Technologie bevorzugen, die Ihr CSS gegen das gerenderte Markup prüft und die Dinge herauszieht, die Sie nicht benötigen. Denn wenn später eine Plattform aufholt, können Sie diesen Teil des Bauwerkzeugs herausziehen, ohne alles ändern zu müssen. Es erweitert nur das, was Sie bereits haben, während CSS und JS Ihnen nicht die gleichen Vorteile bieten. Ich nehme nur das heraus, aber ich denke viel breiter über viele dieser Technologien nach.

Chris: Ich habe das Gefühl, dass Dinge wie React oder Vue wahrscheinlich einige Kuhpfade ebnen, die Browser irgendwann einholen und wahrscheinlich ähnliche Ansätze verwenden werden, wenn nicht die gleichen, sodass dort möglicherweise weniger Umschreibungen erforderlich sind. Viele der Ökosystem-Sachen, die daran angeschlossen werden, sind möglicherweise weniger wichtig.

Drew: Ich finde es richtig, dass sich die Webplattform langsam und vorsichtig bewegt. Sie denken, wenn wir vor fünf Jahren alle JavaScript-Karussells auf unseren Seiten platziert hätten. Sie waren überall. Jeder implementierte JavaScript-Karussells. Wenn die Webplattform gesprungen wäre und eine Karussell-Lösung implementiert hätte, um diesen Bedarf zu decken, würde sie nicht dort sitzen und niemand würde sie benutzen, weil die Leute das nicht mehr mit Karussells machen. Weil es nur eine Modeerscheinung war, ein Designtrend. Um dem entgegenzuwirken und zu verhindern, dass die Plattform selbst aufgebläht und zu einem Problem wird, das gelöst werden muss, muss sie sich in einem viel gleichmäßigeren Tempo bewegen. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it's related to the framework conversation. But it's the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you're getting all this benefit because you're not reloading the entire page framework. I feel like they don't always make good on those performance promises. Würden Sie dem zustimmen?

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don't think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who's unfamiliar with those. When a single-page app, instead of having separate HTML files or if you're using something like a database driven site like WordPress, even though you don't have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That's what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don't have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that's slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they're not confused about where they are or what's going on. Because they can't see the change that's happening, they're hearing it announced. If you don't actually shift focus anywhere, that announcement doesn't happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don't necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website's being built, it doesn't always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you're going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it's not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it's being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. Absolut. Absolut. One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that's already there. So there's no reloading, they don't lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It's again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you'd have just a rectangle embedded in an HTML page which is your Flash Player, and you'd build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we're putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn't exist, I spell article like arcitle instead of article and the browser runs across that, it's going to be like, “Oh, I don't know what this is. Whatever, I'll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let's say I forget the B in bold, so I write old instead, font way old. The browser's going to be, “I don't know what this is. Whatever, we'll just keep going.” Your thing won't be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn't exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn't complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn't work at all.

Chris: There's an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don't disable it and most people are using devices that can actually handle modern JavaScript. That's true, but that's not the only reason why JavaScript doesn't work right, even if you have a linter there for example and you catch bugs ahead of time and things. There's plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we're recording this… a bad deploy took down Cloudflare. Interestingly as we're recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They're an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you'd like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn't part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone's in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it's probably even more now. That's a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There's just all sorts of reasons why JavaScript can fail and when it does, it's so catastrophic.

Chris: And so we built this web that should be faster than ever. It's 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn't have to be that way.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I've hammered on this a couple times. I'm not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn't mean obsolete. It doesn't mean never embrace new stuff, but don't be so quick to just jump on all the shiny new stuff just because it's there. I know it's one of the things that keeps this industry really exciting and makes it fun to work in, there's always something new to learn. But when you pick these new things, do it because it's the right tool for the job and not just because it's the shiny new thing.

Chris: Eines der anderen Dinge, auf die wir nicht so viel eingegangen sind, wie ich es mir gewünscht hätte, aber ich denke, dass es wirklich wichtig ist, ist, dass die Plattform in den letzten Jahren sehr stark aufgeholt hat. Wenn Sie dies so weit wie möglich annehmen, wird dies zu einem Web-Erlebnis für Menschen führen, das schneller, weniger anfällig und für Sie einfacher zu erstellen und zu warten ist, da weniger Abhängigkeiten erforderlich sind, z. B. die Verwendung dessen, was der Browser Ihnen bietet -die Kiste. Früher brauchten wir jQuery, um Dinge wie Klassen auszuwählen. Jetzt haben Browser native Möglichkeiten, dies zu tun. Leute mögen JSX, weil es Ihnen ermöglicht, HTML in JavaScript nahtloser zu schreiben. Aber wir haben auch Template-Literale in Vanilla JavaScript, die Ihnen die gleiche Leichtigkeit ohne die zusätzliche Abhängigkeit bieten. HTML selbst kann jetzt viele Dinge ersetzen, die früher JavaScript erforderten, was absolut erstaunlich ist.

Chris: Wir haben ein bisschen darüber gesprochen … das ist eine CSS-Sache, aber Hover über Links und wie das früher JavaScript erforderte. Aber mit Elementen wie den Details und Zusammenfassungselementen können Sie Offenlegungen wie Erweitern und Reduzieren oder Akkordeonelemente nativ erstellen, ohne dass Skripte erforderlich sind. Sie können Eingaben automatisch vervollständigen, indem Sie einfach ein ... Ich sollte nicht einfach sagen, ich hasse dieses Wort. Verwenden Sie jedoch ein bescheidenes Eingabeelement und dann ein Datenlistenelement, das mit einigen Optionen verknüpft wird. Wenn Sie neugierig sind, wie irgendetwas von diesem Zeug auf vanillajstoolkit.com funktioniert, habe ich eine Menge JavaScript-Zeug, das Ihnen die Plattform bietet. Aber ich habe auch einige, die früher JavaScript erforderten, und jetzt keine Dinge, die auch interessant sein könnten, wenn Sie einige Codebeispiele dazu haben möchten.

Chris: Auf der CSS-Seite ist mein beliebtestes Vanilla JS-Plugin aller Zeiten diese Bibliothek, mit der Sie das Herunterscrollen zu Ankerlinks animieren können. Es ist sehr groß. Es ist das schwierigste Stück Code, das ich je schreiben musste. Und es ist jetzt komplett durch eine einzige CSS-Zeile ersetzt, das Scrollverhalten ist glatt. Es ist leistungsfähiger. Es ist einfacher zu schreiben. Es ist einfacher, sein Verhalten zu ändern. Es ist einfach eine bessere Gesamtlösung.

Chris: Eines der anderen Dinge, von denen ich mir wünschte, wir würden mehr tun, ist, sich auf mehrseitige Apps zu stützen. Ich fühle mich hier ein wenig bestätigt, weil ich kürzlich einen Artikel von jemandem bei Google gesehen habe, der diesen Ansatz tatsächlich auch jetzt vorantreibt. Ich fand das ziemlich interessant, angesichts dieses riesigen eckigen und dann Rahmens … all die Dinge, Boom, die Google vor ein paar Jahren begonnen hat. Irgendwie cool zu sehen, dass sie darauf zurückkommen. Mit Dingen wie statischen Website-Generatoren und großartigen Diensten wie Netlify und CDN-Caching können Sie unglaublich schnelle Web-Erlebnisse für Menschen erstellen, die individuelle HTML-Dateien für all Ihre verschiedenen Ansichten verwenden. Man stützt sich also irgendwie auf etwas von diesem Out-of-the-Box-Zeug.

Chris: In Situationen, in denen das für Sie nicht realistisch ist, in denen Sie mehr JavaScript benötigen, benötigen Sie eine Art Bibliothek, vielleicht zuerst einen Blick auf die kleineren und modulareren Ansätze werfen, anstatt nur auf die Giganten der Branche zu setzen. Würde Preact anstelle von React funktionieren? Anstelle von eckig … ich meine, statt Vue eher, würde Alpine JS funktionieren? Es gibt auch diesen wirklich interessanten Pre-Compiler namens Svelt, der Ihnen ein Framework-ähnliches Erlebnis bietet und dann Ihren gesamten Code in Vanilla JavaScript kompiliert. Sie erhalten also diese wirklich winzigen Bündel, die genau das haben, was Sie brauchen, und sonst nichts. Könnten Sie anstelle von CSS und JavaScript einen CSS-Linter eines Drittanbieters einfügen, der Ihren HTML-Code mit Ihrem CSS vergleicht und das Zeug herausholt, das versehentlich dort zurückgelassen wurde? Würde eine andere Art der CSS-Erstellung, wie objektorientiertes CSS von Nicole Sullivan, stattdessen funktionieren? Wir haben nicht wirklich darüber gesprochen, aber es ist eine wirklich coole Sache, die sich die Leute ansehen sollten.

Chris: Und dann denke ich, dass der vielleicht dritte und wichtigste Teil hier, obwohl es weniger ein spezifischer Ansatz ist und mehr nur eine Sache ist, von der ich wünschte, dass mehr Leute sie im Hinterkopf behalten, ist, dass das Web für alle da ist. Viele der Tools, die wir heute verwenden, funktionieren für Menschen mit guten Internetverbindungen und leistungsstarken Geräten. Aber sie funktionieren nicht für Leute, die auf älteren Geräten sind und lückenhafte Internetverbindungen haben. Dies sind nicht nur Menschen in Entwicklungsgebieten. Dies gilt auch für Menschen in Großbritannien, in bestimmten Teilen der USA, wo wir absolut miserable Internetverbindungen haben. Die Mitte unseres Landes hat sehr langsames Internet. Ich weiß, dass es in Teilen von London Orte gibt, an denen aus historischen Gründen kein neues Breitbandkabel angeschlossen werden kann, also bleiben Ihnen diese alten Internetverbindungen, die wirklich schlecht sind. Solche Orte gibt es auf der ganzen Welt. Als ich das letzte Mal in Italien war, war es dasselbe. Das Internet dort war schrecklich. Ich weiß nicht, ob es sich seitdem geändert hat.

Chris: Die Dinge, die wir heute bauen, funktionieren nicht immer für alle, und das ist schade. Denn die Vision des Webs, die ich daran liebe, ist, dass es eine Plattform für absolut jeden ist.

Drew: Wenn Zuhörer mehr über diesen Ansatz erfahren möchten, sind Sie in Ihrem Buch „The Lean Web“ ausführlich darauf eingegangen. Und das ist online verfügbar. Ist es ein physisches Buch oder ein digitales Buch?

Chris: Es ist ein bisschen von beidem. Nun, nein. Es ist definitiv kein physisches Buch. Sie gehen zu leanweb.dev. Sie können das Ganze kostenlos online lesen. Sie können auch, wenn Sie wollen, es gibt EPUB- und PDF-Versionen für einen wirklich kleinen Geldbetrag, ich habe jetzt vergessen, wie viel. Ich habe es mir eine Weile nicht angeschaut. Das Ganze ist kostenlos online, wenn Sie es wollen. Sie können sich auch einen Vortrag zu diesem Thema ansehen, in dem ich auf mehr Details eingehe, wenn Sie möchten.

Chris: Aber ich habe auch eine spezielle Seite nur für Zuhörer des Smashing Podcast unter gomakethings.com/smashingpodcast zusammengestellt, weil ich bei der Benennung von Dingen sehr kreativ bin. Dazu gehört neben dem Buch eine Reihe von Ressourcen zu Dingen, über die wir heute gesprochen haben. Es enthält Links zu vielen der verschiedenen Techniken, die wir behandelt haben, und zu anderen Artikeln, die ich geschrieben habe, die tiefer auf einige dieser Themen eingehen und meine Gedanken ein wenig erweitern. Wenn die Leute mehr lernen wollen, wäre das wahrscheinlich der beste Ausgangspunkt.

Drew: Das ist großartig. Danke. Ich habe alles über das Lean Web gelernt. Was hast du in letzter Zeit gelernt, Chris?

Chris: Ja, ein paar Dinge. Ich habe etwas früher darauf angespielt, als ich mir Jeremys Video zu progressiven Web-Apps ansah. Ich habe es ein paar Jahre lang hinausgezögert, zu lernen, wie man meine eigene progressive Web-App schreibt, weil ich für nichts, womit ich arbeitete, einen bestimmten Bedarf hatte. Ich habe kürzlich von einem meiner Schüler in Südafrika erfahren, dass sie wegen irgendwelcher Dinge, die dort unten vor sich gehen, mit Stromausfällen zu kämpfen haben. Infolgedessen kann sie einige der Projekte, die wir regelmäßig zusammen durchführen, nicht bearbeiten, weil der Strom ausfällt und sie nicht auf das Lernportal zugreifen und mitmachen kann.

Chris: Für mich hat jetzt der Aufbau einer Erfahrung, bei der es funktioniert, auch wenn jemand kein Internet hat, eine höhere Priorität als … Mir wurde klar, dass es vielleicht früher so war, also habe ich einfach angefangen, mich damit zu beschäftigen und hoffe, dass ich das zusammenfügen kann die nächsten Wochen. Wir werden sehen. Jeremy Keiths Ressourcen zu diesem Thema waren jedoch ein absoluter Lebensretter. Ich bin froh, dass es sie gibt.

Chris: Ich weiß, Drew, du hast erwähnt, dass einer der Gründe, warum du diese Frage gerne stellst, darin besteht, zu zeigen, dass Menschen, egal wie erfahren sie sind, immer lernen. Nur eine kleine verwandte Anekdote. Ich bin, glaube ich, seit ungefähr acht Jahren als Webentwickler tätig. Ich muss immer noch die CSS-Eigenschaft googeln, um Dinge kursiv zu machen, buchstäblich jedes Mal, wenn ich sie verwende. Aus irgendeinem Grund verwendet mein Gehirn standardmäßig die Textdekoration, obwohl das nicht die richtige ist. Ich probiere ein paar Kombinationen verschiedener Dinge aus, und jedes Mal mache ich immer ein Wort falsch. Ich schreibe auch manchmal kursiv statt kursiv. Ja. Wenn irgendjemand jemals das Gefühl hat, oh, ich werde dieses Zeug nie lernen … sei dir einfach bewusst, dass es immer etwas wirklich Grundlegendes gibt, das du immer und immer wieder googelst, egal wie erfahren du bist.

Drew: Ich bin seit 22, 23 Jahren Webentwickler und muss immer noch jedes Mal die verschiedenen Eigenschaften für Flexbox googeln. Obwohl ich das seit 23 Jahren benutze. Aber ja, einige Dinge sind einfach … es werden wahrscheinlich mehr davon, wenn ich älter werde.

Chris: Ja. Ehrlich gesagt habe ich am Ende eine ganze Website mit Sachen erstellt, die ich immer und immer wieder gegoogelt habe, nur um eine einfachere Referenz zum Kopieren und Einfügen zu haben, weil das einfacher war als Googeln.

Drew: Das ist keine schlechte Idee.

Chris: So faul bin ich. Ich baue eine ganze Website, um mir drei Sekunden Googlen zu sparen.

Drew: Wenn Sie als Zuhörer mehr von Chris hören möchten, finden Sie sein Buch im Internet unter leanweb.dev und seinen Entwicklertipps-Newsletter und mehr unter gomakethings.com. Chris ist auf Twitter unter Chris Ferdinandi. Und Sie können sich seinen Podcast auf vanillajspodcast.com oder wo auch immer Sie Ihre Podcasts normalerweise erhalten, ansehen. Danke, dass du heute dabei bist, Chris. Hast du Abschiedsworte?

Chris: Nein. Vielen Dank, dass du mich eingeladen hast, Drew. Ich hatte eine absolut tolle Zeit. Das hat jede Menge Spaß gemacht. Ich schätze die Gelegenheit zum Plaudern sehr.