Microsoft, Google en Arm sluiten zich aan bij Bytecode Alliance - update

Microsoft, Google en Arm hebben zich aangesloten bij de Bytecode Alliance. Dit samenwerkingsverband stimuleert de ontwikkeling en ingebruikname van WebAssembly, een methode voor het compilen van code die het internet en software veiliger en sneller moet maken.

Samen met bovenvermelde bedrijven besloten ook Shopify, Dfinity Foundation, Embark Studios en de University Of California van San Diego om toe te treden tot de organisatie. In dezelfde aankondiging werd vermeld dat de Bytecode Alliance omgevormd werd tot een non-profitorganisatie. Ralph Squillace, afgevaardigde van Microsoft bij Bytecode Alliance stelt dat Microsoft uitkijkt om het ecosysteem verder te kunnen ontwikkelen. “Aan de hand van Web Assembly en de WebAssembly System Interface kunnen onder andere cloudtoepassingen een stuk veiliger worden", klinkt het.

“Al deze organisaties willen met het WebAssembly-ecosysteem de gaten opvullen in de funderingen van veelgebruikte software die de industrie ervan weerhoudt om een veiligere en performantere toekomst te creëren”, aldus de organisatie. Bytecode Alliance roept ook andere organisatie op om zich aan te sluiten.

In 2019 werd deze non profit-organisatie opgericht door Mozilla, Fastly, Intel en Red Hat om aan de hand van WebAssembly en de WebAssembly System Interface ‘nieuwe software fundamenten’ te bouwen. WebAssembly is een methode voor het compileren van code op het web via bytecode. Ontwikkelaars kunnen nog steeds hun code schrijven in C, C++ of Rust en deze vervolgens compilen naar WebAssembly dat voor uniformiteit en meer veiligheid en efficiëntie op het web moet zorgen. Ook native programma’s die dankzij het gebruik van WebAssembly System Interface cross compatible kunnen worden, behoren tot de toekomstplannen.

Update, zaterdag 1 mei, 10.40: Titel en artikel aangepast op basis van reacties van jandem en lilmonkey.

Reacties (57)

Nadat eerder al Arm, Google, Shopify en de University of California zich aansloten, besloot ook Microsoft

Dit is onjuist (deze organisaties waren niet eerder dan MS) en dit artikel legt ook de focus verkeerd.

• De Bytecode Alliance is opgericht in November 2019 door Mozilla, Intel, Fastly en Red Hat.
• Sinds deze week is de Bytecode Alliance officieel een eigen non-profit organisatie. Ook zijn nu Microsoft, Arm, DFINITY Foundation, Embark Studios, Google, Shopify en UCSD toegetreden.

Verder staat dit (deels) los van WebAssembly in de browser. Waar het hier meer om gaat is andere toepassingen waar je veilig en snel code van derden wilt kunnen draaien. Het is bijvoorbeeld mogelijk om WebAssembly te gebruiken voor embedded of cloud toepassingen en strict te reguleren waar die code bij kan.

Zie bijvoorbeeld MS Flight Simulator waar je add-ons voor kunt schrijven in onder andere C++ en dan kunt compileren naar WASM: draait in hetzelfde proces, maar je add-on kan niet meer zomaar bij het geheugen van het programma zelf of bij het OS zonder dat MSFS dat toestaat. Vroeger waren dat DLLs die overal bij konden.

In Firefox wordt WASM gebruikt voor het sandboxen van oude C/C++ libraries. Die libraries hebben dan hun eigen stukje geheugen waar ze in kunnen rommelen, maar die code kan niet meer zomaar bij andere dingen in hetzelfde proces.

Fastly en Red Hat zien hier ook voordelen in: met WASM kunnen ze klanten snel en veilig code op hun cloud platform laten draaien. Iets als Docker heeft veel meer overhead vergeleken met WASM.

[Reactie gewijzigd door jandem op 1 mei 2021 08:45]

