Smashing Podcast Folge 45 mit Jeremy Wagner: Was ist verantwortungsvolles JavaScript?

Diese Episode wurde freundlicherweise von unseren lieben Freunden bei Wix unterstützt, der Plattform für Fachleute, um Kundenseiten zu erstellen, komplexe Projekte zu verwalten und Unternehmen online auszubauen. Danke!

In dieser Folge sprechen wir über verantwortungsvolles JavaScript. Was bedeutet es, dass Code verantwortlich ist, und wie sollten wir Projekte anders angehen? Ich habe mit dem Experten Jeremy Wagner gesprochen, um das herauszufinden.

Notizen anzeigen

• Verantwortliche JavaScript-Website
• Kaufen Sie das Buch von A Book Apart
• Jeremys persönliche Website
• Jeremy auf Twitter

Wöchentliches Update

• Fitts' Law In The Touch Era geschrieben von Steven Hoober
• Webdesign gut gemacht: Perfectly Pointless geschrieben von Frederick O'Brien
• Alles, was Sie über die Erstellung von Sprachbenutzeroberflächen wissen möchten, geschrieben von Nick Babich & Gleb Kuznetsov
• Auswirkungen des Beitritts von WordPress zum Blockprotokoll, geschrieben von Leonardo Losoviz
• Gedanken zu Markdown, geschrieben von Knut Melvar

Abschrift

Drew McLellan: Er ist technischer Redakteur, Web-Performance-Nerd, Entwickler und Redner und arbeitet derzeit bei Google. Er hat für A List Apart, CSS-Tricks und das Smashing Magazine geschrieben und ist Autor eines neuen Titels, Responsible JavaScript for A Book Apart. Wir wissen also, dass er ein erfahrener Techniker und Kommunikator ist, aber wussten Sie, dass er die Welt auf einem Standup-Paddle-Board umrunden möchte? Meine großartigen Freunde, bitte heißen Sie Jeremy Wagner willkommen. Hallo Jeremy, wie geht es dir?

Jeremy Wagner: Ich bin der Hammer. Wie geht es dir?

Drew: Mir geht es sehr gut. Danke. Ich wollte heute mit Ihnen über diese Idee von Responsible JavaScript sprechen. Ist dies eine Art neuer Ansatz oder Technik, oder sprechen Sie buchstäblich über den verantwortungsvollen Umgang mit JavaScript?

Jeremy: Ich spreche buchstäblich über den verantwortungsvollen Umgang mit JavaScript. Laut HTTP-Archiv haben wir im letzten Jahr also einen durchschnittlichen Anstieg der von Mobilgeräten heruntergeladenen JavaScript-Menge um fast 58 % von etwa 290 Kilobyte auf fast 500 Kilobyte festgestellt.

Drew: Wow.

Jeremy: Wenn ich also über den verantwortungsvollen Umgang mit JavaScript spreche, ist es eine Art Benutzer-zuerst-Ansatz, um zu sagen … kritisch zu bewerten, was wir bauen und was das Ziel dessen ist, was wir bauen, das von modernen Webentwicklungspraktiken unterstützt wird, also sprechen. Und ich denke, das ist irgendwie … vielleicht nicht ironisch, aber ich habe mich nicht mit moderner Webentwicklung beschäftigt, aber ein Nebenprodukt der modernen Webentwicklung ist, dass es sehr einfach ist, Abhängigkeiten zu Projekten hinzuzufügen. Alles ist eine MPM-Installation entfernt und jede MPM-Installation hat Kosten, die variieren. Aber was wir sehen, ist, dass in diesen HTTP-Archivdaten das 95. Perzentil … das heißt die 5 % der Erfahrungen, die am langsamsten sind … oder nicht am langsamsten sind, aber das meiste JavaScript liefern, das im letzten Jahr um etwa 875 gestiegen ist Kilobyte auf etwa 1,4 Megabyte.

Drew: Wow.

Jeremy: Es ist also eine enorme Menge an JavaScript, die übertragen wird, und dies wirkt sich sowohl auf die Ladeleistung als auch auf die Laufzeitleistung aus.

Drew: Du hast da also Leistung erwähnt. Es scheint, als ob die moderne Weberfahrung aus meiner Sicht zu 10 % aus HTML und CSS und zu 90 % aus JavaScript besteht. Und es muss eine Art Leistungsüberlegung dazu geben. Ich meine, Sie haben über die Menge an Daten gesprochen, die wir übertragen, aber es gibt noch andere Überlegungen zur Leistung, wenn Sie viel JavaScript verwenden.

Jeremy: Richtig. Wenn Sie also eine langsame Internetverbindung haben und wissen Sie … wo ich in den Vereinigten Staaten lebe, wird es, wenn Sie weit genug außerhalb einer Großstadt gehen, ziemlich schwierig, je nachdem, wohin Sie gehen … damit fertig zu werden, wie langsam das Internet sein kann eine Art dieser ländlichen Gebiete und ist bedeutend für die Menschen, die in solchen Gebieten leben. Und so ist der Aspekt der Ladeleistung bereits herausfordernd genug, wenn Sie anfangen, Megabytes an JavaScript zu versenden, aber Sie haben es vielleicht auch mit jemandem zu tun, der kein iPhone hat … wie ein iPhone X oder wie ein iPhone 13.

