W3C promoveert Web Audio-api tot officiële standaard

Het World Wide Web Consortium heeft de Web Audio-api tot een officiële standaard verklaard. Het besluit opent de weg voor verdere ontwikkeling van de JavaScript-api, in de vorm van een v2-versie met meer mogelijkheden.

De promotie tot officiële standaard is het resultaat van een lang W3C-traject voor de Web Audio-api. Een werkgroep van de W3C publiceerde al in 2011 de eerste draft voor de api. Het gaat om een high-level JavaScript-api voor de verwerking en het gebruik van audio in websites en webapplicaties. De api is complementair aan het <audio>-element, dat te gebruiken is voor eenvoudige audiobediening voor het web. Web Audio maakt complexer gebruik mogelijk, zoals stereopanning, het gebruik van effecten en het vervormen van geluid met behulp van interface-elementen.

Tal van diensten maken al gebruik van de api, waaronder SoundCloud, Ableton, Google Meet en Stadia en Spotify. Ook browserbouwers zoals Mozilla ondersteunen de api al een tijd en er is een jaarlijkse Web Audio-conferentie waar de ontwikkeling besproken wordt. Volgens de W3C heeft deze brede ondersteuning bijgedragen aan de status van een W3C Recommendation-standaard. De organisatie werkt al aan Web Audio API v2, die voortborduurt op de huidige standaard en meer complexiteit en functies voor ontwikkelaars gaat bieden. Wanneer het werk aan versie twee afgerond moet worden, is niet bekend.

Reacties (37)

[jj71]

Leuk, maar wat ik wel jammer vind - hier liep ik een tijdje geleden met een hobbyproject tegenaan - is dat Web MIDI nog zo slecht ondersteund wordt. Ok, dat is nog niet officieel tot standaard uitgeroepen, maar bestaat ook al een aantal jaren. Het werkt wel in Chrome en Edge, maar niet in Firefox en Safari. Op de website van Mozilla is er wel documentatie over maar Firefox ondersteunt het (nog) niet.

[Wolfos]

Waarom niet gewoon een native app? Dingen als web midi vraag ik me echt af of je dat moet willen. We gooien steeds meer dingen in de browser, maar het is totaal niet efficient. Al die Electron apps gebruiken honderden MB's aan geheugen, puur zodat ze hun 3 regels code in Javascript kunnen schrijven.

[jj71]

Omdat de Web MIDI API heel makkelijk is, één van de eenvoudigste manieren om iets met MIDI te doen. Het was een hobbyprojectje, en het was makkelijk om iets in elkaar te klussen met HTML en CSS.

Ik programmeer eigenlijk nooit native GUI apps dus als ik er een native app van zou willen maken dan moet ik eerst uitzoeken hoe dat werkt, en bovendien is het dan weer totaal verschillend voor Windows / macOS / iOS / Linux / Android. Ook de MIDI API's van die platformen verschillen behoorlijk.

[R4VANG3R]

Omdat web cross-platform is en je dus niet meerdere apps hoeft te onderhouden

[Schway]

Daar is de eerste draft uit 2012, die is dus volgend jaar aan de beurt

[gimbal]

Leuk voor game development ook. Het begint best wel laagdrempelig te worden om dat te doen, alhoewel ik zelf er nog wel Typescript tussen zet om een beetje leesbare code te kunnen schrijven. Als je niet 2D gaat op een platte canvas dan is er wel three.js voor 3D games / toepassingen.

[Tadango]

En hoever is WebAssembly al? Dat lijkt me nog een stuk beter dan Javascript....

[wica]

WebAssembly draait in de browser toch met javascript?

[Myri]

Klopt :-)

Ik denk dat het vooral gaat om het "schrijven" van JavaScript, wat voor velen nu niet bepaald een prettige ervaring is.

[Mr. Awesome]

Waarom is dat voor velen niet bepaald een prettige ervaring?

[Ablaze]

Wasm biedt developers de mogelijkheid om frontend applicaties te maken in hun eigen taal. Alles wordt immers gecompileerd naar bytecode.
Iemand die een backend maakt in C# kan die taal dus nu ook gebruiken voor de frontend.
Een ander voordeel is dat sommige developers niet zo van js houden omdat het niet strongly typed is, waardoor veel bugs pas runtime naar voren komen, in plaats van compile time. Dat kan natuurlijk opgelost worden met TypeScript, maar dat wordt niet rechtstreeks door browsers ondersteund en moet ook weer aangeleerd worden.