Precies. WebAssembly wordt - net als JavaScript eerder - uit de browser gehaald en ook elders toegepast. Het voorbeeld wat jij schetst met plugin modules wordt op die manier trouwens ook al gebruikt voor Node.js applicaties. Waar voorheen voor performance-redenen bepaalde code vaak als native C library gecompiled werd en dan middels bindings in Node.js consumeerd werd, wordt dat nu steeds meer met WASM modules gedaan. Makkelijker om in een cross-platform vorm te distribueren; en veiliger om te draaien.

[Reactie gewijzigd door R4gnax op 1 mei 2021 09:56]

@jandem Beste, het artikel is aangepast. Bedankt voor de feedback.

Tweakers is helaas steeds vaker niet juist geïnformeerd.

WebAssembly is een methode voor het compileren van code op het web via bytecode en heeft overeenkomsten met het huidige asm.js.

Het huidige asm.js, echt? WebAssembly heeft asm.js al lang verdrongen. Asm.js is deprecated en de spec is sinds 2014 niet meer geüpdatet met als laatste status "This specification is working towards a candidate draft for asm.js version 1".

@lilmonkey Beste, het artikel is aangepast. Bedankt voor de feedback.

Firefox ook
https://blog.mozilla.org/...ng-the-bytecode-alliance/

[Reactie gewijzigd door DJMaze op 1 mei 2021 08:50]

Ik zie niet helemaal het verband tussen webassembly gebruiken en betere veiligheid. Volgens mij is het vooral sneller omdat native code betere performance geeft dan JavaScript. Maar veiliger? Hoe lower level hoe meer vrijheid juist toch?

WebAssembly (in tegenstelling tot JS) is ontworpen met veiligheid in het achterhoofd en heeft betere sandboxing dan JS. JavaScript is vrij lastig om met een beetje acceptabele snelheid te draaien, waardoor er allerlei trucs uitgehaald moeten worden om dit voor elkaar te krijgen, en door deze complexiteit sluipen er nogal eens wat bugs/sandbox escapes bij JavaScript engines naar binnen.

Helaas zijn er nog tal van klassieke veiligheidsgaten in WebAssembly zoals hier beschreven in deze paper.
https://www.usenix.org/co...ty20/presentation/lehmann

Er moet dus nog heel wat gebeuren om het veiliger te maken.

Wat ik ervan begrijp draait webAssembly in dezelfde sandbox als javascript

Als WebAssembly minder functies heeft dan JavaScript kan het veiliger zijn. Maar tja, je moet altijd naar het OS kunnen.
Misschien is het securitymodel ook eenvoudiger/minder crufty?

Moet WebAssembly wel bij het OS kunnen? Dat wil je toch juist zoveel mogelijk beperken?

Wel ala je het wil/moet gebruiken voor filetoegang, gps, camera, dongels etc.

Daar kun je toch de huidige api's voor gebruiken die nu in de browser zitten? En daarmee kun je die toegang afschermen.

Of je nu een API van "het OS" of van "de browser" gebruikt, in beide gevallen heb je een vergelijkbare uitdaging om legitiem gebruik toe te staan en onbedoeld gebruik tegen te gaan.

Nu wordt React en vergelijkbare libraries steeds groter. Als we afstappen van JavaScript, want zijn hiervoor de gevolgen?

De gevolgen als we eindelijk serieuze statically typed programmeertalen kunnen gaan gebruiken voor web development? Lijkt me alleen maar positief. Javascript is een abominatie, dat mag van mij zsm verdwijnen.

serieuze statically typed programmeertalen

JavaScript is statically typed. Elk ding wat je maakt heeft een vast type. Alleen zijn er zaken zoals comparison operators waar bijv. numbers en strings automatisch tijdelijk naar equivalente types gecoerced worden, waardoor het lijkt alsof er geen echte types zijn. Deze type coercion is een implicit cast en dat soort zaken heeft bijv. C# ook ingebouwd, waar types een implicit cast operator kunnen implementeren.

In JavaScript zijn er alleen geen type guards op o.a. assignments en method calls en dus heb je gelimiteerde mogelijkheden tot zaken als static type inference om code completion aan te zwengelen. (Juist dat gat wordt door TypeScript gevuld.)

