Revision 451: Neue Webstandard-Proposals und Podcast-Verstarkung!

Published: Nov. 17, 2020, 8:15 a.m.

Im Rahmen einer Throwback-Folge besprechen nicht nur die \xfcblichen Schepp, Stefan\nund Peter neue Webstandards/Browser-APIs, sondern begr\xfc\xdfen auch Verst\xe4rkung im\nPodcast-Team!\n\n\nUNSER SPONSOR\n\nKennst Du das Gef\xfchl\u2026 die Projektleitung ben\xf6tigt dringend die Stunden f\xfcr das\nProjekt r\xfcckgemeldet, Du hattest aber w\xe4hrend der Arbeit am Projekt keine Zeit\ndiese zu notieren? Nun musst Du m\xfchsam alles zusammensuchen um die Stunden zu\nerfassen? timr unterst\xfctzt Dich und Dein Team dabei Eure Zeit mit minimalem\nAufwand zu erfassen. Am Ende des Tages ist alles erfasst. Die Projektleitung\nfreut sich weil sie t\xe4glich einen \xdcberblick hat. Sie kann damit nicht nur\nreagieren, sondern agieren. Neben der Projektzeiterfassung k\xf6nnt Ihr sogar Eure\nArbeitszeit erfassen, inkl. Urlaubsantr\xe4ge.\n\nTeste timr 14 Tage kostenlos und hol Dir 10% Rabatt auf Deinen ersten Kauf unter\ntimr.com/workingdraft.\n\n\nSCHAUNOTIZEN\n\n[00:01:46] HALLO VANESSA!\n\nWillkommen im Team, Vanessa B\xf6hner! Bekannt aus vergangen Workingdraft-Folgen,\nvon Twitter, von den FrontendFoxes und durch Podcasts \xfcber Testing und Wein\nverst\xe4rkt sie nun auch diesen Podcast.\n\n[00:11:15] DOM PARTS PROPOSAL\n\nDOM-Parts verst\xe4rken das Template-Element, das eigentlich nur ein deklaratives\nDocumentFragment ist, um Features aus Template-Sprachen wie Handlebars. Im\nRahmen des \xdcber-Themas Templating sprechen wir auch \xfcber\nFrontend-Framework-Monokultur, Security, hyperHTML, JSX und statisch vs.\ndynamisch typsierte Programmiersprachen.\n\n[00:31:20] CENTRALIZEDCONSENTAPI\n\nDie API f\xfcr die Reduktion von Cookie-Consent-Bannern wird kontrovers diskutiert!\nW\xe4hrend einige von uns an die API glauben, wittern andere eine Verschw\xf6rung\ngegen das Project Fugu und wieder andere berufen sich auf die via Brave Browser\nund uBlock Origin umgesetzte Castle Doctrine in der eigenen Web-Experience.\n\n[00:50:10] COOKIE-STORE\n\nBrauchen wir bessere Frontend-APIs f\xfcr Coookies? Entsprechende jQuery-Plugins\ndeuten darauf hin. Die neue API verspricht asynchrone Funktionen, Cookie-Events\nund Cookies im Service Worker. Wir vergleichen die Cookie-API und das\nentsprechende jQuery-Plugin mit der URL-API und Rodneys URI.js. Au\xdferdem\nversuchen wir zu ergr\xfcnden, ob wir asyncrhone APIs brauchen, warum es keinen\nCookie-Observer angelehnt an den Mutation Observer gibt und gleichen das\nProposal mit Mozillas Positionen zu divsersen Standards ab.