[Reactie gewijzigd door Ablaze op 24 juli 2024 05:12]

[Myri]

Als je als bedrijf een pool hebt van mensen die niets tot weinig van JavaScript afweten dan kan je toch verder met WebAssembly wat de code kwaliteit en onderhoudbaarheid ten goede komt (voor het scenario zoals in dat gegeven bedrijf).

Je kan dan gerust zeggen dat mensen zich moeten bijscholen, en langs de éne kant heb je gelijk, en langs de andere kant is dat helaas niet wat er dan gebeurd. Een bedrijf stuurt dan een paar mensen op cursus, misschien zelfs een paar weken. Bedrijf denkt: prima, nu kunnen we ermee aan de slag. Mogelijk gevolg is brakke, niet onderhoudbare code, frustraties bij dev, frustraties bij mgmt., ...

[Tadango]

Klopt? web assembly draait niet in javascript oid, dus klopt niet ;-)

[Myri]

Zie jou opmerking iets eerder geplaatst.
Kwestie van de verwarring niet nog groter te maken

[Tadango]

Klopt nog steeds niet naar mijn idee

[Tadango]

Nee, zie ook https://webassembly.org/

Dit draait onafhankelijk van javascript maar er is wel een interop mogelijkheid om javascript functies / api's aan te roepen.

[Myri]

Niet helemaal correct als ik het zo lees van je gelinkte website:

WebAssembly minimizes costs by having a design that allows (though not requires) a browser to implement WebAssembly inside its existing JavaScript engine (thereby reusing the JavaScript engine’s existing compiler backend, ES6 module loading frontend, security sandboxing mechanisms and other supporting VM components). Thus, in cost, WebAssembly should be comparable to a big new JavaScript feature, not a fundamental extension to the browser model.

Dus het is wel degelijk JavaScript in de achtergrond. Maar je merkt er helemaal niks van als je je apps schrijft in C++, C#, ...

[Tadango]

Dat lees ik anders. Zover ik heb begrepen draait het onafhankelijk maar kan je het gebruiken ALS een nieuwe javascript functie, maar dat is het niet.

[Myri]

Ok, beetje verder ingelezen Wasm is een low-level assembly-like language in een compact binary formaat en is dus niet achterliggend JavaScript. Wel heb je browsermatig de JavaScript engine nodig om het in je browser aan de praat te krijgen. En lijkt er me dus wel een zeer grote koppeling tussen de 2.

Dus de originele vraag:

WebAssembly draait in de browser toch met javascript?

Is eigenlijk "Ja, met de JavaScript Engine, maar Wasm is geen JavaScript"

Corrigeer maar hoor als je het niet eens bent.. ik vind het een interessante discussie

[Reactie gewijzigd door Myri op 24 juli 2024 05:12]

[djwice]

Wasmjs is gewoon een sub-set van JavaScript. Door slechts gebruik te maken van de beperkte set en grammatica kan de code veel beter worden geoptimaliseerd.

Daardoor is de executie van de code vele malen sneller dan normaal JavaScript.

[edit]: oeps dat is http://asmjs.org/

Daarna kwam wasm:

Toen dat bleek te werken - in niet aangepaste browsers - zijn de browser engines nog verder geoptimaliseerd voor wasm.

[edit]: Someone suggested https://www.assemblyscript.org/
https://developer.mozilla.../Using_the_JavaScript_API

[Reactie gewijzigd door djwice op 24 juli 2024 05:12]

[youngroger]

ASM.js was een subset van JS waarop WASM gebaseerd is. WASM is zelf zeker geen subset van JS. Het werkt met andere standaarden zoals WASI ook buiten de browser d.m.v. van standalone runtimes zoals wasmtime en wasmer. Er zijn zelfs use-cases waarbij JS in WASM runtimes gerund wordt.

[Tadango]

Javascript wordt gebruikt als een bootloader zeg maar, maar daarna draait het onafhankelijk. Daar komt later vast ook iets anders voor zodat je de assembly files direct kan starten.

