WASM hot or not?

Zastanawiam się, czy obecnie jest jeszcze sens używać do aplikacji webowych JS'a, włączając w to jakieś pudrowane TypeScript'y?
Patrząc z mojego punktu widzenia, JS wydaje się być kompletnym dinozaurem. Większa objętość, niższy performance, przeznaczony do działania na DOM. Czy istnieją jakieś powody, dla których warto dzisiaj używać frameworków takich jak React/Angular, skoro mam wybór w postaci WASM?
Zrobiłem krótką kwerendę i dostałem następujące argumenty:

1. Brak bezpośredniego dostęu do drzewa DOM
2. Duże pliki binarne
3. Złożone debugowanie

Tylko dla mnie, te argumenty są mocno naciągane:
Dostęp do drzewa DOM, nie jest mi potrzebny, bo piszę aplikację mającą działać w przeglądarce, a nie "zautomatyzowany dokument". Nie chcę mieć drzewa DOM, nie chcę się odwoływać do jakiegoś tam DIV'a, żeby wypełnić go treścią. Nie chcę tego wszystkiego kolorować CSS'em. Czyli w skrócie - nie potrzebuję dostęu do DOM, jeżeli go nie mam.

Duże pliki binarne - w przypadku prostych rzeczy - OK. Gdybym chciał zrobić jakiś prosty formularz ze sprawdzaniem, czy użytkownik wprowadził kod pocztowy we właściwym formacie, byłaby to prawda. Tylko robiąc coś odrobinę bardziej złożonego, ten argument traci sens.

Złożone debugowanie - tak, nie jestem w stanie debugować działania programu w przeglądarce, ale przecież mogę robić to w IDE, jest to dla mnie dużo bardziej wygodne.

Jedyny argument, jaki do mnie przemawia, to to, że mamy armię frontendowców, którzy znają JS/TS i nie chcą startować od zera.

Ale przecież ostatni "przeciwny" argument:

Jedyny argument, jaki do mnie przemawia, to to, że mamy armię frontendowców, którzy znają JS/TS i nie chcą startować od zera.

też możesz obalić: "przecież nie potrzebuję armii bo appkę robię sam"

Jeżeli brak dostępu do DOM Ci nie przeszkadza to musi to być jakaś specyficzna appka chyba? Podałbyś przykład? Jak będziesz robił UI?

Aplikacje desktopowe nie mają DOM, aplikacje mobilne nie mają DOM, dlaczego twoim @anonimowy zdaniem aplikacje webowe muszą go mieć?
Jakiś tam prosty przykład: https://trivia.potulski.eu/#quizzes

Nie jestem profesjonalnym programistą JavaScript ani Wasm, ale amatorsko, na własne potrzeby korzystam z tych technologii, co ciekawsze projekty wrzucam na Github.

Moje zdanie na temat JavaScript i WASM jest następujące: WebAssembly to jak najbardziej TAK, w języku C++ lub Rust. Co prawda, istnieją kompilatory do WASM do praktycznie każdego języka progrmowania, ale C++ i Rust to języki najbardziej "naturalne" do WASM i w tych językacj najprościej jest zainstalować i skonfigurować kompilację. Wykorzystanie WASM ma oczywiste zalety:

1. W C++ lub Rust mogę pisać kod, który może działać zarówno w aplikacji desktopowej/konsoloweg (głównie testy kompilacji i działania, niż aplikacja do użytku), wykorzystując do tego standardowe IDE, a potem dokładnie te same pliki źródłowe, po odpowiednim rozplanowaniu architektonicznym, można kompilować do WASM.
2. Wielokrotnie stwierdziłem, ze ten sam algorytm zdecydowanie łatwiej mi jest zaimplementować i przetestować w C++/Rust niż w JavaScript, szczególnie jakiś większy, złożony projekt. A i wydajność zadań obliczeniowych jest większa moim zdaniem, co też przemawia z WASM.
3. Gdy mam jakąś aplikację desktopową w Java lub w C# i chciałbym mieć taką samą, ale "przeglądarkową", to łatwiej i szybciej jest przerobić na C++ i WASM niż na JavaScript ze względu na podobieństwo języków i łatwiejsze testowanie/debugowanie.

A JavaScript wykorzystuję tylko do obsługi GUI, czyli w tym przypadku jest to HTML/DOM. Czyli logikę biznesowa w WASM, a interfejs i obsługa interfejsu w JavaScript. Zarówno skrypt JavaScript może uruchomić funkcję WASM, jak i funkcja WASM może wywołać skrypt JavaScript.

