Anmelden

Working Draft· Folge 695

Revision 695: Browser-News-Roundup

Dienstag, 30. Dezember 2025 · 1 h 31

MP3

Shownotes

In dieser Revision schauen wir wieder gemeinsam auf frische Browser-Features aus Chrome, Firefox und den WebKit Nightlies. Wir sprechen über praktische Bugfixes, neue CSS-Möglichkeiten, bessere DOM-APIs und ein paar eher nischige, aber extrem mächtige JavaScript-Neuerungen.

Schaunotizen

[] Overscroll-Behavior für Container ohne Scroll-Layer (Chrome) (bram.us/2025/11/25/use-overscroll-behavior-con…)
Chrome respektiert overscroll-behavior jetzt auch dann, wenn ein Element faktisch keinen eigenen Scroll-Container hat. Das behebt einen langjährigen Pain Point bei Dialogen, Overlays und Off-Canvas-Navigationen, bei denen sonst plötzlich der Seitenhintergrund scrollt.

Wir erklären, warum das bisher ein Spec-Problem war, wieso Chrome hier nachgezogen hat und warum man sich damit endlich fiese Workarounds sparen kann. Als anschauliches Beispiel schauen wir uns eine Scroll-Situation auf code.movie/play.html an.
[] WeakMap & WeakSet mit nicht-registrierten Symbols (Firefox) (developer.mozilla.org/en-US/docs/Mozilla/Firef…)
Firefox erlaubt nun auch nicht-registrierte Symbols als Keys in WeakMap und WeakSet. Damit sind Weak-Collections endlich vollständig konsistent mit der Garbage-Collection-Semantik von Symbols.

Wir sprechen ausführlich darüber, warum das relevant ist, wann man Symbols überhaupt sinnvoll einsetzt und wie Peter sie unter anderem in seinem Web-Component-Framework Ornament (github.com/SirPepe/ornament) nutzt – inklusive Exkurs zu registrierten Symbols, Symbol.for() und instanceof-Fallstricken bei gebundelten Libraries.
[] CSS stretch-Keyword für width/height (developer.mozilla.org/en-US/docs/Web/CSS/Refer…)
Mit dem neuen Keyword stretch lassen sich Elemente sauber über die Content-Box ihres Elternteils aufspannen – ohne calc(), ohne absolute Positionierung und ohne Wissen über Padding.

Wir ordnen ein, warum das funktional dem alten developer.mozilla.org/en-US/docs/Web/CSS/Refer… entspricht, wie die Browser-Unterstützung aussieht (Can I Use (caniuse.com/mdn-css_properties_width_stretch)) und warum das Feature trotz breiter Nutzbarkeit noch nicht als Baseline gilt.
[] Atomics.waitAsync() (developer.mozilla.org/en-US/docs/Web/JavaScrip…)
Atomics.waitAsync() bringt endlich eine Promise-basierte Alternative zur blockierenden Atomics.wait()-API. Damit lassen sich Shared-Array-Buffer-Synchronisationen auch im Main-Thread sinnvoll nutzen.

Wir erklären, warum die alte API praktisch nur in Workern sinnvoll war, welche Workarounds man bisher brauchte und warum sich das Feature zwar nach Hardcore-Low-Level anhört, in der Praxis aber trotzdem nur selten lohnt.
[] developer.mozilla.org/en-US/docs/Web/CSS/Refer…
@scope ist jetzt Baseline und ermöglicht echtes CSS-Scoping ohne Namenskonventionen, Build-Tools oder CSS-Modules. Styles lassen sich direkt an Komponenten koppeln – inklusive Donut-Scoping für Slots und Durchreiche-Bereiche.

Wir diskutieren, warum das besonders für serverseitige Templates (PHP, Twig & Co.) hilfreich ist, wie man damit Toolchains drastisch vereinfachen kann und warum @scope ein echter Gamechanger für „CSS für Arme“ ist – im besten Sinne
[] moveBefore() (developer.mozilla.org/en-US/docs/Web/API/Eleme…)
moveBefore() ist die State-erhaltende Alternative zu insertBefore() (developer.mozilla.org/en-US/docs/Web/API/Node/…). DOM-Nodes werden verschoben, ohne ihren internen Zustand zu verlieren – inklusive laufender Animationen, Video-Playback und Iframes.

Für Web Components ist wichtig, dass sie den neuen connectedMoveCallback (developer.mozilla.org/en-US/docs/Web/API/Web_c…) Lifecycle-Hook definieren, damit auch sie bei einem Move-Vorgang erhalten bleiben und nicht von Grund auf neu gebaut werden.
[] CSS sibling-count() (developer.mozilla.org/en-US/docs/Web/CSS/Refer…) & sibling-index() (developer.mozilla.org/en-US/docs/Web/CSS/Refer…)
Mit sibling-count() und sibling-index() bekommt CSS endlich Zugriff auf strukturelle Informationen, die bisher nur mit Selector-Akrobatik (lea.verou.me/blog/2011/01/styling-children-bas…) oder JavaScript möglich waren.

Wir erklären, wie man damit responsive Layouts, gestaffelte Animationen oder Karten-Stacks umsetzt – und warum das Zählen ab 1 zwar logisch, aber trotzdem ein dankbarer Diskussionspunkt ist.

Schepp fällt eine Coding-Challenge von den Kollegen Syntax.fm ein, bei der Scott Tolinski das Feature sehr anschaulich zu seinem Vorteil einsetzt. (youtube.com/watch?v=9H34nxxVEgc)
[] @custom-media (in Arbeit) (developer.mozilla.org/en-US/docs/Web/CSS/Refer…)
Eigene Media-Query-Aliasse erlauben sprechende Breakpoints statt Magic Numbers. Firefox ist hier aktuell im Rollout, Chrome und Safari sind schon weiter. Ein großer Gewinn für Wartbarkeit und Lesbarkeit von CSS.
[] CSS Module Scripts (Firefox auf dem Weg) (web.dev/articles/css-module-scripts)
CSS direkt per JavaScript importieren und als CSSStyleSheet weiterreichen – ohne Bundler, ohne Magie. Firefox schließt hier bald die letzte Lücke.

Wir sprechen darüber, warum das besonders für Web-Components und native Module spannend ist und wie sich damit Toolchains und node_modules-Ordner spürbar verkleinern lassen.

Links

Working Draft Revision 686 (workingdraft.de/686)
Die vorherige News-Round-Up-Folge, auf die wir mehrfach Bezug nehmen – inklusive weiterer Browser-Features, Device-Memory-API und Invoker-Commands.
Bower (bower.io)
Ein nostalgischer Blick zurück auf einen der frühen Paketmanager fürs Web – inklusive Vogel-Logo, Merch-Shop und der Erkenntnis, dass manche Tools einfach nie ganz verschwinden.

Diskutiert die Folge mit uns in unserem Community-Slack: draft.community

Transkriptvom Podcast bereitgestellt · Zeitmarken springen hin

Was auch neu Baseline ist, ist CSS Scopes, also AdScope. Juhu! Yay, yay, yay. Oder CSS. CSS ist ja mehr so die Bad Noir der Enterprise-Entwickler. Genau, da passiert ja auch mehr als im JavaScript-Bereich. Wobei ich auch finde, dass sich so ein ganz bisschen verlangt hat. Also marginal, marginal. Du machst AdImport im CSS-Server. Irgendwie sowas, ne?

Ja. Und dann funktioniert das ja schon nicht mehr, weil das ja tatsächlich etwas ist, was nur funktioniert im HTML-Kontext, weil es halt ein HTML-Attribut voraussetzt. Das hier ist definitiv die bessere Lösung. Ja, genau. Also ich denke mal, das war auch eins dieser Jugend-Forsch-Geschichten damals so im Kontext von Web-Components.

Diese Revision von Working Draft wird euch präsentiert von euch, von unserer Community. Podcasting ist keine Einbahnstraße und ohne euer Feedback wäre das hier alles gar nichts. Und deshalb haben wir für euch einen Slack-Channel eingerichtet. Unter draft.community könnt ihr beiträgen und mit uns Podcast-Host sowie der erlesenen restlichen Hörerschaft abhängen.

Wir diskutieren über den Podcast, tauschen Links aus und immer dann, wenn wir etwas Besonderes vorhaben, erfahrt ihr es dort zuallererst. Also klickt doch mal rein unter draft.community. Hallihallo Hallöle und herzlich willkommen zu Working Draft Revision 695. Heute sind am Start der Shep. Hallo! So, meine Wenigkeit, der Peter und außerdem am Start ein paar neue Browser-Versionen seit dem letzten News-Round-Up.

Und deswegen haben der Chef und ich, wir uns hören uns wieder die Change-Logs der diversen Browser- und Browser-ähnlichen Konstrukte, so Safari-Technology-Preview, hergenommen und haben sehr viele interessante Sachen in Firefox gefunden, ein bisschen was in Chrome und so gar nichts wie in Safari. Ja, wir haben auch viel Interessantes gefunden, worüber wir letztes Mal schon aus Versehen gesprochen haben. Also, was heißt aus Versehen, aber wir haben mal darüber gesprochen.

Wir haben uns sozusagen so ein bisschen selber in die Parade, in die zukünftige Parade gefahren. Ja, es ist halt eben so. Die Zukunft ist schon da, nur nicht gleichmäßig verteilt. So sieht's aus. Tja, aber dann tauchen wir doch mal direkt ein in die spannenden Features, die wir da haben. Nämlich, das hast du mit dem Kommentar geil versehen hier in unserem Dokument.

Chrome kann jetzt Overscroll Behaviour für Container ohne Scroll-Layer. Genau. Ich habe keine Ahnung, was irgendwie auch nur eins von diesen Wörtern da drin bedeutet. Echt? Ach, ich wollte gerade fragen. Okay, also du weißt nicht, wofür Overscroll Behaviour sein könnte. Wenn ich was wüsste, würde ich es jetzt trotzdem nicht sagen, damit wir hier eine bessere Podcast-Experience hinkriegen.

Na gut, dann musst du mir das hinterher erzählen, ob du da was wusstest. Nee, wahrscheinlich, wenn ich es erkläre, dann wird es dir irgendwie schon dämmern. Overscroll Behavior ist eine CSS-Property, die du meistens benutzt, also wenn du zum Beispiel so auf Canvas-Menüs oder so auffährst und du kannst in den scrollen.

Wenn du da an das Ende des Call-Containers kommst, dann ist eigentlich das Browser-Standard-Verhalten, dass der Browser dann die gesamte Seite weiter scrollt, also weil aus dem Container einfach nichts mehr rauszuholen ist. Ah, also sei es mit dem Finger, aber auch mit dem Mausrad. Genau, und in dem Kontext ist das in Regel ein Verhalten, das wir nicht haben wollen.

Und du kannst dann diesem Off-Canvas-Menü ein Overscroll Behaviour Contain verpassen und dann liegt quasi das Scrollen nicht raus und, fließt dann sozusagen oder wird dann weiter eskaliert an das Document Root zum Beispiel. Also die gesamte Seite wird dann nicht mehr gescrollt, wenn du ans Ende kommst.

Weil einfach dein Scroll Intent bleibt in diesem Container dann eingesperrt. Und das willst du haben, das ist eigentlich ganz cool. Wenn man das immer haben? Also ich glaube, bei so einem Off-Canvas-Menü willst du das schon immer so haben. Ja. Also da würde ich das für merkwürdig halten, wenn auf einmal eben dann der Hintergrund scrollt.

Also der die ganze Seite scrollt unter deinem vielleicht fix positionierten also wenn es, zumindest wenn es fix positioniert ist, aber was ja bei den ganzen Off-Canvas-Dingern eigentlich die Regel ist. Ich hab dir da mal grad was reingepastet. Und wenn du da unten in der rechten Seite unten rechts da auf Theme klickst, dann ploppt ja auch wieder eine ganze Menge Krempel auf.

Warte mal, Close Tutorial muss ich erstmal machen. Wo muss ich da drücken? Das ist so jetzt hier code.movie slash play.html, ne? Ja, nur weil ich da auch so ein Scrollding hab. Und wenn du da unten mal Theme aufklappst, dieses Details-Element. Ah ja. So, dann musst du ja wahrscheinlich auch scrollen. Ja, genau, da passiert das auch.

Aber das find ich eigentlich richtig. Also ich scroll in diesem Theme-Moped an das untere Ende und dann scrollt das nicht mehr weiter und auf einmal fängt dann der linke Teil der Seite oder der, ja, genau, der linke Teil der Seite fängt an zu scrollen. Ja, wenn du das so haben willst, ist das doch super.

Ich weiß aber nicht, ob ich das so haben will, weil ich halt nicht drüber nachgedacht habe, dass man es anders haben könnte. Ich dachte halt eben, ah, okay, so verhält sich das, okay. Es gibt ja irgendwie, wenn man sozusagen das Ende dann erreicht hat, irgendwie auch so einen Widerstand nochmal, bevor er das macht.

Jedenfalls hier bei mir im Firefox mit meinem Linux hier. Bei mir nicht, also, nee. Ah, okay. Dann ist das wahrscheinlich anders unter anderen Browsern halt nochmal was lästiger und dann tatsächlich eine gute Idee, das mal einzubauen. Ja. Genau, also. Genau, also man kann, beides kann man wollen, aber es ist halt so, dass du, genau, du kannst dem aussuchen, wie du es haben willst.