Jeremy: Sie sind vielleicht nur auf einem Feature-Phone oder einfach wie ein preisgünstiges Android-Handy und versuchen einfach, durch das Leben zu navigieren. Ich meine, denken Sie an Dinge wie Online-Banking, Arbeitslosenhilfe oder andere staatliche Hilfen, Portale wie dieses für Bewerbungen. Online-Lernen, es gibt nur viele Orte, an denen übermäßiges JavaScript wirklich nachteilige Auswirkungen auf Menschen haben kann, die möglicherweise nicht das Glück haben, in großen Ballungsräumen oder sogar in Ballungsräumen zu leben, die nicht gut mit Breitband-Internet versorgt werden, und die langsamere Geräte verwenden . Ich denke, als Entwickler haben wir diese Tendenz zu betrachten … wir kaufen MacBooks oder diese High-End-Geräte, und wir sehen manchmal nicht wirklich, wo diese Probleme auftreten können, wenn wir JavaScript überbeanspruchen.

Drew: Und so wie Sie es dort erwähnt haben, sind es manchmal die Personen, die am meisten zu verlieren haben, wenn sie keinen Zugang zu einem Dienst haben, die durch solche Dinge bestraft werden. Diese Menschen ohne schnelle Datenverbindungen oder ohne sehr leistungsfähige Geräte greifen manchmal auf Dienste zu, die ihnen alles bedeuten… es bedeutet ihnen alles, dass sie Zugang erhalten können. So wird es in gewisser Weise fast zu einer Menschenrechtsfrage.

Jeremy: Ja. Ich meine, wir neigen dazu zu sehen, dass die Webleistung in Bezug auf den Geschäftswert eingerahmt wird. Ich war Leistungsberater für ein E-Com und wie ein großes Lebensmittelunternehmen, ein großes E-Com … wie ein Geschäft, wie ein Elektronikgeschäft, und es ist sehr verlockend, das zu tun, oder? Denn wenn Sie für ein Unternehmen arbeiten, möchten Sie natürlich, dass die Finanzen gesund sind, und die Webleistung spielt dabei eine Rolle, denke ich. Ich denke, es gibt eine Reihe von Fallstudien, die das belegen. Es gibt jedoch diesen menschlichen Aspekt und sogar für Unternehmen, wie zum Beispiel Lebensmittelgeschäfte und dergleichen. Ja, sie sind umsatzgesteuert. Sie möchten gesunde Finanzen haben, und die Webleistung ist ein Teil davon, aber sie bedienen auch ein wichtiges Bedürfnis, oder? Als müsste man essen, oder?

Jeremy: Und wie manche Menschen aus dem einen oder anderen Grund nach Hause gefesselt sein könnten. Sie können möglicherweise nicht einfach in ein Auto steigen. Sie haben vielleicht kein Auto. Sie verlassen sich also auf diese Dienste, um Nahrung zu bekommen, aber mehr noch, Hilfe, wenn sie sie brauchen, und vor allem mögen sie Krisenintervention und solche Dinge. Ich denke nicht, dass es sehr weit hergeholt ist zu sagen, dass ein Partner, der missbraucht und aus seinem Haus geworfen wurde, sich an sein Smartphone wenden und auf Google suchen könnte, um zu versuchen, ein Portal für Krisenintervention und -hilfe zu finden. Und JavaScript kann solchen Zielen im Wege stehen und diesen menschlichen Bedürfnissen dienen. Wenn wir dazu neigen, uns ein bisschen zu sehr darauf zu stützen.

Drew: Ich meine, wir haben, wir haben in den letzten 18 Monaten oder so eine Art Vorgeschmack davon gesehen, als COVID und Menschen in Isolation gingen und, wie Sie sagten, Lebensmittel bestellen mussten, die geliefert werden sollten. Das Web wird an diesem Punkt zu einer Lebensader für sie. Sie fühlen sich angeschlagen, können ihre Unterkunft nicht verlassen, weil sie isoliert sind und Essen und lebenswichtige Vorräte besorgen müssen. Also ja, es ist ein immer wichtiger werdender Teil des alltäglichen Lebens für uns alle, denke ich.

Jeremy: Genau. Und um auf die Art von Gerätegeschichte zurückzukommen, Tim Kadlec hat vor ein paar Jahren einen erstaunlichen Artikel geschrieben, ich glaube, es war zwei Jahre, vielleicht drei Jahre her, aber es hieß Prioritizing the Long Tail of Performance. Und wenn Sie sich das ansehen … also sprechen wir im Web-Performance-Jargon über Labordaten im Vergleich zu Felddaten. Und Labordaten sind so, als ob Sie Lighthouse betreiben oder eine Website einem Webseitentest unterziehen, um zu sehen, wie es läuft. Das sind alles wirklich nützliche Tools, aber wenn Sie sich diese Felddaten ansehen, erhalten Sie wirklich ein größeres Bild und einen größeren Überblick darüber, wer Ihre Zielgruppe wirklich ist. Und in diesem Artikel spricht Tim Kadlec darüber, was es bedeutet, dem Long-Tail der Leistung Priorität einzuräumen. Gemeint sind all diese Geräte, die … vielleicht nicht so kräftig und leistungsfähig sind wie die Geräte, die wir als Entwickler haben.