[Reactie gewijzigd door R4gnax op 1 mei 2021 09:52]

De meest gangbare definitie van een statically typed programmeertaal is een programmeertaal waar de types al bekend zijn voordat het programma wordt gedraaid [1]. Voor JavaScript is dit niet het geval (zie ook [2]).

[1] https://stackoverflow.com...namically-typed-languages

[2] https://stackoverflow.com...cript-an-untyped-language

Je beschrijft het begrip weakly typed

Met .NET ben ik niet bekend, maar de implicit conversions in Scala zou ik eerder scharen onder syntactic sugar dan weak typing. De erased generic types in Java dan misschien weer wel omdat de compiler daar allerlei casts inbouwt.

Je beschrijft het begrip weakly typed

Inderdaad. Weak/strong typing. Wat in de regel iets anders is als static/dynamic typing.

De pest is dat dit onderscheid vreselijk lang niet gemaakt is, waardoor in de regel 'static typing' geassocieerd wordt met static type checking - i.e. compile-time type checking, wat eigenlijk een aspect is van strong typing.

Een sterk type system dwingt het gebruik van bepaalde types af.
Een weak type system niet.

Een static typed taal heeft vaste type definities en kan de mogelijkheid hebben om deze runtime te inspecteren. Een dynamic typed taal heeft geen vaste type definities en alles zweeft.

C is van origine bijv. strongly dynamically typed: er is een type system wat compile-time gebruikt wordt en typing afdwingt op functie calls; gedeclareerde variabelen; etc. maar runtime bestaan er geen echte types.

JS is weakly statically typed. Alles heeft in principe een type wat runtime opvraagbaar is en er zijn legio mogelijkheden tot type introspection, als je netjes constructor functies of classes gebruikt.
Je kunt ook alles op expando objects gooien. Dan ben je met dynamic typing bezig.

JS biedt geen sterk type system wat voorkomt dat verkeerd getypte parameters aan functies meegegeven kunnen worden, etc. En dat is het stuk wat TypeScript wel biedt. (Hoewel eigenlijk ook niet helemaal. Wat TypeScript biedt is duck typing: type definities gebaseerd op structural equivalence.)

[Reactie gewijzigd door R4gnax op 2 mei 2021 15:54]

De pest is dat dit onderscheid vreselijk lang niet gemaakt is, waardoor in de regel 'static typing' geassocieerd wordt met static type checking.

Nou ben je de weg helemaal kwijtgeraakt.

Ten eerste: de regel "static typing" wordt geassocieerd met "static type checking". Uh, ja, misschien vergat je je post na te lezen voordat je op de verzend knop drukte?

Static type checking betekend dat de compiler het gebruik van specifieke typen afdwingt. Dat is bij JavaScript / ECMAScript juist niet het geval. Dus JavaScript is dynamically typed.

Strongly typed betekend dat je tijdens runtime niet zomaar een type in een ander type kan veranderen. Dat lijkt bij JavaScript niet het geval, hoewel je bijvoorbeeld een class wel met methoden en velden kan uitbreiden. Het zal wel ergens in het midden liggen wat dit betreft.

Nou ben je de weg helemaal kwijtgeraakt.

Ten eerste: de regel "static typing" wordt geassocieerd met "static type checking". Uh, ja, misschien vergat je je post na te lezen voordat je op de verzend knop drukte?

Dat is nu net het hele ding. Die twee lijnen aan begrippen zijn compleet verweven geraakt, maar static vs dynamic slaat op de types zelf en weak/strong slaat op het systeem als geheel. "Static type checking" betekent "het statisch (dwz. compile-time) checken van types." Dat is een andere 'static' dan de 'static' in static vs dynamic types.

Dus JavaScript is dynamically typed.

JavaScript heeft dynamic types, in de vorm van expando properties op alle vormen van object instanties die je maar wilt. En het heeft ook static types; zoals string, number, met een typeof operator om de types te duiden, en classes (of constructor functies) met een instanceof operator om het type te duiden.
Maar er is geen compiler die deze afdwingt en veel zaken worden door de runtime automatisch van het ene naar het andere type ge-coerced (omgezet), waardoor het type system weak (zwak) is.