@piotrpo: Argumentacja na temat dostępu i manipulacji DOM, moim zdaniem jak najbardziej ma sens. W aplikacjach desktopowych, mobilnych i konsolowych nie ma DOM, ale w zamian za to mają odpowiednio formularze (czyli de facto okna, ale zazwyczaj nazywane domyślnie form1, form2), widoki/aktywności, strumienie standardowe. W przypadku aplikacji "przeglądarkowej" nie ma formularzy, ale jedyny "kontakt z użytkownikiem", a więc odczytanie lub wypisanie odbywa się właśnie poprzez DOM.

@piotrpo: Co do armii frondendowców, to jak zwykle trzeba powiedzieć "to zależy". Jeżeli skrypt miałby wykonać tylko jakieś proste przetworzenie i wysłanie żądania do serwera, to goły JavaScript jest jak najbardziej na miejscu. A jeżeli chciałbyś zaimplementować jakąś grę (choćby taką jak "snake", "tetris", "minesweeper"), to logikę biznesową lepiej napisać w WASM, a pobieranie z formularza i wyświetlanie planszy w JavaScript.

Pisząc program na własne potrzeby, w miarę możliwości rozdzielam kod przyjmując zasadę "a może mi się odwidzi i będę chciał mieć taki sam program z innym interfejsem", np. mam prorgam desktopowy w C++/QT, a teraz będe chciał mieć program przeglądarkowy. Już miałem taką sytuację, że aplikację C#/WinForms przerabiałem na C++/WASM. W JavaScript byłoby mi trudniej i więcej czasu by mi to zajęło.

A TypeScript? Jedynie wiem, że takie coś istnieje, ale nic "konkretnego" w tym nie tworzyłem. To miał być taki "lepszy JavaScript z typami". A skoto to i tak trzeba kompilować (przy czym owa kompilacja to tak naprawdę konwersja do JavaScript), to zdecydowanie wolę WASM, bo C++ znam dobrze, a Rust jeszcze nie znam, ale to dobry powód, żeby go poznać zamiast narzekać na niego i wymyślać argumenty "dlaczego nie Rust". Teraz to moim zdaniem, nie ma po co poznawać TypeScript, skoro do prostych rzeczy wystarczy JavaScript, a do skomplikowanych JavaScript+WASM.

piotrpo napisał(a):

Dostęp do drzewa DOM, nie jest mi potrzebny, bo piszę aplikację mającą działać w przeglądarce, a nie "zautomatyzowany dokument". Nie chcę mieć drzewa DOM, nie chcę się odwoływać do jakiegoś tam DIV'a, żeby wypełnić go treścią. Nie chcę tego wszystkiego kolorować CSS'em. Czyli w skrócie - nie potrzebuję dostęu do DOM, jeżeli go nie mam.

Czy aby na pewno? Może jeśli chciałbyś oprzeć w 100% swoją aplikację na canvasie to tak, ale jeśli chcesz mieć jakieś kontrolki porozmieszczane w przestrzeni (jak w GTK, QT, nie wiem czym jeszcze) to zawsze jest jakaś hierarchia tych obiektów i tu DOM, moim zdaniem jest wygodniejszy niż cokolwiek czego używałem (choć przyznaję, że nie było tego dużo). Może to kwestia przyzwyczajenia i tego, że nie muszę się uczyć niczego nowego, ale ten model myślena o interfejsie mi pasuje. Dodatkowo, możliwość użycia inspektora w przeglądarce to spore ułatwienie. Natomiast odkąd zacząłem się bawić Vue, to już w ogóle nie mam ochoty myśleć o robieniu innych frontendów.

andrzejlisek napisał(a):

Nie jestem profesjonalnym programistą JavaScript ani Wasm, ale amatorsko, na własne potrzeby korzystam z tych technologii, co ciekawsze projekty wrzucam na Github.

Moje zdanie na temat JavaScript i WASM jest następujące: WebAssembly to jak najbardziej TAK, w języku C++ lub Rust. Co prawda, istnieją kompilatory do WASM do praktycznie każdego języka progrmowania, ale C++ i Rust to języki najbardziej "naturalne" do WASM

Nie przesadzałbym z tą naturalnością. Z całym szacunkiem do C++, robienie w tym języku UI jest raczej stratą czasu, chyba, że mowa o jakimś mocno skomplikowanym obliczeniowo komponencie (np. mapa). Zwyczajnie biblioteki UI do tego języka są takie sobie.

1. Gdy mam jakąś aplikację desktopową w Java lub w C# i chciałbym mieć taką samą, ale "przeglądarkową", to łatwiej i szybciej jest przerobić na C++ i WASM niż na JavaScript ze względu na podobieństwo języków i łatwiejsze testowanie/debugowanie.

