Webassembly, de toekomst van het web?

Door elhopo op donderdag 23 augustus 2018 00:02 - Reacties (11)
Categorie: Internet, Views: 4.256

https://webassembly.org/css/webassembly.svg

Geschiedenis
In de begintijd van het internet was er alleen maar html. De eerste pagina
bestond uit wat tekst en enkele linkjes. Meer was er ook niet mogelijk. De standaard werd langzamerhand wat uitgebreid, en naarmate er meer mogelijk was werden de pagina’s ook uitgebreider. Toch miste er wat, de pagina’s waren niet erg dynamisch.
Rond 1995 werd hiervoor Javascript bedacht. Met Java als inspiratie werd Javascript geboren. De naam is gekozen om mee te liften op het succes van Java, en op die manier een snelle acceptatie van het publiek te krijgen. Het werd een groot succes, en tot op heden duurt het succes nog steeds voort. In de loop der jaren is het uitgebreid en aangepast, maar toch heeft het zijn tekortkomingen en daarom zijn de grote technologiebedrijven op zoek gegaan naar een aanvulling.

Wat is Webassembly?
Webassembly is een soort virtuele machine, die draait in de browser. Deze machine kan je dan gebruiken in de belangrijkste browsers, Firefox, Chrome, Safari en Edge. De afgelopen tijd hebben alle fabrikanten hier ondersteuning voor toegevoegd. Klinkt mooi, maar wat betekent dat? WebAssembly bestanden(WASM) kunnen door browsers worden binnengehaald, en als bytecode worden uitgevoerd, om near-native te draaien. Het idee is dat ontwikkelaars een applicatie die bijvoorbeeld C of C++ is geschreven naar WebAssembly kunnen compileren, zodat deze in de browser kan worden gedraaid. Om dan een programma te draaien heb je alleen maar de link nodig naar het programma. Verder niets. De browser haalt het bestand op en voert het uit in de virtuele machine. Het werkt verder onder de meeste besturingssystemen. Hmm, waar hebben we dat eerder gehoord? Java servlets? Flash? Allemaal soortgelijke initiatieven, maar ze bleken op den duur zo onveilig dat besloten is er weer vanaf te stappen. Hoe is dit anders dan? Volgens de documenten hierachter werkt het in een gesandboxte (is dat een woord?) omgeving. Net als in een zandbak met hoge muren kan je er dus niet uitkomen en kan je alleen spelen met het zand wat in de bak zit.

Wat kan je er nou mee?
Wellicht eerst wat voorbeelden.
tanks
Tanks!
Dit is Tanks, een spel wat wordt beschreven in een Unity tutorial. Dit spel is geŽxporteerd naar Webassembly. Je kan met z’n tweeŽn spelen, de blauwe tank kan je besturen met WASD en schieten met de spatiebalk, de rode tank kan je besturen met de pijltjestoetsen en schieten met enter.
zen
Een ander voorbeeld is de Epic zen garden
Let wel op, laden en starten duurt heel even. Hierna is het alsof je een lokaal geÔnstalleerd spel speelt.

Veel bedrijven gebruiken een programmeertaal als C++ voor het maken van hun software. Om dergelijke functionaliteit te ontwikkelen voor het web in Javascript is vaak erg tijdrovend. Bedenk maar eens hoeveel tijd het zou kosten om Autocad te maken voor het web. Door nu Webassembly te gebruiken kunnen bedrijven zoals de makers van Autocad veel code hergebruiken, en zo op de kosten sparen.
Andere bedrijven hebben bijvoorbeeld veel software in Javascript geschreven. Browsers zijn de laatste jaren steeds sneller geworden in het uitvoeren van Javascript, maar ondanks alle performance verbeteringen is het nog lang niet zo snel als een native programma. Denk bijvoorbeeld aan gezichtsherkenning. Met Javascript is een snelheid van 1 beeld per seconde te halen, terwijl met Webassembly op dezelfde machine 15 beelden per seconde te halen is. Allemaal prima resultaten. Ook een update van een programma is veel makkelijker te installeren. De beheerder hoeft niet alle computers langs, enkel de server moet worden geupdate.