Oder was auch ein Klassiker ist, ist, du hast quasi einen Dialog, der aber vielleicht nicht modal ist, also und damit wird dann eben der Rest der Seiten vom Browser nicht automatisch auf inert gestellt, also quasi nicht interagierbar. Ja, also er ist interagierbar und du hast vielleicht auch dann deinen Backdrop und in diesem Dialog-Element hast du, das kannst du vielleicht auch scrollen, weil du vielleicht auf einem kleinen Bildschirm bist und du hast irgendwie mehr in dem Dialog drin und dann kann man scrollen und dann hast du das Problem auch, dass auf einmal eben die Seite hinter dem Backdrop anfängt, auch zu scrollen, wenn du ans Ende kommst und das ist halt einfach total weird.

Ja, ich glaube, je lästiger, umso kleiner das Scroll-Ding ist, bei dem du ans Ende kommst, wenn das irgendwie wirklich so die halbe Spalte ist. Wie jetzt in meinem Use Case ist das, glaube ich, noch vergleichsweise unseltsam, aber dein Beispiel mit dem Mini-Dialog ist natürlich eine andere Kiste. Ja. Oder auch das die Navigation da, genau.

Du kannst, glaube ich, auch damit diese Browser, also diese Navigationsgesten, unterdrücken auf einer Seite, also dieses Swipe nach links zurück, Swipe nach rechts. Das ist, also ich finde das manchmal erwägenswert, wenn du zum Beispiel so einen horizontalen Slider hast und du kommst da ans Ende und dann, wups, aus Versehen hast du dann, ja, Kacke.

Ich habe jetzt gerade einen Backbutton aus Versehen ausgelöst und bin weg von der Seite oder so. Also super praktisch, aber es gibt einen fiesen Haken an diesem Feature bisher, und zwar unter Chrome. Funktionierte das immer nur, wenn tatsächlich auch ein Scroll-Container vom Browser erzeugt wurde. Aber wenn der Inhalt klein genug ist, dass nicht gescrollt werden muss, innerhalb des Elternelements, dann, gibt es halt keinen Scroll-Container. Und dann funktioniert der Overscroll-Gehäufer immer nicht.

Also das heißt, du hast einen Dialog, der Inhalt, den du da zeigst, sind vielleicht irgendwie zwei Knöpfe oder sowas und ein Text. Ja, nein, ist klein genug, passt da rein, es muss nichts gescrollt werden. Du. Du kommst mit deinem Finger irgendwie dahin oder du kannst dann trotzdem darauf swipen und auf einmal scrollst du durch diesen Dialog hindurch den Hintergrund.

Ja, okay, das ist Pest. Genau. Und ich habe mir immer damit beholfen, dass ich in all diesen Overlays habe ich mir quasi, also es ist ziemlich hacky, aber ich habe dann per After-Pseudo-Element habe ich mir dann immer Content erzeugt, der definitiv groß und lang genug war, um eben dieses Eltern-Ding scrollen zu lassen.

Und dann habe ich, man kann ja in CSS, kannst du ja mit Slash, kannst du dann ja einen Alternativtext hinterlegen für diesen erzeugten Content. Ja, ich bin gespannt. Ich wollte nämlich genau danach gerade fragen. Genau, den habe ich dann natürlich auf Layer gestellt, sodass eben Leute mit Screenreader nicht irgendwie den ganzen Quatsch da vorgelesen kriegen, den ich da erzeuge.

Ich muss ja irgendwelche Zeichen erzeugen, dann habe ich eine ziemlich große Font-Size genommen und die Color auf Transparent gesetzt, sodass wirklich einfach ein großes Ding erzeugt wird, immer, das aber eben nicht zu sehen ist und auch nicht vorgelesen wird, wo der Browser was scrollen muss und wo ich dann aber hingehe und die Scrollbar auch noch verstecke, damit man einfach nicht wahrnimmt, dass da ein scrollbarer Container ist.

Damit dann dieses Overstroll Behaviour Contain eben auch funktioniert in der Stelle. Das ist jetzt halt, und das ist das, warum ich eben geil geschrieben habe, dass die das gefixt haben, dass das eben nicht mehr nötig ist. Ja. Ich meine, es ist immer natürlich schade, wenn man so viel Zeit und Energie investiert hat, um so ein Workaround zu bauen. Und da kommt der jetzt einfach weg.

So ist das. So ist das im Leben. Genau. Ja, aber geht das jetzt, du hast jetzt gerade gesagt, das ist, Chrome kann das jetzt können, das andere auch? Also ich glaube, die anderen haben es von vornherein schon sozusagen korrekt implementiert. Okay, gut. Das heißt, dann hat nur der wichtigste aller Browser sich da jetzt geupgradet.

War das denn, also das war schon so, dass Overscroll-Behavior immer gehen musste und dass das, was Chrome da jetzt angemacht hat, wirklich ein Bugfix war, richtig? Also ich meine, laut Spec ist es glaube ich so, dass das eben nur für Scroll-Container gilt. Ja, sehe ich auch gerade. Genau, und dann, wenn du keinen Scroll-Container hast, wenn er nicht erzeugt wird vom Browser, dann lief diese Angabe beim Chrome zumindest bislang ins Leere.

Also die haben sich schon an die Spec gehalten, aber die Spec hat halt sagen müssen, Und ungeachtet dessen, ob da jetzt ein Scroll-Container ist oder nicht, die Scroll-Intent soll einfach nicht hochbubbeln oder weiter hochbubbeln zu den Eltern-Elementen. Ja. Also Specs sagen, Element, das kein Scroll-Container ist, muss die Property ignorieren.

Ja, dann ist die Specs ja eigentlich auch doof. Ja, beziehungsweise Specs sind ja deskriptiv, also sollte mal die Specs geupdatet werden, würde ich sagen. Wenn es alle so machen. Naja, okay. Hey, super. Das ist doch das Beste, was ich an Working Draft immer so habe. Live-Tech-Support. Da kann ich jetzt direkt eine neue Zeile CSS schreiben und alles ein bisschen weniger räudig machen. Genau.

Ja, habe ich nochmal was gelernt. So, jetzt lerne ich was. Vielleicht, vielleicht auch nicht. Ist nämlich jetzt so, dass eine Neuerung im aktuellen Firefox ist, dass jetzt es erlaubt ist, in Weak Maps und Weak Sets Symbols, die nicht registriert sind, als Keys zu verwenden. Normalerweise gehen da ja nur Objekte drin. Die Idee von WeakSet und WeakMap ist, da kann man Objekte drin ablegen, beziehungsweise im Falle von einer WeakMap mit Objekten irgendwelche Daten assoziieren.

Und die Sets, beziehungsweise die Keys der WeakMap, halten nur schwache Referenzen. Das bedeutet, wenn diese Referenz die letzte ist, die noch auf dieses Objekt gehalten wird, dann gilt diese Referenz nicht mehr, wird aufgelöst und die Garbage Collection kann hingehen, kann das entsprechende Objekt einsammeln und dagegen immer nur mit Objekten.

Nur sind Symbols ja Objekten in der Hinsicht nicht unähnlich, als dass die ja, weil ja jedes Symbol für sich genommen ein eigenständiger Wert ist, wovon es keine Duplikate gibt, die ja sozusagen die gleiche Energie versprühen und die ja im Prinzip auch Gegenstand der Garbage Collection sind oder zumindest sein können oder sich zumindest so anfühlen könnten.

Und deswegen ist eigentlich kein guten Grund, warum die nicht in Weak Maps und Weak Sets da auch vorkommen könnten. Im Falle von Weakmaps immer bedenken, ich rede von den Keys, nicht von den Values. Und das ist jetzt halt eben repariert. Und mit dem Firefox jetzt als letzten Browser ist das so, man kann in seinen Weakmaps Symbols als Keys verwenden und in Weak-Sets sie ablegen, solange die Symbole nicht registriert sind.

Aber das ist ja ein noch randständiger Use-Case als Symbols und Weakmaps und Weak-Sets ohnehin schon. Ich war etwas überrascht, als du sagtest, den ganzen Krempel verwende ich nicht, wo ich doch denke, du bist ja noch Framework-averser als ich, denke mir halt eben so, da baut man sich doch sowas selber mit genau solchen Sachen.

Genau, also Weakmaps und Weaksets benutze ich wohl, also so oft ich kann, also manchmal geht's nicht, weil es gibt ja keine For-Each-Methode darauf oder ich glaube, es gibt auch keine Entries-Property oder sowas. Nee, aber das wäre ja auch verkehrt, weil es widerspricht sich ja notwendigerweise. Du kannst ja nur das eine oder das andere haben.

Ja, ja, genau. Also haben wir ja auch in unserer letzten Revision, mit der wir uns ja schon viele Inhalte hier vektorpediert haben, da sprachen wir auch über Weekmaps und Weeksets und hatten da, und Weekrefs und haben da einen schönen Talk verlinkt drin, um das Prinzip so ein bisschen zu verstehen von diesen Week-Geschichten.

Was ich halt nicht benutze, sind Symbols. Insofern, also das ist halt das, weswegen mich diese Neuerung kalt lässt. Wann sollte ich denn Symbols benutzen? Deiner Meinung nach. Oder was gibt es für Use Cases, um Symbols zu benutzen? Oh Gott, wo soll ich anfangen? Sie sind so zahlreich. Okay. Jaja, ich weiß, dass du mit denen rumhantierst. Vielleicht sind das ja auch so Unknown-Undowns bei mir. Oder ich habe den Use Case vielleicht nicht. Keine Ahnung.

Aber sagen wir mal so fangen wir mal bei dem Basalsten an du willst irgendwie eine Property haben, die nicht innumerable ist, der einfachste Weg ist tatsächlich ein Symbol. Okay, also ich will quasi sowas wie ein Objekt haben, aber mit einer Property drin, die man eben, genau, oder ich könnte, also so quasi wie wenn ich eine Class mit einer Private Property.

Da habe ich leider zuletzt auch über die Spezifikationen gelesen, wie die funktionieren. Wir sollten diesen Bereich weiträumig umfahren, wenn wir heute noch mit dieser Sendung fertig werden wollen. Okay, ja. Es ist wirklich mehr so, vergleiche es wirklich, du kannst ja, also hier, du machst irgendwie foo.x gleich 42.

Unter der Haube ist das ja Object Defined Property auf x, nee, auf foo 1x mit writable, innumerable, configurable und value. Und normalerweise wäre ja innumerable das Ding, was darüber entscheidet, ob es in vor-in-Schleifen auftaucht und ob es halt auch bei so Sachen wie Object-Keys auftaucht. Und wenn du das nicht willst, dann würdest du halt eben sagen, okay, ich mach das mit Define Property, statt einfach zu schreiben foo.x gleich, aber du machst das natürlich nicht, weil das halt so ein Syntax-Block ist, dass du da einfach nur in die Tischkante beißen möchtest.

Und das Schöne an Symbols ist, alle APIs, die halt so Loops über Objekte machen, machen halt immer nur Loops über die String-Properties auf den Objekten. Die Symbols, auch wenn sie als Enumerable markiert sind, tauchen da drin nicht auf. Okay, du würdest halt so quasi deinen Wert anstatt in eine normale Property in ein Symbol in diesem Objekt stecken. Das wäre zum Beispiel eine Idee.

Andere Idee, wenn man jetzt nicht mit Klassen rumhantiert und man will trotzdem was haben, was so ausreichend privat ist. Ich meine, der Use Case von Private ist ja jetzt nicht irgendwie NSA-Level Security, sondern mehr so, dass man das halt nicht versehentlich falsch benutzt. Ist ein Simpel natürlich auch gut, weil man kann nicht versehentlich diesen Key tippen.

Keine Nutzer können irgendwas in ein Formular schreiben, womit sie versehentlich irgendwie dann Unfug machen. Also du willst mir ein neues Webprojekt zum Spielen. Ich melde mich immer als her unterstrich unterstrich proto unterstrich unterstrich an in der Hoffnung, irgendwie da Magic Keys kaputt zu machen. Das ist halt eben auch so ganz gut einfach so als Best Practice zur Sicherheit.

Du kannst das halt eben komplett privat machen. Du kannst damit, wenn du tatsächlich Klassen verwendest, so dein eigenes Konzept von Protected implementieren. Also das normale OOP, da ist ja Protected tatsächlich immer so, der Sichtbarkeitsmoderationslayer ist das vererbungsmechanische Zusammenhängen von verschiedenen Klassen.

Aber letztlich ist das ja sozusagen nur eine Vorgabe zwischen Public und Private, mit einem bestimmten Mechanismus moderiert. Aber sobald du Symbols hast und du ja Zugriff auf dieses Symbol an irgendwelche anderen Teile deines Programms geben kannst, kannst du ja quasi dein eigenes Konzept von Protected implementieren.

Im Sinne von, da können nicht alle ran, sondern da können nur die ran, die halt in einer bestimmten Beziehung zu dem Objekt stehen. Und diese Beziehung muss nicht Vererbung sein, sondern kann auch sowas sein wie, hat halt von mir dieses Symbol übergeholfen bekommen. Mhm. So, wenn du natürlich dann irgendwie so der Effizienz-Nazi bist und du musst ganz viele Objekte haben, die irgendwie in Objekte reinindizieren und anhand eines anderen Index dann in was anderes reinindizieren, sowas halt eben, ist natürlich auch ein Symbol ganz praktisch, weil du halt tatsächlich dann sagen kannst, dieses Symbol ist im Prinzip ein Stand-in für ein anderes Objekt und weil ich halt weiß, dass das mit diesem Objekt für das ein Stand-in ist,