Jeremy: Und die Idee hinter diesem Artikel ist, dass wir, wenn wir uns auf das 90. oder 95. Perzentil konzentrieren können, das wir sind … und diese Erfahrung für diese Leute verbessern, wir ein schnelleres Web für alle aufbauen, einschließlich derer auf schnellen Geräten. Und greifen Sie einen Datenpunkt in den USA an und das ist nur von statcounter.com. Etwa 28 Punkte … rund 28 % der Menschen verwenden ein iOS-Gerät, das dieses Tool erfasst. Und rund 21 % davon sind Android. Und Android stellt in der Regel einen guten Teil dieser langen Gerätekette dar, da Android nicht monolithisch ist. Mehrere Gerätehersteller stellen Android-Telefone her, aber um das irgendwie mit der Welt zu vergleichen, denn die Welt besteht aus mehr als nur den Vereinigten Staaten, es sind etwa 16 % der Menschen, die iOS verwenden, und etwa 41 % der Menschen, die Android verwenden. Es zahlt sich also wirklich aus, diese langsameren oder potenziell langsameren Erfahrungen zu priorisieren.

Drew: Ich habe in Ihrem Buch über die thermische Drosselung von Geräten gelesen, was ich vorher nicht wirklich in Betracht gezogen hatte. Welche Bedenken gibt es dort?

Jeremy: Die Bedenken dort, und ich bin keineswegs ein Experte für Mikroprozessoren. Ich bin nur der Webentwickler, der wahrscheinlich etwas zu viel schreibt, aber … die Idee hinter der thermischen Drosselung und die existiert in allen Systemen, nicht nur in Telefonen und Tablets, ist, dass ein Mikroprozessor … wenn er übermäßige Arbeitslasten übernimmt oder wirklich nur Arbeitslasten im Allgemeinen, das Abfallprodukt dieser Arbeit ist Wärme. Und so haben Geräte Möglichkeiten, dies zu mildern. So wie Ihr Laptop sowohl über ein passives als auch über ein aktives Kühlgerät verfügt.

Jeremy: Ein passives Kühlgerät ist also wie ein Kühlkörper oder eine Art Wärmeverteiler. Und der aktive Teil davon ist wie ein Lüfter, um die Wärme effizienter zu verteilen. Einige wie benutzerdefinierte PC-Builds verwenden möglicherweise eine Flüssigkeitskühlung, was ein relativ extremeres Beispiel ist, aber ein Mobiltelefon hat das nicht, denn wo werden Sie wirklich einen Lüfter in all das einbauen, wenn Portabilität etwas von Ihnen ist Sache, oder?

Jeremy: Damit diese Geräte diese hohen Arbeitslasten bewältigen können, können sie die Geschwindigkeit des Prozessors künstlich reduzieren, z. B. die Taktrate reduzieren, bis das Gerät in einen Zustand eintritt, in dem diese Taktrate erhöht werden kann. Und das hat Auswirkungen, denn wenn Sie Tonnen und Tonnen und Tonnen und Tonnen von JavaScript durchkauen, kommen diese großen Brocken durch die Leitung, nun, das startet die Verarbeitung, richtig? Es ist also eine Menge Verarbeitung durch Auswertung und Analyse bei der Kompilierung und dann Ausführung. Und wenn Sie das mit etwa ein oder zwei Megabyte JavaScript machen und viele andere Prozesse im Hintergrund laufen, wie verschiedene Registerkarten, solche Dinge, die Ihren Status anzeigen können ... das erhöht die Wahrscheinlichkeit, dass Das Gerät kann in einen thermisch gedrosselten Zustand übergehen, was bedeutet, dass es weniger in der Lage ist, diese zusätzliche Arbeit zu übernehmen.

Drew: Es ist also eine Art negative Rückkopplungsschleife. Ist es nicht? Sie geben dem Gerät viel Arbeit. Es wird sehr heiß und ist dann weniger in der Lage, diese Arbeit tatsächlich auszuführen, weil es drosseln muss.

Jeremy: Richtig. Und noch einmal, ich bin kein Mikroprozessor-Experte. Ich bin sicher, wenn, wenn, wenn ein Ingenieur, der damit wirklich vertraut ist, mich in einigen Einzelheiten korrigieren könnte, aber die allgemeine Idee ist, dass das Gerät mit zunehmendem Umgebungsdruck weniger dazu in der Lage ist Bewältigen Sie diese hohen Arbeitsbelastungen, bis dieser Druck nachlässt.

Drew: Also schreiben wir JavaScript für das gesamte Spektrum an Geräten, vom neuesten Apple M1 Max ist der neue Prozessor, nicht wahr? Laptops bis hin zu Geräten, die kaum genug Arbeitsspeicher haben, um eine Webseite zu rendern. Aber das Web hat nicht so angefangen, jüngere Zuhörer könnten interessiert sein zu erfahren, dass wir früher interaktive Web-Erlebnisse ganz ohne JavaScript erstellt haben. Unser großes, schweres Gerüst wird uns zum Verhängnis werden.

Jeremy: Ich würde sagen, dass Frameworks eine Zeit und einen Ort haben, und diejenigen, die Auszüge aus diesem Buch lesen, könnten auf die Idee kommen, dass ich gegen Frameworks bin. Und ich stehe einigen Frameworks definitiv kritisch gegenüber, aber sie erfüllen einen Zweck und es ist möglich, sie so zu verwenden, dass eine gute Benutzererfahrung erhalten bleibt oder zu einer guten Benutzererfahrung führen kann. Aber was wir meiner Meinung nach nicht genug tun, ist, diese Frameworks dahingehend kritisch zu bewerten, wie sie der Laufzeitleistung schaden, richtig? Also die Art von Dingen, von denen ich spreche, wo, wenn Sie auf eine Schaltfläche klicken, und das Gerät etwa eine Sekunde oder zwei braucht, um auf diese Eingabe zu reagieren, weil im Hintergrund so viel los ist. Sie haben JavaScript-Sachen von Drittanbietern wie das Sammeln von Analysen und dann haben Sie andere Dinge, die in Threads ausgeführt werden.

