Ich schau ziemlich viele Videos zu IT-Themen, aber dieses Video ist eines der besten, die ich seit langem gesehen habe. Alles sehr verständlich und doch auf einem guten Niveau erklärt. Kein Geschwafel, alles auf den Punkt, keine unnötigen Schnitte. Ehrlich, sehr gut. Und kein nerviges 'like, subscribe', was bei eurem content auch nicht nötig ist, da ich sofort abonniert habe :) Ich freue mich auf zukünftige Videos und hoffe, dass ich die Zeit finde, eure bisherigen zu sehen
Hallo, bisher hab ich kaum Videos auf deutsch über Programmieren gesehen. Ich hätte nicht gedacht, dass es so großartigen Content gibt. Man merkt ganz deutlich, daß der Fokus bei euch auf dem Inhaltlichen liegt. Viel Content auf TH-cam konzentriert sich hauptsächlich auf die Präsentation und der Inhalt ist nicht nennenswert. Zum Thema: Auf meiner Arbeit nutzen wir Docker für machine learning Experimente (Kubernetes kommt auch bald) und um unterschiedliche Buildumgebungen für C++ bereitzustellen. Webassembly kann diese Anforderungen für uns nicht abdecken. Danke, hab euch abonniert!
Genau der Detailgrad, den ich gebraucht habe. Perfekt für einen Über- und Einblick in die verschiedenen Technologien und deren Zusammenhänge. Danke auch für deine Prognose. Ich bin gespannt, was aus WASM noch so wird.
Als Solomon Hykes sagte, dass Docker nich nötig gewesen wäre wenn wasm und wasi schon früher existiert hätten, habe ich das nicht ganz verstanden. Die Erklärung in diesem Video war die beste die ich bis jetzt im deutschen und englischen Sprachraum gehört habe. Jetzt verstehe ich die Aussage endlich. Danke für diese Video!
[gr] Sehr gerne, freut mich 😊 Für alle, die den angesprochenen Tweet nicht kennen, hier noch ein Link: twitter.com/solomonstre/status/1111004913222324225
Fantastisch, danke für dieses tolle Video! Anmerkung: Gerade dieses Numbers Crunching finde ich sehr interessant. Zugegebenermaßen ist es vielleicht eine er skurrile Lösung, aber ein WASM-Modul, welches einfach im Browser mit Daten gefüttert wird (vom Server) und das Ergebnis wieder zurück schickt ist eine super simpel zu deployende Lösung, um viele Berechnungen auf mehrere/viele Clients zu verteilen. Die Clients müssen einfach nur die URL aufrufen und sind mit im Pool der Worker und helfen so mit, die Berechnungen durchzuführen. Daher hoffe ich, das uns WASM im Browser noch einige Zeit erhalten bleibt.
Tolle Präsentation. Danke für diese sehr kompakte und konzentrierte Vorstellung der Thematik. Keine unnötigen Ausschweifungen aber auch keine unpräzise, unfundierte Argumentation. Sehr hilfreich!
Vielen Dank für das tolle Video. Da ich kein Programmierer bin, sondern eher Management ist das Finden von aufschlussreichen Video immer eine Herausforderung. Du hast es geschafft, sowohl den Tekki mitzunehmen, als auch mich - Vielen Dank dafür
[gr] Gern geschehen 😊 Und ja, man hört tendenziell eher wenig(er) darüber, aber eigentlich wäre es ja naheliegend (ich hab's zugegebenermaßen aber auch nur mitbekommen, weil ich viel mit Node.js zu tun habe und Node.js Unterstützung dafür bekommen hat).
Ich wünsche jede Nacht bevor ich schlafen gehe, dass C#, Java oder egal welche andere Programmiersprache JS im Web ersetzt. WebAssembly hat diese hoffnung für mich wieder entfacht.
Guter Beitrag, vielen Dank. Normalerweise gucke ich by design nur englisch sprachige Videos, aber hier ist die Umsetzung aus deutschem Grundwort und Fremdworten so gut gelungen, "Daumen hoch"!
Sehr gute Präsentation! Ich habe mir eine Pause gewünscht und der guter Mann könnte ein Schluckwasser trinken. Ich kenne zwar WASAM nicht, nachdem ich das Video angeschaut habe, sieht es so aus, als ob WASAM doch ein Konkurrent zu Docker sein würde.
[gr] Sehr gerne 😊 Und lass Dich nicht verrückt machen - nicht alles wird so heiß gegessen, wie es gekocht wird. Zum Thema, dass es manchmal einfach zu viel ist / wird: th-cam.com/video/CYRnA9ue1cI/w-d-xo.html
Habe nach 12 Minuten, welche mich der Antwort auf die Ja/Nein-Frage nicht näher brachten, abgebrochen. Die Menge an Zusatzinformation ist mir, da diese bereits bekannt, zu viel. Bin eigentlich Fan davon, dass sachdienliche Hinweise gestreut werden. in diesem Video wirkt es auf mich aber so, als das die Frage samt Antwort (noch) kein Publikum haben kann,wenn soviel Grundlagen als Beiwerk von Noten. .. so, genug ich mir meins und meinen 5 Cent zum Video. DU machst nen Klasse Job!👍
Danke, Deine/Eure Gedankengänge dazu entsprechen auch in etwa meinen. Ich sehe da noch einige Anwendungskomplexe, wo ich es mir aktuell nicht vorstellen kann sie mit WASM umzusetzen, aber die durchaus mit Docker möglich sind. Aber viele kompaktere Anwendungen dürften eben durchaus super damit laufen. Ich sehe WASM auch als DIE Möglichkeit aus der PHP-Bindung bei einfachen Webspaces rauszukommen. Aktuell hat man ja in der Regel die Wahl zwischen einem einfachen Webspace ohne SSH und einer starken Bindung an PHP fürs Backend oder komplexeren Webspaces mit SSH für mehr Sprachenvielfalt wählen. Mit WASM und Crustlet könnten Hoster auch genauso einfache Webspaces anbieten, wie sie es aktuell nur mit PHP machen. Ich bin gespannt was das noch für Veränderungen für Webdeveloper so mit sich bringt. Vielleicht werden ja so auch demnächst die gerade noch meistverbreiteten CMSe wie WordPress, Drupal, Joomla und Co. vom Trohn gestoßen.
[gr] Spannender Punkt - an klassischen Webspace habe ich dabei ehrlich gesagt gar nicht gedacht, weil ich das gar nicht mehr so auf dem Schirm habe, aber ja, den gibt's durchaus auch noch 😊 Das mit den CMS-Systemen ist auch ein spannender Punkt … ein gewisser Anfang ist da ja mit den Headless-Systemen à la Contentful & Co schon gemacht, aber irgendwie erwarte ich mir da auch noch mehr … mal abwarten 😊
Wie man es gewohnt ist, ein extrem informationsdichtes, gutes Video! Kurze Frage an Golo: Kannst du Informationsquellen empfehlen, bei denen man die neusten IT-/Programmiertrends kurz und bündig vorgestellt bekommt, oder woher ziehst du immer deine extrem guten Informationen? #fürDenAlgorithmus
[gr] Vielen Dank für das Lob 😊 Tja, woher bekomme ich meine Informationen … ich würde sagen, aus einem ganzen Sammelsurium von Quellen: Twitter, Hacker News, Heise, Golem, verschiedene Newsletter, Kolleg:innen, … und dann halt eigene Recherche: Dokumentation lesen, ausprobieren, … vieles ist einfach Erfahrungssache. Zum Beispiel: Für dieses Video habe ich mich rund einen Tag in den aktuellen Stand von WebAssembly eingelesen. Einfach gegooglet, und mehr oder weniger alles gelesen, was ich an halbwegs aktuellem gefunden habe. Das versucht, zu strukturieren und zu bewerten. Und mit Docker arbeite ich seit zig Jahren quasi täglich, und was eine Intermediate Language ist, kenne ich noch aus meiner .NET-Zeit, wo ich mich auch mehrere Jahre mit MSIL beschäftigt habe. Insofern sind mir viele von den Konzepten häufig bekannt, es sind dann nur andere Implementierungen. Die oben genannten Nachrichtenquellen sind dann eher nur der Trigger, wo man mal wieder reingucken könnte, aber das meiste ist Erfahrung und ganz klassisch, Doku lesen und ausprobieren.
@@thenativeweb Es war unglaublich spannend und auch fordernd! In meinen praktischen Ergebnissen hat sich jedoch gezeigt, dass WASI Funktionen einen overhead in der Performance zu generieren scheinen. Andere Versuche bezogen sich meist nur auf WASM und auch den vor dir angesprochenen cold Start. Getestet habe ich mit wasmer und wasmtime, kompiliert aus Rust jeweils im Vergleich zu nativ (rust->native)
Danke für den Vortrag! Scheinbar habe ich die letzten 18 Monate unter einem Stein gelebt - für mich war wasm immer nur ein Browser-Thema. Daher habe ich das Video mehr aus Unglaube als aus Interesse angeklickt. Aber jetzt scheint mit das Konzept aber wie der fehlende Stein, der den ganzen kubernetes-stack auch für kmu-unternehmen rechtfertigt.
In dem Zusammenhang interessant ist auch Oracles GraalVM, die ebenfalls viele verschiedene Programmiersprachen ausführen kann (unter anderem JavaScript) und auch deren Mischung erlaubt.
Bei Docker geht es ja nicht darum, irgendwie Container zu nutzen, sondern mit bestehenden Technologien wie NodeJS, PHP, Phyton, einen Memcache usw. (und spezielle Versionen davon) unabhängig voneinander zum Entwickeln nutzen zu können , aber ohne diese auf Rechner nativ installieren zu müssen, und die Software die man entwickelt dann mit allen Abhängigkeiten exakt so produktiv deployen zu können. Diese verschiedenen Technologien in den Containern, arbeiten dann als "Services" mit einander. Mir ist es leider im Video nicht klar geworden, ob genau das mit serverbasierten WebAssembly möglich wäre. Viele Grüße! PS. Ich galube Figma verwendet WebAssemblys für ihre UIs im Browser.
Man kann ja mit Docker auch fertige Anwendungen wie Word-Press einsetzen, ohne sich um dessen Abhängigkeiten kümmern zu müssen, oder einfach als "Utility-Container" in einem Deploy-Vorgang oder nur so auf einem Entwicklungsumgebung. Auch dafür ist Docker gedacht, aber ich weiß nicht, ob das auf WebAssemblies zutrifft.
[gr] Ich würde sagen, beides nein. WebAssembly ist einfach nur eine Sprache, die sich sehr gut system-, plattform- und betriebssystemübergreifend ausführen lässt. Nicht mehr, nicht weniger. Insofern kann WebAssembly Container nicht ersetzen - es sei denn, der ganze Zweck des Containers ist, ein Deployment-Vehikel für Anwendungen zu sein, die nur aus einem Binary bestehen.
Super Video! Teile die Meinung der coexistenz von wasm und docker. Was ich mir wünschen würde: An mancher Stelle imho etwas zu sehr vereinfacht. Bitte etwas mehr auf die Schwierigkeiten mit wasm eingehen (.net nur mit blazor, also .net console app nicht in wasmtime ausführbar (GC ist ein Problem), blazor aber nicht einfach so stand-alone afaik). Außerdem Probleme mit pthreads, exceptions (c++) und eben eingeschränkter wasi (c runtime Grenzen). Und nett wäre auch ein Ausflug zu den Auswirkungen bzgl Jit und AOT complied Code im Umfeld wasm.
Ein kleiner inhaltlicher Fehler ist das Quellcode größer Binär oder IL Code ist, egal welche Sprache man sich anschaut sieht man das compiled Code immer größer als Quellcode ist. Ein gutes Beispiel ist .NET Web assembly wo man den langsameren interpretierten Modus statt schnellen AoT Modus wählen kann um Package Size zu sparen.
Großartig. Sehr sehr angenehm zuzuhören. Kannst du auch Mal ein Video über hashicorp nomad als orchestrator, ggf auch im Zusammenhang mit webassembly machen?
Ich finde das Thema WASM sehr interessant, weil es die theoretische Wiederverwendbarkeit von Quellcode extrem verbessert. Interessant wären dabei noch Lösungsansätze für einheitliche Schnittstellen in der Programmierung, also die Integration von Quellcode, welche in WASM kompiliert wurde, in den eigenen. Besonders spannend ist die Integration von funktionellen Sprachen zur Lösung von spezifischen Problemen,
Erstmal: Wirklich ausgesprochen gut erklärt! Herzlichen Dank! Mir stellt sich nur die Frage: Es gibt doch Runtime VMs für den Backend schon lange. zB die Java VM. Warum hyped nun WASM am Backend? Ansich ist das ja nichts neues. Oder doch?
[gr] Vielen Dank für das Lob 😊 Was den Vergleich zur Java-VM angeht: Ja, das ist theoretisch genau das gleiche. Der einzige Unterschied ist, dass die VM dafür jetzt eben auch nativ im Browser existiert, und man damit eine "echte" Plattformunabhängigkeit bekommt, ohne dass man erst noch etwas installieren müsste (anders als früher zB das Java-Plugin).
[gr] Project Fugu wäre prinzipiell eine schöne Idee - gibt es da etwas Spezielles, was Dich interessiert? Also eher die Beweggründe dahinter, oder welche APIs das sind, oder …?
@@thenativeweb Es ist keine spezifische API sondern eher die Idee, dass wir durch diese neuen APIs in der Zukunft wrapper wie Electron nicht mehr brauchen werden. Anwendungen wie Spotify oder Discord wären als PWAs genau so leistungsstark wie die jetzigen Varianten. Diese Apps könnten ebenfalls auf allen Betriebssystemen installiert werden ohne für jedes build targets zu haben, da die APIs direkt nativ funktionieren. Das alles kombiniert mit WebAssembly und es wird kaum noch Gründe geben Applikationen zu schreiben, die nicht auf Web-Technologien basieren! Edit: Vergessen habe ich, dass wir vollwertige Apps im Browser haben!
[gr] Nein, es ist nicht eine (1) spezifische API, aber ja durchaus eine Sammlung von APIs, die alle ein gemeinsames Ziel verfolgen. Deshalb die Frage, ob’s Dir konkret um diese APIs geht, oder eher um ein Gesamtbild.
In Docker kann man aber nahezu alles packen, ohne dass man es neu kompilieren muss. Bei wasm stelle ich mir dies aktuell schwierig vor. Den Ansatz finde ich aber gut. Eher würde ich sagen müsste man den Code dann für wasm schreiben, nur hat man da freie Wahl der Programmiersprache.
[gr] Ja, das stimmt. Bestehenden Code wirst Du nur bedingt 1:1 für Wasm neu kompilieren können - je nachdem, was erforderlich ist, muss man den dann schon anpassen. Aber das Schöne ist ja, dass es diese Option nun gibt 😊
@@thenativeweb I have once written a program in C, (GitHub: luke10x/bible-overtype). Then I wanted to distribute it as a web app so I chose to port it to WASM. Some code had to be changed because the WASM VM just like the javascript itself is mainly based around non-blocking interfaces, therefore the C code had to be rewritten to be more non-blocking. The conclusion is that not all C code can run on WASM, as it can run in Docker. But still, it was quite a nice way to distribute my command line, curses program as a web app. I like your video as it helps me to improve my German.
Ich höre immer wieder es sei nicht möglich mittels docker auf Linux ein anderes os zu nutzen. Ist es aber denn theoretisch nicht möglich ein qemu in einem Container laufen zu lassen? Dann könnte im qemu ein Windows laufen ;) also grundsätzlich schon möglich.
Danke für den tollen Beitrag zum Thema. Was ich bei dem Vergleich mit Docker / Kubernetes nicht verstehe: Wie soll man denn seine Systemarchitektur in WebAssembly abbilden können? Also z.B. eine MariaDB, ElasticSearch, Nginx über WebAssembly laufen lassen? Das sind doch eher die typischen Anwendungsgebiete von Docker / Kubernetes. Oder zielt dein Fazit genau darauf ab?
[gr] Genau das ist der Punkt - das ist mit WebAssembly gar nicht möglich. Im Prinzip ist WebAssembly nur ein weiteres Format, in dem man Binaries speichern und ausführen kann, nicht mehr und nicht weniger … insofern ist der Vergleich auch Quatsch, es sei denn, man nutzt den Docker-Container ausschließlich dafür, ein einzelnes Binary zu verpacken und auszuführen … Falls Dich die Details zu WebAssembly näher interessieren, guck mal hier: th-cam.com/video/x07mUrhAecE/w-d-xo.html
Zuerst mal ein großes Lob, Themenauswahl und Darstellung sind top, mit das Beste, was ich in letzter Zeit an deutschsprachigen Content zum Themengebiet gesehen hab. Beim aktuellen Thema kann ich aber der These "WebAssembly (WASM) verdrängt Docker?" nicht ganz folgen. WASM wäre doch eher mit (ggf. multilingualen, IL basierten) Runtimes wie JVM oder CLR zu vergleichen, also dann eher "WebAssembly (WASM) verdrängt Java?". Docker nehme ich doch der deterministischen Umgebung wegen, auch eine Java oder .NET-core Applikation packe ich doch trotz Plattformunabhängier Runtime in einen Docker-Container. Kann aber sein, dass ich irgendein wichtiges Konzept übersehen hab...
[gr] Nein, das siehst Du genau richtig - aber das ist ja im Prinzip auch das, was ich im Video erkläre. Natürlich kann man sich den Docker-Container zukünftig sparen, wenn der einzige Sinn davon ist, ein einzelnes Binary zu wrappen, um es per Umgebungsvariablen konfigurieren und ein virtuelles Dateisystem einklinken zu können. Das geht nämlich auch mit WebAssembly wunderbar - aber für alles, was darüber hinausgeht, wird man um einen richtigen Container nicht herumkommen.
Klingt für mich ziemlich interessant. Die Argumentation, dass mit Blazor WebAssembly mit Kanonen auf Spatzen geschossen wird, kann ich erst mal so nicht teilen. Immerhin hat es doch seine Vorteile bezüglich Wartbarkeit und kürzeren Entwicklungszeiten, wenn man seinen Code bei Verwendung von Blazor Server mit dem Blazor WebAssembly Code teilen kann, im speziellen wenn man komplexe Entity Objekte austauschen will. Nur dann macht es Sinn. Wenn der Server in NodejS implementiert ist, dann würde ich sicherlich für das Frontend auch eine JS Client Implementierung wie Angular bevorzugen.
Docker erfüllt für mich hauptsächlich den Zweck von Infrastructure-as-Code. Man zwingt sich dazu, alle Abhängigkeiten pinibelst aufzuschreiben, damit möglichst nix Unerwartetes passiert. Und dabei macht es einen guten Job. Aber klar, der Universal-Bytecode, den man in Windeseile auf jedem Rechner ans Laufen bringt und mit allen anderen Sprachen mischen kann, wäre schon ne nette Sache, um ehrlich zu sein. OCI-kompatible WASM-Module kann ich mir gut als "alternative Container" vorstellen. Was mich an Docker stört, ist die schlechte Unterstützung für UI-Anwendungen im Frontend. Vielleicht bringt ja WASM den Durchbruch für containerisierte Desktop-Anwendungen auf dem Client, jetzt mal abgesehen von Websites. Ich werde das auf jeden Fall weiterverfolgen. Danke für das interessante Video!
[gr] Vielen Dank 😊 Und Du hast ein aus meiner Sicht sehr wichtiges Stichwort gebannt: OCI-kompatible WASM-Module … das wird IMHO noch ein großes Thema werden …
[gr] Das ist tatsächlich eine sehr gute Frage. Meiner Meinung nach eigentlich lediglich die Tatsache, dass die Laufzeit Umgebung bereits im Web-Browser integriert ist. Im Backend ist das aber natürlich nicht relevant, insofern ist es hier nur die Kompatibilität mit dem Frontend.
Vielen Dank für die gute Zusammenfassung! Für mich ist WebAssamby die spannedeste Software Entwicklung seit den Blockchains. Obwohl ich nun auch in der WebEntwicklung bin, kann ich mich mit der bestehenden Welt in JS einfach nicht anfreunden. Zuviele Meinungen, zuviel gefährliches Halbwissen und zu einfach es schlecht zu machen. Und gerade im Web, was eines der wichtigesten Technolgiene der heutigen Welt ist, ist mir das einfach nicht gut genung. Alle verbesserungen scheitern aber seit jahrzenten immer am gleichen Problem: den JS-Interpreter, welcher unersetzbar ist. Und da sehe ich immer noch sehr grosses Potential von WASM. Das das Umfeld so leicht zu erweitern ist, fasziniert mich umso mehr. Aber ein voller Ersatz für Docker wird es wohl nicht werden. Muss es auch nicht: Right Tool for the right Job. WASM kann viele heute übliche Probleme wohl besser als Docker lösen, aber eben nicht alle. Und das sollte es auch nicht.
[gr] Danke für Deinen Kommentar, und ja, WebAssembly hat zumindest das Potential, da noch sehr viel zu bewegen. BTW: JavaScript wird schon seit Jahren nicht mehr interpretiert, sondern in praktisch allen Runtimes mit einem JIT-Compiler übersetzt.
@@thenativeweb Das stimmt... ich denke mir fehlt nur das der Code einen "Kompilierungs-Schritt" hat. Ähnlich zu Java. Ich glaube das würde der JS Welt etwas helfen. Aber danke für die Richtig-stellung.
@@thenativeweb Nutze ich, und bin glücklich mit. Leider kann er aber noch keine Type zuweisung wirklich korrigieren. z.B. Json-DateString -> let d:Date ... d.getDate() ... error :D Aber ich komm gut klar damit. Hoffe nur auf Weiterentwicklung.
Mit anderen Worten zusammengefasst: aktuell noch nicht - hat aber hindeutend vielversprechendes potenziell in vielen Hinsichten auf jedenfall. Ich finde das man noch hätte eher auf die Unterscheidungen eingehen können, bzw diese einfahc nur etwas mehr zu betonen. Das es bei Docker quasi ein no brainer ist eine closed source third party Tools to containerisieren und man sich keine großen Gedanken machen muss worauf es dann läuft als host, während wir bei WASM den Source selber compilen müssten mit Zugriff darauf, was dann eher von den Entwicklern selber geboten werden müsste bei Closed Source. Und auch wenn du dich generell auf den Open-Source Teil konzentriert hast mit diesem Video hätte man nochmal erwähnen müssen, dass viele bereits bestehende Anwendungen bestimmte andere Abhängigkeiten an Libs besitzen und durch Ihre API Verwendung vllt. sogar nicht mehr ohne weiteres Host unabhängig sind, wodurch man nicht ohne weiteres ohne erheblichen Aufwand größere Projekte porten könnte. Und selbst wenn das Problem mit den Abhängigkeiten nicht existieren würde, ganz ohne Anpassung kommt man da nicht weiter, wenn am Ende WebAssembly text format erhalten will, der so viel Abhilfe wie möglich bieten soll im Vergleich zu Docker. Vielen Dank für dieses Video. Die Qualität deiner Arbeit weiß ich und viele andere Zuschauer auf jeden Fall zu schätzen.
Ich denke, das Ganze hat sehr viel Potential. Es gibt verdammt viele .NET-Entwickler, die für das Front-End keine große Lust bzw. Ressourcen frei haben, um diese mit Java und Co. zu realisieren. Für diese ist das natürlich ein Segen, da sie in ihrem Ökosystem bleiben können. Viele alten geschäftsrelevanten Softwaresysteme, die für den "normalen" Desktop entwickelt wurden, werden sicherlich in den nächsten Jahren zumindest teilweise auf Webassembly portiert werden. Genau hier sehe ich viel Potential für Blazor. Spannende Zeiten stehen uns bevor.
@@sven2529 Einstellungssache und Zielrichtung. Es kommt darauf an, was man macht und welchen Hintergrund man hat. Neben andern Sprachen programmiere ich seit über 30 Jahren C/C++ und seit ca. 15 Jahren C#. Da tue ich mir mit PHP schwer, wenn es um große Projekte geht - für mich ein bisschen ein Rückschritt. Wenn ich nun Front- und Backend in C# gleichermaßen abhaken kann, steigt die Effektivität, da ich in meinem Ökosystem bleibe.
Ich sehe als Vorteil von Containern noch, dass man Drittprogramme problemlos als Image verpacken kann, z.B. Datenbanken, Message Queues, Reverproxies usw. Wenn ich jetzt nur auf WebAssembly setze, müssen diese Komponenten auch alle erstmal in WebAssembly lauffähig gemacht werden. Ich sehe auch noch nicht so den Vorteil von WebAssembly gegen der Java Virtual Machine, oder Dotnet (bin nicht der Dotnet Experte). Eigentlich sind sie doch ähnlich. Es gibt jeweils mehrere Quellsprachen, die dann nach WebAssembly/Java Bytecode kompiliert werden und das Ergebnis ist performant und plattformunabhängig. Also Java kann das schon seit über 25 Jahren (über GraalVM seit kurzem auch JS, Ruby, Python als Quellsprachen). Ist die Frage, warum sollte WebAssembly jetzt der bessere Containerersatz werden, wenn Java es schon nicht wurde (oder der Trend dreht sich wieder). Ein Trend ist ja noch Functions as a service. Wo auch nur noch die Hochsprache geschrieben wird und der Cloudhoster kümmert sich drum, wie es betrieben wird. Ob es unter der Haube Docker, WebAssembly, Java, Node, ... ist, kann dem Entwickler egal sein.
WebAssembly ist doch letztendlich nur eine weitere Laufzeitumgebung wie z.B. .Net. Wie soll das ein Containersystem das in 99% der Fälle für ein unkompliziertes Deployment von komplexen Anwendungen (die in allem möglichen geschrieben sind) ersetzen? Das erschließt sich mir irgendwie jetzt nicht so ganz. Und ich liebe WebAssembly auf dem Client in form von Blazor über alles. Und Blazor hat gerade erst seine erstes echtes LTS Release mit .Net 6 bekommen. Kein Javascript mehr. Eine C# / VB.Net / Whatever Anwendung vom Server zum Client und das mit (fast) vollständigem .Net Framework Support. Keine Brüche mehr. Und wenn es nötig ist, schreibt man noch ein paar Extras mit Java Script.
Hi, wurde mein Beitrag gelöscht? Ich kann ihn nicht mehr finden. Wenn ich was falsches geschrieben haben sollte, bitte um eine kurze Info was es war. LG
[gr] Hey 👋 Wir löschen keine Beiträge (es sei denn, sie sind beleidigend, oder ähnliches), insofern - nein, wir haben ihn nicht aktiv gelöscht. Uns ist aber schon des Öfteren aufgefallen, dass TH-cam eigenständig Beiträge löscht, unter anderem, wenn Links enthalten sind, und öfters auch, wenn Text enthalten ist, der wie ein Link aussieht (zum Beispiel ein Produktname wie ASP.NET, der als Domain interpretiert werden könnte). Leider sehen wir die Kommentare auch nicht, die automatisch gelöscht werden, daher kann ich Dir auch nicht sagen, was das Problem war 😕 Da hilft eigentlich nur, noch mal posten, und alles entfernen, was eventuell den Filter auslösen könnte (was halt leider ein bisschen im Trüben fischen ist …).
@@thenativeweb Nun ja, was ich alles geschrieben habe, kann ich leider nicht mehr so aus dem Kopf wiederholen. Ich hatte das Video gelobt und die Tatsache, dass es aus einem einzigem Schnitt gedreht worden ist. Mein Abo kommt aus diesem Video. Dein KnowHow und die Methode alles gut zu erklären. Weiter hatte ich meine Erfahrungen zu diesem Thema geteilt. Ähnlich wie in den anderem Post. LG pS: Tolle Arbeit, weitermachen.
Im Browser würde ich eher Elm als Programmiersprache verwenden statt JS oder gar WASM. Das zusammen mit einem Rust Server als Backend, der in einem WASM Container läuft: perfekt.
Sehr gut erklärt, danke. Mein Gedanke war auch das Docker etwas anderes als WebAssembly ist und WebAssembly, zumindest jetzt, nicht überall Sinn macht. Im normaler Web-Entwicklung sollte WebAssembly kaum eine Rolle spielen, da es zumindest im Moment zu aufwendig ist.
Ich denke, das Ganze hat sehr viel Potential. Es gibt verdammt viele .NET-Entwickler, die für das Front-End keine große Lust bzw. Ressourcen frei haben, um diese mit Java und Co. zu realisieren. Für diese ist das natürlich ein Segen, da sie in ihrem Ökosystem bleiben können. Viele alten geschäftsrelevanten Softwaresysteme, die für den "normalen" Desktop entwickelt wurden, werden sicherlich in den nächsten Jahren zumindest teilweise auf Webassembly portiert werden. Genau hier sehe ich viel Potential für Blazor. Spannende Zeiten stehen uns bevor.
[gr] Ich weiß leider nicht, was genau dein Kommentar war, aber TH-cam löscht von sich aus Kommentare, zum Beispiel unter anderem dann, wenn darin Links enthalten sind. Wir löschen keine Kommentare, solange sie nicht gegen den Anstand oder Ähnliches verstoßen. Vielleicht kannst du es einfach noch einmal posten, gegebenenfalls mit angepasstem Inhalt?
@@thenativeweb 🤔 komisch.. aber gut, dass ihr nich löscht. Danke für die Antwort. Frage mich, ob da vielleicht Sonderzeichen drin waren.. 🤔 (Schade.. hatte mir den Text nicht abgespeichert.. ). Egal.. hab unten noch was zu wasm geschrieben...
Also wenn ich mir die Komplexität vieler Javascript Frontend Toolings anschaue und in Verhältnis setze mit den den Möglichkeiten die WASM bietet (siehe z.B. Figma) dann sehe ich das nicht unbedingt als mit Kanon auf Spatzen schießen. Wenn sich auch bei WASM noch einiges tut ist es vielleicht nicht unbedingt nur für die komplexeren UIs vorbehalten. Soooo lange kann man WASM nun auch noch nicht ernsthaft nutzen - und wie lange gibt es im Vergleich JS schon. Selbst wenn es schon das gelbe vom Ei wäre würde das noch lange dauern bis es bei den "Massen" ankommt. Die Nutzung auf dem Server ist aber natürlich auch interessant.
Ich denke es fehlen noch viele Voraussetzungen damit Webassembly im Browser eine Rolle spielt, was mmn aber langfristig der Fall sein wird. Die Entwicklung und Einbindung war bisher einfach zu unhandlich, und so auch zu experimentell für die meisten Firmen. Und dazu fehlen einer wichtigen Zielgruppe, nämlich PWAs, noch so viele Features, dass man so lange weiterhin eher auf native Anwendungen setzt. Insbesondere iOS liegt mit dem PWA support so weit zurück, Steve Jobs würde sich im Grab umdrehen wenn er das wüsste.
[gr] Ja, langfristig gehe ich auch davon aus, dass WebAssembly eine große Zukunft vor sich hat, aber da reden wir über einen Zeitraum von über fünf Jahren IMHO.
Ganz deiner Meinung! WebAssembly wird zuerst die Edge erobern, um hochspezialisierte Workloads auszuführen. Heute bereits entwickeln wir Edge Software (Fastly Compute Edge) in Rust, mit einer Latenz jenseits von Gut und Böse. Spannende Zeiten! WASI hinkt noch zu stark hinterher, als dass es als Runtime für den Server verwendet werden kann. MicroVMs wie Firecracker sind ebenfalls auf dem Vormarsch.
Ich finde das Video gut, aber es holt meiner Meinung nach viel zu weit aus und hat einen zu Reißerischen Titel, "Native Functions für Kubernetes in Web Assembly?" hätte es treffender beschrieben. Denn am Ende ist es genau das was Docker ausmacht was Web Assembly eben nicht kann (und auch nicht braucht), Volumes, Netzwerk Separation, mitbringen der Laufzeitumgebung. Und warum soll ich denn WebAssembly nicht in ein Container Image verpacken wodurch ich ein Image für alle Plattformen erhalte die eh schon einen passene Laufzeitumgebung haben.
WASM im Browser ist im Moment eher uninteressant, da die kompilierten Module relativ schwergewichtig sind. Zudem sind die synthetischen Benchmarks, die die Leistung mit JS vergleichen, eher ernüchternd. WASM wäre aber bspw. für Online-Playgrounds für Programmiersprachen interessant, was User-Expeirence und Sicherheit angeht. Code-Editoren bzw. Online IDEs wie StackBlitz sind auch ein interessanter Use-Case. Die haben es ja geschafft einen ganzen Node.js-Server im Browser zum Laufen zu bringen.
[gr] Ja, das ist ein spannendes Feld für WebAssembly. Was die Größe angeht: Ich denke, das hängt stark vom Compiler ab, beziehungsweise was man da reinpacken will. Denn prinzipiell ist WebAssembly ja doch recht kompakt.
Da WASM schon von allen Browser-Engines unterstützt wird: Wann kommt der JavaScript-zu-WASM Compiler? Und wann kommt der erste physische Prozesser mit Mikrocode, um WASM nativ auszuführen? Ist WASM geeignet, um direkt auf der CPU ausgeführt zu werden?
[gr] Ganz ehrlich - das mit der nativen Unterstützung habe ich mich bei .NET und MSIL auch schon gefragt … wäre ja irgendwie logisch, wenn so was käme.
[gr] Naja, "neu" ist das ja nicht wirklich - ein AOT-Compiler ist ja der klassische Ansatz eines Compilers, der zeitlich unabhängig (das heißt, vor der Ausführung) läuft. Natürlich spart man sich damit den JIT-Compiler, aber man hat dann wieder plattformspezifischen Code (was man mit der Zwischensprache ja gerade vermeiden will). Insofern wäre es schon interessant, eine direkt Hardware-Unterstützung zu haben für Sprachen wie WebAssembly, MSIL, Java Bytecode & Co. - wobei das im Endeffekt dann wieder alles genauso wie vorher wäre, nur um eine Ebene verschoben 😉
@@thenativeweb Ich habe natürlich immer dotnet Blazor im Hinterkopf und da ist das jetzt ein "brandneues" Feature... Etwas näher an die Maschine zu kommen.. mit dem Code, wäre natürlich klasse. Also C++ lässt sich bei dotnet in die wasm mit einlinken. Hatte da mal extra nachgeguckt, ob C++ ggf. tiefer zugreifen kann (also nicht nur wg. speed)... aber der kommt aus einem Sandkasten auch nicht heraus. Gab es nicht mal die Möglichkeit bei C++ einen Assembler/ ASM-Block im Code einzufügen?!🤔 Entweder waren das alles Bytes oder sogar Mnemonics (weiß ich nicht mehr... aber wäre mal interessant, etwas damit zu experimentieren:)
@@gregcyrus2739 [gr] Ah, sorry, das habe ich dann missverstanden. Dann hast Du natürlich recht 😊 Bei C++ weiß ich es nicht, aber in Pascal ging das auf jeden Fall: wiki.freepascal.org/Asm
Nun, das könnte ich mir durchaus vorstellen, dass es für manche Anwendungen Sinn macht. Insbesondere Container, in denen nur ein Prozeß läuft. Wäre natürlich fraglich, wie die Performance ist ... ich kann mir kaum vorstellen, dass ein wasm-Binary aus Rust oder C++ in wasm-jit schneller ist als das native Binary. Zunächst mal müssten natürlich Dinge wie zusätzliche Files in wasm-Packages und/oder directory mounts funktionieren. Frage mich allerdings, wie wasm mit nativen Dependencies umgeht? Von "ersetzen" kann jedenfalls keine Rede sein. Analog wie docker keine virtuellen Maschinen ersetzt. Es sind alles Konzepte, die stellenweise "das gleiche" erreichen aber völlig unterschiedlich funktionieren mit jeweiligen Vor- und Nachteilen.
Schön heruntergebrochen! Ein Aspekt, der mit bei dem Vergleich Docker vs WebAssembly etwas zu kurz kommt, ist die Entwicklungsumgebung selbst. In einem Team, deren Entwickler mit möglicherweise verschiedenen Betriebssystemen arbeiten, sind Container auch super für die Entwicklungsumgebung selbst. Also dass das, was das Buildsystem am Ende ausspuckt, überall das gleiche und reproduzierbar ist. Meinst Du, dass wir in Zukunft ähnliches bei WebAssembly erwarten können? Also dass die Tools, die zum Bauen verwendet werden (Build-Skripte, curl, spezielle NodeJS, Python, was auch immer Version) dann immer in WebAssembly vorliegen und wir explizit die einzeln nutzen? Da würde vielleicht noch eine Package-Registry fehlen 😅
[gr] Das ist eine spannende Frage, die ich mich Stand heute ehrlich gesagt nicht wirklich zu beantworten traue … am ehesten würde ich darauf tippen, dass die ganze Entwicklung mehr und mehr in den Browser wandert, à la Online-IDEs, wo sich die Frage nach dem Betriebssystems des Clients gar nicht mehr stellt … Wobei ich persönlich zumindest bislang so auch nicht arbeiten mag …
@@thenativeweb das ist eine interessante Sichtweise mit den Online IDEs. Ich finde die (bisher) auch nicht so prickelnd, weil es doch so manches mal sehr seltsame Bugs zum Vorschein kommen, die dann gerne von dem jeweils genutzten Editor kamen. Aber natürlich, wenn sich das verbessert, würde es nur noch die eine Entwicklungsumgebung geben und das Docker Setup wäre somit nicht mehr unbedingt notwendig. Also langfristig könnte ich es mir dann so vorstellen... Danke für die Einschätzung! :)
Moin schönes Video und spannende Frage ich glaube man kann noch viel mehr von WASM erwarten als bisher. Aber Blazor ist nicht unbedingt eine Riesen Kanone man kann damit auch schnell Business Sites umsetzen die eben nicht dem normalen Webflow folgen.
[gr] Wie schon in einem anderen Kommentar geschrieben: Blazor hat seinen Anwendungsfall, keine Frage. Aber es wird mir aktuell zu sehr à la Gießkanne angewendet, oft mit der Motivation, bloß kein JavaScript machen zu müssen. Und das halt auch für Hallo-Welt-größenartige Probleme. Und das halte ich eher für eine unglückliche Idee. Denn allein Weg, um die Seite zu laden, ist aufwändiger: HTML + JS + WebAssembly, und Du brauchst einen Compiler von C# nach Wasm, … und jetzt vergleich das mal mit einer leichtgewichtigen reinen JavaScript-Lösung. Ich will nicht sagen, dass man sich bei JavaScript mit all den Frameworks nicht auch verkünsteln kann, aber Blazor wird aktuell viel zu oft als die magische Silberkugel angepriesen, die alle Probleme lösen soll. Und das ist sie nicht.
@@thenativeweb Also ich gebe dir natürlich Recht Golo. Blazor wird wie vieles der letzten Jahre als Heilsbringer der Webentwicklung angesehen. Ist natürlich großer Käse. Beschissen designte Software bleibt auch beschissene Software egal was man nutzt. Allerdings macht Blazor unheimlich Spaß zu entwickeln. Denn sind wir mal ehrlich JS macht doch keiner gerne und Typescript ist auch nur eine wenn auch schöne Hülle. Der Vorteil von Blazor ist doch die wirklich tolle Möglichkeit meinen C# Code (Sicht des Entwicklers ohne die Zwischenebenene) im Web oder als App im Container zu erstellen. Es lässt sich mit minimalen HTML / CSS und bisl JS und C# eben auch echt tolles Zeug machen.
@@sven2529 Muss man ja nicht so sehen Sven. Ich sage dir ganz ehrlich ich mache JavaScript sicher nicht so gern wie ich C# Code schreibe. Ist aber meine persönliche Meinung und ich kenne durchaus viele die sich mit JS schwer tun. Golo hat schon recht vielleicht sollte man mal Lisp machen um sich da das Leben zu vereinfachen. Aber auf der anderen Seite ist halt Blazor dann so cool das ich damit mein Web auch deployed bekomme und das mit C#. ;)
Ich denke WASM/WASI werden auf dem Client (CPU) dynamische 3D fähige UI Anwendungen ermöglichen, in dem dadurch der lokale Grafikprozessor (GPU) des Client eingebunden werden kann. Spontan fällt mir dabei u.a. das Anwendungsfeld der Architektur ein.
WASM is here to stay. Darüber sind wir uns einig. Welche Entwicklung das nehmen wird weiss nur die alte Frau mit der Glaskugel. Docker Desktop ist jetzt lizenzpflichtig - keine schöne Entwicklung und vielleicht schon der erste Docker Sargnagel...
Hmmm, das ist das erste Mal, dass du mich nicht überzeugen konntest. Einen super wichtigen Aspekt hast du bei Docker vergessen: Die Umgebungsvoraussetzungen. Wenn ich eine Anwendung habe, die z.B. memcached voraussetzt, dann kann ich das mit einem WASM-Modul nicht anständig orchestrieren, weil memcached nicht zwangsläufig vorhanden ist. Da bringt mir auch ne Kubernetes-Erweiterung nix, die WASM handhaben kann. Das ist mit Docker ganz anders. Alle Voraussetzungen können fein säuberlich bestimmt werden und sind dann auch vorhanden. Mein Fazit ist daher: WASM kann Docker gar nicht ersetzen und die beiden müssen zwangsläufig koexistieren.
[gr] Ja, das ist richtig (das mit der Orchestrierung). WASM dient eben nur dazu, einen (1) Prozess in eine andere Zwischensprache zu kompilieren, die sehr portabel ist. Alles übrige wird davon nicht tangiert, weshalb man um zB Kubernetes nicht herumkommt. Im Grunde würde ich sagen, dass häufig vermutlich sogar WebAssembly-Module in Docker-Container verpackt werden, die dann auf Kubernetes ausgeführt werden. So hätte man "best of three worlds", weil die Docker-Container damit eventuell plattformunabhängig würden, aber man ihre Vorteile trotzdem weiter nutzen könnte. PS: Dass WebAssembly Docker nicht ersetzen kann und beide koexistieren, zu dem Schluss komme ich ja aber auch, oder haben wir da einander irgendwie missverstanden?
@@thenativeweb Ich hab dein Fazit so verstanden, dass sie eher koexistieren würden, nicht aber zwangsläufig müssen. Und ja, das mit WASM in Docker habe ich selbst auch schon gemacht. Was ich aber eher suche ist sowas wie docker, womit man seine Umgebung deklarieren kann, aber ohne weiteren Overhead. Gibt es da was? Quasi das Betriebssystem direkt als Container nutzen.
@DJTechnostyler Azure Functions (serverless) könnte Dich vllt. interessieren. @andere: Also entweder ist mir was mit wasm entgangen.. oder es wird hier was verwechselt: Wasm mit Docker zu vergleichen passt irgendwie nicht. Durch das Sandbox-Konzept von Wasm eignet es sich schon als Container, startet extrem schnell, ist super kompatibel und z.B. mit .Net-Core auf allen Platformen unendlich erweiterbar. Das ist aber noch Zukunftsmusik... Z.zt. ist Wasm eher für Browser interessant. Z.B: Ajax wird direkt von einer Klasse (httpClient) ersetzt, DOM-Objekte eindeutig identifiziert (kein $-jQuery-Selector mehr, der je nach Webserver-Version nix mehr findet), diese zudem automatisch aktualisiert (Blazor).. Alles viel einfacher, sicherer und vorallem schneller! PS: Html+CSS sollte/muss man aber nach wie vor können! 👍🏼
@@DJTechnostyler [gr] Nicht, dass ich wüsste … also Kubernetes wäre da halt meine übliche Antwort, das ist ja quasi das "Betriebssystem für Container", aber das ist in dem Fall ja nicht das, was Du suchst. Da muss ich ansonsten, fürchte ich, leider passen.
War etwas überrauscht von dem Titel. Würde eher erwarten dass webassembly möglicherweise in docker verwendet wird als dass es docker ersezt (1A click-bait titel^^). Dass man mehrere Sprachen mischen kann ist ganz nett aber da ging die ganze microservice sache ja in eine ganz andere richtung und verbindet auch verschiedenste sprachen über grpc oder nen ganz normalen rest service ohne probleme. Man plant ja nicht dass man einen riesigen monolyth basteln wird in 10 verschiedenen sprachen (wenn doch dann... schlechter plan imo). Gefühlt würde ich denken dass die IL Sprachen von z.B. Java und C# mehr optimiert oder/und mehr features für die sprache für die diese entwickelt wurden haben sollten. Zudem wird man schwer machinencode in webassembly übersetzen können. Wenn man externe programme hat die laufen müssen damit dein program überhaupt was tud wirds schwer. Das mit Blazor von technischer seite... deffinitiv bischen overkill. Jedoch ist das programmiermodell im vergleich zu asp mvc oder razor pages sehr gut. Wenn man moderne webapps mit razor schreiben will fühlt sich das mehr an als schreibe man die ganze app in vanilla JS ohne framework und dann noch mit erstaunlich schlechter JS IDE von der gleichen firma die vscode gemacht hat. Frameworks wie vue sind sehr gut. Aber wenn man wo arbeited wo gewünscht ist möglichst in C# zu bleiben und nicht mehrere tech stacks zu haben. Dann ist meiner meinung nach blazor das geringste übel. Für Fälle wo der Schutz der "inerterlectual property" sehr hoch prioriziert wird denke ich auch dass blazor server sehr viel benutzung finden wird in programmen für firmen. Auch wenn das was "Mit Kanonen auf Spatzen schießen" angeht noch mal eine Liga über dem webassembly ist.
[gr] Du hast natürlich recht, dass der Titel völliger Käse ist… Wir haben ihn eigentlich auch nur deshalb aufgegriffen, weil ich tatsächlich Aussagen in dieser Richtung in den vergangenen Wochen einige Male gelesen habe, und das selbst sehr absurd fand.
Dieser Chanel is ne Goldgrube ... ziemlich schwieriges Thema aber ich denke nicht, dass webassembly Docker ablösen wird (oder sollte), denn Docker wird nicht nur im Kontext "Web" verwendet. Ich denke "Koexistenz" ist das stichword wobei ich befürchte, dass das WEB dadurch nicht wirklcih "sauberer" wird. Wahrscheinlich wirds darauf hinauslaufen dass in den nächsten Jahren mindestens 237 neue Javscript-Frameworks erstellt werden die man dann alle "braucht" um seine NodeJs projekte auf Web-Assembly kompiliieren zu können.
[gr] Was die Koexistenz angeht, bin ich bei Dir - weniger allerdings bei dem Punkt, dass man Node.js nach WebAssembly kompilieren sollte: Da WebAssembly ja als Ergänzung (und nicht als Ersatz) für JavaScript gedacht ist, ist Node.js von allen Backend-Technologien so ziemlich die einzige, die man *nicht* nach WebAssembly kompilieren muss. Oder habe ich Dich grundsätzlich missverstanden?
dass ich auf dem client wenig tut wundert mich nicht. entwickler heute haben gar keinen druck mehr leistungsoptimiert was zu entwickeln - weil es auch die konkurenz nicht mehr macht. kunden kaufen andauernd leistungsfaehigere geraete und wenn etwas langsam laeuft dann ist ja immer die hardware oder das betriebssystem schuld (so denkt der endanwender) ..viel schlimmer, native anwendungen sterben aus und dank react wird alles immer schlimmer. dann sehen wir noch weiter, dass das was frueher in java geschrieben wird heute lieber in python geschrieben wird und da wird es dann auch immer ineffienter.
[gr] Das ist richtig, spricht sich nur leider so schlecht aus (für mein Empfinden). Trotzdem hast du natürlich recht, dass man das eigentlich mit U aussprechen müsste.
[gr] Das ist richtig, und genau darum geht es unter anderem auch im Video. Wir haben den Titel deshalb so gewählt, weil uns der bei einigen Blog-Artikeln aufgefallen ist, und wir uns da auch gefragt haben, wo der Zusammenhang ist..
Wirtschaftlich gesehen werden Linux Distros sterben und viele FOSS-Bibliotheken auch, weil sowohl Go wie auch WASM quasi 0 dependencies haben bzw diese exakt vom Autor definiert werden. Wir sehen die Erosion bzw Vorwegnahme jetzt schon bei k8s durch das Verwenden von proprietären, manages services und proprietary oder zumindest spezialisierte Baselayer. Letztlich läuft alles auf dumb terminals und property main frames as a service hinaus. Die Cloudanbieter werden wie bisher schon ihre Tools nur sehr selektiv freigeben und so immer mehr "Moat" bzw Vorteile aufhäufen. Schaffen sie dann noch besonders effiziente Prozessoren, die am Markt nicht zu kaufen sind, ist es vorbei. Für die Masse bleiben dumb devices und VSCode im Browser als IDE. WASM als universelles Ziel-Runtime ist der perfekte lock-in.
Ich schau ziemlich viele Videos zu IT-Themen, aber dieses Video ist eines der besten, die ich seit langem gesehen habe. Alles sehr verständlich und doch auf einem guten Niveau erklärt. Kein Geschwafel, alles auf den Punkt, keine unnötigen Schnitte. Ehrlich, sehr gut. Und kein nerviges 'like, subscribe', was bei eurem content auch nicht nötig ist, da ich sofort abonniert habe :) Ich freue mich auf zukünftige Videos und hoffe, dass ich die Zeit finde, eure bisherigen zu sehen
[gr] Vielen, vielen Dank - das ist wirklich schönes Feedback, das uns sehr freut 😊
Unglaublich gutes Video. Bitte bitte mehr davon! Auch in diesem Format. Könnte stundenlang zuhören und den hexagons beim pulsieren zuschauen!
[gr] Vielen lieben Dank 😊
Was genau meinst Du mit "in diesem Format"?
Sehr informativ und absolut auf den Punkt gebracht!
[gr] Vielen lieben Dank - und schön, wieder von Dir zu lesen 😊
Hallo, bisher hab ich kaum Videos auf deutsch über Programmieren gesehen. Ich hätte nicht gedacht, dass es so großartigen Content gibt.
Man merkt ganz deutlich, daß der Fokus bei euch auf dem Inhaltlichen liegt. Viel Content auf TH-cam konzentriert sich hauptsächlich auf die Präsentation und der Inhalt ist nicht nennenswert.
Zum Thema:
Auf meiner Arbeit nutzen wir Docker für machine learning Experimente (Kubernetes kommt auch bald) und um unterschiedliche Buildumgebungen für C++ bereitzustellen. Webassembly kann diese Anforderungen für uns nicht abdecken.
Danke, hab euch abonniert!
[gr] Vielen, vielen Dank - das freut uns sehr, und genau der Fokus auf das Inhaltliche ist auch unser Anspruch 😊
Sehr gut und sehr verständlich aber dennoch kompakt erklärt. Sehr gutes Video!
[gr] Vielen Dank 😊
Genau der Detailgrad, den ich gebraucht habe. Perfekt für einen Über- und Einblick in die verschiedenen Technologien und deren Zusammenhänge. Danke auch für deine Prognose. Ich bin gespannt, was aus WASM noch so wird.
[gr] Das freut mich, vielen Dank 😊
Als Solomon Hykes sagte, dass Docker nich nötig gewesen wäre wenn wasm und wasi schon früher existiert hätten, habe ich das nicht ganz verstanden. Die Erklärung in diesem Video war die beste die ich bis jetzt im deutschen und englischen Sprachraum gehört habe. Jetzt verstehe ich die Aussage endlich. Danke für diese Video!
[gr] Sehr gerne, freut mich 😊
Für alle, die den angesprochenen Tweet nicht kennen, hier noch ein Link: twitter.com/solomonstre/status/1111004913222324225
muss schon mal sagen, das ist einer der besten Kanäle die ich je entdeckt habe!
[gr] Vielen lieben Dank 😊
Fantastisch, danke für dieses tolle Video!
Anmerkung: Gerade dieses Numbers Crunching finde ich sehr interessant. Zugegebenermaßen ist es vielleicht eine er skurrile Lösung, aber ein WASM-Modul, welches einfach im Browser mit Daten gefüttert wird (vom Server) und das Ergebnis wieder zurück schickt ist eine super simpel zu deployende Lösung, um viele Berechnungen auf mehrere/viele Clients zu verteilen. Die Clients müssen einfach nur die URL aufrufen und sind mit im Pool der Worker und helfen so mit, die Berechnungen durchzuführen.
Daher hoffe ich, das uns WASM im Browser noch einige Zeit erhalten bleibt.
Tolle Präsentation. Danke für diese sehr kompakte und konzentrierte Vorstellung der Thematik. Keine unnötigen Ausschweifungen aber auch keine unpräzise, unfundierte Argumentation. Sehr hilfreich!
[gr] Vielen Dank, das freut mich sehr 😊
Vielen Dank für das tolle Video. Da ich kein Programmierer bin, sondern eher Management ist das Finden von aufschlussreichen Video immer eine Herausforderung. Du hast es geschafft, sowohl den Tekki mitzunehmen, als auch mich - Vielen Dank dafür
[gr] Wow, das freut mich, vielen Dank 😊
Sehr informativ, vielen Dank. Mir war das bislang überhaupt nicht bewusst das es WebAssembly auch auf dem Server gibt. -> "... mindblown" :)
[gr] Gern geschehen 😊
Und ja, man hört tendenziell eher wenig(er) darüber, aber eigentlich wäre es ja naheliegend (ich hab's zugegebenermaßen aber auch nur mitbekommen, weil ich viel mit Node.js zu tun habe und Node.js Unterstützung dafür bekommen hat).
Wirklich informative Filme! Viele Begriffe, über die ich immer wieder stolpere, sind hier kurz und knapp und vor allem gut erklärt! Danke schön.
[gr] Sehr gerne 😊
Ich wünsche jede Nacht bevor ich schlafen gehe, dass C#, Java oder egal welche andere Programmiersprache JS im Web ersetzt. WebAssembly hat diese hoffnung für mich wieder entfacht.
Guter Beitrag, vielen Dank. Normalerweise gucke ich by design nur englisch sprachige Videos, aber hier ist die Umsetzung aus deutschem Grundwort und Fremdworten so gut gelungen, "Daumen hoch"!
[gr] Vielen Dank 😊
Duuuuude, allein für die Einleitung hast Du meinen Daumen und Abo. Für den Rest hast Du meinen Respekt! Weiter so, freu mich auf weitere Videos.
[gr] Vielen, vielen Dank 😊
Sehr gute Präsentation!
Ich habe mir eine Pause gewünscht und der guter Mann könnte ein Schluckwasser trinken.
Ich kenne zwar WASAM nicht, nachdem ich das Video angeschaut habe, sieht es so aus, als ob WASAM doch ein Konkurrent zu Docker sein würde.
Selten so eine kompakte präzise Übersicht über ein Thema gehört. Toll gemacht!
[gr] Vielen, vielen Dank 😊
Extrem gut erklärt. Und sehr informativ. Haben wir an der auch schon so kommentiert. Mein Kommentar noch mal oben drauf für den Algorithmus.
[gr] Danke schön 😊
Ich beherrsch noch nichtmal Docker/k8s und jetzz rollt schon der nächste Zug auf mich zu.
Danke für deie tolle Einordnung!
[gr] Sehr gerne 😊
Und lass Dich nicht verrückt machen - nicht alles wird so heiß gegessen, wie es gekocht wird. Zum Thema, dass es manchmal einfach zu viel ist / wird: th-cam.com/video/CYRnA9ue1cI/w-d-xo.html
Wau ich bin wirklich begeistert. Tolle expertiese, so kompakt aber tiefgreifend erklärt. Respekt 👌👍
[gr] Das freut mich, vielen Dank 😊
Habe nach 12 Minuten, welche mich der Antwort auf die Ja/Nein-Frage nicht näher brachten, abgebrochen.
Die Menge an Zusatzinformation ist mir, da diese bereits bekannt, zu viel.
Bin eigentlich Fan davon, dass sachdienliche Hinweise gestreut werden. in diesem Video wirkt es auf mich aber so, als das die Frage samt Antwort (noch) kein Publikum haben kann,wenn soviel Grundlagen als Beiwerk von Noten.
.. so, genug ich mir meins und meinen 5 Cent zum Video. DU machst nen Klasse Job!👍
Sehr verständlich und geduldig erklärt!
[gr] Danke schön
Damn! Das war überraschend gut.. hab mal einen Sub dagelassen :) Freue mich auf weitere Videos!
[gr] Vielen, vielen Dank 😊
Danke, Deine/Eure Gedankengänge dazu entsprechen auch in etwa meinen. Ich sehe da noch einige Anwendungskomplexe, wo ich es mir aktuell nicht vorstellen kann sie mit WASM umzusetzen, aber die durchaus mit Docker möglich sind. Aber viele kompaktere Anwendungen dürften eben durchaus super damit laufen. Ich sehe WASM auch als DIE Möglichkeit aus der PHP-Bindung bei einfachen Webspaces rauszukommen. Aktuell hat man ja in der Regel die Wahl zwischen einem einfachen Webspace ohne SSH und einer starken Bindung an PHP fürs Backend oder komplexeren Webspaces mit SSH für mehr Sprachenvielfalt wählen. Mit WASM und Crustlet könnten Hoster auch genauso einfache Webspaces anbieten, wie sie es aktuell nur mit PHP machen. Ich bin gespannt was das noch für Veränderungen für Webdeveloper so mit sich bringt. Vielleicht werden ja so auch demnächst die gerade noch meistverbreiteten CMSe wie WordPress, Drupal, Joomla und Co. vom Trohn gestoßen.
[gr] Spannender Punkt - an klassischen Webspace habe ich dabei ehrlich gesagt gar nicht gedacht, weil ich das gar nicht mehr so auf dem Schirm habe, aber ja, den gibt's durchaus auch noch 😊
Das mit den CMS-Systemen ist auch ein spannender Punkt … ein gewisser Anfang ist da ja mit den Headless-Systemen à la Contentful & Co schon gemacht, aber irgendwie erwarte ich mir da auch noch mehr … mal abwarten 😊
Wie man es gewohnt ist, ein extrem informationsdichtes, gutes Video! Kurze Frage an Golo: Kannst du Informationsquellen empfehlen, bei denen man die neusten IT-/Programmiertrends kurz und bündig vorgestellt bekommt, oder woher ziehst du immer deine extrem guten Informationen? #fürDenAlgorithmus
[gr] Vielen Dank für das Lob 😊
Tja, woher bekomme ich meine Informationen … ich würde sagen, aus einem ganzen Sammelsurium von Quellen: Twitter, Hacker News, Heise, Golem, verschiedene Newsletter, Kolleg:innen, … und dann halt eigene Recherche: Dokumentation lesen, ausprobieren, … vieles ist einfach Erfahrungssache.
Zum Beispiel: Für dieses Video habe ich mich rund einen Tag in den aktuellen Stand von WebAssembly eingelesen. Einfach gegooglet, und mehr oder weniger alles gelesen, was ich an halbwegs aktuellem gefunden habe. Das versucht, zu strukturieren und zu bewerten. Und mit Docker arbeite ich seit zig Jahren quasi täglich, und was eine Intermediate Language ist, kenne ich noch aus meiner .NET-Zeit, wo ich mich auch mehrere Jahre mit MSIL beschäftigt habe.
Insofern sind mir viele von den Konzepten häufig bekannt, es sind dann nur andere Implementierungen. Die oben genannten Nachrichtenquellen sind dann eher nur der Trigger, wo man mal wieder reingucken könnte, aber das meiste ist Erfahrung und ganz klassisch, Doku lesen und ausprobieren.
Ich habe meine Bachelorarbeit über WASM outside the Web geschrieben und alle angesprochen Punkte decken sich mit meiner Recherche. Gutes Video!
[gr] Ui, das klingt spannend! Vielen Dank für Dein Feedback 😊
@@thenativeweb Es war unglaublich spannend und auch fordernd!
In meinen praktischen Ergebnissen hat sich jedoch gezeigt, dass WASI Funktionen einen overhead in der Performance zu generieren scheinen. Andere Versuche bezogen sich meist nur auf WASM und auch den vor dir angesprochenen cold Start. Getestet habe ich mit wasmer und wasmtime, kompiliert aus Rust jeweils im Vergleich zu nativ (rust->native)
Echt gut erklärt, vielen Dank dafür!
[gr] Vielen Dank 😊
Lustig, dass TH-cam mir jetzt erst auf einmal diesen Kanal empfiehlt, ich komme relativ aus der Nähe zu Riegel :)
[gr] Das ist tatsächlich lustig - wenn ich fragen darf, woher kommst Du denn?
@@thenativeweb Komme aus Merdingen und studiere momentan Medieninformatik in Furtwangen :)
Tolles Video! Super erklärt und nun hab ich mal eine Vorstellung von webassambley
[gr] Das freut mich, vielen Dank 😊
Danke für den Vortrag! Scheinbar habe ich die letzten 18 Monate unter einem Stein gelebt - für mich war wasm immer nur ein Browser-Thema. Daher habe ich das Video mehr aus Unglaube als aus Interesse angeklickt. Aber jetzt scheint mit das Konzept aber wie der fehlende Stein, der den ganzen kubernetes-stack auch für kmu-unternehmen rechtfertigt.
Ja, daß denkt mal leider öfter hier auf YT. Aber trotzdem ist man ja auch, wenn man ein wenig gerade geht, recht schnell vorn ;) Dranbleiben
Wow. Merci fuers Update, kann ich wieder punkten in der Kaffeekueche ;-)
[gr] Haha, viel Erfolg 😊
In dem Zusammenhang interessant ist auch Oracles GraalVM, die ebenfalls viele verschiedene Programmiersprachen ausführen kann (unter anderem JavaScript) und auch deren Mischung erlaubt.
Bei Docker geht es ja nicht darum, irgendwie Container zu nutzen, sondern mit bestehenden Technologien wie NodeJS, PHP, Phyton, einen Memcache usw. (und spezielle Versionen davon) unabhängig voneinander zum Entwickeln nutzen zu können , aber ohne diese auf Rechner nativ installieren zu müssen, und die Software die man entwickelt dann mit allen Abhängigkeiten exakt so produktiv deployen zu können. Diese verschiedenen Technologien in den Containern, arbeiten dann als "Services" mit einander. Mir ist es leider im Video nicht klar geworden, ob genau das mit serverbasierten WebAssembly möglich wäre. Viele Grüße! PS. Ich galube Figma verwendet WebAssemblys für ihre UIs im Browser.
Man kann ja mit Docker auch fertige Anwendungen wie Word-Press einsetzen, ohne sich um dessen Abhängigkeiten kümmern zu müssen, oder einfach als "Utility-Container" in einem Deploy-Vorgang oder nur so auf einem Entwicklungsumgebung. Auch dafür ist Docker gedacht, aber ich weiß nicht, ob das auf WebAssemblies zutrifft.
[gr] Ich würde sagen, beides nein. WebAssembly ist einfach nur eine Sprache, die sich sehr gut system-, plattform- und betriebssystemübergreifend ausführen lässt. Nicht mehr, nicht weniger. Insofern kann WebAssembly Container nicht ersetzen - es sei denn, der ganze Zweck des Containers ist, ein Deployment-Vehikel für Anwendungen zu sein, die nur aus einem Binary bestehen.
Sehr spannend! Danke für das tolle Video.
[gr] Gerne 😊
Super Video! Teile die Meinung der coexistenz von wasm und docker. Was ich mir wünschen würde: An mancher Stelle imho etwas zu sehr vereinfacht. Bitte etwas mehr auf die Schwierigkeiten mit wasm eingehen (.net nur mit blazor, also .net console app nicht in wasmtime ausführbar (GC ist ein Problem), blazor aber nicht einfach so stand-alone afaik). Außerdem Probleme mit pthreads, exceptions (c++) und eben eingeschränkter wasi (c runtime Grenzen). Und nett wäre auch ein Ausflug zu den Auswirkungen bzgl Jit und AOT complied Code im Umfeld wasm.
Ein kleiner inhaltlicher Fehler ist das Quellcode größer Binär oder IL Code ist, egal welche Sprache man sich anschaut sieht man das compiled Code immer größer als Quellcode ist.
Ein gutes Beispiel ist .NET Web assembly wo man den langsameren interpretierten Modus statt schnellen AoT Modus wählen kann um Package Size zu sparen.
1001 Like gepusht oida. Top Folge ! Thx
[gr] Danke ☺️
Großartig. Sehr sehr angenehm zuzuhören. Kannst du auch Mal ein Video über hashicorp nomad als orchestrator, ggf auch im Zusammenhang mit webassembly machen?
Ich finde das Thema WASM sehr interessant, weil es die theoretische Wiederverwendbarkeit von Quellcode extrem verbessert. Interessant wären dabei noch Lösungsansätze für einheitliche Schnittstellen in der Programmierung, also die Integration von Quellcode, welche in WASM kompiliert wurde, in den eigenen. Besonders spannend ist die Integration von funktionellen Sprachen zur Lösung von spezifischen Problemen,
Sehr informativ, vielen Dank! 🙏🏻
[gr] Danke schön 😊
Erstmal: Wirklich ausgesprochen gut erklärt! Herzlichen Dank!
Mir stellt sich nur die Frage: Es gibt doch Runtime VMs für den Backend schon lange. zB die Java VM. Warum hyped nun WASM am Backend? Ansich ist das ja nichts neues. Oder doch?
[gr] Vielen Dank für das Lob 😊
Was den Vergleich zur Java-VM angeht: Ja, das ist theoretisch genau das gleiche.
Der einzige Unterschied ist, dass die VM dafür jetzt eben auch nativ im Browser existiert, und man damit eine "echte" Plattformunabhängigkeit bekommt, ohne dass man erst noch etwas installieren müsste (anders als früher zB das Java-Plugin).
Ich freu mich so sehr auf die Zukunft was Webtechnologien angeht. Vielleicht ein Video zum Project Fugu ? :)
[gr] Project Fugu wäre prinzipiell eine schöne Idee - gibt es da etwas Spezielles, was Dich interessiert? Also eher die Beweggründe dahinter, oder welche APIs das sind, oder …?
@@thenativeweb Es ist keine spezifische API sondern eher die Idee, dass wir durch diese neuen APIs in der Zukunft wrapper wie Electron nicht mehr brauchen werden. Anwendungen wie Spotify oder Discord wären als PWAs genau so leistungsstark wie die jetzigen Varianten. Diese Apps könnten ebenfalls auf allen Betriebssystemen installiert werden ohne für jedes build targets zu haben, da die APIs direkt nativ funktionieren.
Das alles kombiniert mit WebAssembly und es wird kaum noch Gründe geben Applikationen zu schreiben, die nicht auf Web-Technologien basieren!
Edit: Vergessen habe ich, dass wir vollwertige Apps im Browser haben!
[gr] Nein, es ist nicht eine (1) spezifische API, aber ja durchaus eine Sammlung von APIs, die alle ein gemeinsames Ziel verfolgen. Deshalb die Frage, ob’s Dir konkret um diese APIs geht, oder eher um ein Gesamtbild.
@@thenativeweb Eher das Gesamtbild -> Apps komplett nativ mit Webtechnologien zu entwickeln und entsprechend die Vorteile genießen!
@@kabo123 [gr] Alles klar, danke für die Aufklärung 😊
In Docker kann man aber nahezu alles packen, ohne dass man es neu kompilieren muss.
Bei wasm stelle ich mir dies aktuell schwierig vor. Den Ansatz finde ich aber gut.
Eher würde ich sagen müsste man den Code dann für wasm schreiben, nur hat man da freie Wahl der Programmiersprache.
[gr] Ja, das stimmt. Bestehenden Code wirst Du nur bedingt 1:1 für Wasm neu kompilieren können - je nachdem, was erforderlich ist, muss man den dann schon anpassen. Aber das Schöne ist ja, dass es diese Option nun gibt 😊
My German is not good at all, but feel like I can understand quite a lot, as I might be a bit exposed to this topic before. Good stuff, viel Danke!
[gr] Thanks a lot 😊
@@thenativeweb I have once written a program in C, (GitHub: luke10x/bible-overtype). Then I wanted to distribute it as a web app so I chose to port it to WASM. Some code had to be changed because the WASM VM just like the javascript itself is mainly based around non-blocking interfaces, therefore the C code had to be rewritten to be more non-blocking. The conclusion is that not all C code can run on WASM, as it can run in Docker. But still, it was quite a nice way to distribute my command line, curses program as a web app. I like your video as it helps me to improve my German.
Super interessant und sehr gut erklärt 👌
[gr] Vielen Dank 😊
Wieso immer das proprietäre docker? Podman ist das freie Open source tool.
[gr] Sieh Docker an der Stelle als Synonym für alle Container-basierten Systeme, quasi so wie Tempo stellvertretend für Papiertaschentuch steht …
Ich höre immer wieder es sei nicht möglich mittels docker auf Linux ein anderes os zu nutzen. Ist es aber denn theoretisch nicht möglich ein qemu in einem Container laufen zu lassen? Dann könnte im qemu ein Windows laufen ;) also grundsätzlich schon möglich.
Danke für den tollen Beitrag zum Thema. Was ich bei dem Vergleich mit Docker / Kubernetes nicht verstehe: Wie soll man denn seine Systemarchitektur in WebAssembly abbilden können? Also z.B. eine MariaDB, ElasticSearch, Nginx über WebAssembly laufen lassen? Das sind doch eher die typischen Anwendungsgebiete von Docker / Kubernetes. Oder zielt dein Fazit genau darauf ab?
[gr] Genau das ist der Punkt - das ist mit WebAssembly gar nicht möglich. Im Prinzip ist WebAssembly nur ein weiteres Format, in dem man Binaries speichern und ausführen kann, nicht mehr und nicht weniger … insofern ist der Vergleich auch Quatsch, es sei denn, man nutzt den Docker-Container ausschließlich dafür, ein einzelnes Binary zu verpacken und auszuführen …
Falls Dich die Details zu WebAssembly näher interessieren, guck mal hier: th-cam.com/video/x07mUrhAecE/w-d-xo.html
Zuerst mal ein großes Lob, Themenauswahl und Darstellung sind top, mit das Beste, was ich in letzter Zeit an deutschsprachigen Content zum Themengebiet gesehen hab. Beim aktuellen Thema kann ich aber der These "WebAssembly (WASM) verdrängt Docker?" nicht ganz folgen. WASM wäre doch eher mit (ggf. multilingualen, IL basierten) Runtimes wie JVM oder CLR zu vergleichen, also dann eher "WebAssembly (WASM) verdrängt Java?". Docker nehme ich doch der deterministischen Umgebung wegen, auch eine Java oder .NET-core Applikation packe ich doch trotz Plattformunabhängier Runtime in einen Docker-Container. Kann aber sein, dass ich irgendein wichtiges Konzept übersehen hab...
[gr] Nein, das siehst Du genau richtig - aber das ist ja im Prinzip auch das, was ich im Video erkläre. Natürlich kann man sich den Docker-Container zukünftig sparen, wenn der einzige Sinn davon ist, ein einzelnes Binary zu wrappen, um es per Umgebungsvariablen konfigurieren und ein virtuelles Dateisystem einklinken zu können. Das geht nämlich auch mit WebAssembly wunderbar - aber für alles, was darüber hinausgeht, wird man um einen richtigen Container nicht herumkommen.
Danke, sehr gutes Video. Schön erklärt 👍
[gr] Merci 😊
Klingt für mich ziemlich interessant. Die Argumentation, dass mit Blazor WebAssembly mit Kanonen auf Spatzen geschossen wird, kann ich erst mal so nicht teilen. Immerhin hat es doch seine Vorteile bezüglich Wartbarkeit und kürzeren Entwicklungszeiten, wenn man seinen Code bei Verwendung von Blazor Server mit dem Blazor WebAssembly Code teilen kann, im speziellen wenn man komplexe Entity Objekte austauschen will. Nur dann macht es Sinn. Wenn der Server in NodejS implementiert ist, dann würde ich sicherlich für das Frontend auch eine JS Client Implementierung wie Angular bevorzugen.
Sehr tolle Videos, da folge ich euch gerne ;)
[gr] Vielen Dank, das freut uns sehr 😊
Docker erfüllt für mich hauptsächlich den Zweck von Infrastructure-as-Code. Man zwingt sich dazu, alle Abhängigkeiten pinibelst aufzuschreiben, damit möglichst nix Unerwartetes passiert. Und dabei macht es einen guten Job.
Aber klar, der Universal-Bytecode, den man in Windeseile auf jedem Rechner ans Laufen bringt und mit allen anderen Sprachen mischen kann, wäre schon ne nette Sache, um ehrlich zu sein. OCI-kompatible WASM-Module kann ich mir gut als "alternative Container" vorstellen.
Was mich an Docker stört, ist die schlechte Unterstützung für UI-Anwendungen im Frontend. Vielleicht bringt ja WASM den Durchbruch für containerisierte Desktop-Anwendungen auf dem Client, jetzt mal abgesehen von Websites.
Ich werde das auf jeden Fall weiterverfolgen. Danke für das interessante Video!
[gr] Vielen Dank 😊
Und Du hast ein aus meiner Sicht sehr wichtiges Stichwort gebannt: OCI-kompatible WASM-Module … das wird IMHO noch ein großes Thema werden …
Du bist ein Guter 👍
[gr] Vielen Dank 😊
Klasse Video, abonniert! ;)
[gr] VIelen lieben Dank 😊
wollte mich nur kurz für die elliptische kurven berechnung tutorials bedanken, 👍👍
[gr] Danke schön - und gern geschehen ☺️
Docker ist eben auch inzwischen eine etablierte Technologie und wird in absehbarer Zeit kaum ersetzt werden.
Edit: und gleich mal subscribed. :)
[gr] Danke für Dein Feedback 😊
Jetzt stellt sich mir abschließend die Frage: Was bringt den WASM im Backend nun neues was nicht auch schon vorher mit JVM oder CLR gegangen wäre?
[gr] Das ist tatsächlich eine sehr gute Frage. Meiner Meinung nach eigentlich lediglich die Tatsache, dass die Laufzeit Umgebung bereits im Web-Browser integriert ist. Im Backend ist das aber natürlich nicht relevant, insofern ist es hier nur die Kompatibilität mit dem Frontend.
Der Content ist einfach super. Ihr habt definitiv viel zu wenig Abonnenten.
[gr] Vielen, vielen Dank - und was die Abos angeht: Was nicht ist, kann ja noch werden 😊
Any English translations of this video available? Would love to understand this.
[gr] Can you send me a mail to golo [dot] roden [at] thenativeweb [dot] io, please?
@@thenativeweb just sent an email to that address. thank you for your response.
[gr] Thanks, and you’re welcome ☺️
das war mir ein Abo wert
[gr] Danke schön 😊
Vielen Dank für die gute Zusammenfassung!
Für mich ist WebAssamby die spannedeste Software Entwicklung seit den Blockchains.
Obwohl ich nun auch in der WebEntwicklung bin, kann ich mich mit der bestehenden Welt in JS einfach nicht anfreunden. Zuviele Meinungen, zuviel gefährliches Halbwissen und zu einfach es schlecht zu machen. Und gerade im Web, was eines der wichtigesten Technolgiene der heutigen Welt ist, ist mir das einfach nicht gut genung. Alle verbesserungen scheitern aber seit jahrzenten immer am gleichen Problem: den JS-Interpreter, welcher unersetzbar ist.
Und da sehe ich immer noch sehr grosses Potential von WASM.
Das das Umfeld so leicht zu erweitern ist, fasziniert mich umso mehr. Aber ein voller Ersatz für Docker wird es wohl nicht werden. Muss es auch nicht:
Right Tool for the right Job.
WASM kann viele heute übliche Probleme wohl besser als Docker lösen, aber eben nicht alle. Und das sollte es auch nicht.
[gr] Danke für Deinen Kommentar, und ja, WebAssembly hat zumindest das Potential, da noch sehr viel zu bewegen.
BTW: JavaScript wird schon seit Jahren nicht mehr interpretiert, sondern in praktisch allen Runtimes mit einem JIT-Compiler übersetzt.
@@thenativeweb Das stimmt... ich denke mir fehlt nur das der Code einen "Kompilierungs-Schritt" hat. Ähnlich zu Java. Ich glaube das würde der JS Welt etwas helfen.
Aber danke für die Richtig-stellung.
[gr] Ich nehme an, der TypeScript-Compiler ist nicht das, was Dich glücklich machen würde?
@@thenativeweb Nutze ich, und bin glücklich mit. Leider kann er aber noch keine Type zuweisung wirklich korrigieren. z.B. Json-DateString -> let d:Date ... d.getDate() ... error :D
Aber ich komm gut klar damit. Hoffe nur auf Weiterentwicklung.
Mit anderen Worten zusammengefasst: aktuell noch nicht - hat aber hindeutend vielversprechendes potenziell in vielen Hinsichten auf jedenfall.
Ich finde das man noch hätte eher auf die Unterscheidungen eingehen können, bzw diese einfahc nur etwas mehr zu betonen.
Das es bei Docker quasi ein no brainer ist eine closed source third party Tools to containerisieren und man sich keine großen Gedanken machen muss worauf es dann läuft als host, während wir bei WASM den Source selber compilen müssten mit Zugriff darauf, was dann eher von den Entwicklern selber geboten werden müsste bei Closed Source.
Und auch wenn du dich generell auf den Open-Source Teil konzentriert hast mit diesem Video hätte man nochmal erwähnen müssen, dass viele bereits bestehende Anwendungen bestimmte andere Abhängigkeiten an Libs besitzen und durch Ihre API Verwendung vllt. sogar nicht mehr ohne weiteres Host unabhängig sind, wodurch man nicht ohne weiteres ohne erheblichen Aufwand größere Projekte porten könnte. Und selbst wenn das Problem mit den Abhängigkeiten nicht existieren würde, ganz ohne Anpassung kommt man da nicht weiter, wenn am Ende WebAssembly text format erhalten will, der so viel Abhilfe wie möglich bieten soll im Vergleich zu Docker.
Vielen Dank für dieses Video. Die Qualität deiner Arbeit weiß ich und viele andere Zuschauer auf jeden Fall zu schätzen.
[gr] Danke für das Lob und Deinen ausführlichen Kommentar 😊
Danke, super Informativ.
[gr] Freut mich, vielen Dank 😊
Sehr guter content. Von mir gibts ein instant-like-abo!
[gr] Vielen Dank 😊
Ich denke, das Ganze hat sehr viel Potential. Es gibt verdammt viele .NET-Entwickler, die für das Front-End keine große Lust bzw. Ressourcen frei haben, um diese mit Java und Co. zu realisieren. Für diese ist das natürlich ein Segen, da sie in ihrem Ökosystem bleiben können.
Viele alten geschäftsrelevanten Softwaresysteme, die für den "normalen" Desktop entwickelt wurden, werden sicherlich in den nächsten Jahren zumindest teilweise auf Webassembly portiert werden. Genau hier sehe ich viel Potential für Blazor.
Spannende Zeiten stehen uns bevor.
@@sven2529 Einstellungssache und Zielrichtung. Es kommt darauf an, was man macht und welchen Hintergrund man hat. Neben andern Sprachen programmiere ich seit über 30 Jahren C/C++ und seit ca. 15 Jahren C#. Da tue ich mir mit PHP schwer, wenn es um große Projekte geht - für mich ein bisschen ein Rückschritt. Wenn ich nun Front- und Backend in C# gleichermaßen abhaken kann, steigt die Effektivität, da ich in meinem Ökosystem bleibe.
Ich sehe als Vorteil von Containern noch, dass man Drittprogramme problemlos als Image verpacken kann, z.B. Datenbanken, Message Queues, Reverproxies usw. Wenn ich jetzt nur auf WebAssembly setze, müssen diese Komponenten auch alle erstmal in WebAssembly lauffähig gemacht werden.
Ich sehe auch noch nicht so den Vorteil von WebAssembly gegen der Java Virtual Machine, oder Dotnet (bin nicht der Dotnet Experte). Eigentlich sind sie doch ähnlich. Es gibt jeweils mehrere Quellsprachen, die dann nach WebAssembly/Java Bytecode kompiliert werden und das Ergebnis ist performant und plattformunabhängig.
Also Java kann das schon seit über 25 Jahren (über GraalVM seit kurzem auch JS, Ruby, Python als Quellsprachen). Ist die Frage, warum sollte WebAssembly jetzt der bessere Containerersatz werden, wenn Java es schon nicht wurde (oder der Trend dreht sich wieder).
Ein Trend ist ja noch Functions as a service. Wo auch nur noch die Hochsprache geschrieben wird und der Cloudhoster kümmert sich drum, wie es betrieben wird. Ob es unter der Haube Docker, WebAssembly, Java, Node, ... ist, kann dem Entwickler egal sein.
[gr] Schön zusammengefasst 😊
Seit ein paar Tagen ist auf der Docker-Homepage ein "+WASM" im Logo eingehängt. Scheint voran zu gehen, aber (?leider?) anders als vorhergesagt ;-)
[gr] Ja … guck Dir mal th-cam.com/video/B2Z6jFk6BfM/w-d-xo.html dazu an, wenn Dich Details dazu interessieren 😊
Spitzenvideo!
[gr] Vielen, vielen Dank 😊
WebAssembly ist doch letztendlich nur eine weitere Laufzeitumgebung wie z.B. .Net. Wie soll das ein Containersystem das in 99% der Fälle für ein unkompliziertes Deployment von komplexen Anwendungen (die in allem möglichen geschrieben sind) ersetzen? Das erschließt sich mir irgendwie jetzt nicht so ganz. Und ich liebe WebAssembly auf dem Client in form von Blazor über alles. Und Blazor hat gerade erst seine erstes echtes LTS Release mit .Net 6 bekommen. Kein Javascript mehr. Eine C# / VB.Net / Whatever Anwendung vom Server zum Client und das mit (fast) vollständigem .Net Framework Support. Keine Brüche mehr. Und wenn es nötig ist, schreibt man noch ein paar Extras mit Java Script.
Hi, wurde mein Beitrag gelöscht? Ich kann ihn nicht mehr finden. Wenn ich was falsches geschrieben haben sollte, bitte um eine kurze Info was es war. LG
[gr] Hey 👋
Wir löschen keine Beiträge (es sei denn, sie sind beleidigend, oder ähnliches), insofern - nein, wir haben ihn nicht aktiv gelöscht.
Uns ist aber schon des Öfteren aufgefallen, dass TH-cam eigenständig Beiträge löscht, unter anderem, wenn Links enthalten sind, und öfters auch, wenn Text enthalten ist, der wie ein Link aussieht (zum Beispiel ein Produktname wie ASP.NET, der als Domain interpretiert werden könnte).
Leider sehen wir die Kommentare auch nicht, die automatisch gelöscht werden, daher kann ich Dir auch nicht sagen, was das Problem war 😕
Da hilft eigentlich nur, noch mal posten, und alles entfernen, was eventuell den Filter auslösen könnte (was halt leider ein bisschen im Trüben fischen ist …).
@@thenativeweb Nun ja, was ich alles geschrieben habe, kann ich leider nicht mehr so aus dem Kopf wiederholen. Ich hatte das Video gelobt und die Tatsache, dass es aus einem einzigem Schnitt gedreht worden ist. Mein Abo kommt aus diesem Video. Dein KnowHow und die Methode alles gut zu erklären. Weiter hatte ich meine Erfahrungen zu diesem Thema geteilt. Ähnlich wie in den anderem Post. LG pS: Tolle Arbeit, weitermachen.
[gr] Vielen lieben Dank 😊
Im Browser würde ich eher Elm als Programmiersprache verwenden statt JS oder gar WASM. Das zusammen mit einem Rust Server als Backend, der in einem WASM Container läuft: perfekt.
Sehr gut erklärt, danke. Mein Gedanke war auch das Docker etwas anderes als WebAssembly ist und WebAssembly, zumindest jetzt, nicht überall Sinn macht. Im normaler Web-Entwicklung sollte WebAssembly kaum eine Rolle spielen, da es zumindest im Moment zu aufwendig ist.
[gr] Vielen Dank - und schön zusammengefasst 😊
Ich denke, das Ganze hat sehr viel Potential. Es gibt verdammt viele .NET-Entwickler, die für das Front-End keine große Lust bzw. Ressourcen frei haben, um diese mit Java und Co. zu realisieren. Für diese ist das natürlich ein Segen, da sie in ihrem Ökosystem bleiben können.
Viele alten geschäftsrelevanten Softwaresysteme, die für den "normalen" Desktop entwickelt wurden, werden sicherlich in den nächsten Jahren zumindest teilweise auf Webassembly portiert werden. Genau hier sehe ich viel Potential für Blazor.
Spannende Zeiten stehen uns bevor.
Wieso wurde mein Kommentar gelöscht???!
[gr] Ich weiß leider nicht, was genau dein Kommentar war, aber TH-cam löscht von sich aus Kommentare, zum Beispiel unter anderem dann, wenn darin Links enthalten sind. Wir löschen keine Kommentare, solange sie nicht gegen den Anstand oder Ähnliches verstoßen. Vielleicht kannst du es einfach noch einmal posten, gegebenenfalls mit angepasstem Inhalt?
@@thenativeweb 🤔 komisch.. aber gut, dass ihr nich löscht. Danke für die Antwort. Frage mich, ob da vielleicht Sonderzeichen drin waren.. 🤔
(Schade.. hatte mir den Text nicht abgespeichert.. ). Egal.. hab unten noch was zu wasm geschrieben...
Also wenn ich mir die Komplexität vieler Javascript Frontend Toolings anschaue und in Verhältnis setze mit den den Möglichkeiten die WASM bietet (siehe z.B. Figma) dann sehe ich das nicht unbedingt als mit Kanon auf Spatzen schießen. Wenn sich auch bei WASM noch einiges tut ist es vielleicht nicht unbedingt nur für die komplexeren UIs vorbehalten. Soooo lange kann man WASM nun auch noch nicht ernsthaft nutzen - und wie lange gibt es im Vergleich JS schon. Selbst wenn es schon das gelbe vom Ei wäre würde das noch lange dauern bis es bei den "Massen" ankommt. Die Nutzung auf dem Server ist aber natürlich auch interessant.
[gr] Das ist richtig - meine Einschätzung beruht auf dem aktuellen Stand, aber der wird sich definitiv noch verändern im Lauf der Zeit 😊
Ich denke es fehlen noch viele Voraussetzungen damit Webassembly im Browser eine Rolle spielt, was mmn aber langfristig der Fall sein wird. Die Entwicklung und Einbindung war bisher einfach zu unhandlich, und so auch zu experimentell für die meisten Firmen. Und dazu fehlen einer wichtigen Zielgruppe, nämlich PWAs, noch so viele Features, dass man so lange weiterhin eher auf native Anwendungen setzt. Insbesondere iOS liegt mit dem PWA support so weit zurück, Steve Jobs würde sich im Grab umdrehen wenn er das wüsste.
[gr] Ja, langfristig gehe ich auch davon aus, dass WebAssembly eine große Zukunft vor sich hat, aber da reden wir über einen Zeitraum von über fünf Jahren IMHO.
@@thenativeweb ja gemessen an der bisherigen Geschwindigkeit mindestens
Ganz deiner Meinung! WebAssembly wird zuerst die Edge erobern, um hochspezialisierte Workloads auszuführen. Heute bereits entwickeln wir Edge Software (Fastly Compute Edge) in Rust, mit einer Latenz jenseits von Gut und Böse. Spannende Zeiten! WASI hinkt noch zu stark hinterher, als dass es als Runtime für den Server verwendet werden kann. MicroVMs wie Firecracker sind ebenfalls auf dem Vormarsch.
Starker Punkt - Danke
Ich finde das Video gut, aber es holt meiner Meinung nach viel zu weit aus und hat einen zu Reißerischen Titel, "Native Functions für Kubernetes in Web Assembly?" hätte es treffender beschrieben. Denn am Ende ist es genau das was Docker ausmacht was Web Assembly eben nicht kann (und auch nicht braucht), Volumes, Netzwerk Separation, mitbringen der Laufzeitumgebung. Und warum soll ich denn WebAssembly nicht in ein Container Image verpacken wodurch ich ein Image für alle Plattformen erhalte die eh schon einen passene Laufzeitumgebung haben.
moin moin, wollte mal fragen ob Sie gute projekte für WASM kennen, LG aus Hamburg
[gr] Da muss ich leider passen, sorry 😕
WASM im Browser ist im Moment eher uninteressant, da die kompilierten Module relativ schwergewichtig sind. Zudem sind die synthetischen Benchmarks, die die Leistung mit JS vergleichen, eher ernüchternd. WASM wäre aber bspw. für Online-Playgrounds für Programmiersprachen interessant, was User-Expeirence und Sicherheit angeht. Code-Editoren bzw. Online IDEs wie StackBlitz sind auch ein interessanter Use-Case. Die haben es ja geschafft einen ganzen Node.js-Server im Browser zum Laufen zu bringen.
[gr] Ja, das ist ein spannendes Feld für WebAssembly. Was die Größe angeht: Ich denke, das hängt stark vom Compiler ab, beziehungsweise was man da reinpacken will. Denn prinzipiell ist WebAssembly ja doch recht kompakt.
Da WASM schon von allen Browser-Engines unterstützt wird: Wann kommt der JavaScript-zu-WASM Compiler? Und wann kommt der erste physische Prozesser mit Mikrocode, um WASM nativ auszuführen? Ist WASM geeignet, um direkt auf der CPU ausgeführt zu werden?
[gr] Ganz ehrlich - das mit der nativen Unterstützung habe ich mich bei .NET und MSIL auch schon gefragt … wäre ja irgendwie logisch, wenn so was käme.
Es gibt neuerdings AOT-Compilation (Ahead of Time)... Das ist zwar kein reiner Maschinencode.. erübrigt aber die "langsamere" JIT Compilation.
[gr] Naja, "neu" ist das ja nicht wirklich - ein AOT-Compiler ist ja der klassische Ansatz eines Compilers, der zeitlich unabhängig (das heißt, vor der Ausführung) läuft. Natürlich spart man sich damit den JIT-Compiler, aber man hat dann wieder plattformspezifischen Code (was man mit der Zwischensprache ja gerade vermeiden will).
Insofern wäre es schon interessant, eine direkt Hardware-Unterstützung zu haben für Sprachen wie WebAssembly, MSIL, Java Bytecode & Co. - wobei das im Endeffekt dann wieder alles genauso wie vorher wäre, nur um eine Ebene verschoben 😉
@@thenativeweb Ich habe natürlich immer dotnet Blazor im Hinterkopf und da ist das jetzt ein "brandneues" Feature...
Etwas näher an die Maschine zu kommen.. mit dem Code, wäre natürlich klasse.
Also C++ lässt sich bei dotnet in die wasm mit einlinken. Hatte da mal extra nachgeguckt, ob C++ ggf. tiefer zugreifen kann (also nicht nur wg. speed)... aber der kommt aus einem Sandkasten auch nicht heraus.
Gab es nicht mal die Möglichkeit bei C++ einen Assembler/ ASM-Block im Code einzufügen?!🤔
Entweder waren das alles Bytes oder sogar Mnemonics (weiß ich nicht mehr... aber wäre mal interessant, etwas damit zu experimentieren:)
@@gregcyrus2739 [gr] Ah, sorry, das habe ich dann missverstanden. Dann hast Du natürlich recht 😊
Bei C++ weiß ich es nicht, aber in Pascal ging das auf jeden Fall: wiki.freepascal.org/Asm
Nun, das könnte ich mir durchaus vorstellen, dass es für manche Anwendungen Sinn macht. Insbesondere Container, in denen nur ein Prozeß läuft. Wäre natürlich fraglich, wie die Performance ist ... ich kann mir kaum vorstellen, dass ein wasm-Binary aus Rust oder C++ in wasm-jit schneller ist als das native Binary. Zunächst mal müssten natürlich Dinge wie zusätzliche Files in wasm-Packages und/oder directory mounts funktionieren. Frage mich allerdings, wie wasm mit nativen Dependencies umgeht? Von "ersetzen" kann jedenfalls keine Rede sein. Analog wie docker keine virtuellen Maschinen ersetzt. Es sind alles Konzepte, die stellenweise "das gleiche" erreichen aber völlig unterschiedlich funktionieren mit jeweiligen Vor- und Nachteilen.
[gr] Deshalb wird es, wieso oft, auch eher auf eine Koexistenz hinauslaufen, als auf ein X ersetzt Y.
Schön heruntergebrochen! Ein Aspekt, der mit bei dem Vergleich Docker vs WebAssembly etwas zu kurz kommt, ist die Entwicklungsumgebung selbst. In einem Team, deren Entwickler mit möglicherweise verschiedenen Betriebssystemen arbeiten, sind Container auch super für die Entwicklungsumgebung selbst. Also dass das, was das Buildsystem am Ende ausspuckt, überall das gleiche und reproduzierbar ist. Meinst Du, dass wir in Zukunft ähnliches bei WebAssembly erwarten können? Also dass die Tools, die zum Bauen verwendet werden (Build-Skripte, curl, spezielle NodeJS, Python, was auch immer Version) dann immer in WebAssembly vorliegen und wir explizit die einzeln nutzen?
Da würde vielleicht noch eine Package-Registry fehlen 😅
[gr] Das ist eine spannende Frage, die ich mich Stand heute ehrlich gesagt nicht wirklich zu beantworten traue … am ehesten würde ich darauf tippen, dass die ganze Entwicklung mehr und mehr in den Browser wandert, à la Online-IDEs, wo sich die Frage nach dem Betriebssystems des Clients gar nicht mehr stellt …
Wobei ich persönlich zumindest bislang so auch nicht arbeiten mag …
@@thenativeweb das ist eine interessante Sichtweise mit den Online IDEs. Ich finde die (bisher) auch nicht so prickelnd, weil es doch so manches mal sehr seltsame Bugs zum Vorschein kommen, die dann gerne von dem jeweils genutzten Editor kamen. Aber natürlich, wenn sich das verbessert, würde es nur noch die eine Entwicklungsumgebung geben und das Docker Setup wäre somit nicht mehr unbedingt notwendig. Also langfristig könnte ich es mir dann so vorstellen... Danke für die Einschätzung! :)
Moin schönes Video und spannende Frage ich glaube man kann noch viel mehr von WASM erwarten als bisher. Aber Blazor ist nicht unbedingt eine Riesen Kanone man kann damit auch schnell Business Sites umsetzen die eben nicht dem normalen Webflow folgen.
[gr] Wie schon in einem anderen Kommentar geschrieben: Blazor hat seinen Anwendungsfall, keine Frage. Aber es wird mir aktuell zu sehr à la Gießkanne angewendet, oft mit der Motivation, bloß kein JavaScript machen zu müssen. Und das halt auch für Hallo-Welt-größenartige Probleme.
Und das halte ich eher für eine unglückliche Idee. Denn allein Weg, um die Seite zu laden, ist aufwändiger: HTML + JS + WebAssembly, und Du brauchst einen Compiler von C# nach Wasm, … und jetzt vergleich das mal mit einer leichtgewichtigen reinen JavaScript-Lösung.
Ich will nicht sagen, dass man sich bei JavaScript mit all den Frameworks nicht auch verkünsteln kann, aber Blazor wird aktuell viel zu oft als die magische Silberkugel angepriesen, die alle Probleme lösen soll. Und das ist sie nicht.
@@thenativeweb Also ich gebe dir natürlich Recht Golo. Blazor wird wie vieles der letzten Jahre als Heilsbringer der Webentwicklung angesehen. Ist natürlich großer Käse. Beschissen designte Software bleibt auch beschissene Software egal was man nutzt. Allerdings macht Blazor unheimlich Spaß zu entwickeln. Denn sind wir mal ehrlich JS macht doch keiner gerne und Typescript ist auch nur eine wenn auch schöne Hülle. Der Vorteil von Blazor ist doch die wirklich tolle Möglichkeit meinen C# Code (Sicht des Entwicklers ohne die Zwischenebenene) im Web oder als App im Container zu erstellen. Es lässt sich mit minimalen HTML / CSS und bisl JS und C# eben auch echt tolles Zeug machen.
@@sven2529 Muss man ja nicht so sehen Sven. Ich sage dir ganz ehrlich ich mache JavaScript sicher nicht so gern wie ich C# Code schreibe. Ist aber meine persönliche Meinung und ich kenne durchaus viele die sich mit JS schwer tun. Golo hat schon recht vielleicht sollte man mal Lisp machen um sich da das Leben zu vereinfachen. Aber auf der anderen Seite ist halt Blazor dann so cool das ich damit mein Web auch deployed bekomme und das mit C#. ;)
Ich denke WASM/WASI werden auf dem Client (CPU) dynamische 3D fähige UI Anwendungen ermöglichen, in dem dadurch der lokale Grafikprozessor (GPU) des Client eingebunden werden kann. Spontan fällt mir dabei u.a. das Anwendungsfeld der Architektur ein.
woher kommt eigentlich das "ü" in k"u"bernetes das alle deutschen immer aussprechen? 🤔
[gr] Wahrscheinlich, weil man unbewusst an Kybernetik und Co. denkt, auch wenn die Aussprache mit U eigentlich richtig wäre.
Nach fast 10 Jahren sagte mal einer zu mir, das hiesse "Sziiekquell-Server".. mittlerweile bin ich wieder zu "Es-Ku-ELL Server" degeneriert;)
[gr] Kenne ich tatsächlich auch so, dass SQL als „Sequel“ ausgesprochen wird.
WASM is here to stay. Darüber sind wir uns einig. Welche Entwicklung das nehmen wird weiss nur die alte Frau mit der Glaskugel. Docker Desktop ist jetzt lizenzpflichtig - keine schöne Entwicklung und vielleicht schon der erste Docker Sargnagel...
Vielen Dank!
[gr] Sehr gerne 😊
Klasse
[gr] Vielen lieben Dank 😊
Hmmm, das ist das erste Mal, dass du mich nicht überzeugen konntest. Einen super wichtigen Aspekt hast du bei Docker vergessen: Die Umgebungsvoraussetzungen. Wenn ich eine Anwendung habe, die z.B. memcached voraussetzt, dann kann ich das mit einem WASM-Modul nicht anständig orchestrieren, weil memcached nicht zwangsläufig vorhanden ist. Da bringt mir auch ne Kubernetes-Erweiterung nix, die WASM handhaben kann. Das ist mit Docker ganz anders. Alle Voraussetzungen können fein säuberlich bestimmt werden und sind dann auch vorhanden. Mein Fazit ist daher: WASM kann Docker gar nicht ersetzen und die beiden müssen zwangsläufig koexistieren.
[gr] Ja, das ist richtig (das mit der Orchestrierung). WASM dient eben nur dazu, einen (1) Prozess in eine andere Zwischensprache zu kompilieren, die sehr portabel ist. Alles übrige wird davon nicht tangiert, weshalb man um zB Kubernetes nicht herumkommt.
Im Grunde würde ich sagen, dass häufig vermutlich sogar WebAssembly-Module in Docker-Container verpackt werden, die dann auf Kubernetes ausgeführt werden. So hätte man "best of three worlds", weil die Docker-Container damit eventuell plattformunabhängig würden, aber man ihre Vorteile trotzdem weiter nutzen könnte.
PS: Dass WebAssembly Docker nicht ersetzen kann und beide koexistieren, zu dem Schluss komme ich ja aber auch, oder haben wir da einander irgendwie missverstanden?
@@thenativeweb Ich hab dein Fazit so verstanden, dass sie eher koexistieren würden, nicht aber zwangsläufig müssen. Und ja, das mit WASM in Docker habe ich selbst auch schon gemacht. Was ich aber eher suche ist sowas wie docker, womit man seine Umgebung deklarieren kann, aber ohne weiteren Overhead. Gibt es da was? Quasi das Betriebssystem direkt als Container nutzen.
@DJTechnostyler Azure Functions (serverless) könnte Dich vllt. interessieren.
@andere: Also entweder ist mir was mit wasm entgangen.. oder es wird hier was verwechselt: Wasm mit Docker zu vergleichen passt irgendwie nicht. Durch das Sandbox-Konzept von Wasm eignet es sich schon als Container, startet extrem schnell, ist super kompatibel und z.B. mit .Net-Core auf allen Platformen unendlich erweiterbar. Das ist aber noch Zukunftsmusik...
Z.zt. ist Wasm eher für Browser interessant. Z.B: Ajax wird direkt von einer Klasse (httpClient) ersetzt, DOM-Objekte eindeutig identifiziert (kein $-jQuery-Selector mehr, der je nach Webserver-Version nix mehr findet), diese zudem automatisch aktualisiert (Blazor)..
Alles viel einfacher, sicherer und vorallem schneller! PS: Html+CSS sollte/muss man aber nach wie vor können! 👍🏼
@@DJTechnostyler [gr] Nicht, dass ich wüsste … also Kubernetes wäre da halt meine übliche Antwort, das ist ja quasi das "Betriebssystem für Container", aber das ist in dem Fall ja nicht das, was Du suchst. Da muss ich ansonsten, fürchte ich, leider passen.
danke
[gr] Gern geschehen 😊
Sandbox ist zwar Sandbox, aber im Detail gibt's dann schon erhebliche Unterschiede. Und Docker != nodejs, auch wenn das manche meinen.
[gr] Docker === Node.js?! Wie kommt man denn auf die Idee?
War etwas überrauscht von dem Titel. Würde eher erwarten dass webassembly möglicherweise in docker verwendet wird als dass es docker ersezt (1A click-bait titel^^). Dass man mehrere Sprachen mischen kann ist ganz nett aber da ging die ganze microservice sache ja in eine ganz andere richtung und verbindet auch verschiedenste sprachen über grpc oder nen ganz normalen rest service ohne probleme. Man plant ja nicht dass man einen riesigen monolyth basteln wird in 10 verschiedenen sprachen (wenn doch dann... schlechter plan imo). Gefühlt würde ich denken dass die IL Sprachen von z.B. Java und C# mehr optimiert oder/und mehr features für die sprache für die diese entwickelt wurden haben sollten. Zudem wird man schwer machinencode in webassembly übersetzen können. Wenn man externe programme hat die laufen müssen damit dein program überhaupt was tud wirds schwer. Das mit Blazor von technischer seite... deffinitiv bischen overkill. Jedoch ist das programmiermodell im vergleich zu asp mvc oder razor pages sehr gut. Wenn man moderne webapps mit razor schreiben will fühlt sich das mehr an als schreibe man die ganze app in vanilla JS ohne framework und dann noch mit erstaunlich schlechter JS IDE von der gleichen firma die vscode gemacht hat. Frameworks wie vue sind sehr gut. Aber wenn man wo arbeited wo gewünscht ist möglichst in C# zu bleiben und nicht mehrere tech stacks zu haben. Dann ist meiner meinung nach blazor das geringste übel. Für Fälle wo der Schutz der "inerterlectual property" sehr hoch prioriziert wird denke ich auch dass blazor server sehr viel benutzung finden wird in programmen für firmen. Auch wenn das was "Mit Kanonen auf Spatzen schießen" angeht noch mal eine Liga über dem webassembly ist.
[gr] Du hast natürlich recht, dass der Titel völliger Käse ist… Wir haben ihn eigentlich auch nur deshalb aufgegriffen, weil ich tatsächlich Aussagen in dieser Richtung in den vergangenen Wochen einige Male gelesen habe, und das selbst sehr absurd fand.
@@thenativeweb Aber gutes video! :) (war ich wohl sehr motiviert gestern.. son haufen text geschrieben unglaublich)
[gr] 😊
Jetzt fehlt nur noch ein Compiler, der Lisp in Webassembly übersetzt.
[gr] Das wäre eine feine Sache 😊
Dieser Chanel is ne Goldgrube ... ziemlich schwieriges Thema aber ich denke nicht, dass webassembly Docker ablösen wird (oder sollte), denn Docker wird nicht nur im Kontext "Web" verwendet.
Ich denke "Koexistenz" ist das stichword wobei ich befürchte, dass das WEB dadurch nicht wirklcih "sauberer" wird.
Wahrscheinlich wirds darauf hinauslaufen dass in den nächsten Jahren mindestens 237 neue Javscript-Frameworks erstellt werden die man dann alle "braucht" um seine NodeJs projekte auf Web-Assembly kompiliieren zu können.
[gr] Was die Koexistenz angeht, bin ich bei Dir - weniger allerdings bei dem Punkt, dass man Node.js nach WebAssembly kompilieren sollte: Da WebAssembly ja als Ergänzung (und nicht als Ersatz) für JavaScript gedacht ist, ist Node.js von allen Backend-Technologien so ziemlich die einzige, die man *nicht* nach WebAssembly kompilieren muss.
Oder habe ich Dich grundsätzlich missverstanden?
dass ich auf dem client wenig tut wundert mich nicht. entwickler heute haben gar keinen druck mehr leistungsoptimiert was zu entwickeln - weil es auch die konkurenz nicht mehr macht. kunden kaufen andauernd leistungsfaehigere geraete und wenn etwas langsam laeuft dann ist ja immer die hardware oder das betriebssystem schuld (so denkt der endanwender) ..viel schlimmer, native anwendungen sterben aus und dank react wird alles immer schlimmer. dann sehen wir noch weiter, dass das was frueher in java geschrieben wird heute lieber in python geschrieben wird und da wird es dann auch immer ineffienter.
[gr] Danke für Deinen Kommentar 😊
Es heißt Kubernetes, nicht Kübernetes
[gr] Das ist richtig, spricht sich nur leider so schlecht aus (für mein Empfinden). Trotzdem hast du natürlich recht, dass man das eigentlich mit U aussprechen müsste.
Docker braucht man immer. Nur Podman ersetzt docker
[gr] Podman ist auf jeden Fall eine interessante Option 😊
Das Video ist sicher informativ, aber der Vergleich passt gar nicht. Docker und Webassembly sind komplett unterschiedliche Dinge.
[gr] Das ist richtig, und genau darum geht es unter anderem auch im Video. Wir haben den Titel deshalb so gewählt, weil uns der bei einigen Blog-Artikeln aufgefallen ist, und wir uns da auch gefragt haben, wo der Zusammenhang ist..
Wirtschaftlich gesehen werden Linux Distros sterben und viele FOSS-Bibliotheken auch, weil sowohl Go wie auch WASM quasi 0 dependencies haben bzw diese exakt vom Autor definiert werden. Wir sehen die Erosion bzw Vorwegnahme jetzt schon bei k8s durch das Verwenden von proprietären, manages services und proprietary oder zumindest spezialisierte Baselayer. Letztlich läuft alles auf dumb terminals und property main frames as a service hinaus. Die Cloudanbieter werden wie bisher schon ihre Tools nur sehr selektiv freigeben und so immer mehr "Moat" bzw Vorteile aufhäufen. Schaffen sie dann noch besonders effiziente Prozessoren, die am Markt nicht zu kaufen sind, ist es vorbei. Für die Masse bleiben dumb devices und VSCode im Browser als IDE. WASM als universelles Ziel-Runtime ist der perfekte lock-in.