To oczywistość. Pytanie dlaczego robiąc aplikację przeglądarkową mam sięgać po JS'a?

@piotrpo: Argumentacja na temat dostępu i manipulacji DOM, moim zdaniem jak najbardziej ma sens. W aplikacjach desktopowych, mobilnych i konsolowych nie ma DOM, ale w zamian za to mają odpowiednio formularze (czyli de facto okna, ale zazwyczaj nazywane domyślnie form1, form2), widoki/aktywności, strumienie standardowe. W przypadku aplikacji "przeglądarkowej" nie ma formularzy, ale jedyny "kontakt z użytkownikiem", a więc odczytanie lub wypisanie odbywa się właśnie poprzez DOM.

To dlaczego nie użyć tych formularzy, okienek i komponentów wizualnych w przeglądarce?

@piotrpo: Co do armii frondendowców, to jak zwykle trzeba powiedzieć "to zależy". Jeżeli skrypt miałby wykonać tylko jakieś proste przetworzenie i wysłanie żądania do serwera, to goły JavaScript jest jak najbardziej na miejscu. A jeżeli chciałbyś zaimplementować jakąś grę (choćby taką jak "snake", "tetris", "minesweeper"), to logikę biznesową lepiej napisać w WASM, a pobieranie z formularza i wyświetlanie planszy w JavaScript.

Dlaczego mam wyświetlać cokolwiek używając JS'a? Co mi to daje? Uruchamiając jakiś projekt, dostępność ludzi na rynku, lub zasoby wiedzy w zespole są dość istotne.

A TypeScript? Jedynie wiem, że takie coś istnieje, ale nic "konkretnego" w tym nie tworzyłem. To miał być taki "lepszy JavaScript z typami".

TS to jedynie przyjemniejszy i mniej błędogenny język programowania.

elwis napisał(a):

Czy aby na pewno? Może jeśli chciałbyś oprzeć w 100% swoją aplikację na canvasie to tak, ale jeśli chcesz mieć jakieś kontrolki porozmieszczane w przestrzeni (jak w GTK, QT, nie wiem czym jeszcze) to zawsze jest jakaś hierarchia tych obiektów i tu DOM, moim zdaniem jest wygodniejszy niż cokolwiek czego używałem (choć przyznaję, że nie było tego dużo).

Na ekranie zwykle masz jakąś hierarchię obiektów. Okno aplikacji, jakiś kontener zarządzający rozmieszczeniem innych kontenerów, zarządzających rozmieszczeniem kontrolek w środku

Może to kwestia przyzwyczajenia i tego, że nie muszę się uczyć niczego nowego, ale ten model myślena o interfejsie mi pasuje. Dodatkowo, możliwość użycia inspektora w przeglądarce to spore ułatwienie. Natomiast odkąd zacząłem się bawić Vue, to już w ogóle nie mam ochoty myśleć o robieniu innych frontendów.

Ja rozumiem podejście, że "potrafię robić coś w X, więc nie będę się uczył Y, bo zanim osiągnę potrzebny poziom miną miesiące". W sumie podchodzę do tego w podobny sposób, tylko z innej strony. Mam sporo doświadczenia z aplikacjami mobilnymi (lata temu trzaskałem je taśmowo), mając wolną chwilę pobawiłem się Kotlin Compose, dla mnie całkiem wygodny framework. UI ma jakąś strukturę, powiedzmy, że DOM, ale nie jest to struktura obsługiwana przez przeglądarkę. Nie widzę w tym nic złego. Dlatego zastanawiam się jakie są argumenty przeciwko używaniu takiego podejścia. Oczywiście inne niż "nasi ojcowie i dziadowie robili inaczej".

Very hot

ktoś coś już klepał produkcyjnego w wasm? to że jest hot to jeszcze nie znaczy że manago będą to chcieć. Jakie jest ratio projektów WASM do TS/JS?

No i jak pisałem wcześniej w komentarzu: jako programista Javy to wolę już TS/JS niż C++ :P Może jakbym dostał Javę kompilowaną do WASM to by to rozwiązało problem, ale w przeszłości były już testowane rozwiązania jak Java kompilowana do JS i zawsze wychodziła

piotrpo napisał(a):

Dostęp do drzewa DOM, nie jest mi potrzebny, bo piszę aplikację mającą działać w przeglądarce, a nie "zautomatyzowany dokument". Nie chcę mieć drzewa DOM, nie chcę się odwoływać do jakiegoś tam DIV'a, żeby wypełnić go treścią. Nie chcę tego wszystkiego kolorować CSS'em. Czyli w skrócie - nie potrzebuję dostęu do DOM, jeżeli go nie mam.