Betekent dit dan het einde van Javascript?
Nee, aldus de organisaties erachter. Webassembly en Javascript zijn bedoeld om naast elkaar te gebruiken. Vanuit Javascript kan je dus Webassembly aanroepen en andersom. Sommige dingen zijn wat makkelijker te doen vanuit Javascript, zoals DOM manipulatie, het veranderen van hoe je webpagina eruit ziet of de inhoud ervan. Zoals ze zelf aangeven: Javascript is here to stay!

Voordelen
  • Webassembly is efficient en snel. Omdat het al gecompileerd is hoeft de browser dat niet zelf te doen. Ook de bestanden zijn kleiner, omdat niet de broncode wordt gebruikt maar het gecompileerde eindresultaat.
  • Er is een open standaard, zodat iedereen er gebruik van kan maken. Momenteel kunnen via de officieele weg alleen C, C++ en RUST als programmeertaal worden gebruikt, maar er zijn al opensource partijen die bijvoorbeeld Java ondersteunen. Later zullen meer talen officieel ondersteund gaan worden. Een voorbeeld hiervan is Teavm, die zelfs een online editor hebben waar je wat in kan proberen: http://teavm.org/sandbox/index.html . Bij de Examples afdeling zijn zelfs wat grafische voorbeelden te vinden. Microsoft is ook bezig met een C# versie
  • Webassembly is erg veilig. Door de gesandboxte omgeving en de virtual machine constructie zouden beveiligingsproblemen tot het verleden moeten horen
  • Webassembly is zelfs in de browser te debuggen. Vaak is dat lastig bij gecompileerde code, maar hier is speciaal rekening mee gehouden. Hierdoor is het ontwikkelen ervan ook makkelijker.
Nadelen
  • Door de sandbox omgeving kan je simpelweg niet alles lokaal benaderen. Dat wil je ook niet, niet iedere webapplicatie mag bijvoorbeeld in je email of in je documenten kijken. Je kan wel, net als op het web, een bestand uploaden, maar niets zonder expliciete toestemming. Echter kan het soms onhandig zijn.
  • Dan de assembly’s zelf. Ze zijn weliswaar gecompileerd, maar nog steeds leesbaar. Hierdoor is het iets makkelijker om code te lezen, en bijvoorbeeld software te kraken. Gelukkig is code dan wel weer te beveiligen.
  • De code is niet zo snel als native code. Mocht de code echt optimaal moeten presteren dan zal je een gewone applicatie moeten installeren.
  • Niet alle platformen worden volledig ondersteund. Op mijn IPhone kan ik bijvoorbeeld de Epic zen garden demo niet bekijken.
De toekomst
Webassembly is nog volop in ontwikkeling. Enkele belangrijke dingen die er aan komen zijn multithread ondersteuning. Hierdoor kan de applicatie beter gebruik maken van de aanwezige cores in je processor. Een andere belangrijke ontwikkeling is ondersteuning van een garbage collector. Dit is tevens waarom momenteel alleen C, C++ en Rust worden ondersteund. Deze talen hebben geen garbage collector. Wat een garbage collector doet: Tijdens het programmeren gebruik je allerlei variabelen om even wat in op te slaan. In talen zonder de garbage collector moet de programmeur deze zelf weer opruimen als hij ze niet meer gebruikt. Talen met een garbage collector, zoals Java doen dit automatisch. Wanneer een onderdeel nergens vandaan meer gebruikt wordt, is deze dus niet meer nodig en wordt deze opgeruimd.

