Udvikler: Hvorfor eksploderer mine 3 linjer JavaScript-kode til 300?

At afspille en lydfil i JavaScript burde være så let som at skrive tre linjer kode.
Men i praksis har den slags opgaver det med at eksplodere op i fjæset på den sagesløse udvikler, som gerne vil have skidtet til at virke på tværs af flere forskellige browsere.
Sådan lyder budskabet fra freelance-udvikleren Rob Ashton, da Version2 fanger ham på Microsoft-konferencen Warm Crocodile i København. Han arbejder til daglig med blandt andet udvikling af store JavaScript-applikationer og spiludvikling i HTML5.
Og det er et godt eksempel på et problem med at skrive kode til webbrowsere, hvor producenter som Microsoft, Google, Mozilla og Apple på papiret er enige om standarderne. Og så alligevel ikke er det.
»Mit rant går på afspilning af lyd i JavaScript, fordi det opsummerer alt omkring browsere, som jeg ikke kan lide,« siger Rob Ashton til Version2.
Han uddyber:
»Det burde være tre linjer kode i JavaScript, men sådan er det ikke. Fordi hver browser understøtter forskellige typer af mediefiler, så du ender med at skrive seks eller otte linjer kode for at finde ud af, hvilken du skal afspille,« siger Rob Ashton.
Men her stopper det ikke ifølge udvikleren, der undervejs i interviewet speedsnakker henover en konstant humoristisk undertone:
»Du tror, at det er nok, men så går du over til Apples enheder, og pludselig kan du ikke indlæse en lydfil, med mindre brugeren klikker på en knap. Så det giver dig endnu 25-30 linjer kode for at få det til at virke på iOS-enheder. Men det er stadig ikke nok,« fortsætter han.
»For hvis du skal afspille den samme fil flere gange i spillet, hvilket ikke er utænkeligt, skal du have pools til dine lydfiler for fem forskellige kopier liggende i hukommelsen, så du kan trykke play, og det virker. Du tror, at det nu er nok, men på iOS kan du kun afspille en audiofil af gangen, så hvis du gør det på den måde, virker det ikke på iOS mere.«
»Så du går fra tre linjer kode til at have brug for 300 eller 400 linjer kode. For mig viser det, at det er svært at skrive sådan noget som spil til webbrowsere. For der er standarder, men ingen ser ud til at være enige om implementeringsdetaljerne,« siger Rob Ashton.
Hvad er løsningen på det problem?
»Der er ingen løsning på problemet her og nu. Men det vil gå væk med tiden. Vi må bare finde os i det. Det handler om evolution,« siger Rob Ashton.
Han sammenligner med det kendte JavaScript-bibliotek jQuery, som i dag er et vidt udbredt abstraktionslag til at løse problemerne, der opstod på grund af browseres måde at håndtere forskellige hændelser på i DOM - den grænseflade, der ofte bruges mellem JavaScript og HTML.
På samme måde ser man nye biblioteker pible frem, som eksempelvis gør det lettere at håndtere lydproblemet. Rob Ashton arbejder selv på et, Primo Audio, som spiller sammen med hans 2D spilmotor til HTML5 Canvas, PrimoJS.
»Når du laver en applikation til det moderne web, så skriver du heller ikke kode til DOM direkte længere. Du bruger jQuery, eller hvad du nu har lyst til. Så alt, du skal bekymre dig om, er at bruge et library. Og det er den vej, det går. Standarderne er der, og så lægger vi (udviklere, red.) nogle lag oven på standarderne, som gør, at det pludselig er til at holde ud,« siger Rob Ashton til Version2.
Version2 er mediepartner på udviklerkonferencen Warm Crocodile, der finder sted 16.-17. januar i København. Du kan læse mere om konferencen her.
Kommentarer (1)
Prøv f. eks. at spole i en lydfil på IOS eller sæt playbackRate på IE8 (eller IE9).
(Skrevet af en af udviklerne af LYT.)