To jak to ma cokolwiek wyświetlać? Brzmi trochę jak idealny język funkcyjny, którego cechą szczególną jest to, że jest bardzo pure i nic nie robi

Jedyny argument, jaki do mnie przemawia, to to, że mamy armię frontendowców, którzy znają JS/TS i nie chcą startować od zera.

Żyjemy w świecie, gdzie nawet interfejs w rakietach i desktopowych grach to JS. WASM musiałby być naprawdę game changerem, żeby całę community się nim zainteresowało. Teraz tak zdecydowanie nie jest

Nie przesadzałbym z tą naturalnością. Z całym szacunkiem do C++, robienie w tym języku UI jest raczej stratą czasu, chyba, że mowa o jakimś mocno skomplikowanym obliczeniowo komponencie (np. mapa). Zwyczajnie biblioteki UI do tego języka są takie sobie.

Nie UI w C++. Dla uproszczenia, tak powiedzmy, że chcesz napisać skrypt obliczajacy BMI. WASM do tego nie ma sensu, ale tak powiedzmy. Samo BMI to jest funkcja, która przyjmuje dwie liczby i podaje jedną liczbę. W swoim HTML wstawiasz dwa pola, pierwsze to "masa", drugie to "wzrost". Przycisk "Oblicz" uruchamiałby mniejwięcej taką funkcję (pisze z głowy, może mieć błędy, chodzi o pogląd).

function calcBMI()
{
  // Obsługa UI w JavaScript - pobranie danych
  const mass = int.parse(document.getElementById("massField").value);
  const height = int.parse(document.getElementById("heightField").value);
  if (mass <= 0) { alert("Podaj dodatnią masę"); return; }
  if (height <= 0) { alert("Podaj dodatni wzrost"); return; }

  // Wywołanie logiki obliczeniowej - wywołanie WASM
  const bmi = Module.ccall("calcBMI", "number", ["number", "number"], [mass, height]);

  // Obsluga UI w Javascript - wydanie wyniku
  document.getElementById("bmiField").value = bmi;
  document.getElementById("commentField").value = "w normie";
  if (bmi < 17) document.getElementById("commentField").value = "za mało";
  if (bmi > 30) document.getElementById("commentField").value = "za dużo";
}

Jak widać, w C++ implementuję samą logikę biznesową, a nie UI, który obsługuję w JavaScript. Przykład trywialny (zbyt trywialny, żeby w ogóle używać WASM), ale widać wyraźny "podział ról".

@KamilAdam Każda nowa technologia jest nowa. Ja wiem, że korporacyjny, smutny standard to Springboot + Angular, ale jest to smutny standard.
WASM to format bytecode'u, który nie ma wiele wspólnego z językiem programowania. W Java pewnie też się da, chociaż nie wiem po co, bo JavaFX nie jest technologią, która czyni ludzi szczęśliwymi. W przekonywaniu managerów mam pewne doświadczenie.

Patrzę na to, tak jak pisałem w pierwszym poście. HTML, CSS, JS to jakaś tam ewolucja i dostosowanie narzędzi stworzonych do prezentowania statycznych treści z lat dziewięćdziesiątych ubiegłego stulecia, do kompletnie nowych zadań. Coś co się sprawdzało w przypadku wyświetlenia sformatowanego tekstu z hyperlinkami + zaimplementowania jakiejś prostej dynamiki, nie koniecznie jest optymalnym zestawem narzędzi do tworzenia aplikacji w których dużo się dzieje po stronie klienta.

@slsy

To jak to ma cokolwiek wyświetlać?

Normalnie, wstawiasz html z pojedynczy, elementem, w którym wyświetlany jest canvas. To co jest w nim wyświetlane nie dotyka już w żaden sposób HTML'a:

<div id="compose-target"></div>

Brzmi trochę jak idealny język funkcyjny, którego cechą szczególną jest to, że jest bardzo pure i nic nie robi

Tutaj masz pełną dowolność. Możesz naparzać kod, możesz sobie zdefiniować własny język opisu, możesz umieścić własną przeglądarkę i w niej wyświetlić co ci się tam podoba (chociaż nie wiem po co), Podobnie jak zwykła desktopowa aplikacja.
Ja akurat użyłem "dziwnego funkcyjnego języka, który jest w 100% pure i nic nie robi", ale to mój wybór wynikający z posiadanych umiejętności. https://kotlinlang.org/docs/multiplatform/get-started.html

