Nors WebAssembly dažniausiai siejama su specialiais varikliais, vertimas į C ir kompiliavimas įprastu kompiliatoriumi gali būti stebėtinai sunkus įveikti. Naujausių benchmark’ų duomenimis, šis kelias vis dar gyvybingas, tačiau naujos kartos varikliai, palaikantys išplėstinę aritmetiką, vėl pirmauja.

Iš naršyklės į debesį

WebAssembly viešai pristatytas 2015 m., o 2017 m. jau turėjo minimaliai gyvybingą produktą (MVP), tų pačių metų pabaigoje visos pagrindinės naršyklės jį palaikė. Šiandien palaikymas siekia 99 proc. — tai tapo nauju standartu, leidžiančiu rašyti iš C, C++, Rust ar kitų kalbų sukompiliuotas programas, kurios naršyklėje veikia artimu natyviu greičiu.

Esminis posūkis įvyko, kai atsirado WASI (WebAssembly System Interface) — standartizuota sąsaja, leidžianti WebAssembly moduliams saugiai pasiekti operacinės sistemos resursus (failus, tinklą, aplinkos kintamuosius). Tai atvėrė duris serverių, debesijos ir daiktų interneto aplinkoms: tas pats modulis, parašytas vieną kartą, dabar beveik be pakeitimų veikia tiek naršyklėje, tiek „edge" platformose ar konteineriuose.

Kur čia saugumas?

WASI saugumo modelis remiasi principu „leidimai pagal galimybes" (capability-based). Sistema nesuteikia neribotos prieigos — kiekvienam resursui reikia aiškiai suteikto leidimo. Taip net ir serverio pusėje paleistas WebAssembly modulis negali tyliai skaityti failų ar užmegzti naujų tinklo ryšių, jei paleidėjas to neleido. Tai smarkiai sumažina atakų paviršių, palyginti su tradiciniais konteineriais.

1.25x natyvaus greičio kaina

Praktiniuose testuose, kuriuos atliko Frank Denis naudodamas libsodium kriptografinę biblioteką, palyginimo matas buvo lėtėjimas, palyginti su natyviu kodu. 1.25x reikštų, kad operacija užtruko 25 % ilgiau.

Pats netikėčiausias rezultatas: WebAssembly modulio vertimas į C („wasm2c" kelias) ir sukompiliavimas standartiniu C kompiliatoriumi vis dar pasirodė puikiai — štai čia ir išlieka gyvybinga alternatyva specializuotiems varikliams. Tačiau šio lyginimo metu keli varikliai, palaikantys išplėstinės aritmetikos plėtinį (wide arithmetic), sugebėjo dar labiau priartėti prie natyvaus kodo ir šiame etape aplenkti C kelią.

Denis pripažįsta: dar 2023 m. jis tikėjosi, kad šis argumentas laikui bėgant susilpnės, nes WebAssembly varikliai tobulėja. Rezultatai rodo, kad kova dar nesibaigė — tiesiog vyksta abiejose fronto pusėse.

Papildomas pliusas transpiliavimo į C kelyje — diegimo paprastumas. Nereikia išlaikyti viso WebAssembly variklio proceso; pakanka bet kurios platformos su C kompiliatoriumi ir bent minimalia libc palaikymu.

43 tūkstantių svetainių faktas

Nepaisant techninių varžybų, WebAssembly jau įsitvirtino praktikoje. Manoma, kad šiuo metu ji naudojama maždaug 43 000 svetainių, tarp jų — tokie sunkūs produktai kaip Figma, Unity ar Fastly tinklo paslaugos.

Kertinė savybė — ne pakeisti „JavaScript", o dirbti šalia jos, atnešant natyviai artimą našumą ten, kur jo reikia, išlaikant naršyklės saugumo modelį.

Serverių pusėje WASI vis dažniau svarstoma kaip lengvesnė alternatyva tradiciniams konteineriams, ypač trumpalaikiams darbams kraštiniuose (edge) įrenginiuose. Galimybė naudoti transpiliavimą į C dar labiau išplečia palaikomų taikinių spektrą — WebAssembly modulis gali virsti paprastu C failu ir veikti ten, kur specialaus variklio tiesiog nėra.

Šaltiniai

  1. [1] [Techstory.in | 2026-07-12] WebAssembly: The Technology Transforming the Future of High-Performance Web Applications
  2. [2] [00f.net | 2026-07-12] The best WebAssembly runtime may still be no runtime at all
  3. [3] [C-sharpcorner.com | 2026-07-12] WASI Explained: The Future of WebAssembly Beyond the Browser