[Wolfos]

Beter dan ASM.js in ieder geval, maar voor mensen die de oude Unity plugin kennen (zonder enige aanpassing draaien op dezelfde snelheid als native) blijft het een flinke stap achteruit. Er zijn grote limieten, geen multithreading bijvoorbeeld.

[youngroger]

WASM heeft worker-based threads, alhoewel deze alleen nog maar in Chrome gesupport worden.

[gimbal]

Geen idee eigenlijk, WebAssembly is nieuw en eng

[Tadango]

Ha, ligt eraan wat je als bron taal gebruikt. Vanuit een .Net oogpunt is Blazor -> WebAssembly geweldig en zijn alle javascript front-ends eng.... Wij draaien al een hele tijd een Blazor Webassembly applicatie in productie en als je na een tijdje de code opent is alles zo lekker duidelijk en snel aanpasbaar.... daar is niets engs aan.

[Ablaze]

Wasm wordt al zeker drie jaar ondersteund in browsers. De compilers ervoor zijn wel relatief jon, het js ecosysteem is (nog) veel groter.

[Reactie gewijzigd door Ablaze op 24 juli 2024 05:12]

[SillieWous]

Javascript is eng. Hoop dat wasm zal zorgen voor wat minder wildgroei aan programmeertalen die allemaal net weer anders moeten zijn. Maar ik vrees dat de wildgroei nooit zal ophouden.

[Ed Vertijsment]

Wat maakt het dan precies beter?

[Megamind]

Daar worden best mooie dingen mee gedaan, valve source engine port bv https://cs-online.club/ counterstike 1.6 port in webassembly.

[Snippo]

Voor game development kan je beter Babylon.js gebruiken i.p.v. Three.js als je iets laagdrempeligs zoekt.

[ichnaton]

Bedankt voor de tip, dit is ruig.

[HollowGamer]

Waarom is W3C altijd zo langzaam met het introduceren van nieuwe officiële standaarden? Of is dat niet zo?

[Donvermicelli]

Waarom is W3C altijd zo langzaam met het introduceren van nieuwe officiële standaarden? Of is dat niet zo?

Omdat W3C niet op zichzelf staat, een standaard maken is leuk maar als niemand wil meewerken aan de implementatie ervan ben je nog nergens. Er zit echt heel veel werk in het reviewen van voorstellen en deze af te stemmen met alle stakeholders.

Dit is dan ook zowel de kracht als de achilleshiel van opensource/public works, ALS er iets uit komt dan is het redelijk robuust en breed ondersteund, alleen je verliest controle en daardoor is ontwikkeling beduidend langzamer.

Vergelijk iOS met Android bijvoorbeeld: doordat Apple volledige controle heeft over het OS kan Apple zelfstandig bepalen welke devices ondersteund worden, welke API's er nieuw bij komen, welke API's depricated worden en of zelfs verwijderd worden. Hierdoor zit een relatief groot aantal gebruikers altijd op de laatste versie. In Android moet er eerst afstemming zijn met een groot scala aan shareholders en zie je dus ook veel meer versplintering. Dit is goed voor keuze maar zorgt er bijvoorbeeld wel voor dat time critical updates niet altijd tijdig afgeleverd worden.

[bbg0]

Bij W3C hebben standaarden vrij lang "draft" status. Pas als de specificatie helemaal stabiel is en er twee afzonderlijke implementaties zijn, dan is het klaar en wordt het een "recommendation". Dit zorgt ervoor dat W3C standaarden de actuele werkelijkheid beschrijven, en dus niet een gewenste maar onzekere toekomst.

[bdbfz]

Het Engelse "promotes" is in dit geval in het Nederlands "promoveert" volgens mij, niet "promoot".

Edit: de titel is nu aangepast. Zo klopt het.

[Reactie gewijzigd door bdbfz op 24 juli 2024 05:12]

[GekkePrutser]

Is dit niet die API die zoveel informatie lekt voor adverteerders? Ik had gehoord dat dit een zwak punt was van bijvoorbeeld firefox. Echter kan ik er nu niets meer over vinden. Misschien heb ik het door elkaar gehaald met een andere API.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 05:12]