Jeremy: Und dass Sie, wenn Sie die Laufzeitleistung eines Frameworks nicht kritisch bewerten, möglicherweise einige Möglichkeiten ungenutzt lassen, um Ihren Benutzern einen besseren Service zu bieten. Ein gutes Beispiel, das ich immer gerne verwende, ist Reagieren versus Vorhandeln. Ich schlage schon seit einiger Zeit auf diese Trommel. Ich habe vor einiger Zeit einen Artikel für CSS-Tricks geschrieben, in dem eine grundlegende Klick-Interaktion für ein mobiles Navigationsmenü profiliert wurde. Und es klingt trivial, aber was Sie feststellen, ist, dass React auf allen Geräten eine bessere Laufzeitleistung liefert, aber im Grunde die gleiche API hat. Es gibt Unterschiede, es gibt ein paar kleine Unterschiede und Dinge, die mit Pre-Act Compat überspielt werden können, aber so einfach … und ich sollte nicht sagen, eine einfache Wahl, aber diese Wahl, diese grundlegende Wahl kann den Unterschied zwischen einer Erfahrung ausmachen das für alle Benutzer oder zumindest die meisten Benutzer wirklich gut funktioniert, oder eine Erfahrung, die nur für einige gut funktioniert. Hoffentlich hat das etwas Sinn gemacht.]

Drew: Ich meine, mit all den Frameworks und Build-Tools scheinen sie immer besser darin zu werden, Dinge wie Tree Shaking zu tun und die Bundles zu optimieren, die sie versenden und wie sie dann an den Browser geliefert werden. Gibt es bei der Verwendung großer Frameworks Ihrer Meinung nach einen Wendepunkt, an dem Sie eine so große Anwendung schreiben, so viel eigenen Code, dass das Framework es Ihnen ermöglicht, aufgrund seiner Abstraktion weniger Code zu versenden?

Jeremy: Das ist eine schwierig zu beantwortende Frage. Ein Aspekt davon ist, dass das Framework selbst eine Menge an Code darstellt, die Sie niemals wegoptimieren können. So ein dünnes Gerüst zu haben, wie Pre-Act oder eine beliebige Anzahl von Ähnlichem… Oder wie zum Beispiel Zaubersprüche, das hilft sehr. Aber das Problem, das ich gesehen habe, und ich denke, die Daten aus dem HTTP-Archiv unterstützen diesen Punkt, ist, dass es scheint, dass wir immer dann, wenn diese Fortschritte bei Mikroprozessoren und Netzwerken schneller werden, dazu neigen, diesen Gewinn zu verbrauchen, richtig?

Jeremy: Wir neigen dazu, auf dieser Tretmühle zu sein, wo wir nie wirklich vorankommen. Und ich weiß nicht, als wäre ich kein Hellseher, was die Geschichte von … oder sorry, wie die Zukunft von Frameworks aussieht. Ich bin mir sicher, dass sich einige Effizienzgewinne erzielen lassen. Aber was wir im Feld sehen, wie viel rohes JavaScript ist … es wird nur die rohe Menge an JavaScript verwendet. Sagt mir nicht, dass dies ein Problem ist, aus dem wir uns irgendwie automatisieren können. Ich denke, wir müssen … wir müssen Menschen sein und eingreifen und Entscheidungen treffen, die im besten Interesse der Benutzer sind. Ansonsten sehe ich nicht, dass wir aus dieser Tretmühle herauskommen, vielleicht nicht in meiner Karriere, aber ich weiß es nicht.

Drew: In dem Buch sprichst du über Websites und Web-Apps und wie das Verständnis des Unterschieds und welche, mit der du arbeitest, dir hilft, deine Strategie für die Entwicklung und Optimierung auszuwählen. Erzählen Sie uns etwas darüber.

Jeremy: Das ist eine wirklich gute Frage. Und ich schreibe darüber in dem gleichnamigen Artikel namens Responsible JavaScript Part One, den ich für A List Apart geschrieben habe und der eine Art Auftakt zu diesem Buch ist. Ist das, dass wir eine Menge in diese Terminologie laden? Als technischer Redakteur sehe ich, dass die beiden irgendwie austauschbar verwendet werden. Was ich sehe, ist bei Websites, die Implikation ist, dass es sich um eine Art Multi-Age-Erfahrung handelt, richtig? Es ist eine Sammlung von Dokumenten. Jetzt ein Dokument … diese Dokumente können eingebettete Funktionen wie diese kleinen Inseln haben, wie der Begriff in letzter Zeit so hieß, diese kleinen Inseln der Funktionalität, die es den Menschen ermöglichen, Dinge zu erledigen.

Jeremy: Aber dann gibt es solche Web-Apps, und Web-Apps haben diese Konnotation von nativer App-ähnlicher Funktionalität. Wir sprechen also über Single-Page-Anwendungen, wir sprechen über große Mengen an JavaScript, um komplexe Interaktivität zu fördern. Und es gibt Zeiten, in denen das Web-App-Modell sinnvoll ist. Spotify ist zum Beispiel ein gutes Beispiel dafür. Das funktioniert besser als Web-App. Sie würden nicht wirklich versuchen wollen, dies zu verwenden oder als mehrseitige Anwendung zu entwerfen. Wie eine traditionelle Website, aber ich denke, es ist kein nachhaltiger Standard, denn wenn Ihr Standard für jedes Projekt lautet: „Nun, alles, was wir brauchen, ist eine Single-Page-Anwendung, wie einen clientseitigen Router und ein schweres Framework, und alles auszulagern dieser Verarbeitung des Renderns vom Server auf den Client.“ Ich denke, da kommt man an einen Punkt, an dem man Nutzer ausschließt, wenn auch unbeabsichtigt, aber dennoch.

