Google kończy z Native Clientem: webowe aplikacje tylko w WebAssembly

Do tej pory web to przede wszystkim oskryptowany hipertekstuzupełniony multimediami. Próby upowszechnienia aplikacji webowychkończyły się do tej pory tak sobie, czy to z powodu niedostatkówtechnologii, czy ze względu na niemożliwość uzgodnieniastandardów między producentami przeglądarek. Nowy standard uzyskałjednak konsensus. Czy z WebAssembly zobaczymy, jak web hipertekstuprzemienia się w web aplikacji? Deweloperzy Chromium są przekonani,że to już czas i przygotowując miejsce na nowy standard, porzucajągoogle’ową technologię, z którą kiedyś wiązano przecież takduże nadzieje.

Bastion – jedna z najładniejszych gier na platformę NaCl

Adam Golański

4 czerwca 2017, 18:24

Sześć lat temu, wraz z debiutem systemu Chrome OS, Googlezaprezentowało Native Clienta (NaCl) – środowisko, którepozwalało na uruchamianie skompilowanego kodu C/C++ bezpośrednio wprzeglądarce, z niemal natywną wydajnością. W czasie gdy ChromeOS nie potrafił niczego poza uruchamianiem aplikacji webowych wJavaScripcie/HTML5, w NaCl widziano szansę na wyjście poza teograniczenia. I faktycznie, pierwsze gry dla NaCl (m.in. Bastion)wychodziły daleko poza to, co możliwe było dotąd wprzeglądarkach.

Minusem NaCl była ograniczona kompatybilność – kod wJavaScripcie uruchamiał się na dowolnej architekturze sprzętowej,skompilowany kod w C/C++ tylko na maszynach z procesorami x86, ale zczasem i temu zaradzono. Portable Native Client (pNaCl) działał nietylko na x86, ale też na procesorach ARM i MIPS, wykorzystując etapkompilacji do kodu pośredniego (tak jak Java czy .NET).

Pomimo starań Google’a, Native Client szału jednak nie zrobił.W sklepie Chrome Web Store pojawiło się nieco gier i aplikacji,wśród nich takie perełki jak From Dust czy Lara Croft and TheGuardian of Light… ale to wszystko. Nie pomogło nawet otwarcieNative Clienta w ramach projektu Chromium.

Mozilla zaczęła propagować swoją własną platformę asm.js,działającą we wszystkich przeglądarkach i zbliżoną wydajnościądo natywnej, a świat skręcił w stronę natywnych aplikacjimobilnych. W końcu zaś Chrome OS dostał możliwość uruchamianiaaplikacji Androida – a na horyzoncie pojawił się zupełnie nowystandard uruchamiania skompilowanego kodu w przeglądarkach –przenośna maszyna stosowa WebAssembly (wasm). Native Client nie byłjuż nikomu potrzebny, mimo że Chrome stało się najpopularniejsząprzeglądarką na świecie.

Żegnaj Native Cliencie, lepiej będzie nam z WebAssembly

Dlatego Google ogłosiło, że kończyz pNaCl. Do pierwszego kwartału 2018 roku środowisko toprzestaniebyć wspierane – wyjątek ma być póki co zrobiony tylko dladotychczasowych rozszerzeń Chrome i aplikacji Chrome (które toaplikacje też niebawem zostaną porzucone). Cały wysiłekdeweloperów ma zostać włożony we wspieranie WebAssembly, jakouniwersalnej, uzgodnionej między głównymi producentamiprzeglądarek platformy uruchomieniowej dla kodu pośredniczącego.

Już dzisiaj WebAssembly oferuje niemal natywną wydajnośćaplikacji, wyższą średnio o 5-7% od asm.js oraz wsparcie dlalicznych funkcji nowoczesnych procesorów niedostępnych dlaJavaScriptu i asm.js (np. 64-bitowe liczby całkowite, instrukcjeload/store czy różne specjalne instrukcje z rozszerzonychzestawów). Co zaś chyba najważniejsze, środowisko to działarównie dobrze we wspierających je przeglądarkach: Chrome 57 iFirefoksie 52, a także w testowych wersjach Microsoft Edge i Safari.

Dla deweloperów zainteresowanych pisaniem aplikacji webowych naWebAssembly, Google przygotowało harmonogramrozwoju i implementacji tego środowiska. Czy tym razem coś z tegoprojektu wyjdzie, czy też po prostu wszyscy sobie kupią chromebookii będą na nich uruchamiać miliony aplikacji androidowych – czaspokaże.

Adam Golański