kann ich quasi Objekte anhand von Objekten direkt indizieren auf Objekten, ohne mich mit Maps rumschlagen zu müssen. Das ist natürlich ganz nett und letztens hatte ich einen sehr schönen Use Case für registrierte Symbols, den fand ich ganz komod. Achso, ne, warte mal, Welder und Symbols muss ich natürlich auch noch erwähnen, ne, du baust dir deine eigenen Objekte und du willst irgendwie das Verhalten von Instance-Off überladen, Iterationen anlegen.

Das ist, glaube ich, ein bisschen jetzt nicht so, ich benutze Symbols, sondern das ist ja mehr so ein Pattern, das du dann verwendest. Ja, aber nee. Letztens hatte ich hier ganz toll Kundschaft. Die haben gesagt, weißt du was, wir haben hier unsere eigene Flotte an NPM-Paketen gleichsam. Und wir haben auch unsere Basislibrary für Errors. Macht ja irgendwie Sinn.

Dann hast du ja ein Bad Request Error. Und dann wird diese Library verwendet von anderen Libraries, die von anderen Libraries, die von anderen Libraries verwendet werden. Und wenn dann jedes Mal der Bundler läuft, führt das dazu, dass dieses Error-Package mehrfach in diesen Modulen geinlined ist. Und dann schmeißt du halt ein Bad Request Error, aber wenn du dann sagst, ist dieser Error ein Instance of, mein Bad Request Error, obwohl er das ist, kriegst du dann falsch raus, weil du halt natürlich dann einen Constructor verwendet hast, um das Ding zu schmeißen und einen anderen, gegen den du das dann in Instance of gegencheckst.

So. Shep, wie reparierst du das? Du hast es mit OOP-Menschen zu tun, die wollen Instance of verwenden. Die machen alles mit Klassen, weil das halt eben so ihr Vibe ist und denen wirst du jetzt nicht beibringen können, normales JavaScript zu schreiben. Tja. MMMM. Also, weil man kann ja Instance-Off überladen. Es gibt ein well-known Symbols namens hasInstance.

Damit kannst du eine statische Methode auf deiner Klasse implementieren und kannst dann sagen, okay, die kriegt einen Input und dann ist der Rückgabewert, der aus dieser Methode rausfällt, der Indikator dafür, was Instance-Off sagen soll. Das geht. Aber wie kriegst du es hin, dass BadRequestError Constructor 1, ein Bad Request Error Constructor 2, 3, 4, 5 und N, die alle dem ersten Bad Request Error Constructor nicht bekannt sind, wie kriegst du es denn, dass die sich untereinander identifizieren?

Ohne, dass du die API natürlich richtig fallen lässt. Hm. Tja, weiß ich nicht. Wahrscheinlich mit Symbols. Du wirst es mir gleich sagen. Der belegste Trick wäre natürlich, ich stecke halt eine Property drauf. Also alle Bad Request Errors, weil die haben ja diese ganze Flotte von NPM-Modulen im Griff.

Und die können einfach sagen, unsere Basislibrary rollt jetzt ein neues Ding aus und dieses neue Ding, das wir ausrollen, da ist jetzt auf der Bad Request Error, auf den Instanzen ist jetzt ein Feld drauf, das sagt, ich bin Bad Request Error. Das wäre das Einfachste, was du machen könntest. Problem ist aber, dann hast du halt eine andere API-Oberfläche und jedes andere Objekt könnte ja auch diese Property beinhalten und es ist halt eben nicht so superbombenfest.

Was du aber machen kannst, ist, du kannst ein Registered Symbol verwenden. Okay. Und das ist, wenn du nicht Symbol verwendest, also die Symbol-Funktion selber, sondern das ist ja quasi auch ein Namespace und das enthält eine statische Methode in Airquotes namens 4, also Symbol.4. Und Symbol.4 kannst du aufrufen, kannst du einen String reinstecken und wenn du Symbol.for aufrufst, mit zweimal dem gleichen String, kriegst du zweimal das gleiche Symbol zurück.

Okay, das ist schon mal gut. Und zwar global, im Sinne von über alle Browsing-Kontexte, also über Cross-i-Frames, Tabs und was, nicht alles. Okay. Die greifen alle auf den gleichen globalen Symbol-Store zu. Das heißt, was du dann machen kannst, ist, du kannst einen String definieren, wie zum Beispiel Company-Name, Projekt-Name, Unterstrich, Unterstrich ist ein Bad Request Error.

Kannst das in Symbol4 reinstecken, kannst es auf die Klasse draufstecken und dann hast du auf den Instanzen eine Property, die ist nicht innumerable, die ist nicht versehentlich abrufbar, weil sie halt ein Symbol ist, gibt einem aber trotzdem garantiert die Information raus, ob es ein Bad Request Error ist oder nicht.

Und dann kann dein Instanzchecker einfach nur gucken, ob unter dem Symbol für diesen speziellen Key, letztlich, ob das vorhanden ist auf dieser anderen Instanz. Ja. Und damit kriegt man das hin und das wäre dann sogar noch von Vorteil, weil es halt eben dann so auch noch Cross-i-Frame-kompatibel wäre und anderes.

Ja, okay. Und mit diesen Dingern, mit den registrierten Symbols, geht das mit den Weekmaps und Weeksets natürlich nicht, weil die Dinger natürlich nicht Gegenstand der Garbage Collection sein dürfen, weil ja die Idee ist, dass du die halt eben jederzeit wieder heraufbeschwören kannst für den richtigen String.

Man könnte also sagen, diese Register-Symbols sind bloß Strings mit Zwischenschritten, aber halt mit so ein paar Eigenschaften von Symbols im Sinne von immer unique und immer non-enumerable, und damit haben wir dann das Problem relativ gut gelöst bekommen. Es brauchte einen sehr langen Kommentar da oben drüber, um das wirklich verständlich zu machen, weil das natürlich schon von hinten durch die Brust ins Auge ist.

Aber man musste halt nichts ändern an dem Grundproblem und konnte trotzdem ein Hotfix ausrollen, was ganz Nettes. Und niemand musste was Neues lernen. Ja, geil. Das ist cool. Und das sind halt so die Simples. Also ich verwende die halt wirklich gerne so als Stand-in. Oder wenn du halt wirklich Mega-Meter unterwegs bist.

Also irgendwie, das ist hier meine Web-Component-Ornament-Decorator-Kiste da. Da muss sich ja unterscheiden zwischen null und defined und da ist kein Wert drin. Ich bin ja Metaprogrammierung und dann kann ja jemand da einfach irgendwie was reintun, wie zum Beispiel null und undefined und das ist das gleiche wie zu sagen, da ist kein Wert drin.

Also habe ich mir ein extra Symbol gebaut, das heißt no value und wenn das irgendwo drin steht, ist das sozusagen mein eigenes persönliches Sub-null oder undefined für, da ist kein Wert drin, da ist nicht mal null oder undefined drin, aber die JavaScript-Semantik verlangt von mir, dass ich da einen Wert reinschreibe und dafür habe ich halt eben mein Symbol reingebastelt.

Und das sind so die Use Cases. Und ich hätte halt einfach erwartet, dass du mit sowas ständig rumjonglierst. Von wegen so, ich indiziere da rein und gedöns. Nee, aber vielleicht, ja, eigentlich müsste ich das dann. Genau. Weiß ich nicht, vielleicht mache ich es ja bald. Ich merke mir das mal und denke mal darüber nach, wo ich das einsetzen könnte.

Das ist halt einfach eine wunderbare Droge, sobald du halt eben damit anfängst. Ja, letzte Frage. Wann Symbols Talk von Peter Kröner? Ein Symbols Talk in dem Sinne habe ich jetzt nicht, aber ich mache natürlich gerne so Workshops zu dem JavaScript-Kram, den keiner benutzt. Also ich habe so ein kombiniertes Programm für Proxys, Symbols, was ist da noch drin? Decorators.

Ich habe mir vorgestern eine coole Location für einen Workshop angeguckt. Wir könnten ja mal aufgleisen und gucken, ob wir genug Leute zusammenkriegen, wenn du Bock hast. Ganz ehrlich, ich trage im Moment wirklich ein Konzept von Firma zu Firma und sage, weißt du was? Eure ganzen Konferenzen, die krebsen irgendwie rum, weil das ist mit dem JavaScript so, da kommt jetzt nicht mehr in der gleichen Geschwindigkeit Neues, wie das früher mal der Fall war.

Aber trotzdem gibt es halt eben noch ein riesiges, unentdecktes Land, womit halt eben auch der abgehärteteste Senior, der jetzt verstanden hat, wie rum man die KI halten muss, damit die einem Code generiert, wo der wirklich was Neues lernen kann. Der hat nämlich garantiert noch nicht wirklich durchdrungen, wie so ein Proxy funktioniert. Der hat den bestimmt schon benutzt, aber der hat das Ding noch nicht wirklich irgendwie mal durchdrungen.

Da hat noch nicht wirklich jemand mal erklärt, wie diese Private Properties in Klassen eigentlich wirklich funktionieren und wie das zum Beispiel mit so einem Proxy interagieren würde. Weil warum sollte man das? Das braucht man für den Alltag halt so einmal im Schaltjahr. Ja, ja, genau. Aber trotzdem wäre das halt wissenswert.

Genau, es ist so Spezialwissen. Also genau, habe ich ja auch so divers. Aber manchmal gibt es eben dann doch diese eine Situation, so wie jetzt bei dir mit dieser, ja, mit der Error-Geschichte, wo man halt dann so, wo es einem dann wieder einfällt und man sagt so. Dafür braucht man es. Zum Beispiel habe ich mal irgendwann einen Workshop gemacht zu, aber sozusagen einfach als Tweet für mich selber, weil ich da Bock drauf hatte, zu HTML5-Canvas-Programmierung.

Also wie man da quasi prozedurale Kunst mitmacht oder eben Dinge erzeugt oder Feuerwerk oder Bäume wachsen lässt und so. Und ich glaube zwei Jahre später oder so hatte ich eben eine Anfrage, wo genau das gefordert war. Ja, wo es gefordert ist und natürlich sind andererseits solche Sachen auch immer, also ich habe bei so Kisten wie so diese größeren Dinge, die so ein bisschen untypisch sind, wie halt zum Beispiel auch Canvas, ist es halt wirklich so ein Ding, wenn du das irgendwie so siehst und du kriegst irgendwie so deine Hallo Welt Demo, dann hat sich nicht wirklich in deinen Hirn schon reingefressen, wie du darüber nachdenken kannst und du hast das noch nicht wirklich durchdrungen und du musst dich da wirklich durch so einen Workshop durchkauen,

bis du verstanden hast, okay, das ist ein Paralleluniversum und so funktioniert dieses Paralleluniversum. Und das kann das und das kann das nicht. Und dann ergeben sich ja gegebenenfalls erst die Use Cases. Dann kommst du ja erst auf den Trichter. Ah, warte mal, das ist genau der Workaround, den ich da brauche.

Ja, genau. Bei mir war es eigentlich eher so eine Anforderung, eben was Bestimmtes visuell zu erzeugen. Und dann kannst du halt so, okay, mache ich das mit SVG? Kann man ja auch animieren oder womit mache ich das? Und dann, aber da ich eben diesen Background hatte. Habe ich dann gesagt, ja klar, HTML5 Canvas, machen wir da mit.

Ja, oder meine PDF-Render-Bug-Geschichte da, die ich da auch schon wahrscheinlich 150 Mal erzählt habe. Das ist schon lange her, darfst du auf jeden Fall nochmal kurz anreißen. Die Firma hatte Problem-PDFs werden erzeugt und auf manchen Geräten, wenn die Hardware-Beschleunigung im Betriebssystem aktiviert war, unter Windows wurden die PDFs nicht richtig erzeugt mit JavaScript.

War ein Problem, nicht in der JavaScript-Library, PDF-JS von Mozilla, sondern in Chrome, wo unter bestimmten Betriebssystem-Driver-Hardware-Kombinationen, einfach ein Rundungsfehler letztlich stattfand, wenn die Fontmetriken nicht richtig gesetzt waren. Und dann fehlten halt Buchstaben. Und wenn du halt irgendwie so ein Finanzunternehmen bist, ist das halt irgendwie nicht so toll, wenn aus der Tabellenzelle da plötzlich irgendwie die Eins vorne dran verschwindet.

Das ist ja schon ein bisschen bedenklich. Und irgendwie so per Administration zentral im Windows Du musst so Hardware-Beschleunigung abschalten, dazu war einfach die IT in dem Laden strukturell nicht in der Lage. Genau, ja, das willst du ja dann aber auch nicht, also weil das ist natürlich so, du fällst ja tief, wenn du das machst, ne?

Ja, gerade wenn du dann halt irgendwie so olle Thinkpads irgendwie am Start hast und auch nicht die fettesten, dann tut das halt irgendwie auch schon weh, ne? Lösung war halt eben, das Problem ist Hardwarebeschleunigung. Kann man dem Canvas-Element irgendwie sagen, Hardwarebeschleunigung abschalten? Nee, kann man nicht. Aber man kann das Canvas-Element dadurch, man kann dem Canvas-Element sagen, ich mache ganz viele Readbacks, also ich hole mir ganz viel die Pixel, die du da draufmalst, wieder aus dir raus.