Drew: Gibt es Ihrer Meinung nach eine große Kluft zwischen den Leuten, die den Ansatz verfolgen, dass wir eine Website veröffentlichen werden und sie möglicherweise interaktive Funktionen hat, und denen, die sagen: „Wir sind ein Softwareunternehmen, das sind wir Wir entwickeln ein Produkt, ein Softwareprodukt und unsere Plattform, über die wir es bereitstellen werden, über das Web und nicht über native Anwendungen für mehrere Plattformen.“ Ist es wahrscheinlich, dass sie das Problem auf völlig unterschiedliche Weise angehen? Sind die Überlegungen je nach Ihrem Ausblick zu diesem Zeitpunkt unterschiedlich?

Jeremy: Das ist eine schwierige Frage. Damit-

Drew: Es war schwer für mich zu sagen.

Jeremy: Ich würde sagen, dass ein Unternehmen, das … also ein gutes Beispiel wäre, wie eine Nachricht wäre, oder? Sie sind mit der Art von Website-Modell gut bedient, weil es buchstäblich eine Sammlung von Dokumenten und Artikeln ist. Und die Leute, die diese Erfahrungen entwickeln, werden wahrscheinlich andere Fähigkeiten haben als beispielsweise ein Unternehmen wie Spotify oder ein Unternehmen, das eine große Webanwendung wie Envision oder ähnliches hat. Und ja, ich denke, sie werden das aus verschiedenen Blickwinkeln angehen. So wie ich es sehe, gibt es ein Segment … oder zumindest habe ich die Webentwicklungsgemeinschaft insgesamt so wahrgenommen, dass es ein Segment von Leuten gibt, von Webentwicklern, die aus der nicht-traditionellen Softwareentwicklung kommen Hintergründe, oder? Und ich bin einer dieser Leute, ich habe am Internet herumgebastelt, als ich noch wie ein Kind war, richtig?

Jeremy: Wie in der Mittelschule und das Erstellen von dummen Fanseiten für alle, wie die Videospiele damals, die ich wirklich mochte. Und ich hatte nie eine solche Informatikausbildung. Es gibt Informatikkonzepte, die ich auf dem Weg aufgeschnappt habe. Dann gibt es noch ein Segment von Entwicklern, insbesondere die, glaube ich, die in den letzten fünf bis zehn Jahren dazugekommen sind, die das eher informatikorientiert angehen. Und ich denke, das wird … diese Unterschiede und Erfahrungen dazu führen, dass jede dieser Gruppen ihre eigenen Schlussfolgerungen darüber zieht, wie sie am besten für das Web entwickeln. Aber ich denke, der einzige Weg, wie Sie wirklich … nachhaltig für das Web entwickeln können, besteht darin, kritisch zu bewerten, was Sie bauen, und zu versuchen, sich an einem Ansatz auszurichten, der den Benutzern dieser Produkte am besten dient. Und das ist sozusagen der Ort, an dem die Website und die Web-App-Modelle in meinem Kopf sitzen, wenn ich diese Dinge bewerte.

Drew: Ja. Es ist interessant. Ich meine, in dem Buch zitieren Sie tatsächlich einige meiner Arbeiten. Danke sehr. Und meine Wahl langweiliger Technologien auf im Grunde bemerktem PHP Apache und einer Prise handgerolltem JavaScript kann standardmäßig eine sehr flinke Benutzererfahrung schaffen, ohne dass eine besondere Optimierung vorgenommen werden muss. Ich denke, das sorgt für eine großartige Benutzererfahrung für die Front-End-Besucher, die kommen und Inhalte auf der Website ansehen.

Drew: Aber eigentlich habe ich das Gefühl, dass diese Umgebung zum Verfassen von Inhalten eine Art Kehrseite ist, sobald Sie eingeloggt sind und Ihre Inhalte auf der Website veröffentlichen. Ich denke, es leidet ein wenig darunter, dass es mit einem Website-Ansatz erstellt wurde und nicht mit einem JavaScript-lastigen Web-App-Ansatz, so sehr, dass ich denke ... oder vielleicht muss es beides sein. Ich muss das Frontend weiterhin in schönem statischem HTML und CSS und winzigen Stückchen JavaScript veröffentlichen. Aber für das Backend, in dem ich Inhalte erstellen möchte, wäre vielleicht eine andere Technologie besser. Ganz interessant, weil es nicht immer das eine oder das andere sein muss, oder? Es ist keine binäre Wahl. Es ist eher ein Spektrum, würden Sie sagen?