@Composable
@Preview
fun App() {
    MaterialTheme {
        var showContent by remember { mutableStateOf(false) }
        Column(
            modifier = Modifier
                .background(MaterialTheme.colorScheme.primaryContainer)
                .safeContentPadding()
                .fillMaxSize(),
            horizontalAlignment = Alignment.CenterHorizontally,
        ) {
            Button(onClick = { showContent = !showContent }) {
                Text("Click me!")
            }
            AnimatedVisibility(showContent) {
                val greeting = remember { Greeting().greet() }
                Column(
                    modifier = Modifier.fillMaxWidth(),
                    horizontalAlignment = Alignment.CenterHorizontally,
                ) {
                    Image(painterResource(Res.drawable.compose_multiplatform), null)
                    Text("Compose: $greeting")
                }
            }
        }
    }
}

Szukałem po prostu czegoś, co od strzału da mi możliwość tworzenia w wygodny sposób aplikacji desktopowych, mobilnych i przeglądarkowych., żeby nie poświęcić za dużo czasu na naukę, a zyskać możliwość zrobienia czegokolwiek. Znam Kotlin, mam spore doświadczenie z Androidem i tak wyszło naturalnie.

Oczywiście możliwe jest również użycie tego w sposób opisany przez @andrzejlisek i np. wstawienie i uruchomienie lokalnie jakiejś "logiki", np. piszesz sobie w C++ program, do którego przekazujesz kawałek muzyki, robisz FFT i zwracasz rytm, czy wrzucasz tam jakąś prostą sieć neuronową odpalaną lokalnie.

W Java pewnie też się da, chociaż nie wiem po co, bo JavaFX nie jest technologią, która czyni ludzi szczęśliwymi

Klepanie frontendu w C++ czyli ludzi bardziej szcześliwym niż klepanie frontendu w Javie? wciąż nie widzę zalet

BTW najlepszą technologią frontendową jest frontendowiec który wyklepie front za mnie

Zresztą do klepania frontendu w Javie nie była używana JavaFX tylko GWT. można sobie pewnie wygooglać jak GWT roztrzaskało się mimo że stał za tym dział google

piotrpo napisał(a):

Normalnie, wstawiasz html z pojedynczy, elementem, w którym wyświetlany jest canvas. To co jest w nim wyświetlane nie dotyka już w żaden sposób HTML'a:

Kopiuj

<div id="compose-target"></div>

Rozumiem, wydawało mi się to niekoszerne dlatego o tym nie pomyślałem

O ile dobrze wiem to flutter wspiera właśnie takie podejście tj. rysowanie całego UI jest po stronie fluttera https://docs.flutter.dev/platform-integration/web/renderers

Jeszcze jest kwestia kompatybilności - bo o ile JS/CSS działa obecnie praktycznie na wszystkim - z komórkami włącznie, nie jestem przekonany, czy WASM pójdzie wszędzie bez zajęknięć. Wiadomo - na Win11 z najnowszą przeglądarką to się odpali, ale co z 4-letnią komórką na Androidzie, która od 3 lat nie ma aktualizacji i jest 3 wersje Andka do tyłu? Albo jakiś Ajfon parę generacji wstecz (chociaż Apple wszystko robi po swojemu, więc bym się nie zdziwił, jakby się okazało, że w ogóle nie obsługują takich wynalazków).

Do tego kwestie, które akurat mi latają koło ogórka, ale niektórzy na to zwracają uwagę (a w niektórych stronach - np. urzędowych/państwowych, to jest nawet wymagane) - czyli dostępność: jakieś tryby wysokiego kontrastu, jakieś czytniki ekranowe i inne ułatwienia.

Co z zapisaniem strony - czy można normalnie (jak typowego HTML) sobie zapisać to lokalnie na dysku u siebie? Będzie to działać?

cerrato napisał(a):

Jeszcze jest kwestia kompatybilności - bo o ile JS/CSS działa obecnie praktycznie na wszystkim - z komórkami włącznie, nie jestem przekonany, czy WASM pójdzie wszędzie bez zajęknięć. Wiadomo - na Win11 z najnowszą przeglądarką to się odpali, ale co z 4-letnią komórką na Androidzie, która od 3 lat nie ma aktualizacji i jest 3 wersje Andka do tyłu? Albo jakiś Ajfon parę generacji wstecz (chociaż Apple wszystko robi po swojemu, więc bym się nie zdziwił, jakby się okazało, że w ogóle nie obsługują takich wynalazków).

a nawet jak jest update to czy stare przeglądarki urządzenia CanvasKit (WebGL)? Potem użytkownicy chodzą wnerwieni jak mój ojciec (jak jeszcze gadaliśmy) ze sobą:

• 5 lat temu bez problemy mogłem sprawdzić stronę banku z tego kompa? a teraz nie mogę. weź to napraw
• ale dodali tyle JSa na stronę że komp tego nie umie dzwingąć
• nie obchodzi mnie to, napraw mi komputer

Do tego kwestie, które akurat mi latają koło ogórka, ale niektórzy na to zwracają uwagę (a w niektórych stronach - np. urzędowych/państwowych, to jest nawet wymagane) - czyli dostępność: jakieś tryby wysokiego kontrastu, jakieś czytniki ekranowe i inne ułatwienia.

A nawet mi nie mów. Hindusi wyklepali apkę którą miano sprzedać na zachód europy ale się okazało że w europie mają jednego ślepego pracownika a reader nie ogarnia apki i cała poszła do przeorania żeby ją dostosować do readera. Czy wasm da radę z readerem? Można w tym robić wewnętrze apki, ale apkę którą mogą używać niewidomi?

@KamilAdam Nie bardzo rozumiem twoją argumentację. WASM nie jest językiem programowania, nie jest rozwiązaniem promowanym przez pojedynczą firmę, Zacytuję ich oficjalną stronę:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

https://webassembly.org/

Czyli to rozwiązanie na tym samym poziomie do windowsowe portable executable (.exe).

Tak GWT się roztrzaskało. Co to ma do rzeczy? W tej chwili WASM jest wspierany przez wszystkie ważniejsze przeglądarki (Chrome, Firefox, Edge, Safari) i pewnie jeszcze sporo takich, które chodzą na tych samych silnikach. Mając w pamięci ile czasu zajęło im dogadanie się w sprawach takich jak formaty obrazków, nie sądzę, żeby nagle podjęli wspólną decyzję "walić to". Oczywiście nie dotyczy to wybranego przez programistę języka, frameworku itd., ale to oznacza jedynie tyle, że w którymś momencie przestanie się rozwijać.

BTW najlepszą technologią frontendową jest frontendowiec który wyklepie front za mnie

No daj pan spokój. Z takim podejściem, to można skończyć jako Scrum Master

@cerrato

Albo jakiś Ajfon parę generacji wstecz (chociaż Apple wszystko robi po swojemu, więc bym się nie zdziwił, jakby się okazało, że w ogóle nie obsługują takich wynalazków).

Obsługuje. Nie weim czy taki 4 generacje wstecz, ale za 4 lata dzisiejszy top będzie 4 generacje wstecz. Na Androidzie sprawdzałem, w przeglądarkach sprawdzałem. Zresztą kompatybilność przeglądarek nie jest już takim problemem jak kiedyś (autoupdate).

Co z zapisaniem strony - czy można normalnie (jak typowego HTML) sobie zapisać to lokalnie na dysku u siebie? Będzie to działać?

Strona to nadal "zwykły HTML", ze "zwykłym js'em". Zapisać możesz, ale treści nie zobaczysz. Tylko takiego FB też sobie na dysku nie zapiszesz.

Pierwsze co przychodzi mi do głowy słysząć WASM to success story przeportowania aplikacji photoshop na przeglądarkę. Goście z adobe staneli przed nie lada wyzwaniem bo mieli sporo legacy kodu napisanego w c++. Napisanie od nowa wersji na przeglądarki w js musiałoby być bardzo kosztowną katorgą. W tym widzę głównę zastosowanie WASM. https://www.reddit.com/r/WebAssembly/comments/1ax359g/most_impressive_apps_ported_to_web_browsers_using/

Rozwiązania jak blazor wydaje mi się że próbują podbić rynek frontendowy w którym już istnieją dobre frameworki js.

Wiktor Nocoń napisał(a):

Pierwsze co przychodzi mi do głowy słysząć WASM to success story przeportowania aplikacji photoshop na przeglądarkę. Goście z adobe staneli przed nie lada wyzwaniem bo mieli sporo legacy kodu napisanego w c++. Napisanie od nowa wersji na przeglądarki w js musiałoby być bardzo kosztowną katorgą. W tym widzę głównę zastosowanie WASM. https://www.reddit.com/r/WebAssembly/comments/1ax359g/most_impressive_apps_ported_to_web_browsers_using/

(...)

a to nie jest tak, że gui przeglądarkowego photoshopa zrobili od nowa i te photoshopy (webowy i desktopowy) mają ze sobą tyle wspólnego co np. rider ma z resharperem?

https://medium.com/@addyosmani/photoshop-is-now-on-the-web-38d70954365a

UI Flexibility with Web Components