Und dann ist es halt eine Optimierung tatsächlich nicht, dauernd die Daten hin und her zu shutteln zwischen Grafikkarte und CPU. Und damit hat man dann halt die Hardwarebeschleunigung ausgeschaltet. Und das ist quasi so eine Art CSS-Will-Change-Ansage an die Canvas und dann bereitet die sich entsprechend da auch vor.

Will-Read-Frequently heißt das, genau. Und du machst es dann aber gar nicht, sondern du. Veräppelst sie sozusagen. Genau. Und weil man das natürlich nicht zu Mozilla hintragen kann, von wegen, ey, macht mal euer Programm langsamer, damit der Chrome-Bug repariert ist, haben wir das dann damals einfach in den, Canvas-Prototype reingepatcht, dass immer, wenn man GetContext aufbietet.

Das mache ich übrigens gerne. Ach, das machst du gerne, aber Symbols nicht, ne? Das ist zu spooky. Genau, wir haben auch noch gleich was, da überlege ich auch, ob ich das noch reinpatche. Da kommen wir noch zu dem Thema, hoffe ich. Aber das ist jedenfalls so, es ist halt so, wenn du halt sozusagen diese extra Meile gehst und halt wirklich, verstanden hast, wie die Wurst unter der Haube wirklich gemacht wird und auch die obskuren Sachen hast, dann hast du halt einfach mehr Sachen im Werkzeugkoffer.

Brauchst du den Trennschleifer jeden Tag? Nee, du brauchst wahrscheinlich jeden Tag einen Hammer. Aber wenn du halt den Trennschleifer brauchst, dann gibt es halt auch keinen Ersatz für den Trennschleifer. Nee. Naja, genau. Also es lässt sich halt vorher auch nie sagen, was unnützes Wissen bleibt und was eben nicht.

Hängt dann eben auch vom Zufall ab. Ja, und wenn dein Weltbild präziser wird, war das Wissen nicht unnütz, ne? Mhm. Ja. So, dann ist das trotzdem auch was wert. Vielleicht halt nicht unmittelbar monetär ausdrückbar. Aber dann wunderst du dich weniger, wenn du eine JavaScript-Datei aufmachst. Ja. Davon können wir alle mehr gebrauchen.

Ja, cool. Oder CSS. CSS ist ja mehr so die Bednoir der Enterprise-Entwickler. Genau, da passiert ja auch mehr als im JavaScript-Bereich, wobei ich auch finde, dass sich so ein ganz bisschen verlangsamt hat da. Also marginal, marginal. Genau, also aber genau, passiert noch viel generell in diesem UI-Bereich natürlich und immer wenn eine Google I.O.

Ansteht, passiert da auch sehr viel. Das Google I.O.-Driven Development. Ne, also was jetzt kommt oder schon da ist und teilweise da ist und teilweise noch kommt, ist das CSS-Keyword Stretch. Und das ist ganz praktisch, wenn man Width oder Height setzt und möchte, dass ein Kind-Element eben den zur Verfügung stehenden Eltern-Element die Content-Box ausfüllt.

Ist das so mein neues breite Höhe 100%? Genau, aber mit dem Vorteil, dass bislang, wenn du, lass mal überlegen, also wenn du Padding hast, dann ist 100% ja nicht die Contentbox, meine ich. Und dann hast du halt das Problem, da musst du mit Kalk arbeiten und musst dann quasi in dem Kind-Element sagen, also Höhe 100%, aber abzüglich der Paddings meines Eltern-Elements, damit du dann auf die richtige Höhe kommst und irgendwie das nicht weiter auseinanderdrückst oder eben einen Scroll-Container erzeugst. Ja.

Genau, und das kannst du halt jetzt mit Stretch machen. Warte, warte. Dann ist Stretch also ähnlich zu Position Absolut in Set 0 oder für die Eltern unter uns Top Left, Bottom Right 0. Es macht ja keine absolute Positionierung, ne? Nee, nee, es macht keine absolute Positionierung. Aber auch das, was du gerade sagtest, würde auch Padding ignorieren.

Also du würdest dann, genau, du wärst dann wirklich an der Außenkante, also Border wäre dann noch immer davon losgelöst, aber deine Paddingbox wäre dann auch überdeckt. Ja, okay. Also es ist eigentlich eher wie bei Flexbox. Also wenn du jetzt zum Beispiel einen Flex-Column hast und du hast halt eben oben 20 Pixel und unten 20 Pixel Ding, das eben weder wächst noch schwingt und dann hast du eben dazwischen, der restliche Raum wird dann eben benutzt für das mittlere Element und das kannst du eben dann mit Stretch machen. Genau, also.

Ich meine, mit Kalk ging das ja bisher auch oder du machst es mit Position Absolut, wie du gesagt hast, aber dann müssen halt die Offsets eben dem Padding entsprechen. Dann würdest du das quasi auch aufspannen im Contentbox. Das Kalk setzt ja auch voraus, dass du sozusagen griffbereit hast, was das Padding ist und dass du nicht generalisiert sagst, ich schmeiß dich da rein und du füllst das jetzt aus.

Genau, also das ist natürlich auch noch so ein Ding, wenn das voneinander losgelöste Komponenten sind. Klar, du hast halt irgendwie Design-Tokens und vielleicht passt es dann, aber vielleicht weißt du es auch einfach nicht, was das Padding ist oder du baust irgendwas, dass irgendwelche Leute überall reinschmeißen können.

Naja, und dann ist halt Stretch super und ich glaube in Chrome gibt es das. In den anderen Browsern, da findet man das unter Webkit Fill Available. Also das gab es auch natürlich vorher in Chrome schon. Also man kann es eigentlich überall einsetzen, als Webkit-Fill-Available, Aber jetzt hat es eben dann auch den Weg in die, also den offiziellen Weg in die Specs gefunden und es ist nicht einfach nur ein von Safari initial implementiertes Ding, das dann natürlich durch den Fork auch in Chrome gelandet ist und dann von den anderen Browsern gepolyfilled oder retrofitted wurde für eben die ganzen EntwicklerInnen, die die halt Repkit-Prefix-Sachen benutzen.

Okay, das ist also jetzt, wenn ich es richtig verstanden habe, das ist jetzt Baseline? Ne, das ist nicht Baseline, aber man kann es überall benutzen und es kommt natürlich dann auch überall. Moment, dann versteht man den Unterschied zwischen Baseline und man kann es überall benutzen nicht. Naja, es ist nicht Baseline, weil es gibt es zum Beispiel in Firefox nicht.

In Firefox heißt das, da haben wir es, die Support Table. Also Chrome hat es und Safari und Firefox haben es nicht. Aber es ist trotzdem Baseline, weil du es eben unter dem alternativen Namen Binnenstrich WebKit, Binnenstrich Fill, Binnenstrich Available nutzen kannst. Das ist quasi deren Keyword, aber es ist eben kein... Aha, es ist kein Baseline, weil man tatsächlich diesen Workaround braucht.

Man muss einen Vendor-Prefix machen wie früher in der guten alten Zeit. Und das ist den feinen Herren von der Baseline-Abteilung nicht gut genug. So sieht's aus. Ja, die sollen sich aber nicht so anstellen. Ja, Schweinerei. Also wir mussten früher den Kaskadenberg so hoch in beide Richtungen, bei Schnee im Winter.

Mit MS-Präfix und O-Präfix. So, mit MS und O-Präfix. So sieht es mal aus. Und nicht zu vergessen das K-HTML-Präfix. Von dem Urahmen des Webkit-Präfix. Lang ist es her. Es ist schon besser geworden, ne? Ja. Okay. Dann hast du wieder was Übles hier. Aus der Abteilung Features, die keine alte Sau braucht.

Ja, Atomics WaitAsync. Idee ist, man nehme sich einen Shared Array Buffer, dass man also im Prinzip so ein Byte Array hat, das man zwischen mehreren Browsing-Kontexten teilen kann. Also Browser Fenster, Webworker hast du nicht gesehen. Und dann ist das ja geteilter Memory. Und dann gibt es die Atomics API, mit der man da drauf rumschreiben kann, ohne sich da gegenseitig die Daten zu korrumpieren.

Alles ist schön, aber ich würde ja annehmen, dass man mitkriegen möchte, wenn die andere Partei irgendwas fertig geschrieben hat. Und dafür gab es halt lange Zeit nur Atomics.wait, wo man irgendwie sagen konnte, ey, guck mal auf diese Daten in diesem Array-Buffer rein und sag mir halt eben Bescheid, wenn die da drin sich geändert haben.

Und das Ding ist, dieses Atomics-Wade ist tatsächlich eine blockierende Funktion gewesen. Kurze Zwischenfrage, also war das dann genau dieses Wage, also das hat man eigentlich dann, also wenn die Atomics quasi blockiert waren, weil ein anderer gerade drin rumschreibt, ein anderer Prozess. Ja, beziehungsweise es gab ja, oder es gab halt keine Änderung.

Das kann ja genauso gut sein, der andere Prozess macht auch nichts, sondern man sitzt halt eben da einfach drauf rum und wartet. Okay, also das macht man auch sozusagen nicht nur, wenn es gerade blockiert ist, weil jemand anders drin schreibt, sondern einfach so präemptiv, waited man immer, damit man immer mitbekommt, wenn sich was ändert, zum Beispiel.

Ja, genau. Das ist so die Idee. Du willst halt irgendwie so Sachen haben, also das Einfachste, wenn du einfach so einen Locking-Mechanismus hast. Von wegen, ist das jetzt irgendwie fertig? Kann ich da jetzt das auslesen? Hat da jetzt jemand irgendwie seine Message reingeschrieben, so ähnliche Kisten?

Dieser Gestalt ist das. Und ja, wie gesagt, es gab halt nur diese Wait-Methode, von dem Atomics-Namespace und die war halt synchron, das heißt, die konnte man de facto nur in Webworkern verwenden. Einziger Workaround außerhalb dieses Kontextes war halt irgendwie sowas mit einem Request-Animation-Loop periodisch per Polling quasi zu checken, ob sich da was getan hat.

Und jetzt haben wir halt Wait-Async, das macht das gleiche wie Wait, gibt einem aber ein Promise, das heißt, wir können da jetzt asynchron drauf warten, also so entfällt dieser Request-Animation-Frame-Worker-Route. Ja, okay. Also damit der ein und derselbe Web-Worker oder Worker, nicht Web-Worker, sondern Worker, andere Dinge auch noch machen kann.

Ja, das natürlich auch. Das ist jetzt so ein weiteres Ding. Aber vor allen Dingen macht es halt das Warten im Frontend, also in der Gegenseite halt einfacher. Weil der Worker könnte ja theoretisch halt eben blockieren. Also der idealtechnische Worker ist ja tatsächlich so irgendwie, du hast da ein so ein Teil drin, Und das macht halt so auf Zuruf eine Aufgabe und beendet die Aufgabe und dann ist fertig.

Oder das Frontendial im Prinzip ständig multitasken muss. Das heißt, es ist quasi für den Main Threat gedacht, dass der eben Dinge tun kann und nicht blockiert wird, wenn er selber waitet darauf. Genau. Beziehungsweise ist es ja eigentlich ein Unding gewesen, wie man das vorher auf dem Main Threat machen musste.

Ja. Und warum macht man dann wait und warum gibt es kein Event, das geworfen wird? Also sowas wie bei Local Storage oder so, wenn Storage changes und so? Wer müsste denn das Event werfen? Also welches Event-Target? Wo hängst du deinen Listener drauf? Ja. Achso, weil das im Grunde kein, ja, weil du, weil das manifestiert sich einfach nicht im DOM als Dings.

Das ist ja auch gar nicht möglich, du kannst ja einfach so ein standalone Event-Target haben, das ist nicht das Problem. Aber du könntest halt eine beliebige Anzahl an Shared Array Buffers haben. Und die Atomics API ist ja bloß ein Namespace, wo die diversen Methoden für den Umgang mit diesen Buffern rumliegen.

Ja. Und das wäre, glaube ich, dieses richtige Event-Target. Und ich würde halt auch erwarten, weiß ich jetzt halt nicht sicher, aber normalerweise sind ja native Events asynchron, machen also ihren Trip über den Event Queue und vielleicht will man das nicht haben. Ja, okay. Ja. Oder vielleicht gab es auch einfach vorher einfach nicht die Notwendigkeit, wenn man sich halt dachte, machst du halt im Frontend deinen Request-Animation-Frame-Workaround.

Am Ende benutzt diese APIs eh so gut wie keine. Von daher ist das vielleicht auch nicht so höchste Priorität gewesen. Mhm. Aber jetzt ist es da und das macht halt, wenn man mal mit dem Kram rumspielt, immer viel Spaß. Periodisch gucke ich ja immer, ob es sich lohnt, irgendwie ein Single-Page-Application-State irgendwie in binär zu serialisieren, in so einen Shared-Array-Buffer reinzuschreiben und dann so ein State-Management in Anführungszeichen irgendwie im Worker zu machen, um halt den Main-Thread freizukriegen.

Es ist bisher mir nicht irgendwie aufgefallen, dass es das wert wäre. Weil immer dieses Serialisieren halt einfach so viel länger dauert, als es halt wäre, entweder das State Management eh auf den Main Threads zu machen und sich halt mit der Performance ein bisschen Mühe zu geben oder zum anderen, wenn man halt eben tatsächlich in den Webworker reingehen muss und schickst halt eine Message durch die Gegend.