Jeremy: Ja, absolut. Und ich denke, wir beginnen, in der Community mehr Diskussionen darüber zu sehen, dass die Webentwicklung ein solches Spektrum ist. Um einfach für Leute zu sein, die an meinem Buch interessiert sein könnten, es kommt definitiv von der Website-Seite des Spektrums. Und wieder, weil ich das Gefühl habe, dass das immer wie ein guter Standard ist. Wenn Sie nicht wissen, wie Sie etwas erstellen möchten, ist es wahrscheinlich am besten, es auf eine Weise zu erstellen, die die Verwendung von JavaScript minimiert und minimiert, dass mehr Arbeit auf den Client übertragen wird. Das heißt, ich denke, dass bemerkt ist eine ausgezeichnete Erfahrung. Ich denke, dass diese abgenutzten und irgendwie wirklich „langweiligen“ Technologien wirklich gut für die anstehende Aufgabe funktionieren. Und es tut dies auf eine Art und Weise, die für den Entwickler wie offen und befähigend ist, richtig?

Jeremy: Sie müssen nicht so tiefgehende Kenntnisse haben wie… über State-Management-Stores oder State-Management-Frameworks, um diese Art von Dingen wirklich durchzuziehen. Und ich denke, dass dies mit diesem speziellen Ansatz gut gedient ist. Aber zu Ihrem Punkt, ich denke, es gibt auf jeder Website Möglichkeiten, sich näher an die Mitte des Spektrums zu bewegen, ohne sich auf das gesamte clientseitige Routing einzulassen, wie schwere Frameworks, die alles auf dem Client und dergleichen verwalten. Ich denke, der Ansatz der Insel beginnt zu erforschen, wie das aussieht. Und ich gebe zu, ich habe wahrscheinlich unabsichtlich etwas von dem Insel-Ding gemacht. Ich denke, das haben wir schon eine ganze Weile, wir haben uns nur noch nicht wirklich einen Namen dafür gemacht. Aber ich denke, jetzt, wo wir das als vielleicht einen Mittelpunkt identifiziert haben, könnten wir anfangen, Web-Erlebnisse zu sehen, die eine gute Benutzererfahrung bieten, aber immer noch interaktiver sind. Hoffentlich war das nicht schrecklich mäandrierend.

Drew: Es erinnert ein bisschen an die Tage zurück, als wir eine Insel aus Flash eingebettet haben oder -

Jeremy: Ja.

Drew: Irgendwas auf einer Seite, wo das unser kleiner interaktiver Bereich ist, und der Rest davon fließt irgendwie herum.

Jeremy: Ja, wie Flash, oh mein Gott, drei Iterationen meines persönlichen Portfolios nach dem College waren wirklich beschissen für fortgeschrittene Flash-Knockoffs und ähnliche Hover-Effekte. Und das Zeug hat wirklich, wirklich Spaß gemacht. Und ich vermisse es manchmal, als gäbe es eine ganze Fülle von Inhalten, die einfach verschwinden werden, weil wir Flash nicht mehr verwenden. Und das ist wirklich scheiße, aber in gewisser Weise war es eine Art Vorläufer für diese Art von Insel-Ding, über das wir sprechen. Das heißt, Sie könnten einfach eine statische Webseite und alles haben, aber dann hätten Sie diese wirklich reichhaltige interaktive Erfahrung, als wären Sie mittendrin.

Drew: Seit langem gilt die progressive Verbesserung als bewährte Methode zum Erstellen von Weberlebnissen. Ist das noch so, meinst du?

Jeremy: Ich würde zugeben, dass es wahrscheinlich… nicht wahrscheinlich, ich würde zugeben, dass es mehr Arbeit ist, progressive Verbesserungen zu machen, weil Sie in gewisser Weise Ihre Entwicklungserfahrung aufteilen. Sie versuchen, die minimal praktikable Funktionalität einer Website so bereitzustellen, dass der Server diese Schlüsselinteraktionen verarbeiten kann. Aber obendrein sagen Sie: „Okay, nun möchte ich diese Interaktion erleichtern, damit sie mit JavaScript ein bisschen reibungsloser abläuft.“ Ich denke immer noch, dass es ein praktikabler Weg ist, Ihre Ziele mit Ihrer Website, Ihrer App oder Ihrem Produkt zu erreichen.

Jeremy: Aber was ich sagen würde ist, dass ich niemals empfehlen würde, dass jede einzelne Interaktion auf einer Website durch dieses synchrone Navigationsmuster erleichtert werden muss. So wie ein gutes Beispiel sein könnte, sollte Ihre Checkout-Seite für Ihre econ-Website unbedingt eine Serverroute haben. Sie sollten eine Serverroute haben, um Dinge in den Warenkorb zu legen, und dann sollten Sie in der Lage sein, gerade genug JavaScript einzustreuen, um das ein bisschen angenehmer zu machen, damit die Dinge ein bisschen schneller und asynchroner sein können.

Drew: Wenn es darum geht, die Leistung zu messen. Wir hören viel über Core Web Vitals, hauptsächlich von Google. Sind das wirklich die Maßstäbe, an denen wir uns messen sollten? Oder will Google uns das nur glauben machen? Ich verstehe jetzt, dass dies eine schwierige Frage sein könnte, dass Sie angefangen haben, bei Google zu arbeiten.

Jeremy: Ja, ja. Weißt du, also spreche ich hier für mich. Ich denke, dass Web Vitals … die anfänglichen Kern-Web Vitals sind ein guter Versuch, zu definieren, welche Teile der Benutzererfahrung wichtig sind. Ich denke, dass Metriken wie die kumulative Layoutverschiebung und die größte Contentful-Farbe anfangen, auf eine Weise über die Erfahrung nachzudenken, die wir wirklich nicht zu quantifizieren begonnen hatten. Vor einer besonders kumulativen Layout-Verschiebung, denn wenn es jemals einen Moment gab, in dem Sie wüten, tippen Sie darauf, weil sich eine Schaltfläche gerne auf der Seite bewegt oder so. Ich meine, ich denke, dass das eine hilfreiche Sache ist, um es zu messen. Es ist unvollkommen. Und ich denke, jeder, der an zentralen Web-Vitals arbeitet, würde zustimmen, dass Verbesserungen bei einigen dieser Metriken wünschenswert sind. Es gibt andere Metriken, denen ich nicht unbedingt vollständig zustimme. Wie die erste Eingangsverzögerung ist eine Metrik, die schwer zu bestimmen ist.

