WebAssembly: MVP

Obecnie możemy się cieszyć WebAssembly w wersji MVP, czyli most valuable product. I tym właśnie jest obecnie webassembly - produktem, nadającym się do użycia, ale ograniczonym.

Twórcy webassembly powtarzają, że kompatybilność wstecz jest bardzo istotna i aplikacje, które teraz napiszemy, będą działać zawsze, także przy nowych wersja. Co więcej bez żadnych zmian z naszej programistycznej strony, może się zdarzyć, że aplikacja będzie działać szybciej i lepiej, ponieważ użytkownik ma nowszą przeglądarkę obsługującą więcej funkcji.

Skupmy się jednak na tym co obecnie dostępne, czyli MVP.  Rysunek przewodni tego posta to wycinek drzewka umiejętności WebAssembly według Link Clark  WebAssemblys post-MVP- future: A cartoon skill tree 

• Portability

czyli możliwość uruchomienia kodu na wszystkich przeglądarkach, a dokładniej na wszystkich nowych przeglądarkach. O ile działa Edge, to w końcu możemy zapomnieć o Internet Explorerze… albo martwić się, że go musimy brać pod uwagę.

• Compilation target

 tutaj nie ma uwag, technologia jest tak zaprojektowana i to się nie zmieni.

• Compact 

ponieważ rozmawiamy ciągle o formacie binarnym mamy pewność zwartości treści, żadnych nadmiarowych rozumianych przez człowieka znaków, tylko maszynowe zero jedynki

Gdy zaczynamy używać webassembly - już skompilowanego kodu, okazuje się, że mamy do czynienia z Modułami 
Moduł webassembly jest oparty o stos wywołań typu LIFO (stack machine, dobry opis zawsze w Wikipedi).
Do dyspozycji mamy 67 instrukcji. 4 typy danych wejściowych - wszystkie numeryczne. Ostatnia dana która zostaje na stosie wywołań to wynik, jest on też typu numerycznego.
Niewiele możliwości, szczególnie uciążliwe może być posługiwanie się stringami.


Moduł webassembly jest bezstanowy i może być współdzielony pomiędzy okna i workery. Dokładnie tak jak moduł ES2015 deklaruje importy i eksporty.

 • Linear memory

Moduł taki korzysta z liniowej pamięci, czyli tablicy bajtów, do której mamy dostęp przez odpowiednie instrukcje.
Liniowa pamięć to też powód, dlaczego natywnie są wspierane języki same zarządzające pamięcią takie jak C++ czy Rust. To głównie z myślą o tych językach powstawało webassembly, a zarządzanie pamięcią jest w nich z goła inne niż w JavaScript, co jest zaletą nie wadą. W końcu chodzi o różnorodność narzędzi.
Więcej można poczytać w WebAssembly key concepts 

• Fast execution

Jedną z korzyści, które na początku ma oferować webassembly jest wydajność - szybki czas wykonania prekompilowanego kodu.

Jest to troszkę uproszczenie. Silniki JavaScript miały wiele lat na doskonalenie optymalizacji i radzą sobie obecnie naprawdę dobrze. Nie każdy kod będzie też napisany bardzo wydajnie. Jednak to co zapewnia nam webassembly to spójność czasu wykonania.
Nie jesteśmy zależni od optymalizacji wywołań, znamy czas uruchomienia danego kodu.
Widać to bardzo ładnie na przykładzie generowania mapy kodu napisanego w Rust Oxidizing source maps with Rust and WebAssembly 
Jeden obrazek wart 1000 słów, spójrzmy więc poniżej. Pomarańczowe kropki to czas wykonania JavaScript, niebieskie - Rust, niebieskie kropki mają zdecydowanie mniejszy rozrzut.

To jest pełen stan WebAssembly MVP, trwają prace oczywiście nad dalszym rozwojem, ale z takim stanem możemy już produkcyjnie używać WebAssembly. Choć nie zawsze.