Photoshop is part of Adobe’s broader Creative Cloud ecosystem. Using a standardized Web Components strategy built on Lit allows UI consistency across applications.

Photoshop’s UI elements come from Adobe’s Spectrum Web Components library, which implements Adobe’s design system.

Spectrum Web Components are:
Accessible by default — Developed with existing and emerging browser specs in mind to support assistive technologies.
Lightweight — Implemented with LitElement for minimal overhead.
Standards based — Built on Web Component standards like custom elements and Shadow DOM.
Framework agnostic — Work with any framework thanks to browser-level support.
Furthermore, the entire Photoshop app is built using Lit-based Web Components. Lit’s templating and virtual DOM diffing allow efficient UI updates. Web Components encapsulation also made it easy to integrate React code from other teams when needed.

Overall, Web Components’ browser-native custom elements, combined with Lit’s performance, provided the flexibility Adobe needed to build Photoshop’s complex UI while maintaining efficiency.

sprawdziłem stronę https://photoshop.adobe.com/ i tam jest pełnoprawne drzewo dom. można sobie otworzyć narzędzia deweloperskie i przejrzeć to drzewo dom. jest element w htmlowym drzewie dom dla każdego elementu z gui photoshopa. w dodatku framework https://github.com/lit/lit/ który służy do generowania drzewa dom dla gui przeglądarkowego photoshopa jest napisany w js+ts.

piotrpo napisał(a):

Zastanawiam się, czy obecnie jest jeszcze sens używać do aplikacji webowych JS'a, włączając w to jakieś pudrowane TypeScript'y?

podstawowy powód to taki, że te pudrowane typescripty to sprawdzona w boju technologia. możesz się od tego odciąć i zostać betatesterem czegoś niszowego.

Patrząc z mojego punktu widzenia, JS wydaje się być kompletnym dinozaurem. Większa objętość, niższy performance, przeznaczony do działania na DOM. Czy istnieją jakieś powody, dla których warto dzisiaj używać frameworków takich jak React/Angular, skoro mam wybór w postaci WASM?

po minifikacji i gzipowaniu objętościowo pewnie nie ma kosmicznej różnicy i to pod warunkiem, że wasmowa platforma jest przystosowana do generowania małych plików. taki blazor na przykład generuje ociężałe kobyły, które nie dość, że generują większe pliki wasm od typowego javascriptu, to jeszcze wolniej działają wolniej i zużywają więcej ramu. dużo zależy od tego co jest dostępne i co działa.

weźmy na tapet fluttera https://docs.flutter.dev/platform-integration/web/wasm#learn-more-about-browser-compatibility :

Learn more about browser compatibility

To run a Flutter app that has been compiled to Wasm, you need a browser that supports WasmGC.

Chromium and V8 support WasmGC since version 119. Chrome on iOS uses WebKit, which doesn't yet support WasmGC. Firefox announced stable support for WasmGC in Firefox 120, but currently doesn't work due to a known limitation (see details below).

Why not Firefox? Firefox versions 120 and later were previously able to run Flutter/Wasm, but they're experiencing a bug that is blocking compatibility with Flutter's Wasm renderer. Follow this bug for details.
Why not Safari? Safari now supports WasmGC, but is experiencing a similar bug that is blocking compatibility with Flutter's Wasm renderer. Follow this bug for details.

Warning
Flutter compiled to Wasm can't run on the iOS version of any browser. All browsers on iOS are required to use WebKit, and can't use their own browser engine.

jakie są w ogóle dobrze działające opcje do tworzenia gui w wasmie z pominięciem drzewa dom?

(...)
Dostęp do drzewa DOM, nie jest mi potrzebny, bo piszę aplikację mającą działać w przeglądarce, a nie "zautomatyzowany dokument". Nie chcę mieć drzewa DOM, nie chcę się odwoływać do jakiegoś tam DIV'a, żeby wypełnić go treścią. Nie chcę tego wszystkiego kolorować CSS'em. Czyli w skrócie - nie potrzebuję dostęu do DOM, jeżeli go nie mam.
(...)

jest jakaś fundamentalna różnica między drzewem dom, a drzewem komponentów w typowych toolkitach do gui, albo całościowo między html5, a niewebowymi toolkitami? jedyne co mi przychodzi to renderowanie pixel-perfect niezależnie od platformy. html renderuje się różnie w zależności, np od sposobu renderowania czcionek w systemie.

jeśli bardzo chcesz to możesz tworzyć własne znaczniki zgodnie ze standardem html: https://html.spec.whatwg.org/multipage/custom-elements.html