Das dauert auch lange im Vergleich, aber weniger lange als irgendwie eine Userland-Implementierung von mach aus JSON, Binärdaten oder sowas. Ja. Ja, vielleicht ist es ja auch was, das einfach noch nicht so durchoptimiert ist oder so, weil es eben vielleicht auch zu wenig Leute benutzen oder so. Weiß ich nicht.

Die Leute, die es benutzen, in dem Sinne gibt es ja schon. Also wenn du jetzt wirklich irgendwie, ich schicke jetzt JSON-Payloads für eine Single-Page-Application durch die Gegend. Da ist ja sicherlich es schon so, dass du tatsächlich Protokolle sprechen kannst, die nicht plaintext sind, die sehr viel effizienter sind.

Und da gibt es ja sogar eine breite Auswahl. Und auch verschiedene Implementierungen von diesen breiten Auswahlen. Aber das lohnt sich halt alles im Frontend nicht. Weil in dem Moment, wo du sagst, okay, ich rendere jetzt ein Extra-Listen-Element in meine Seite, da manifestiert sich am Ende ein Performance-Problem, wenn existent.

Und der ganze Rest ist eigentlich komplett egal. Und je mehr man darauf rumoptimiert mit Multithreading oder Binär-Serialisierung, umso schlimmer macht man es bloß. Es gibt halt einfach keinen Ausweg für das schnelle Frontend, als da halt einfach mit so wenig wie möglich, so viel wie möglich zu erreichen, das CSS schlau zu schreiben und halt nicht 7 GB JavaScript zu laden als allererstes.

Kein Code ist so schnell wie kein Code. Blöder Spruch, aber stimmt halt leider. Ja, da ist es recht. Genau, das ist auch Baseline jetzt. Also so richtiges Baseline, nicht so wie WebKit Fill Available, sondern... Baseline, Baseline? Genau, also in allen Browsern steht das jetzt zur Verfügung. Und was auch neu Baseline ist, ist CSS Scopes, also AdScope. Juhu! Ja, ja, ja.

Genau, und da kann man zumindest in Betracht ziehen als eine weitere Technik, dieses Scoping, um eben Style-Leaking zu verhindern, was man bisher eben mit zum Beispiel. Namenskonventionen geregelt hat oder was man mit CSS-Modules geregelt hat oder solchen Techniken. CSS-Modules meint natürlich auch im Hinblick auf Ende der Sendung, dass man so React-Style CSS in JavaScript macht, ne?

Ja. Weil man da dann Klassennamen automatisch generieren kann. Also du hast jetzt gleich gesagt, Namenskonvention. Das ist ja das einzige Wittel, das du mehr oder minder hattest bis dato, ne? Entweder überlegt sich ein Mensch vernünftige Namen oder es überlebt sich ein Programm unvernünftige Namen. Aber Hauptsache, sie sind eindeutig zuordnbar und man verliert nicht den Überblick.

Ja. Oder du nimmst halt sowas wie Taegund. Und das sozusagen die umkehrt, was worauf zeigt. Also bei Tailwind ist ja sozusagen das DOM, was auf diverse Stylingfragmente zeigt. Und wir arbeiten ja eben, und Selektoren sind eben Dinge, die ins DOM hineingreifen, und da auch irgendwie großflächig unterwegs sind, wenn man Pech hat.

Halte ich jetzt aber für eine Variante von Mensch hat sich Klassennamen überlegt. Genau, aber du hast halt eben keine strukturelle Konvention. Also es ist jetzt nicht sowas wie Eltern-Kind-Beziehung oder ja, aber im Endeffekt endet das am Ende den CSS-Modules, den erzeugten Namen auch. Also ich wollte halt sagen, es ist halt Durchspielungsspielräume von wegen, wer hat sich die Klasse ausgedacht und wie ist es passiert?

Algorithmisch oder per irgendwie BEM mit so Systematik oder per Tailwind mit, ich hab mal meinen Kollegen da unten in der Hölle angerufen und hab so gefragt, was wäre das Übelste, was man machen kann. Genau und jetzt geht das eben auch mit Added Scope und da gibt es ja verschiedene Varianten, also ich glaube, ich hab das schon so ein paar Mal rausgehört, also Deine liebste Variante ist ja, einfach Style-Tags vor die Elemente zu hängen, die man stylen möchte oder in die Elemente, die man stylen möchte und dann einen Ad-Scope zu verwenden und dann gilt das quasi für das aktuelle Element.

Richtig? Ja, ich überlege halt immer so, wie kann ich halt meine Wertenentwicklerinnen und Entwickler, die so in meinen Workshops rumsitzen, wie kann ich die halt mächtiger machen? Wie kann ich die upgraden? Was kann ich denen beibiegen, dass sie halt einfach mehr auf die Reihe kriegen? Und das wird ja üblicherweise über den Angriffsvektor von installieren noch mehr JavaScript-Tools gemacht.

Und ich denke halt eben, wenn man einfach den Menschen, die damit eigentlich nur in zweiter Ordnung was mit zu tun haben wollen, sagen kann, guck mal, du kannst dir einfach eine ganze Menge Kram ersparen, wenn du das verwendest, dann fängt es eigentlich immer besser. Wenn ich irgendwie eine Lösung haben kann, die dann irgendwie einfach so, die da abholt, wo sie schon sind.

Und ich denke halt bei sowas wie AdScope und dem Szenario, das du gerade aufgemacht hast, meine Komponente. Ist halt einfach so ein bisschen HTML und da klemm ich CSS direkt rein mit so einem Style-Block und AdScope. Da kannst du halt wirklich theoretisch sehr viel dann machen, wenn du einfach so ganz banales, so 2000er-Style serverseitiges Templating hast.

Du hast irgendwie PHP mit Twig-Templates oder du machst irgendwelchen Java-Krempel. Da hast du ja auch Komponenten. Deine Komponenten sind nicht irgendwelche React-Kisten, sondern das sind halt einfach irgendwelche Sachen, die auf dem Server existieren. Aber du denkst über die gleiche Sache darüber nach.

Und du hast dann immer CSS noch mehr als in einem React zum Beispiel, als ein Fremdkörper, was in dieses System halt einfach nicht reinpasst. Und deswegen führt halt immer so diese, was ich vorhin so meinte, mit die Bad Noir der richtigen Entwickler, ist CSS. Weil das halt so ein komplettes Out-of-Context-Problem war, das halt nicht sich irgendwie in so ein PHP-Trick-Template irgendwie reinbauen ließ auf vernünftige Weise.

Und das wird halt jetzt einfach mal zur totalen Trivialität. Du kannst halt einfach hingehen, Du kannst in deiner serverseitigen Anwendung da bleiben. Du schmeißt noch View-Transitions rein. Du optimierst deinen Server, dass es alles schön lädt. Das ist halt wirklich eine Möglichkeit, womit du die Leute von Single-Page-Applications fernhalten kannst.

Ich hatte wirklich einen Kunden, der sagte, hier, Peter, berat mich mal, soll ich jetzt Next.js oder Web-Components nehmen? Ich bin hier so ein Ein-Mann-Mensch und ich programmiere mit einem PHP-Backend diese Anwendung und ich möchte eigentlich mit dem Frontend so wenig wie möglich zu tun haben. Next.js oder Web-Components?

Ja, also beides würde ich sagen für so jemanden anstrengend. Wahrscheinlich hast du auch weder das eine noch das andere empfohlen, aber... Ja, ich habe halt gesagt, was ist denn deine Browsermatrix? Und er sagte so, ja, ich habe Chrome und okay, und was willst du erreichen? Ich will halt vor allen Dingen, dass das CSS weggekapselt ist.

Da habe ich gesagt, okay, du hast Chrome, AdScope gibt es schon, das erschlägt schon mal 80% deiner Probleme, dann kannst du einfach weiter dein PHP schreiben den ganzen Tag und guck mal, ob du mit Vanilla JavaScript die letzten 20% erschlagen bekommst. Ja. Und war halt der Fall. Und seitdem habe ich von dem nie wieder was gehört, weil vermutlich alles funktioniert.

Aber könnten diese PHP-Menschen nicht also auch die AdScope-Rules in ihrem, die haben ja irgendein CSS, irgendein zentrales, da nutzen? Oder ist es eher, weil du sagst, wir haben ja gerade darüber gesprochen, dass man eben den Style-Element in das, in den Container, in den Root dieses gekapselten Element oder der Komponente setzt und dann einfach AdScope verwendet.

Genau, könnte ja sein, dass sich das dann über die Seite wiederholt und so. Vorteil ist wahrscheinlich, den du siehst, den ich auch sehe, ist, dass man dann einfach diese Datei löscht und dann ist das CSS mit weg. Das CSS ist dann mit weg. Es ist halt auch, Colocation ist halt von Vorteil. Genau, aber eben sozusagen Colocation für Arme.

Ohne das Böse zu meinen, aber eben ohne Aufwand und dass man da nochmal eine separate CSS-Datei in dem Folder liegen hat, die dann irgendwie weggebandelt werden muss zu einem großen CSS. So genau, das muss nicht weggebandelt werden. Du hast halt also einmal die simpelstmögliche Variante von Co-Location.

Und in einem perfekten, reibungslosen Universum, sphärischer Entwickler und so, da ist ja die einfachste Variante immer die beste und die einfachste Variante ist, es gibt eine Datei und da steht drin, was die Komponente macht. Das ist ja mehr oder weniger das Erfolgsmodell von auch so Kisten wie React.

Du willst wissen, was dein Foo-Button macht, dann gibt es eine Komponente, da steht was drin. Und dann musst du halt eben damit leben, dass halt dann seltsame Sachen wie irgendwie CSS-Modules gemacht werden, um das auch zu implementieren. Und damit holt man das Ganze halt eben in die Welt. Also Single-File-Component-Ansatz letztlich.

Und damit holst du das halt eben in die Welt der Backend-Entwickler, ohne dass die irgendwas installieren oder lernen müssen. Du sagst halt nur, schreib den ganzen Krempel, den du sowieso schreiben würdest, aber mach halt eben so diesen Talisman, AdScope da oben drüber. Und wenn du irgendwie so Sachen hast wie Komponenten, Slots, gleichsam, wo was anderes reingerendert werden kann, der Scope kann ja auch so ein From-To machen, dass man so eine Donut-Form quasi ausstanzen kann.

Und dann ist das halt wirklich einfach der totale No-Brainer. Man braucht halt null Tools, null Nachdenken. Was ich halt immer sehr schön finde, es ist nicht so wahnsinnig schwer, eine gute CSS-Namenskonvention zu pflegen, mit BAM oder so. Das ist absolut machbar. Aber wenn man es nicht machen muss, ist es noch besser.

Und deswegen bin ich zum Beispiel bei meinen Web-Components so großer Fan von Shadow DOM, weil ich halt eben sagen kann, okay, ich hab halt hier so ein 100 Zeilen CSS free for all, da kann ich mich aufführen wie die letzte Sau, kann Importen verwenden und alles, weil ich weiß, dass ich damit keinen größeren Schaden anregen kann.

Das ist mein Wellebutt, in dem ich einfach mal sagen kann, ich kann das CSS so verwenden, wie es halt auch mal gedacht war. Ich schreib mal Haufen von sich gegenseitig widersprechenden und überschreibenden Regeln. Das ist, wofür es gemacht ist. Das ist, was es gut kann. BAM und Konsorten sind Workarounds dafür.

Und das ist ja nichts weiter als sozusagen eine Non-JavaScript-Variante dessen und die geht jetzt in allen und allen Browsern und meine Güte, selbst ich in meinem Web-Component-Universum habe just heute Morgen ein bisschen Code geschrieben, wo ich so dachte, okay, ich habe jetzt eine Variante von dieser Sidebar gebaut und das kommt an dieser einen exakt einzigen Stelle, an dieser einen Stelle in meiner Applikation vor. Das existiert ein einziges Mal.

Und jetzt muss ich erstmal rausgucken, in welche von meinen drei CSS-Files muss es rein. Und wie muss ich das gemäß BAM nennen und hast du nicht gesehen. Versus, ich schreibe einfach einen scheiß Style-Tag für so eine One-Off-Problematik da rein. Ja. Manchmal ist die einfachste und die billigste und die dreckigste Lösung die korrekte.

Wahrscheinlich, genau. Wenn das der Hans-Christian Otto gehört, wird der mir den Hals umdrehen. Aber ich habe halt Recht. Ja, aber er kann sich ja nicht verteidigen, der ist ja nicht da. Ach, der ist aber mittlerweile so oft hier in der Sendung. Ja, das muss aufhören, Peter. Ja, also man muss halt aber dann damit leben, dass das eben jedes Mal, wenn man diese Komponente benutzt, dass eben dann auch dieses Style und, Element oder Style-Tag mit den Styles darin eben jedes Mal auch aufkreuzt.

Welche Probleme siehst du da? Weiß ich nicht. Ich sehe grundsätzlich erstmal keine Probleme. Ich glaube, das ist eher so ein ästhetisches Ding. Aber ich glaube, vielleicht sind das ja auch so, oder in den Kontexten, die du gerade genannt hast, hat man wahrscheinlich viele ästhetische Probleme. Da sind wahrscheinlich auch so Dinge wie JavaScript Doppelpunkt in Hariffs und so Sachen vielleicht öfters mal gang und gäbe oder inline On-Click-Handler und so zu drüben.