Hopelijk is het zo duidelijk wat ik bedoel?
Want het hele begrippenlandschap wat betreft deze dingen is één grote f***ing bende geworden, doordat static vs. dynamic een dubbele betekenis heeft gekregen.

[Reactie gewijzigd door R4gnax op 2 mei 2021 16:07]

Heb je ook een bron waar dat jouw mening ondersteunt? Ik kan er namelijk geen enkele vinden. Alle bronnen noemen Javascript een dynamisch getypeerde taal of zelfs een niet getypeerde taal. Ik vind dat onderscheid dat jij maakt tussen statische en dynamische typisches ook behoorlijk zinloos. Een type is er om te aan te geven dat een object bepaalde eigenschappen heeft. Als een "dynamisch type" betekent dat je het type zelf kunt veranderen (in plaats van dat je het type van een object verandert) dan betekent "dynamisch type" hetzelfde als "geen type". JavaScript's typeof operator levert voor die "expando"-objecten dan ook "object", als ik me goed herinner.

Maar eigenlijk is het ook om het even. We kunnen hier een welles-nietes discussie over terminologie gaan houden, of we kunnen gewoon even kijken naar de inhoud. En het oorspronkelijke punt van vbmod dat WebAssembly het mogelijk maakt om statisch getypecheckte talen te gebruiken blijft natuurlijk staan. Statische typechecking heeft grote voordelen wat betreft ondersteuning van de ontwikkelaar (vooral bij grotere projecten naar mijn mening erg belangrijk) en compileroptimalisaties. Dat is ook de reden dat de trend tegenwoordig is dat ook dynamische getypecheckte programmeertalen steeds meer die kant op gaan. WebAssembly maakt het mogelijk echte statische getypecheckte programmeertalen te gebruiken zonder die als tussenstap naar JavaScript the transpilen.

Wat je beschrijft heet al sinds 1960 loosely typed. Statically typed betekent dat als je zegt dat een variabele een integer moet bevatten je er geen string aan kunt assignen. Stille conversie van string naar integer betekent niet dat het statically typed is.

Typescript is al een prima getypeerde taal die veel wordt gebruikt bij web dev in Angular en kan ook met React. Of dat nou uiteindelijk naar JavaScript of WebAssembly wordt getranspiled maakt niet zoveel uit voor de doorsnee web dev.

Klinkt als een logische stap. Microsoft lijkt vol in te zetten op Blazor (spa framework), aangezien dat gebruik maakt van WebAssembly is het wel zo fijn als dat succesvol is. Voor Microsoft ontwikkelaars betekend dit dat ze gewoon .Net en c# kunnen gebruiken en daar worden ze natuurlijk erg blij van / zijn ze snel productief.

Het is oude wijn in nieuwe zakken. Java compileert ook naar byte code en kon ook in de browser uitgevoerd worden en dat is al 20 jaar oud.

Ik zie dit soort dingen niet als positief. Je krijgt effectief dat er applicaties in de browser gaan draaien met als gevolg dat ad-blockers, DNS-filters, cookie blockers. locatie-fakers niet meer werken.

Om dezelfde redenen dat we Java applets en Flash applets hebben uitgefaseerd moeten we ook niet beginnen aan weer bytecode runtime die in de browser draait.

Java applets & flash waren traag, onhandig in gebruik (3rd party install nodig), minder secure (web assembly draait op een stack-based VM). Ik heb liever webassembly dan de huidige blob van duizenden javascript/typescript frameworks. DNS filters en dergelijke zijn op een andere laag.

[Reactie gewijzigd door Waswat op 30 april 2021 22:22]

Java applets waren traag, onhandig in gebruik, niet native en minder secure (web assembly draait virtueel).

WebAssembly klinkt ook niet echt bepaald native, voor zover ik weet kunnen de meeste processoren niet direct WebAssembly bytecode uitvoeren, dus dat zou ik ook niet native noemen. Java applets draaiden zover ik weet ook "virtueel" in de Java Virtual Machine,. Ik snap dus niet echt waar die laatste twee punten vandaan komen.