Jeremy: Ich denke, es ist wirklich nützlich, oder? Denn was Sie wörtlich sagen, ist, dass wir die Verzögerung und Interaktivität bei dieser ersten Interaktion des Benutzers messen möchten, aber es fehlt ein wenig Kontext, oder? Weil einige ... viele Dinge es beeinflussen können, weil es nicht unbedingt immer mit JavaScript verbunden ist. Die erste Eingabeverzögerung könnte die Verzögerung darstellen, die durch das Fokussieren des Formularfelds entsteht, richtig? Diese Art von Dingen, Dinge in HTML. Ich denke, diese Metriken ... solche Metriken wie die Verzögerung der ersten Eingabe können ... sie können nützlich sein, wenn Sie sie mit Dingen wie Einträgen aus der API für lange Aufgaben, Element-Timing und solchen Dingen kontextualisieren können. Letztendlich denke ich, dass die Zukunft von Core Web Vitals beweisen wird, dass es hilfreich und instrumentell sein wird, um zu messen, was eine gute Benutzererfahrung ausmacht. Das ist meine persönliche Meinung.

Drew: Ich denke, es ist eines dieser Dinge, die Sie immer mit sich selbst messen können, messen Sie Ihre eigenen Verbesserungen oder ob sich Ihre Erfahrung verschlechtert hat, wenn sich Ihre Punktzahl ändert, sich nicht so sehr um die Ampeln zu kümmern, sondern sich darum zu kümmern, was Sie wissen über den Kontext Ihrer Website und darüber, wie eine Änderung zu einer Verbesserung geführt hat.

Jeremy: Ich denke, dass Metriken wie die kumulative Layoutverschiebung hervorragend sind, aber auch sie könnten von einer kleinen Verbesserung profitieren. So wie es aussieht, misst die kumulative Layoutverschiebung hauptsächlich Layoutverschiebungen, die während der Last auftreten. Und wie wir wissen, kann es jederzeit zu Layoutverschiebungen kommen, wenn ein Benutzer eine Seite besucht und auf einer Seite landet, richtig? Ich denke also, es gibt definitiv Arbeit, die getan werden kann, um die Art und Weise zu verbessern, wie wir diese Art von Phänomen beobachten, mit Sicherheit.

Drew: Ich denke, Layout-Stabilität ist etwas schwieriger zu erreichen, wenn man mit progressiver Verbesserung arbeitet. Manchmal, wenn Sie eine vom Server gerenderte Seite laden und dann beginnen, sie im Client zu verbessern, besteht die Gefahr, dass diese Art von Layoutverschiebung entsteht, nicht wahr?

Jeremy: Absolut. Und hier wird die Hydratation von Komponenten ziemlich schwierig, da sich die Abmessungen dieser Komponente aus einer Reihe von Gründen ändern können. Als ob in der clientseitigen Komponente Inhalte vorhanden sein könnten, die auf dem Server einfach nicht gerendert werden, da der Status erst ausgewertet wird, wenn er auf dem Client ausgeführt wird. Es ist ein extrem schwieriges Problem. Ich werde nicht hier sitzen und so tun, als hätte ich die Wunderwaffe dafür.

Drew: Ich wollte ein bisschen über eine Art Dynamik von Importen und Code-Splitting sprechen, beides unterschiedliche Techniken für das Problem des Herunterladens und Ausführens eines riesigen JavaScript-Pakets im Voraus zu Beginn der Erfahrung. Besteht die Gefahr einer Überoptimierung durch viele kleine Anfragen, insbesondere bei einfachsten kleineren Projekten, oder ist es etwas, dass sie bei der Implementierung absolut keinen Schaden anrichten, um von Anfang an zu verhindern, dass Sie diese Probleme haben werden? Oder sollten Sie warten, bis Sie tatsächlich Leistungsprobleme sehen, bevor Sie über solche Dinge nachdenken?

Jeremy: Ich würde also empfehlen, dass das Ende von dem, was du gerade gesagt hast, ein guter Weg ist, damit anzufangen. Wir sollten nicht versuchen, vorzeitig zu optimieren, es sei denn, diese Optimierungen können natürlich sehr schnell und einfach erreicht werden, aber wenn es viel Aufwand erfordert, früh zu optimieren, wenn es nicht wirklich viele Leistungsprobleme gibt, würde ich das argumentieren Code-Splitting ist wahrscheinlich etwas, das nicht passieren muss. Sie können diese Funktionalität wahrscheinlich einfach im Voraus laden.

Jeremy: Aber zum Beispiel spreche ich darüber in dem Buch. Wenn Sie eine hochwertige Interaktion haben, die von einem großen Stück JavaScript gesteuert wird, und für mich könnte ein großes Stück JavaScript 20 Kilobyte bedeuten, weil das über die Leitung komprimiert ist und am Ende ein 60-Kilobyte-Stück JavaScript sein könnte. Wenn Sie das dann für das Hauptpaket oder eines Ihrer unzähligen Pakete herausziehen können, wird Ihre Website möglicherweise ausgeliefert, und Sie werden die Startleistung verbessern.