Tot slot
Het is afwachten of Webassembly echt zo veilig is als dat men zegt. Helaas komen we daar pas na verloop van tijd achter. In het verleden bleek dat Java en Flash toch niet zo veilig was als gedacht. Wat wel een verschil is met het verleden is dat er nu grote namen achter staan, zoals Google, Mozilla, Apple en Microsoft. Mijn verwachting is dat het net zo’n revolutie teweeg zal brengen als destijds Javascript deed. We zullen er in de toekomst nog veel van horen! Meer weten? Hier kan je alles vinden: https://webassembly.org/

Volgende: Mijn tijd als BBS sysop 15-08 Mijn tijd als BBS sysop

Reacties


Door Tweakers user Ramon 73, donderdag 23 augustus 2018 08:15

De volgende stap in de onomkeerbare trend: de cliŽnt-server architectuur. Voor mij als "oudje" (45) terug naar iets dat we al kenden, mainframes. De basis draaide op een centrale host en wij gebruikten alleen redelijke simpele cliŽnts. Toen de software uitgebreider werd, en de netwerken het niet bijhielden schakelde de sector over op lokale architectuur en kwamen er allerlei hulpstukken zoals remote management, gebruikersprofielen.
Tegenwoordig zijn de verbindingen steeds beter, sneller en zowat overal aanwezig en zie je veel dingen weer terug gaan naar een centraal systeem.

Door Tweakers user GrooV, donderdag 23 augustus 2018 08:29

Zo "snel" is webassembly nou ook weer niet als je de initiŽle laadtijd mee rekent, leuk voor spelletjes of grafische applicaties maar dit gaat het normale web echt niet vervangen

Door Tweakers user elhopo, donderdag 23 augustus 2018 09:28

GrooV schreef op donderdag 23 augustus 2018 @ 08:29:
Zo "snel" is webassembly nou ook weer niet als je de initiŽle laadtijd mee rekent, leuk voor spelletjes of grafische applicaties maar dit gaat het normale web echt niet vervangen
Dat is ook niet de bedoeling van Webassembly. Daarom was het ook een vraag, de toekomst van het web? Voor een standaard website voegt het ook niet veel toe, maar wanneer het eenmaal geladen is kan je dingen doen die in Javascript niet of nauwelijks mogelijk zijn. Daarnaast is het, als het eenmaal geladen is, ook stukken sneller dan Javascript.
Denk bijvoorbeeld aan gezichtsherkenning, of iets opnemen via het web, direct in MP3. De MP3 library kan je dan in een Webassembly doen. De voorbeelden hier zijn ook vrij groot, en zijn meer een soort showcase. Als je wat kleinere code neemt wordt het bijna instant geladen.
Ramon 73 schreef op donderdag 23 augustus 2018 @ 08:15:
De volgende stap in de onomkeerbare trend: de cliŽnt-server architectuur. Voor mij als "oudje" (45) terug naar iets dat we al kenden, mainframes. De basis draaide op een centrale host en wij gebruikten alleen redelijke simpele cliŽnts. Toen de software uitgebreider werd, en de netwerken het niet bijhielden schakelde de sector over op lokale architectuur en kwamen er allerlei hulpstukken zoals remote management, gebruikersprofielen.
Tegenwoordig zijn de verbindingen steeds beter, sneller en zowat overal aanwezig en zie je veel dingen weer terug gaan naar een centraal systeem.
Een andere trend die daarbij komt is dat software de nieuwe hardware is. Denk maar eens aan hoeveel geld er wordt uitgespaard door virtualisatie. Een machine bijschakelen is een kwestie van seconden of minuten, waar het vroeger uren of dagen was. Geldt hier ook een beetje voor, je hoeft geen installer te draaien met wazige DLL's enzo, url aanklikken en gaan. Software weer verwijderen? Gewoon de browser afsluiten.

[Reactie gewijzigd op donderdag 23 augustus 2018 09:30]


Door Tweakers user GrooV, donderdag 23 augustus 2018 10:10

elhopo schreef op donderdag 23 augustus 2018 @ 09:28:
[...]