Je hebt gelijk, het is niet native; heb het aangepast. Overigens was de java VM vanuit mijn ervaring niet een VM zoals we die nu kennen maar meer een interpreter; het ging volgens mij niet beperken wat je kon doen met het systeem. In web assembly blijft het (voor wat ik begrijp) nog binnen de browser.

Wat meer meningen hierover:

Verschillen tussen JVM en Webassembly (en waarom de een de ander niet kan vervangen):

https://stackoverflow.com...d-in-place-of-webassembly

Waarom java applets onveilig zijn:

https://www.reddit.com/r/...ava_applets_insecure_why/

[Reactie gewijzigd door Waswat op 30 april 2021 22:33]

het ging volgens mij niet beperken wat je kon doen met het systeem. In web assembly blijft het (voor wat ik begrijp) nog binnen de browser.

OK, als je op dit niveau moet praten dan kan je beter geen uitleg geven van systemen. Natuurlijk waren er in Java wel degelijk beperkingen aangelegd. Maar die stonden onder controle van de plugin / het Java systeem.

Als je denkt dat Java een (source code) interpreter was dan heb je het mis. Java's bytecode is wel meer Java specifiek, maar uiteindelijk zijn het gewoon instructies die moeten worden uitgevoerd, overigens ook met een stack-based VM.

Die Reddit thread bevat geen informatie en kan je net zo goed overslaan. Het probleem van de Java omgeving was - naar mijn mening - dat je gebruik maakte van de complete Java classes. Dat heeft natuurlijk voordelen, maar het betekend ook dat beveiligingslekken in de classes en (native) functies beschikbaar komen.

Misschien nog wel belangrijker is dat elk lek in een willekeurige Java runtime library tot een (meestal grote) update leidde, en dat er hiervoor een apart "Java Update" werd gebruikt. Dit was een doorn in het oog voor veel gebruikers en systeembeheerders.

Op de laatste zin na (Java SE werkte met een plugin voor Applets) is dat StackOverflow antwoord wel super overigens.

Nouja, webassembly werkt in principe dat het werkelijk nog op de machine zelf naar native gecompileerd wordt voordat het werkelijk start, maar kan ook dmv interpreter.

Java applets & flash waren traag,

Zelf waren ze niet traag, verre van.

Wat wel traag duurde, is het moment dat internetbrowsers de Flash- of Java Runtime opstartten. En die moesten de swf of jar zelf ook nog inladen.

Er was enkel een zwart of wit vlak te zien en dat beschouwde men als "traag opstarten".

Tegenwoordig gebruiken mobiele apps en websites foefjes voor, zoals met spinners, laadbalkjes, vlakken ingekleurd op basis van een gemiddelde kleur van een afbeelding of een screenshot van een al ingeladen app of webpagina.

Achteraf begrijp ik niet waarom webbrowsers niet de optie aanboden om de runtime van bekende plugins zoals Flash en Java alvast in de achtergrond op te starten nadat de browser zelf opgestart is. In plaats van die runtimes pas opstarten wanneer een website het nodig had (wat het laden en het "werken" van de website langer liet duren).

Als dat en die foefjes toen ook werden gebruikt, had het al een bak met kritiek op heel die plugins gescheeld.

[Reactie gewijzigd door RoestVrijStaal op 1 mei 2021 00:20]

Achteraf begrijp ik niet waarom webbrowsers niet de optie aanboden om de runtime van bekende plugins zoals Flash en Java alvast in de achtergrond op te starten nadat de browser zelf opgestart is.

Omdat de browsers zelf al erg langzaam waren, wat o.a. werd veroorzaakt door de langzamere processors, een veel kleinere mogelijkheid qua hardware versnelling, en veel minder geheugen. Het was destijds juist een gevecht om marktaandeel te bouwen, en dit is hoe Internet Explorer uiteindelijk heeft heeft weten te winnen door zichzelf in het hele besturingssysteem te verweven. Juist het gebrek aan start-tijd was een winst die Netscape e.a. niet konden veroorloven. Maar het geheugen was niet vrij om te verkwisten; harde schijven waren veel langzamer, en de logica van de geheugenhuishouding liet ook veel te klagen over. Wie herinnert zich niet de tooltjes die eindeloos Mallocden om andere programmas het geheugen uit te forceren, en zo een spelletje meer geheugen te geven zodat het vloeiender speelde zonder te hoeven swappen?