po minifikacji i gzipowaniu objętościowo pewnie nie ma kosmicznej różnicy i to pod warunkiem, że wasmowa platforma jest przystosowana do generowania małych plików

Z tego co czytałem dawno temu to główne zalety to szybkość całego procesu a niekoniecznie małe pliki. Taki WASM ma tą zaletę, że:

• jest prostszy a i więc więcej możliwości na szybszy parser. Z tego samego powodu parsery JSONa mogą osiągać GB/s a XML to :/
• poszczególne funkcje są od siebie odseparowane i możesz je parsować/przerabiać na struktury w silniku/optymalizować równolegle do pobierania. W JS generalnie jesteś zmuszony do leniwej kompilacji bo tak czy owak musisz najpierw sparsować całość, bo nie wiesz jak kod pod koniec twojego 500MB pliku JS wpływa na to co się dzieje na początku 
• prostszy i typowany kod pozwala na zaaplikowanej większej liczby optymalizacji w czasie budowania
• odpada process parsowania JS do bytecodu, bo już jest to zrobione

@slsy: ogólnie się zgadza, tzn. wasm szybciej się parsuje i ma solidniejsze optymalizacje. jednak op chce się pozbyć konieczności używania drzewa dom, a wtedy odpadają techniki typu https://en.wikipedia.org/wiki/Hydration_(web_development) która to sprawia, że strona ładuje się od razu, zanim jeszcze kod jsowy zostanie sparsowany.

Niedługo będzie dekada od wprowadzenia WASMa, nawet do świata C# jako Blazor :D

Generalnie nie śledziłem tego tematu od lat, jedynie kiedyś używałem WASMa jako backend do zabaw z językami programowania, więc prosze z przymrużeniem oka:

Czy po tylu latach WASM zwojował ekosystem webowy?

Wydaje mi się że nie, i po części obstawiałbym że wynika to z tego, że ogromna większość webówki nie potrzebuje współpracować z codebasem pisanym w innym języku.

Czy to oznacza że WASM to porażka?
Moim zdaniem nie - jest to wymagany krok do tego, aby odciąć webówkę od bycia wyłącznie w JSie i jego derywatywaych.

Pojawił się ciekawy "usecase" WASMa: stworzono runtime/VMkę operującą na WASMie, która miałaby nam dać tą pełną crossplatformowość - różne OSy + przeglądarki, czyli prawie wszystkie duże ekosystemy gdzie możliwe jest odpalanie jakiegoś kodu. Do tego jakaś tam konteneryzacja tego.

Z drugiej strony development WASMa nie wygląda na zbyt... idący do przodu, a przynajmniej szybko.

DOM access jest czymś, o co ludzie dopominali się wiele lat temu.

Już chciałem wymieniać GC jako kolejną rzecz która nie została dowieziona przez wiele lat, ale googlnąłem i coś tam chyba ruszyło
https://developer.chrome.com/blog/wasmgc
https://webassembly.org/features/

Generalnie podchodziłbym do WASMa w ten sposób, że jeżeli jest jakiś nie-JSowy kod i nie chcemy go przepisywać na JS lub potrzebujemy wydajności,
to wtedy można spróbować użyć WASMa do wykonywania obliczeń, a później JSa do zaprezentowania ich.

do samodzielnych apek potrzeba czegoś więcej niż samego wasma. wasi https://en.wikipedia.org/wiki/WebAssembly#WASI jest nadal w powijakach.

DOM access jest czymś, o co ludzie dopominali się wiele lat temu.

blazor działa i bez tego, więc da się wykombinować obejścia

Już chciałem wymieniać tutaj GC, ale wygooglałem i to podobno poszło do przodu
https://developer.chrome.com/blog/wasmgc

czy blazor ma w planach przeniesienie się na to? ztcw to nadal używa swojej implementacji gc.

hmm, poszukałem i raczej nie.
https://github.com/WebAssembly/gc/issues/77
https://github.com/dotnet/runtime/issues/94420

Current status
In order for .NET to make use of the v1 GC proposal we would need to significantly alter the semantics of existing .NET code or limit the use of certain features including refs, Span<T>, [DllImport] both in user code and in the C# base class library, including in the implementation of System.Private.CoreLib. Moderating the use of ref and Span<T> would be contrary to the past several years’ efforts in the .NET runtime to increase the use of stack allocated values and avoid heap allocations in performance-sensitive code. While there are some benefits to utilizing the WasmGC proposal as outlined in https://v8.dev/blog/wasm-gc-porting, the v1 WasmGC semantics do not match .NET requirements.

We will continue to monitor the evolution of the post-v1 WasmGC spec, but at this time we are not planning to adopt it.