Dat is ook niet de bedoeling van Webassembly. Daarom was het ook een vraag, de toekomst van het web? Voor een standaard website voegt het ook niet veel toe, maar wanneer het eenmaal geladen is kan je dingen doen die in Javascript niet of nauwelijks mogelijk zijn. Daarnaast is het, als het eenmaal geladen is, ook stukken sneller dan Javascript.
Denk bijvoorbeeld aan gezichtsherkenning, of iets opnemen via het web, direct in MP3. De MP3 library kan je dan in een Webassembly doen. De voorbeelden hier zijn ook vrij groot, en zijn meer een soort showcase. Als je wat kleinere code neemt wordt het bijna instant geladen.

[...]

Een andere trend die daarbij komt is dat software de nieuwe hardware is. Denk maar eens aan hoeveel geld er wordt uitgespaard door virtualisatie. Een machine bijschakelen is een kwestie van seconden of minuten, waar het vroeger uren of dagen was. Geldt hier ook een beetje voor, je hoeft geen installer te draaien met wazige DLL's enzo, url aanklikken en gaan. Software weer verwijderen? Gewoon de browser afsluiten.
Je zegt zelf, WA is efficiŽnt en snel in je 1e voordeel, dat is dus niet zo

Door Tweakers user elhopo, donderdag 23 augustus 2018 10:34

GrooV schreef op donderdag 23 augustus 2018 @ 10:10:
[...]

Je zegt zelf, WA is efficiŽnt en snel in je 1e voordeel, dat is dus niet zo
Dat is wel zo op het moment dat je precies hetzelfde zou doen in Javascript. Je zou dus precies hetzelfde spel moeten maken in .js en dan kijken wat de verschillen zijn. Op Youtube staan bijvoorbeeld wat filmpjes waar je de verschillen kan bekijken, en dan scheelt het meer dan een factor 10, dus sneller is het wel degelijk.
Als je je verdiept in hoe een browser werkt zie je dat deze Javascript moet precompileren en optimaliseren, voordat het uitgevoerd kan worden. Die stappen kunnen dus allemaal worden overgeslagen. Hierdoor is het standaard al sneller. Vind je laadtijd belangrijk? Ook daar is het sneller, omdat het al gecompileerd is is het veel kleiner. Hierdoor wordt het sneller geladen. Ja, misschien is de initiŽle laadtijd langer omdat de VM misschien moet worden opgestart, maar als alles geladen is en werkt is het gewoon sneller, maar het is wel afhankelijk waar je het voor wil gebruiken.

Door Tweakers user Stoelpoot, donderdag 23 augustus 2018 11:55

Ramon 73 schreef op donderdag 23 augustus 2018 @ 08:15:
De volgende stap in de onomkeerbare trend: de cliŽnt-server architectuur. Voor mij als "oudje" (45) terug naar iets dat we al kenden, mainframes. De basis draaide op een centrale host en wij gebruikten alleen redelijke simpele cliŽnts. Toen de software uitgebreider werd, en de netwerken het niet bijhielden schakelde de sector over op lokale architectuur en kwamen er allerlei hulpstukken zoals remote management, gebruikersprofielen.
Tegenwoordig zijn de verbindingen steeds beter, sneller en zowat overal aanwezig en zie je veel dingen weer terug gaan naar een centraal systeem.
Daar ben ik het niet mee eens. Zoals jij het vroeger beschrijft, lees ik dat applicaties op het mainframe werkten en gebruikers enkel de I/O van het mainframe in beeld kregen. Een vorm van remote desktop in de moderne taal.

Wat ik juist zie, is dat applicaties meer distributed worden. Waarbij in het geval van Javascript en WebAssembly de apps naar de client worden gestuurd zodra deze nodig zijn, en dan als een normaal geÔnstalleerd programma werken bij de client en daar ook vaak zwaardere berekeningen uitvoeren. De server dient dan enkel nog als specialistische database.

Door Tweakers user GeenAngst, donderdag 23 augustus 2018 14:10

