Obietnica Javy – jeden kod uruchamiany wszędzie – może i w jakimś stopniu została spełniona, ale na pewno nie tak bardzo, jak marzyło się to twórcom tej technologii z Sun Microsystems. Dzisiaj Java to głównie zastosowania serwerowe, na desktopach i innych urządzeniach jej popularność drastycznie ogranicza konieczność instalacji specjalnego środowiska uruchomieniowego. Ale czy taką obietnicę da się w ogóle lepiej zrealizować? Mozilla ma na to pomysł, i wcale nie chodzi tu o JavaScript w przeglądarce. Projekt WebAssembly System Interface to technologia, która przypomina aplety Javy, ale pozwala na znacznie więcej.
Niektórzy się pewnie zdziwią, że w coś takiego angażuje się producent Firefoksa, znany ze swojego uwielbienia dla standardowych technologii webowych. To po części i Mozilli zasługa, że przeglądarki internetowe, które powstały, jak sama nazwa wskazuje, do przeglądania dokumentów hipertekstowych, stały się przede wszystkim środowiskami uruchomieniowymi dla aplikacji webowych, których interfejsy napisano w JavaScripcie.
Nowoczesne przeglądarki nie mają już z Wasm problemów
Dokumenty Google, JIRA, Spotify, a nawet Facebook – to przecież wszystko wysoce skomplikowane aplikacje, do uruchomienia których potrzebujemy pokaźnej mocy obliczeniowej współczesnych komputerów. A co gorsze, wszechobecność technologii związanych z przeglądarkami sprawiła, że języki programowania technologii webowych zaczęły panoszyć się także na desktopie i urządzeniach mobilnych, tam też wnosząc związaną z nimi ślamazarność i apetyt na zasoby sprzętowe.
Prób przezwyciężenia wad języka JavaScriptu było kilka, ale te wszystkie rozwiązania z C# i Javą w przeglądarce miały jedną podstawową wadę: uruchamiały się w specjalnych wtyczkach i nie miały nic wspólnego z obiektami HTML strony internetowej.
Dopiero w 2015 roku, właśnie grupa robocza, na czele której stali eksperci z Mozilli, zaproponowała rozwiązanie o nazwie Web Assembly, czyli łatwy w przenoszeniu kod bajtowy, dostępny w jednocześnie w binarnej i tekstowej postaci, wielokrotnie szybszy od JavaScriptu. Aplikacje Wasm mogą być pisane w językach takich C/C++, Go i Rust – wystarczy ustawić odpowiedni cel kompilacji. Uruchomią je wszystkie nowoczesne przeglądarki: Firefox od wersji 52, Chrome od wersji 57, Microsoft Edge od wersji 16, a Safari od wersji 11.1. Co najważniejsze, to wszystko działa niezależnie od architektury sprzętowej.
Zobacz też: Firefox debugowany maszynowo. Kolejny krok do samopiszącego się kodu?
Systemowy interfejs, aby wyjść poza przeglądarkę
Czemu jednak takiego uniwersalnego kodu nie można by uruchomić także i poza przeglądarką?
Powód jest prosty. W WebAssembly nie ma żadnego interfejsu systemowego, z którym ten kod mógłby rozmawiać. Jeszcze nie ma – ale właśnie ma powstać za sprawą inicjatywy WASI – WebAssembly System Interface.
Dzięki WASI, aplikacje Wasm bedą mogły zostać uruchomione w każdym zgodnym ze standardami środowisku, i to już jako skompilowane pliki binarne, z niemal natywną wydajnością, tak samo, jak uruchamia się aplikacje .jar w systemach z zainstalowanym środowiskiem uruchomieniowym Javy (JRE).
Po co nam jednak nowa technologia, skoro mamy analogiczne technologie dla Javy? Po pierwsze, chodzi oczywiście o wolność od Oracle i jego rygorów licencyjnych. Po drugie, chodzi o językową neutralność, aplikacje WebAssembly mogą powstawać w przeróżnych językach, nawet w C#. Po trzecie wreszcie, aplikacje Wasm są znacznie bezpieczniejsze od apletów Javy, zapewniając dobrą ochronę pamięci, izolowaną piaskownicę i spójność przepływu sterowania.
Zobacz też: Pat w sprawie manifestu rozszerzeń Chromium – Google wytrwale dąży do monopolu
Na razie ekosystem WASI jest skromny, szczególnie jeśli porównać go do ekosystemu wokół Javy/JRE. Mamy eksperymentalne środowisko do uruchamiania aplikacji WebAssembly poza przeglądarką o nazwie Wasmtime, oraz Lucet kompilator i środowisko uruchomieniowe do uruchamiania niezaufanych aplikacji WebAssembly wewnątrz innych aplikacji.
Zanim WASI zostanie ukończone, minie jeszcze trochę czasu, ale ta technologia zapowiada się rewolucyjnie, pozwalając tworzyć oprogramowanie działające zarówno na smartfonach jak i w chmurach obliczeniowych. Twórca słynnego mechanizmu zarządzania kontenerami Docker Salomon Hykes uważa wręcz, że gdyby w 2008 roku miał Wasm z WASI, to nie byłoby potrzeby wymyślać Dockera.
Być może przesadza, ale patrząc na potencjał tej technologii można sądzić, że stara obietnica Suna w końcu będzie spełniona.