Nee, weil was ich meinem guten Freund da mit seinem PHP-Projekt auch gesagt habe, ist so, weißt du, es gibt davon auch eine JavaScript-Entsprechung und die heißt halt, mach ein Script-Tag, kein Module, sondern normale Script-Tag und dann machst du da drin Document Current Script Parent Element. Ja. So, das ist dann jetzt die, da würde ich jetzt wirklich sagen, das ist für Arme und dreckig.

Andererseits funktioniert es halt. Ich meine, wenn 80% deines Programms aus PHP-Code bestehen wird und du brauchst halt ein UI und das UI soll halt nicht aussehen wie Windows 95. Dann brauchst du CSS und JavaScript. Aber es wäre ja völlig verkehrt, von diesen restlichen 20% daraus aus der Notwendigkeit abzuleiten, dass das Ding, was eigentlich die 80%, was den Hauptteil trägt, dass der sich daran irgendwie ausrichten müsste. Hier gilt das Recht des Stärkeren.

Das sollte sich also wirklich der Rest nach dem richten, was halt hier ist. Von der ganzen Kompetenzfrage, ich bin halt hier, ich verstehe mich als PHP-Entwickler, ja, ich kann JavaScript, ich kann CSS, aber wenn ich die Wahl habe, schreibe ich halt PHP, Java, was auch immer. Da sollten die Leute in die Lage versetzt werden, das auch machen zu können, ihre Stärken auszuspielen und sich nicht irgendwie Next.js einzutreten.

Oder Web Components oder irgendwie so ein Blödsinn. Ich glaube auch, also, klar, du kannst da natürlich trotzdem noch Dinge irgendwie falsch machen, aber ich glaube auch, dass so eine Seite. Sehr schnell lädt, zum Beispiel. Also weil eben vorab nicht so viel geschippt werden muss. Du fällst da direkt mit der Komponenten-Markup-Tür ins Haus und dann streamt halt der ganze Krempel rein und mal ist es eben dann HTML, mal ist es ein bisschen Styling, dann ist es wieder ein bisschen JavaScript.

Ja, also passt. Was halt auch was ist, was der Browser halt ja tendenziell ganz gut hinkriegt. Ja, das kennt der ja. Und dann ist da halt ein bisschen CSS dupliziert. Oder weil wir aus viel CSS dupliziert. Interessiert den halt nicht. Du hast ein ganz anderes Problem, sobald irgendwann mal diesen Button anklickt und das aktiviert den CSS-Schatten.

Ja, aber weißt du, wann das richtig geil wird? Na? Wenn du irgendwann, wenn die nativen Mix-Sense kommen. Ja, weil dann hast du das recycelbare CSS, ne? Genau, und dann. Könnte, muss nicht, könnte eben das Ganze, dieser Styleblock eben schrumpfen, weil man einfach sich relativ oft an Fun and Mixins bedient.

Was ja tatsächlich auch bei meiner JavaScript-Idee mit dem CurrentScript Parent Element ein Problem ist, weil dann befindest du dich ja nicht in einem Modul notwendigerweise und dann kannst du halt auch nicht eben so einen Import machen. Das heißt, du reduzierst deine CSS und halt auch JavaScript-Capabilities damit halt deutlich, weil du halt nur noch an irgendwie globale Sachen ran kannst.

Und nicht irgendwie Fein-Import-Export machen kannst, aber da sind wir wieder bei der Sache, wenn 80% deines Projekts eh PHP ist, dann mach doch mal lieber den Teil richtig ordentlich und sei beim Rest halt ein bisschen oldschool und mach halt eben, okay, ich brauche eine geteilte JavaScript-Funktion.

Ich stecke die halt in einen globalen Scope mit so einem oldschool-Module-Pattern, wie so aus den frühen 2000ern. Ja, oder einfach quasi, dass du deinen Namespace hast, also Win oder Global Dodge Projektname und dann sind da deine Sachen drin. Ja, ganz genau so, wie wir das früher so 2006 oder so gemacht haben.

Das kann man immer noch so machen und... Soll ich dir mal was sagen? So mache ich das auch immer noch. Ich mache das manchmal genauso. Also wir haben in der Vorbesprechung ja kurz über hier so Invoker gesprochen, was wir ja schon im letzten Feature Roundup ja hatten. Genau, so Command-For und Command-Target.

Command heißt das einfach nur. Nur Command, ja. Was ja im Prinzip so ein Remote-Event-Invocation-Mechanismus ist. Ich klicke auf den Button, aber es passiert jetzt konzeptionell kein Klick-Event auf den Button. Klammer auf, das passiert ja trotzdem, aber darauf lausche ich nicht. Klammer zu, sondern weil es halt ein Command-Button ist, löse ich damit ein Command-Event auf dem Target aus, das halt im Command-Vor drin steht.

So, ist alles schön und gut. Problem ist halt eben dieses Command-Vor. Also was ist das Ziel dieses Command-Buttons? Das gebe ich als String an. Lange Rede, kurzer Sinn, kann man nicht verwenden, sobald man halt irgendwie mit Web-Components und Shadow-Root unterwegs ist, weil diese Strings gleichsam genamespaced sind.

So, das habe ich gemacht. Dann habe ich einen globalen Event-Bus eingeführt für die Fälle, wo ich halt Involker-Commands verwenden möchte, aber nicht kann. Das ist ein globales Objekt und das wird halt eben von dem definiert, der zuerst dieses Ding benutzen möchte und alle anderen lauschen drauf. Das ist halt eben genau das richtige Ding. Das kann man übrigens auch auf dem Symbol liegen, oder?

Du könntest das theoretisch machen, es ist tatsächlich bei mir auch ein Symbol. Also Global This, ein registriertes Symbol und dann halt eben, ist ein leeres Objekt oder wenn es schon da ist, Fragezeichen gleich. Ja. Da haben wir die Brücke auch zu den Symbols wieder zurückgeschlagen. Ich glaube jetzt nicht, dass irgendwer gewohnheitsmäßig über den globalen Namensraum iteriert, außer natürlich irgendwelche Fingerprinter.

Die würden halt das Symbol vielleicht nicht sehen. Genau. Nee, war jetzt auch nur so, einfach nur so ein, weil wir gerade darüber gesprochen haben. Also nötig ist es nicht, aber... Wo du es gerade sagst, eigentlich wäre das eine gute Idee für Browser-Extensions. Weil die stecken ja auch manchmal etwas in den globalen Namensraum rein für ihre Content-Scripts, weil sie das machen müssen.

Und das ist ja genau das, woran man ja tatsächlich gefingerprintet werden kann. Welche Extensions hast du installiert? Und ich weiß nicht, wie gut das noch funktionieren würde, wenn das Symbols wären. Weil also weil so ein Fingerprinter der guckt sich ja im Prinzip ein globales Objekt an macht daraus ein Fingerprint, in dem er es ja also ein Hash draus baut oder sowas, in dem er es ja quasi serialisiert.

Aber Symbols sind ja nicht serialisierbare Objekte, die sind ja nicht einfach nur ein Stand-in für ein String, also könnte man den damit glaube ich ganz gut Kopfrauchen auslösen. Das ist eigentlich auch eine gute Idee sollte jemand mal wieder eine Browser-Extension bauen, was man natürlich unter gar keinen Umständen möchte, weil es die Pest ist.

Ja, genau. Ja, vielleicht sollten die Browser-Hersteller das in ihren Guidelines mal unterbringen. Um zu AdScope zu kommen, du hast es ja eben gesagt, also es gibt ja diese Donut, also so wird es halt genannt, also so Donutscope, das heißt also, es wird nur das Element erfasst, aber und innen drin, wo man vielleicht einen Slot hat oder einen Bereich, wo wiederum andere Elemente reingesteckt werden können, der wird dann ausgespart, darum eben auch Donut, weil das halt dann so ein bisschen aussieht wie so ein Donut anstatt einem Krapfen oder einem Berliner, wie auch immer man das dann in verschiedenen Teilen der Welt nennt.

Was würden die Mathematiker sagen, damit man irgendwie schlau wirkt? Ist das dann ein Torus? Also der Donut wäre ein Toros, glaube ich, ja. Aber der Berliner oder Krapfen, da weiß ich nicht, wie man den nennt. Achso, jetzt weiß ich, was du meinst. Abgeklopfte Kugel. Deformierter Torus. Ja, oder rundgeschliffener Zylinder.

Ja, irgendwie sowas. Ja. Genau, das ist halt super praktisch, weil ansonsten hätte man das nicht, dann würde man zwar irgendwie das Element skopen, aber würde dann ja dummerweise vielleicht auch die Kind-Elemente darin, die irgendwie wieder fremde Komponenten sind, auch mit erfassen. Und dann hätte man nicht so richtig das Problem erschlagen.

Ich glaube, dass, ich weiß gar nicht warum, es gab ja mal diese Scoped Styles, also es gab ja mal Style mit dem Attribut Scoped, glaube ich. Ja. Die haben ganz genau so funktioniert, dass man die im HTML an die so in ein Element eingehängt hat und dann haben die eben alles innerhalb dieses Elements nur gestylt und die sind aber dann wieder deprecated worden.

Vielleicht war das auch das Problem, dass man eben das Donut-Problem nicht gelöst hat damit. Naja, und du hast ja noch andere Sachen, die das dann nicht lösen können, wenn es so ein HTML-Attribut ist. Weil, stell dir vor, du willst Sites haben, die dieses Feature haben, die also gescoped funktionieren, aber du willst sie irgendwie importieren.

Ja, du willst sie in einem quasi insgesamt in einem globalen Style-Sheet möchtest du das alles drin haben. Naja, du willst sie einfach nur heraufbeschwören über einen Mechanismus, der nicht HTML ist. Du machst den Style Sheet Constructor. Du machst den CSS Module Script Import. Import styles from foo.css.

Du machst add import im CSS Server. Irgendwie sowas, ne? Und dann funktioniert das ja schon nicht mehr, weil das ja tatsächlich etwas ist, was nur funktioniert im HTML-Kontext, weil es halt ein HTML-Attribut vorraussetzt. Das hier ist definitiv die bessere Lösung. Genau, also ich denke mal, das war auch eins dieser Jugend-Forsch-Geschichten damals so im Kontext von Web-Components, meine ich, oder?

Die HTML-Imports wahrscheinlich auch. Ja, naja, genau. Jawohl, genau, also das können wir jetzt auf jeden Fall beginnen zu nutzen, je nachdem, wie die Browser-Landschaft aussieht des Projekts, das man bearbeitet. Kann man das vielleicht früher machen, gegebenenfalls müssen wir auch ein bisschen warten.

Ach, ich glaube, wenn das hier raus ist, ich glaube, Firefox updatet sich ja recht zügig. Die ESRs vielleicht nicht, aber... Ja, ja, ja. Aber du hast natürlich dann schon... Ja, also genau, kommt immer drauf an. Also ich... Meinen Projekten sind die Leute, da gibt es halt einfach Leute, die noch auf Elton-Browsern festhängen, ausgründen.

Ja, okay, aber guck mal, mein Freund mit seinem PHP-Projekt, dem habe ich gesagt, go for it im Sommer. Ja, der hat das ja unter Kontrolle. Also der hat ja gesagt, irgendwie aktuelle Chrome-Version. Genau, oder Edge war es, glaube ich, bei ihm. Weil, ich meine, sehr viel Web-Frontends entstehen halt für den internen Gebrauch. Genau.

Ja, wenn du so Internet-Sachen hast, dann ist es natürlich immer super. Aber wenn du jetzt so Firefox ESR hast, dann ist es halt blöd. Oder du hast irgendwie Leute, die ihre Safaris nicht updaten, so wie ich, weil die keinen Bock haben, den Update-Kraft zu drücken. Ich benutze den allerdings auch nicht, muss ich sagen. Aber selbst beim Chrome, der Mac hat auch immer hier rum, neue Chrome-Versionen verfügbar.

Da ich meinen Rechner nie quasi neu starte, so gut wie nie, und meine Browser-Fenster nie zumache, bleibt das halt immer so, bis ich das dann mal mache. Dann hast du noch irgendwelche iOS-Versionen, die nicht mehr up-to-date sind. Oder du hast vielleicht irgendwelche TVs, je nachdem, was du ein Projekt mal hast, die ja auch immer etwas älter sind. Mhm.

Die Frage bei sowas ist natürlich immer auch, wie relevant sind die dann in deiner Zielgruppe? Genau, und was aber auch wichtig ist, ist, wie viel geht kaputt, wenn, also ist das was, was graceful degradiert, wenn jemand AdScope nicht versteht, also ein Browser. Und das ist in dem Fall ja nicht gegeben, so ein bisschen wie CSS-Nesting.

Das wäre ein Totalschaden. Genau. Ja, aber die Frage ist, wie groß ist halt das Problem? Was ist der Failure-Mut jetzt sozusagen dann am Ende substanziell für, was immer du mit dem Projekt zu erreichen gedenkst? Aber vielleicht können wir da nochmal darauf hinweisen, dass Can-I-Use ja die Möglichkeit bietet, zumindest Google Analytics Daten zu importieren.