Goede informatie zo ;)
_/-\o_

Door Tweakers user SinergyX, vrijdag 24 augustus 2018 16:05

Moet zeggen dat die Zen Garden best interessant was, maar er waren toch al meer 'clients' die webbased diverse 3D games/scenes kon maken?

Maar juist omdat het nog niet zo bijzonder 'groot' is, zal de focus op het vinden van exploits/etc ook nog lang niet zo groot zijn. Het is leuk voor een spelletje tussendoor, of wat interessant spul zien, maar voor elk 'iets' wat ze maken, zal er wel een ander zijn die het beter wil doen, of juist anders.

Maar is huidig web dan zo traag? Of niet functioneel? 70% van de laadtijd (en snelheid) van een site is toe te schrijven aan reclame, eye-candy scripts en drag&drop codes die 1 bonk overkill zijn.

Door Tweakers user Gomez12, maandag 27 augustus 2018 12:01

elhopo schreef op donderdag 23 augustus 2018 @ 09:28:
[...]
Denk bijvoorbeeld aan gezichtsherkenning, of iets opnemen via het web, direct in MP3. De MP3 library kan je dan in een Webassembly doen. De voorbeelden hier zijn ook vrij groot, en zijn meer een soort showcase. Als je wat kleinere code neemt wordt het bijna instant geladen.
Dit zijn zo ongeveer de slechtste voorbeelden. Voor opnames via het web heb je microfoon access nodig en dat zijn al weer van die leuke dingen.
Zelfde met gezichtsherkenning, daarvoor moet je toegang hebben tot een camera...

Juist die onderdelen zijn in het verleden compleet ge-exploit.
[...]

Een andere trend die daarbij komt is dat software de nieuwe hardware is. Denk maar eens aan hoeveel geld er wordt uitgespaard door virtualisatie. Een machine bijschakelen is een kwestie van seconden of minuten, waar het vroeger uren of dagen was. Geldt hier ook een beetje voor, je hoeft geen installer te draaien met wazige DLL's enzo, url aanklikken en gaan. Software weer verwijderen? Gewoon de browser afsluiten.
En dit is dus de weg die malware al een tijdje opgaat. Gewoon op de achtergrond wat bitcoins proberen te minen terwijl je op de site zit.

Door Tweakers user elhopo, maandag 27 augustus 2018 13:02

Gomez12 schreef op maandag 27 augustus 2018 @ 12:01:
[...]

Dit zijn zo ongeveer de slechtste voorbeelden. Voor opnames via het web heb je microfoon access nodig en dat zijn al weer van die leuke dingen.
Zelfde met gezichtsherkenning, daarvoor moet je toegang hebben tot een camera...

Juist die onderdelen zijn in het verleden compleet ge-exploit.


[...]

En dit is dus de weg die malware al een tijdje opgaat. Gewoon op de achtergrond wat bitcoins proberen te minen terwijl je op de site zit.
Het zijn voorbeelden waar je lokaal wat rekenkracht voor nodig hebt, of die binnen een normale browseromgeving gewoon niet te realiseren zijn. Omdat in het verleden hier wel eens wat mee werd gerommeld is het voorbeeld an sich niet slecht. De gekozen implementatie binnen de browser kan daarentegen wel slecht zijn. Het gaat dus om het voorbeeld, niet om de uitvoering.

Je tweede opmerking is terecht, en dat is moeilijk te voorkomen. Overigens zijn ze voornamelijk gemaakt in Javascript, zoals Coinhive en Cryptoloot. Het probleem is dus niet specifiek voor Webassembly, maar meer voor webtechnieken in het algemeen.

Door Tweakers user Gamebuster, maandag 27 augustus 2018 14:34

Ik ben persoonlijk erg enthousiast over de komst van WASM, maar voorlopig werken we nog met Typescript :) Even wachten tot webapps maken in WASM rendabel is.

Reageren is niet meer mogelijk