Nachdem es schon wieder unglaubliche zwei Jahre her ist, dass wir mit ihm \xfcber\ndas \u201eActor Model\u201c reden durften, war es nun h\xf6chste Eisenbahn, Surma wieder\neinzuladen und \xfcber aktuelle Entwicklungen im (multigethreadedten) Web zu\nplaudern.\n\n\n[00:00:29] SCHAUNOTIZEN\n\nWEB WORKER\n\nEines von Surmas Steckenpferden ist es, alles was nicht bei \u201eDrei!\u201c auf dem Baum\nist in separate Threads auszulagern. Wir sprechen \xfcber Sinn und Zweck dieser\nHeranangehensweise am Beispiel der Projekte Squoosh und Proxx des Chrome\nDeveloper Relations Teams (siehe auch die Google Chrome Labs auf Github). Wir\nerfahren, dass das Ziel dabei weniger ist, mehr Geschwindigkeit auf ohnehin\nschnellen Plattformen herauszuholen, sondern vielmehr dem UI-Thread auf\nEinsteiger-Hardware den R\xfccken frei zu halten.\n\nCOMLINK\n\nEiner der Nachteile von Web Worker ist die Tatsache, dass sie anstrengend im\nUmgang sind. Moderne Programmierparadigmen und Surmas Open-Source-Projekt\nComLink schaffen hier allerdings Abhilfe. Und auch wenn das Motto \u201eComlink makes\nWebWorkers enjoyable\u201c lautet, so l\xe4sst sich diese Bibliothek auch ganz prima f\xfcr\neine angenehme Kommunikation mit Service Workern oder \xfcber Frame-Grenzen hinweg\neinsetzen (also im Prinzip alles, was auf das Message-Interface setzt).\n\nWASM, WASI UND INTERFACE TYPES\n\nSurma kennt sich aber nicht nur mit elegant programmierbarem Multithreading aus,\nsondern auch mit WebAssembly, kurz: Wasm. So nutzt unter anderem das eingangs\nerw\xe4hnte Squoosh unter der Haube von C++ nach Wasm portierte, gebr\xe4uchliche\nBildkompressoren wie MozJPEG oder OptiPNG. Wir unterhielten uns au\xdferdem \xfcber\nkommende Neuerungen wie Interface Types, sowie nochmal \xfcber WASI (h\xf6re dazu auch\nRevision 394). Und wir sinnierten \xfcber den Grund, weswegen es so aussieht, als\nob Wasm schaffen wird, was Java und Silverlight nicht gelungen ist, n\xe4mlich das\nlangersehnte, universelle Runtime-Environment zu werden.\n\n\n\n> If WASM+WASI existed in 2008, we wouldn\u2019t have needed to created Docker.\n> That\u2019s how important it is. Webassembly on the server is the future of\n> computing. A standardized system interface was the missing link. Let\u2019s hope\n> WASI is up to the task! https://t.co/wnXQg4kwa4\n> \n> \u2014 Solomon Hykes (@solomonstre) March 27, 2019\n\n\n\n\nKEINE SCHAUNOTIZEN\n\nROLLUP-PLUGIN-OFF-MAIN-THREAD\n\nDieses Plugin f\xfcr den Bundler Rollup macht es m\xf6glich ES Modules innerhalb von\nWorkern zu nutzen.\n\nIMPORTFROMWORKER()\n\nDieses andere Projekt von Surma in Zusammenarbeit mit Jason Miller erm\xf6glicht\nes, analog zu ES Modulen, Funktionen aus Web Workern transparent in den\nUI-Thread \u201ezu importieren\u201c und sie dort wie gewohnt zu nutzen.\n\nWEBASSEMBLY SUMMIT 2020\n\nKurz vor Corona-Ladenschluss fand der von Surma organisierte WebAssembly Summit\nstatt, dessen Videos online zum Binge-Watchen bereit stehen.\n\nHTTP 203\n\nIn ihrer Videoserie diskutieren Surma und Jake Archibald regelm\xe4\xdfig neue Web\nFeatures und Konzepte, garniert mit einer guten Portion Humor :)\n\nHTTP 203 PODCAST\n\nNachdem dank Coronavirus auch die Google Developer Relations Menschen von zu\nHause arbeiten m\xfcssen, setzen Jake und Surma ihre Serie nun einfach in Form\neines Podcasts fort (we approve!).