Und dann kann man das eben für sein eigenes Projekt herausfinden, sofern man Google Analytics nutzt. Ja, aber auch da. Nächste Frage ist halt, okay, wie viele von denen, die wirklich mit einem Samsung TV von 1804 anrücken, wie viele von denen drücken auf Kaufen? Das weiß ich nicht, aber... Das ist wahrscheinlich auch sehr unterschiedlich.

So weit kommen die ja dann auch noch nichtmals. Wahrscheinlich besuchen die die Seite und dann bricht ja da schon alles auseinander. Ja, vielleicht auch nicht. Kommt halt echt drauf an. Also wenn ich irgendwie so, keine Ahnung, ich mache jetzt irgendwie Tagesschau.de oder so, würde ich halt eben auch alles supporten, was irgendwie noch gerade so eben zu betreiben ist.

Ja, genau. Aber wenn ich jetzt sage, ich verkaufe irgendwie High-End-Kaffeemaschinen. Nee, da muss man keinen Fernseher. Aber wenn man eben für Unterhaltung, also wenn man Sachen hat, die auf dem Fernseher auch funktionieren könnten und wo es ein valides Szenario ist, dann hängen die ja auch etwas hinterher.

Ja, gerade auch leistungstechnisch. Wenn man da mal versehentlich den Browser anmacht, ist echt schlimm. Genau, da ist übrigens hier mein Trick, den ich mal irgendwann erwähnt hatte, auch in der letzten Folge, die wir müssen unbedingt verlinken, das ist die 686, also die, auf die beziehen wir uns immer.

Da ist ja dieses Navigator-Device-Memory ist halt echt mega gut. Was ist das? Das war doch dieses, wo man so Leistungsdaten, also in Form von zur Verfügung stehenden Hauptspeicher bekommt, aber so in Buckets. Wegen Fingerprinting? Wegen Fingerprinting, genau, und die Fernseher haben da oft eher so 1 Gigabyte, also das wirklich unterste Kante. Ja.

Also dann mit dem memorytrumpcard.gov aufrufen wäre mal ein Versuch wert. Wie meinst du das? Man kann ja nicht messen, wie viel die Seite verbraucht. Nein, ich will nur wissen, was der Fernseher macht, wenn man versucht, diese Seite aufzurufen. Ach so, ja, das ist eine gute Frage. Kann ich ja mal testen.

Also ich meine, wie oft hat man schon das, wenn man wirklich auf dem Fernseher einen Out-of-Memory-Error auslöst? Ich glaube, ja, der äußert sich dann wahrscheinlich einfach, ja, was wird man dann haben? Ja, wahrscheinlich, wenn es Chromium ist, hat man dann wahrscheinlich auch hier dieses Gesicht mit den geäxten Augen oder sowas.

Ja, bei Safari ist das ja so, der Browser ist ja einfach weg. Da stürzt es dann einfach ab, wenn er out of memory geht. Das ist dann auch immer schön, wenn man das debuggen möchte. Nichts besser als das. Da channelt man so die C-Programmierung der 90er wieder. Naja, genau. Alles schon gehabt. Natürlich. Genau, was wir noch nicht gehabt haben, was aber jetzt auch neu ist, noch nicht Baseline, aber auf gutem Weg dahin, ist eine neue DOM-Methode namens MoveBefore.

Die funktioniert eigentlich wie InsertBefore, mit dem Unterschied, dass also Insert Before erlaubt es, Elemente im DOM-Baum umzuhängen. Also auch neue Elemente einzuhängen, aber eben auch Elemente umzuhängen. Und wenn man vielleicht auch so DOM-Diffing-Algorithmen hat oder sowas, dann nutzen die oft Insert Before, aber damit wird sozusagen das Element, das ausgehängt wird, abgerissen und, oder nicht abgerissen, aber der verliert seinen State und wenn man das wieder in den DOM einhängt, dann startet das wieder mit einem neuen State, eine CSS-Animation, läuft dann wieder ein Video-Element, spielt vielleicht nicht mehr und ist wieder am Anfang.

All solche Dinge und mit Move Before kann man das gleiche tun, aber den State Preserve, iFrames sind auch noch so ein Ding, die müssten dann auch nicht neu laden und sowas. Ja. Und das ist sozusagen einfach eine bessere Variante für, wo man Inside Before hatte, muss man halt eben jetzt gucken, was mache ich damit?

Und wenn ich wirklich nur Sachen durch die Gegend geschoben habe, ist halt Move Before der bessere. Anwendungsfall. Genau, und das wäre auch dieses Ding, wo ich meinte, also ich belege gerade, ob ich im aktuellen Projekt das, also Prototype-Patching betreibe, indem ich eben das, was also alle Aufrufe von Insert Before ummappe auf Move Before.

Äh. Das könnte bei dir ganz gut funktionieren? Ja, genau. Also ich würde das nicht, generell würde ich das nicht empfehlen, weil ich glaube, sonst hätten die das ja auch einfach in das Original eingebaut, aber genau, ich würde es zumindest mal ausprobieren wollen bei mir. Ja, oder halt eben einfach so stückweise ausrollen. Es ist ja nicht so, dass Insert Before weggehen würde. Wenn man kein Problem hat, muss man es ja nicht reparieren.

Aber halt eben ab jetzt das im Kopf behalten. Ein einziges Problem daran ist ja, es gibt ja so Features, die sind in der Webplattform und die kannst du verwenden oder du kannst sie ignorieren. Aber dann gibt es ja auch immer so Sachen, die du nicht ignorieren kannst, auch wenn du sie nicht verwendest.

Ja, okay. Und das ist so ein Fall? Das ist tatsächlich so ein Fall. Weil du hast ein Custom Element, ein Web Component, und du machst Insert Before. Auf Web Component kannst du natürlich anlegen, ein Connected Callback und ein Disconnected Callback. Und wenn du ein Insert Before machst und ein schon eingehängtes Element über diesen Mechanismus dann das hinschiegt. Du hast wahrscheinlich ein Disconnect und Connect, oder? Richtig, genau.

Was passiert, wenn du das mit einem Move Before machst? Gar nichts. Genau das Gleiche passiert. Echt? Okay. Weil das Element wird ja trotzdem irgendwie verfrachtet und es hat sich ja was an seinem Zustand geändert. Inwieweit hat sich da was am Zustand geändert? Es ist halt jetzt woanders. Und wenn du halt an deiner Component, in der ja beliebige Logik existieren kann, wenn du zum Beispiel sagst, ey, ich höre jetzt auf das, was mein Elternelement macht oder so.

Das ist jetzt irgendwie nicht optimales Design, so aus HTML-Element-Sicht, weil normalerweise sind die Dinger ja nicht aneinander gebunden, aber bla, die Leute machen halt Zeug. Und du willst ja mitkriegen, okay, bin ich jetzt, also 1, 2, 3, einen Zeitpunkt muss ich ja abfangen, wann ich in einem anderen Eltern-Element sitze.

Und du hast deine Komponente ja bereits geschrieben unter der Annahme, dass move before nicht existiert. Jetzt gibt es plötzlich move before, aber deine Komponente ist so gesagt, dass der Verfraktungsmechanismus insert before ist, der immer diesen disconnected-connected-Mechanismus nach sich zielt. Ja.

Und deswegen muss halt ein Move-before, das nicht Insert-before ist, also eben kein Connect und Disconnect macht, trotzdem die Disconnect und Connect-Events auf der Wert-Component auslösen. Mhm. Was natürlich heißt, dass man da diesen Benefit tatsächlich zu einem großen Teil nicht realisieren kann. Weil wenn du halt in deinem Connected und Disconnected-Ding irgendwie Setup und Teardown machst und du machst das trotzdem, obwohl das nicht nötig sein sollte, weil ja die Intention von Move Before ja ist, es soll im Prinzip alles bleiben, wie es ist.

Es soll jetzt nur halt woanders wohnen, ist es ja ein getrennter Use Case. Und deswegen gibt es natürlich jetzt auch noch neben dem Connected und dem Disconnected-Callback auch noch den Connected-Move-Callback. Und der wird halt eben getriggert, wenn halt eben dieses Move-Dings passiert. Okay, aber wie würde man dann, also an welcher Stelle würde das getriggert werden?

Also bevor der Disconnect kommt oder wann? Der Connected-Move-Callback, wenn vorhanden, wird getriggert, wenn Move-Before eingesetzt wird, anstelle von Connect und Disconnect. Ah ja, okay. Wenn du den nicht angibst, funktioniert weiter dein Connect-Disconnect wegen Abwärtskompatibilität. Aber wenn du die bessere Alternative hast, wenn du also sagst, ich will diesen Fall spezifisch händeln, dann wird diese Handling-Logik auch angetriggert und die normale Disconnect- und Connect-Variante nur, wenn halt wirklich Disconnect und Connect passiert, wie zum Beispiel mit Insert Before. Ja, okay.

Und mir fällt gerade ein, ich habe Connected Move, glaube ich, in Ordnung, noch gar nicht unterstützt und sollte das mal so langsam tun. Ich glaube, einfach weil meine Browser das nicht unterstützt haben und deswegen war das nicht zu testen. Ja, jetzt gibt es es in Chrome und in Firefox. Ja, dann sollte ich mal Gas geben.

Aber hallo. Und wahrscheinlich, bis diese Folge raus ist, kann es sogar der Safari. Ich weiß gar nicht, wie es da aussieht. Wie sieht denn da... Was sagt denn MDN zu Move Before? Haben wir das schon in der Technology Preview drin? Es hat ein No mit Sternchen. Da gibt es den Webkit-Bug dafür. Okay. Dann kannst du dich damit noch herauslavieren. Ja.

Ja, einzige Aktivität ist da drin, dass Leute fragen, ob es Fortschritt gibt. Gut, das braucht man die Webkit-Leute eigentlich nicht fragen. Also da kann man vielleicht die Codebase beobachten oder sowas, aber genau, das werden die denen nicht sagen. Weißt du, da wäre vielleicht mal eine KI ganz sinnvoll, die einfach auf sowas immer antwortet, nein.

Stimmt, ja. Genau, die sich auch immer auf die Codebase bezieht. Nein, guck mal da hat schon niemand was implementiert seit 1804, wie wär's Ja, aber so viel Token-Count hast du wahrscheinlich gar nicht, um die ganze Codebase von so einem Browser da reinzustecken, Ja, ich mein, Apple hat sich ja bisher nicht so overinvested wie die anderen, die haben also noch ein bisschen was in der Hinterhand, ich glaub, die können sich da einfach ihr eigenes, und es ist ja nicht so komplex Entweder das oder die warten ab, bis alles implodiert und dann können sie sich die ganzen Leute für billig holen, Ja, aber ich glaube, wenn wir eh schon so spät dran sind, dann richtig.

Ich glaube, sie haben ja keine Notwendigkeit, sich die Sachen billig zu holen, weil wenn sie eins haben, ist ja Kohle. Ich glaube, die haben einfach andere Dinge im Kopf als der Rest der Welt. So, einen haben wir noch. Genau, einen haben wir noch. Und zwar Css wieder, Sibling Count und Sibling Index findet man in Chrome und in der Safari Technology Preview.

Und das sind zwei CSS-Funktionen, die man eigentlich wie das moderne, es gibt ja jetzt ein aktualisiertes eine Atre-Funktion und die kann man eben alle zum Beispiel in, Calc benutzen oder in. Custom Properties stecken und so. Also wenn man in der neuen Atre-Funktion sagen kann, er nimmt dieses Attribut und interpretiere es als CSS-Wert vom Typ.

Hast du nicht gesehen, als Color, als Length. Ja, genau, man kann dann direkt so ein Typecast hin noch machen. Und genau, jetzt gibt es halt eben Sibling Count, also wenn man wissen will, wie viele Elemente von mir selbst gibt es denn eigentlich, also so Sachen konnte man ja vorher schon mit so Tricks machen, indem man halt gesagt hat.

First Child und dann Last End of Child 7 zum Beispiel, Dann wusste man, aha, okay, Es gibt anscheinend sieben Siblings und dann konnte man dann wiederum mit dem Sibling-Combinator, konnte man dann alle dauffolgenden Stylen, also dann konntest du sowas machen wie, wenn es vor Flexbox zum Beispiel, wenn es eben zwei Elemente sind, dann sollen die 50% breit haben, wenn es drei sind, 33%.

Genau, aber da musstest du eben über Selektoren gehen. Du musstest das so sehr verbose, alle Kombinationen hinschreiben oder eben mit so SCSS-Loops arbeiten. Und was ja auch verbose ist, aber was dann sozusagen, was du dann syntaktisch netter für dich programmieren kannst. Ja, und mit Sibling Count und Sibling Index hast du eben diese Möglichkeiten jetzt direkt in CSS und auch kannst es eben als Werte in Properties reinstecken und da kannst du halt so Stacked-Geschichten zum Beispiel machen, also dass du mit Sibling Index so einen Karten-Stack machst oder dass du Animationen alle um eben 200 Millisekunden delayt, je höher der Index ist, dann starten lässt, sodass du halt so eine Art Wellenbewegung hast. Genau.

Okay, ich muss da aber jetzt mal eine kleine Detailkritik anbringen. Ja, bitte. Also weil CSS fängt ja immer an, bei 1 zu zählen. Nicht bei Null, weil bei Null anfangen zu zählen in Airquotes ist ja bloß, weil man das ja als Offsets normalerweise versteht. Als Indizes in Daten sozusagen. Ja. Und jetzt haben wir hier ein Ding, das heißt schon Sibling Index.