Jeremy: Aber in dem Buch bespreche ich eine Technik, um wahrzunehmen, wann … oder zumindest zu versuchen, wahrzunehmen, wann der Benutzer eine wertvolle Interaktion durchführen könnte. Das Beispiel, das ich verwende, ist also ein Stück JavaScript. Das wird verwendet, um den Inhalt eines Formulars zu validieren, weil die HTML-Formularvalidierung großartig ist, aber sie ist auch nicht gestaltbar und ziemlich einfach. Es gibt nicht viel Flexibilität für Dinge wie Typ gleich E-Mail, oder? Es wertet es auf eine bestimmte Weise aus. Diese Validierung des Formulars auf dem Client ist jedoch sehr hilfreich, da wir es auch stylen können. Und wir können das Erscheinungsbild dieser Validierung so ausrichten, dass es näher an der Markenästhetik oder der Ästhetik der Website liegt. Und so habe ich in diesem Beispiel Folgendes getan: Wenn ein Benutzer fokussiert … auch nur eines der Felder im Formular fokussiert, ist dies der Punkt, an dem wir dieses Stück JavaScript vorab laden.

Jeremy: Hoffentlich bis dahin, und ich würde hoffen, weil es eine Weile dauert, ein Formular auszufüllen, dass das Netzwerk genug Zeit hat, es herunterzuziehen, damit es, wenn der dynamische Import aufgerufen wird, einfach das Geld treffen kann erhalten, was bereits vorinstalliert ist. Es ist etwas, mit dem ich hier und da ein bisschen gearbeitet habe, und es ist schwierig, es in allen Situationen zu tun. Zum Beispiel können Sie dies beim Schweben nicht immer zuverlässig tun, da einige Geräte keinen feinen Zeiger haben. Sie haben … sie sind … es sind Tap-Eingänge, richtig? Ein Schweben erfolgt also zu einem anderen Zeitpunkt, als wenn Sie beispielsweise einen feinen Zeiger hätten.

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

Jeremy: Eine Art ständige Sache, die ich mache, seit es herauskam, ist, mit der CSS-Paint-API herumzuspielen. Ich mag die Paint-API wirklich. Ich meine, es hat irgendwie schon immer für sich selbst existiert…. wie auf seine eigene Weise, da der 2D-Kontext wie die Leinwand eine Sache war. Denn das ist … für diejenigen, die es nicht wissen, die CSS Pain API ist eine Möglichkeit, einen 2D-Leinwandkontext einzubetten und ihn zu parametrisieren und mit CSS zu steuern, was viele wirklich interessante Möglichkeiten eröffnet, wie Sie Dinge damit animieren können Sie konnten vorher nicht animieren und so etwas.

Jeremy: Und kürzlich habe ich eine Blog-Aktualisierung durchgeführt. Das heißt… ich bin ein großer Final-Fantasy-Geek, wie Final Fantasy II, das ich gerade noch einmal gespielt habe, und so gibt es etwa 15 von ihnen und 16 kommen irgendwann heraus, aber es ist eine Art Retro-Feld. Also habe ich die CSS-Paint-API verwendet, um eine zufällige Welt mit verschiedenen Kacheln zu generieren. Es gibt also Flüsse und Sachen, die wie durchfließen und Grasfliesen und Bäume und solche Sachen. Und wenn Sie das so parametrieren, dass der Benutzer meine Website im Dunkelmodus besucht, wird diese Lackierung so gerendert, als ob es Nacht wäre. Es wird nur eine Art Überlagerung darauf haben und so etwas.

Jeremy: Aber die Mal-API ist erstaunlich. Ich muss Tim Holman einen Gruß aussprechen. Er, ich habe ihn auf der JSConf Australia gesehen und er hat einen Vortrag über generative Kunstwerke gehalten. Das war wirklich nur, es hat mich wirklich interessiert. Und dann, als Sam Richard am Vortag auf der CSSConf über die CSS-Mal-API sprach, dachte ich, als diese beiden Dinge für mich zusammenkamen: „Wow, das ist so cool.“ Und so habe ich tatsächlich etwas namens Paintlets gemacht! Es ist eine Paintlets.Herokuapp.com, wenn Sie und Chrome besuchen, und Sie müssen leider, weil es noch nicht sehr gut unterstützt wird. Sie können sehen, wie ein Haufen verschiedener, zufällig generierter Kunstwerke und ... ja, ich habe nur ... das ist, was ich gemacht habe, sorry. Lange Geschichte dazu.

Drew: Erstaunlich. Das klingt gut.

Jeremy: Ja. Ja.

Drew: Wenn Sie, lieber Zuhörer, mehr von Jeremy hören möchten, finden Sie ihn auf Twitter, wo er @malchata ist, und finden Sie seine Schreibpräsentationen, Videos und Projekte auf seiner persönlichen Website, jeremy.codes, Responsible JavaScript ist jetzt bei A Buchen Sie auseinander. Weitere Informationen dazu finden Sie unter Responsiblejs.dev. Danke, dass du heute zu mir gekommen bist, Jeremy, hattest du irgendwelche Abschiedsworte?

Jeremy: Gehen Sie einfach weiter und bauen Sie für das Web so gut Sie können und versuchen Sie, den Benutzer im Auge zu behalten. Das ist sozusagen mein Mantra, und ich hoffe, dass dieses Buch das ein bisschen festhält.