Uiteindelijk is het snelle starten hoe Firefox (of destijds nog 'Firebird' zelfs!) is doorgebroken bij techneuten nadat Microsoft geen interesse had om Internet Explorer nog te verbeteren. Mozilla Seamonkey was een gigantisch traag alles-in-een pakket in de voetstappen van Netscape, en het is juist het afslanken en de modernisatie die er voor zorgden dat mensen praktisch iets hadden aan een andere browser. Maar op dat punt was het alweer Windows XP, terwijl het grootste browsergevecht juist werd uitgevochten gedurende de latere jaren van Windows 98 SE. Contextgewijs: dit waren de jaren waarin de wet van Moore nog volledig in werking was!

Java bytecode is een stack-vm (.Net dan weer niet) en dat betekent niet dat iets veiliger is. De twee hebben niets met elkaar vandoen. Dat Java applets traag waren lag eerder aan het browsermodel en de integratie hierin dan inherent aan het gebruik van een VM (stack of niet). Security in Java is dan weer geregeld via een sandbox (hee, dat zit ook in een browser). Eigenlijk allemaal oude wijn in een nieuwe zak dus.

Java is gebaseerd op een draak van een libraryset. "More is more" lijkt het wel.
WebAssembly lijkt me een geval van "less is more".

Je bedoelt dat WebAssembly het equivalent van een gemiddelde C library aan functies meebrengt? (als in: leuk maar zo low level dat je het in de praktijk niet echt kunt gebruiken?). Een taal zonder bibliotheek is als een motorblok zonder auto: leuk voor puristen, maar als je er mee van A naar B wilt behoorlijk nuteloos. Imho is een (goede) standard library minimaal net zo belangrijk als de syntaxis van een taal. Je ziet dit bijv. bij C++: Boost is ongeveer verplichte kost als je C++ doet omdat je anders te lang bezig bent met het herimplementeren van standaard zaken.
Dat je de libraries een draak vind is dan weer een mening en daar zijn er in IT land al heel veel van.

Bij het "compatibele" java veranderden de libraries wel eens. Best irritant.
Verder helemaal eens met libraries. En dan heb je nog onderscheid tussen libraries in de sandbox zelf (kan niemand wat tegen hebben) en libraries die dingen doen die je niet zelf zou kunnen doen als app-bouwer.

Ik heb menig applicatie van Java 1.4 naar java8 mogen helpen zonder aanpassingen. Alleen de stap naar java9 is soms lastig. Zeker als het framework heavy code is. En de Java sandbox wordt eigenlijk alleen gebruikt door applets. Voor server side ken ik geen applicaties die ervoor gekozen hebben (maar het kan idd. wel)

Ik heb menig applicatie van Java 1.4 naar java8 mogen helpen zonder aanpassingen. Alleen de stap naar java9 is soms lastig. Zeker als het framework heavy code is. En de Java sandbox wordt eigenlijk alleen gebruikt door applets. Voor server side ken ik geen applicaties die ervoor gekozen hebben (maar het kan idd. wel)

Ik heb developers meegemaakt die in absolute paniek raakten als er sprake was van een minor patch update van de JDK/JRE.

Kon absoluut niet. Een drama voor fatsoenlijke updates draaien.

Tijd op de developers te updaten, dan.

Tijd op de developers te updaten, dan.

Het is gelukkig alweer een hele tijd geleden

Ik snap wel dat cross platform ideaal is vanuit een dev perspectief maar meestal is het resultaat toch “sucks universally well on all supported platforms”. Ondanks alle prachtige beloftes heeft het ons draken als Java en meer recentelijk Electron opgeleverd.