Es ist also ein Offset und es fängt trotzdem an, bei 1 zu zählen. Ja, ich meine, ja, okay. Also das CSS mit 1 anfangen muss, das ist ja dann irgendwie gesetzt. Ich würde sagen. Ob es bei 1 anfängt zu zählen oder nicht, kommt halt darauf an, was es ist. Zählst du Offsets oder zählst du Elemente? Nimm dir ein JavaScript-Array.

Du fängst an, bei 0 zu zählen, wenn du nach Offsets gehst. Aber wenn du dir die Length anschaust, fängt die ja bei 1 an zu zählen. Also ich habe auch keine Ahnung, was jetzt hier richtig oder falsch wäre. Aber ich finde es sehr lustig, dass das jetzt sozusagen ein Angriffsvektor für Inkonsistenz ist.

Ich habe nichts Produktives dazu beizutragen, aber das finde ich halt immer sehr unterhaltsam, wenn man so sieht. Ihr habt angefangen, bei 1 zu zählen und das ist auch richtig, aber indem ihr es richtig macht, habt ihr euch jetzt hier natürlich meiner substanzlosen Kritik ausgesetzt, die ich jetzt so clowngleich einfach mal so angebe.

Aber es ist halt einfach so besonders schön zu sagen, du zeigst den richtigen Entwicklern CSS und du machst das halt irgendwie einigermaßen unterhaltsam und so, guck mal an, die fangen bei 1 an zu zählen und alle so platsch. Und dann erklärst du denen, macht ja auch Sinn, weil ist ja kein Offset. Ist ja die Anzahl. Bis auf das Ding, was ein Offset ist, und das fängt auch bei 1 an zu zählen, weil man muss es ja konsistent halten.

Und dafür hat man halt eben zwei Hände zum Facepaulnen. Sehr gut. Nee, aber das ist voll gut. Das sollte man, das muss man haben. Gibt's halt nicht überall. Ich find das auch gut. Und was man damit noch so machen kann, es gab hier die Podcaster von Syntax FM, die machen ja auch jetzt so Videocasts und so Zeugs, machen ja alles.

Die sind gerade irgendwie, geben sich regelmäßig irgendwelche so Coding-Challenges, wo die irgendwelche Effekte oder Dinge nachprogrammieren. Also das, genau, da haben die jetzt einen Challenge auch wieder gehabt und der, wie heißt der denn, der Wesboss und der andere, wie heißt der andere nochmal vergessen, Scott Trulinski, der arbeitet eben damit, während, also insgesamt drei und die anderen beiden, die verirren sich komplett in irgendwelchen krassen JavaScript-Sachen, mit denen die irgendwelche Effekte versuchen zu bauen.

Und der Scott Holinski ist einfach nur, ja, aber das könnte ich doch hier mit CSS, dann mache ich das, dann mache ich mit CSS das. Ah ja, und dann kann ich ja auch den Index benutzen und so fertig nach zehn Minuten und die anderen, die sind noch so, die bauen sich da ihre Frameworks zusammen, damit sie das machen können.

Also sehr, sehr amüsant war das. Genau, und ein toller Use Case dafür. Ja, und auf jeden Fall für so die unknown unknowns. Wann könnte man das gebrauchen, der halt eben dann mit der Use Case aufpoppt. Also das machen die Leute, die sich den JavaScript-Turm da gebaut haben, nicht nochmal. Ja. J.R. ist der dritte im Bunde. Der ist aber noch nicht so lange dabei.

Verlinken wir auf jeden Fall noch in den Show-Notes. Ich habe es hier gerade reingepackt. Genau, und das ist jetzt, glaube ich, so das, was wir so an Themen hatten, was auch irgendwie greifbar ist in den Browsern. Und dann gibt es noch so ein paar Sachen, die werden wir jetzt hier nicht besprechen, weil da kommen wir sicherlich dann so weit dazu, wenn es so weit ist.

Aber genau, wir wollten noch einen kleinen Ausblick geben. Genau, es sind halt einfach so ein paar Sachen, die sozusagen jetzt in den diversen Nightlies gelandet sind und wo man jetzt halt eben sagen kann, sie befinden sich im Zustand des Werdens. Ja, Shep, möchtest du den ersten übernehmen, nehme ich den zweiten?

Ja, genau, also das eine ist add custom media, also dass man eigene Media Queries bauen kann, definieren kann. Äh. Damit man sich halt nicht wiederholen muss, dass man einmal definieren kann, das ist mein breites Layout, das ist mein schmales, man kann es in den Breakpoints in Airquotes definieren und kann halt eben sagen, Admedia, breit oder schmal, mach dieses oder jenes. Man muss ja eben das nicht alles hardcoden.

Ja, oder sich irgendwie das alles merken, welche Breakpoints man da jetzt nochmal gewählt hatte. Ja. Ja, praktisch auf jeden Fall. Tja. Und Firefox ist jetzt tatsächlich auch in Arbeit, also ist schon länger in Arbeit, aber ist jetzt tatsächlich was so das Arbeiten vom Bug angeht, als fertig markiert und ist jetzt im Rollout, geht halt jetzt so durch die diversen Betas und so, CSS-Module-Scripts, was halt eben ist Import hast du nicht gesehen.

From foo.css also Import-State mit dem JavaScript verwenden, um das in CSS zu machen was man dann kriegt, ist ein CSS-Stylesheet-Object und das kann man dann in die Adopted-Stylesheets von seinen Documents in seinen Shadow Roots reinhängen, Chrome und Konsorten können das bereits, Firefox ist der letzte, wo das noch nicht geht, aber die Implementierung ist halt fertig, man rollt es halt jetzt langsam aus und dann irgendwann kann man sich noch mehr Tooling an den Hut stecken, weil man sich einfach seinen JavaScript, diskriminativ dann CSS importieren lassen und muss da nicht mehr irgendwie Compiler und haste nicht gesehen für bemühen und das ist natürlich auch super, jeder Tag, an dem man die Liste der Dependencies verkürzen kann, ist ein guter Tag.

Das heißt aber, das ist quasi auch schon relativ baselineig und es fehlt im Grunde jetzt der Firefox. Und wir haben das deswegen in Zukunft gepackt, weil unser Aufhänger für diese Sachen tatsächlich auch die letzten Firefox-Releases waren. Wohingegen es aus der Chrome-Perspektive wir das wahrscheinlich mit in die Folge reingepackt hätten.

Also unfassbar spannend, obwohl ist es das doch ein Stück weit schon. Stell dir mal vor, du wärst selbst Compounded-Autor. Du kannst halt wirklich eine ganze Toolchain in die Tonne treten. Dann musst du nicht mal eine Single-File-Component haben, sondern du kannst sogar sagen, ich mache hier mein JavaScript und da wohnt mein CSS drin und da wohnt mein HTML drin.

Und da kannst du halt einfach sagen, import diese ganzen Nicht-JavaScript-Dinger mit einem Import-Statement. Dein Modul-Bundler, wenn du verwendest, kannst du verstehen. Dein Browser, wenn du keinen Modul-Bundler verwendest, kannst du auch verstehen. Der kann auch dann die ganzen Sachen machen mit Dependency-Graph aufbauen, die duplizieren.

Das ist natürlich der große Vorteil. Das macht potenziell schon ziemlich viel Gewinn, was so Effizienz angeht. Und wie gesagt, kleineres Node-Modules. Yay! Genau. Ja, das ist auf jeden Fall nicht schlecht. Liebling, ich habe die Node-Modules geschrumpft. Genau, auch in Zeiten von, hier, wie heißen die?

Hier, Hulu, Bulu, diese ganzen, wie heißen die denn? Die Supply Chain Attacks. Schei-Bulut. Ja, genau. Ja. Je weniger Node-Modules man braucht, desto besser. Ja, desto mehr von seinen Bitcoin darf man behalten. Genau. Und auch von seinem Festplattenplatz. Ja. Nerven. Nicht außen vor lassen. Weniger Sachen, die kaputt gehen können. Ja.

Sehr cool. Es ist einfach ein Gewinn für alle. Mal sehen. Also ich meine, als wir mit dem Podcast angefangen haben, gab es ja Node-Modules noch nicht. Oder NPM. Da gab es auch noch nicht mal, hieß es nicht hier, wie hieß es, war es Bauer? Das vorherige Tool da, um zumindest Kommandozeilen basiert Libraries zu installieren.

Ich glaube, das war doch Bauer, oder? War das nicht? Das war von Twitter? Ich meine, es hätte Bauer gehießen. B-E-E-R. Ja, auf jeden Fall. Ich glaube auch einem Vogel als Icon? Vielleicht, ja. Fragezeichen? Warte mal. Ich bin ja auf der Working Draft. Archivseite JavaScript und Bauer. 9. September 2013.

Ja, Bauer. Package Manager war das. Genau. Wenn wir alte Herrschaften sind, dann gibt es für Node-Modules vielleicht auch schon wieder einen Ersatz. Oder dann wird es nur noch in Node genutzt. Ich glaube, es hieß Bauer Components. Also auch Bauer-Components damals. Ja, wobei die Wahrscheinlichkeit nicht hoch ist. Also genau, macht ja schon an sich Sinn.

Kommando-zeilen-basiert Paket installieren und dutzen. Das ist schon nicht schlecht. Die Webseite ist noch am Start, sehe ich gerade. Jetzt halte ich immer noch die Rechnung, die Hosting-Rechnung. Naja, die können ja so groß nicht sein. Der Elon Musk zahlt die wahrscheinlich noch. Nur weil der nicht weiß, dass das existiert. Ja. Guck mal, wie bunt der Vogel ist. Das sind ja quasi Regenbogenfarben.

Ich bin sicher, wenn der wüsste, dass das existiert, würde er das platt machen. Das ist woke. Und was wahrscheinlich auch, wahrscheinlich haben die das ist doch auch nicht Times to Rome, was sie benutzen. Sehe ich genau. Sie sagen, es ist noch maintained, ne? Okay, ja gut, gibt es wahrscheinlich Leute, die das benutzen.

Und dass es maintained ist, sieht man daran, dass sie empfehlen, dass man VEAT verwendet. Okay. Die sind also mindestens zeitlich so orientiert, wie ich das bin. Ja, ist doch cool. Was jetzt nicht sehr ist, aber zumindest mal etwas. Ja, aber wer macht das denn? Das kann doch jetzt nicht ernsthaft noch Twitter sein.

Nee, bestimmt nicht. Also Can I Use kommt ja, glaube ich, nee, Moment, Bootstrap kam von Twitter, ist ja auch nicht mehr Twitter. Und... Man kann immer noch T-Shirts kaufen mit dem Logo. Das ist natürlich schon wieder geil jetzt. Also das würde ich auch sagen. Also im Moment ist es ja mehr so en vogue irgendwie so Enron Merchandise durch die Gegend zu tragen. Aber das kennt ja jeder.

Ja. Also so ein Bauer-Logo auf meinem Laptop, das wäre schon ganz cool. Das einzig Blöde bei diesen T-Shirts ist ja immer, dass die dann aus den USA schippen und sauteuer sind. Ja. Das hält mich dann immer davon ab, mir so T-Shirts zu holen. Ja. Und das ist auch nicht besonders zuverlässig. Ja. Aber ich meine, das wäre schon echt so.

Ja, wäre schon cool. Wo gibt es denn die T-Shirts hier auf der Seite? Ich sehe gar nichts. Bei About. Da gibt es dann einen Link zu dem Shop von Cotton Bureau. Ah ja. Und der lebt noch. Der kann man immer noch aktiv bestellen. Es sieht so aus, ja. Funktioniert. Ich wüsste auch nicht, warum das nicht gehen sollte. Ja.

In der Tat. Ich meine, das ist echt super. Dann gehst du zur Konferenz und dann musst du gar nicht irgendwie nachweisen, dass du das Seniorenticket auch haben darfst. Du trägst es einfach direkt auf der Brust. Auf deiner Plauze. Ja. Das ist herrlich. Na, da haben wir doch eine schöne Revision hier wieder zusammengetackert.

Ja, haben wir. Ach, ist das herrlich. Oh, Mann. Weißt du, da machen wir uns die ganze Zeit darüber lustig, von wegen ist alles nicht maintained und das geht alles irgendwie. Da muss man ständig updaten und so und das Ding macht einfach weiter. Obwohl ich da seit über zehn Jahren nicht drüber nachgedacht habe.

Respekt. Ja. Hut ab. So ein bisschen wie die Winra-Leute, die immer noch versuchen, eine Lizenz zu verkaufen. Okay. Deine Mutter hat eine Windrahr-Lizenz gekauft. So sieht's aus. Okay, wunderbar. Dann würde ich sagen, machen wir doch mal einen Deckel auf diese Revision. Genau. Wenn ihr euch gefallen habt, dann liked ganz viel.

Ja, genau. Mir hat's auch sehr gut gefallen. Wenn's euch auch gefallen hat, dann drückt das in Form von Sternchen aus. Like and subscribe. Like and subscribe und empfehlt uns weiter. Genau. Stalkt uns auf Social Media, kommt in unseren Community Slack. Alle Links auf unserer Seite. Genau. Und wir hören euch dann das nächste Mal zu einem unbekannten Zeitpunkt, zu einem unbekannten Thema.

So siehst du aus. Bis dahin. Danke, Peter. Danke dir. Tschüssi. Tschüss.

Anmelden oder registrieren

Jetzt

0:00 / 0:00