Ik dacht dat dit bedoeld was als alternatief voor Javascript, wat ook crossplatform is, dus wat dat betreft iig geen achteruitgang.
Electron is ook Javascript, zoiets kan hiermee mss ook wel sneller/beter worden?
Ja tov native is het vaak crappy, maar voor mij (Linux user) is het voordeel dat ik daarmee sommige dingen ueberhaupt kan gebruiken, ipv helemaal niet.

Ja dat laatste snap ik maar het probleem wat ik heb met crossplatform applicaties is dat ze er vaak/meestal niet uitzien als native applicaties en veelal geen ondersteuning hebben voor bediening met toetsenbord (gebrek aan shortcuts) en gevoelgsmatig veel focus op looks (het moet er fraai uitzien) en te weinig op performance. Resource gebruik met name bij Electron apps is hoog (Teams daar goed voorbeeld van).

Compile once, run debug everywhere zei ik vroeger altijd. En ja cross platform is leuk, en tegenwoordig moet het ook wel. Zelfs op een desktop is er meer Mac gebruik dan 20 jaar terug (en ook 4-5 jaar terug). Ook in het bedrijfsleven (zeker de managers) die willen een native applicatie op hun macbook. Ze draaien uiteraard ook wel parallels omdat ze toch een windows moeten hebben, maar kom. En dan is er ook nog een gestaag linux desktop gebruik. Een browser is niet zaligmakend uiteraard. En je zit dan ook nog met browsers die bepaalde dingen niet ondersteunen en/ff de makers willen dingen niet toelaten op hun devices. Dat maakt het dus een pak ingewikkelder. En als developper ik zou graag een native app uitbrengen voor Android, ook native voor iOS. Heb ik daar de tijd voor ... nopes. Dus iets cross platform is gewoon gemakkelijker voor mij. Dat het "quirks" heeft neem ik er wel bij. Als alles later goed draait kan ik nog wel eens kijken voor misschien een rewrite en volledig native te gaan, maar als het zover is, dan zal mijn applicatie "did just not suck enough on all supported platforms to be a hit" zijn

Ik ben nooit een Javascript "lover" geweest, ook geen grote Java fan, maar kom. Maar het maakt mij niet uit, als webassembly de dag van vandaag al 100% moest werken, dan had ik daar al lang voor gegaan. Maar het is een kip en het ei probleem. De gebruikers moeten het kunnen draaien, en zolang deze het niet kunnen heeft het geen nut voor mij om te maken ...

Hmmm, en hoe werkt dat dan? Dan draait er een C++ bitcoin miner, in plaats van een in JavaScript met je site mee? Is wel efficiënter...

En ik zie het natuurlijk weer gebeuren dat mijn Firefox browser op Linux weer overal buitengesloten wordt... Dit is inderdaad de pijn van ~15 jaar geleden oprakelend. Klopt deze aanname, of ziet moppersmurf weer apen en beren die er niet zijn?

Bedoeling is juist dat het platform onafhankelijk wordt. Je hebt misschien wel een punt met Firefox. Ik weet niet of die ook WebAssembly ondersteunt of gaat ondersteunen.
In principe kun je code maken die op Windows, Linux en MacOS draait.

WebAssembly (wasm) wordt prima op Firefox ondersteund (https://caniuse.com/wasm).

Eén van de weinige features waar Firefox toch wel voorloopt op de concurrentie.

Alleen een browser zoals Ie zal wasm moeten emuleren (dat kan via wasm.js)

Hoe lopen ze voor op de concurrentie?

Asm.js (de voorloper) komt uit de firefox koker vandaan. Je kunt tegenwoordig bijna stellen dat interresante zaken in de HTML spec bij Firefox vandaan komen en privacy beperkende innovaties uit Chrome

Firefox doet prima WebAssembly.

WebAssembly klinkt leuk, maar ik vraag me af wat er gaat gebeuren als er een te grote footprint gaat ontstaan voor de te gebruiken software op het systeem. In dat geval gaat de beveiliging net zo hard onderuit als met Java of flash. Het idee van een VM bytecode in een sandbox is prima, maar als de rand te laag is...

Waanzin nog wel.... Kan je dat ook verder onderbouwen?