Parę lat temu głośno było o WebAssembly, języku (?) binarnym dla Internetu który otworzył drzwi dla języków innych niż JavaScript w kontekście wykonywaniu kodu w przeglądarkach. Jako że nieszczególnie przepadam za JS, obudziło to we mnie nadzieję, że być może niedługo nie będę już na ten język skazany przy budowaniu aplikacji webowych. Nie interesowałem się tematem kilka lat, stąd moja prośba do was o opinię: czy według was taka sytuacja jest prawdopodobna w najbliższej przyszłości? Jakie są obecnie trendy w tym temacie?
1
2
Już dość długo w użyciu jest blazor (C#) i staje się coraz bardziej popularny. Ma dobre wsparcie i dzięki hot reload w VS 2022 dokonanie zmiany na stronie to przyjemność. Można też użyć rusta i chyba C++ ale wsparcie jest chyba mniejsze
Przykładowa aplikacja w blazorze: http://blazor-realworld.azurewebsites.net/
Dla wewnątrz firmowych apek już teraz WebAssembly jest wykorzystywane i trend będzie raczej rosnący. Dla ogólnodostępnych to jak widzisz - apka zajmuje ponad 3 megabajty (prawie tyle co aplikacja napisana w angularze) i pierwsze załadowanie trwa dość długo więc nadal średnio się nadaje do ogólnego zastosowania
4
Blazor WebAssembly ma dwa tryby: interpretowany (do niedawna jedyna opcja) i AOT (chyba dalej nie jest domyślną opcją).
https://www.telerik.com/blogs/whats-new-dotnet-6-blazor
Ahead of Time Compilation (Blazor Wasm)
Blazor WebAssembly now supports ahead-of-time (AOT) compilation, but before you dash off to enable it for all your projects, it’s worth just pausing to consider what it actually means for your application.
AOT directly compiles your .NET code to WebAssembly as part of the compilation process.
This is different from the standard way your Blazor Wasm apps run today, where your code is never compiled to WebAssembly, instead running on a .NET IL interpreter (which is itself implemented in WebAssembly).
This use of an interpreter means, in practice, your standard Blazor Wasm app will perform more slowly than it would on a normal .NET runtime (for example an MVC or Razor Pages app running on a server).
AOT addresses this performance issue by compiling your code to WebAssembly. For CPU-intensive tasks the performance improvement is significant (up to 5 times faster), but AOT compilation brings its own tradeoffs.
It requires an additional build tool to be installed, the actual compilation itself is quite slow (as of Preview 7) and AOT-compiled apps are larger (about 2x larger on average).
To use AOT you’ll need to install the latest .NET WebAssembly tools (watch out, the name of these tools changed between Preview 4 and Preview 7 of .NET 6. The new name is shown below).
dotnet workload install wasm-toolsThe main tradeoff is that you’ll sacrifice load time for runtime performance, so the decision as to whether this makes sense will vary depending on the specific app you’re building.
https://blog.elmah.io/ahead-of-time-compilation-for-blazor-wasm/
Ahead-Of-Time Compilation for Blazor Wasm
Blazor Wasm applications are being interpreted in the browser by default. The idea behind Wasm is to be able to compile any language to Wasm and in this way have a common platform that all code can be run on. Instead of doing this directly Blazor Wasm first bootstrapped this approach by making an IL interpreter in Wasm and with this made it possible to run .NET code compiled to IL instructions in the browser. In this article, we will look at how you can compile your code directly to Wasm Ahead-Of-Time (AOT) and what pros and cons this brings.
(...)
Compiling AOT
Now we are ready to do the AOT compilation. For this, we simply do a normal Release publish.
dotnet publish -c ReleaseIt took 4 minutes and 42 seconds to compile this template project with AOT. The total published folder is 30.4 MB and on the first load, the page is 8.1 MB.
Compared to a normal publish that takes 11 seconds to compile. Has a published folder size of 25.7 MB and has a load size of 3.3 MB
The most notable difference is that it takes a lot more time to compile the different assemblies and that the compiled assemblies are bigger than the IL code. And for this example, there aren't really any pros. For us to gain something from doing AOT compilation we will have to use some computation heavy work in our application. AOT compilation can potentially make tasks written in C# faster than the same tasks written in JavaScript.
Wydajność i zużycie zasobów nie są mocną stroną Blazora.
https://github.com/krausest/js-framework-benchmark
https://krausest.github.io/js-framework-benchmark/index.html
https://krausest.github.io/js-framework-benchmark/2021/table_chrome_95.0.4638.54.html
blazor-wasm-v5.0.100-rc.2.20479.15 jest drugi od końca jeśli chodzi o wydajność, dużo waży, dużo zabiera pamięci.
1
Oprócz wymienionych wyżej opcji jest też TypeScript, który naprawia większość błędów JSa.
3
TypeScript to raczej taki "ulepszony" JS, ale nie powiedziałbym, żeby naprawiał większość jego błędów. Żadna rewolucja, tylko ewolucja.
Z drugiej strony ludzie nie chcą rewolucji. TypeScript się przyjął dlatego właśnie, że to stary dobry JavaScript (coś, co frontendowcy już znają) + adnotacje dla typów. Jakoś inne silnie typowane języki się nie przyjęły we frontendzie.
C# ma spore grono fanów, ale przecież nie wszyscy znają C#. Co jeśli ktoś zrobi w przyszłości coś jak Blazor, tylko do Pythona? Albo do PHPa? I wyjdzie na to, że każdy będzie pisać frontend w czym mu się podoba? Może będzie ileś obozów.
Swoją drogą jak jest w JVM? Bo tam też jest Java i Scala i Kotlin i Clojure itp. Czy nie spowodowało to, że ekosystem się podzielił przez to? Czy może dalej jest to jeden wielki ekosystem JVM i sobie piszesz np. w Kotlinie używając libek pisanych w Scali? Ktoś wie, jak to tam wygląda?
3
Czy może dalej jest to jeden wielki ekosystem JVM i sobie piszesz np. w Kotlinie używając libek pisanych w Scali? Ktoś wie, jak to tam wygląda?
Różnie.
W Scali i w Kotlinie, Clojure korzysta się z bibliotek zrobionych dla javy - bez problemu.
Zarówno w Scali jak i Kotlinie można robić biblioteki, z których będzie się "wygodnie" korzystało w javie i innych językach na jvm (z tym, że w Kotlinie jest to proste|naturalne, a w Scali wymaga stałego pamiętania o javie na etapie projektowania, albo robi się wrappery).
I w Scali i w Kotlinie są biblioteki przeznaczone wyłącznie dla tych języków (gdzie wykorzystanie w czymś innym będzie trudne, albo i zupełnie bez sensu).
Scala ma relatywnie duży ten "własny" ekosystem bibliotek i narzędzi.
Jakby jvm było planetą Zemeja- to java to by była Azja, kotlin to półwysep w Azji - czyli Europa, clojure i scala to jak Ameryki, a groovy to Afryka :-)
2
C# ma spore grono fanów, ale przecież nie wszyscy znają C#. Co jeśli ktoś zrobi w przyszłości coś jak Blazor, tylko do Pythona? Albo do PHPa? I wyjdzie na to, że każdy będzie pisać frontend w czym mu się podoba? Może będzie ileś obozów.
Przecież taki jest cel WebAssembly.
Jak sama dokumentacja mówi
WebAssembly is a new type of code that can be run in modern web browsers and provides new features and major gains in performance. It is not primarily intended to be written by hand, rather it is designed to be an effective compilation target for source languages like C, C++, Rust, etc.
Co po prostu oznacza - idźcie klepcie swoje języki, a tu macie jeden standard, który macie generować. Zamiast robić XLanguage_2_Javascript, to zamiast tego jsa jest WASM, który ma być bardziej sane.
Blazor to m.in, w ogromnym uproszczeniu wsparcie/framework do obsługi WebAssembly w .NET. Chociaż na ten moment tu jest jeszcze tak, że wykorzystywane jest Mono, więc w praktyce sprawa się komplikuje, ale ogólnie koncept jest prosty.
7
Z tego co mi się wydaje1 za daleko zabrnęliśmy i ugrzęźliśmy w całym tym koślawym, ułomnym ekosystemie na amen. Już pięć lat temu2 front był programistycznym piekłem dla masochistów, a niewiele, o ile cokolwiek, zmieniło się od tego czasu - dalej mamy mamy sezonowe frameworki, is-odd ściągające is-even, Adama narzekającego na mikroblogu na przerośnięte buildy3, a jakieś dwa tygodnie temu wybuchła kolejna afera w związku z dziurami bezpieczeństwa NPM4. Czyste szaleństwo. I to raczej zostaje, bo zbyt dużo dolarów w to wpakowano i zbyt dużo ludzi biegnie wprost do tego bagna, by się z nim zabuksować na amen. Nawet Google nie podołał z wygryzieniem JS-a ze swoim Dartem. Próbuje się zatem łatać dziury, zabawkami pokroju TypeScripta, która to proteza, choć jak się zdaje pomaga, również wydaje się nie satysfakcjonować użytkowników. A cuda pokroju WebAssembly są i raczej zostaną małą niszą dla garstki zapaleńców, bo któż będzie się uczył specjalnie Rusta (o C++ nie wspominam) by robić front, gdy może nabazgrać na kolanie kilka szybkich, gołych skryptów? Tak, że JavaScript raczej nie przestanie nas przysparzać o nerwice natręctw i ból zatok na długie, długie lata. Ale to opinia z boku, mi jest dobrze z daleka od frontu i całego tego nonsensu5.
1 frontem nie jestem i trzymam się od niego z daleka dla zdrowia i higieny psychicznej
2 https://medium.com/hackernoon/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.758uh588b
3 Jestem w projekcie, gdzie Ja...
4 W świecie JS jak zwykle grub...
5 już pomijając nawet patologię technologiczną, na froncie siłą rzeczy człowiek musi częściej użerać się z designerami i product ownerami, co rownież jest wielce szkodliwe i kancerogenne
0
A cuda pokroju WebAssembly są i raczej zostaną małą niszą dla garstki zapaleńców, bo któż będzie się uczył specjalnie Rusta (o C++ nie wspominam) by robić front,
wtf?
A co gdyby z kodu Reacta generować WASM? nikt nie broni
1
WeiXiao napisał(a):
A cuda pokroju WebAssembly są i raczej zostaną małą niszą dla garstki zapaleńców, bo któż będzie się uczył specjalnie Rusta (o C++ nie wspominam) by robić front,
wtf?
A co gdyby z kodu Reacta generować WASM? nikt nie broni
No to ujmując inaczej co miałem na myśli: "programowanie w normalnych językach i kompilowanie do WebAssembly będzie niszą dla garstki zapaleńców". Bo jak kompilujesz z Reacta to chyba jak się zdaje dalej się użerasz z tym całym JS-em i NaNNaNNaNNaNNaNNaNNaN Batman!. Ale jak pisałem, nie moje podwórko.
0
WASM jest też np. generowany z Kotlina:
2
Bez szans. Praktycznie każdy popularny język kompiluje się do JS, i to nie jest nic nowego, takie rozwiązania są od lat i był czas, żeby taki sposób pisania aplikacji frontendowych się spopularyzował. A jak widać, większość dalej klepie w JS. WASM zmienia tu tylko tyle, że da się sensownie skompilować języki, które mają dość niskopoziomowy dostęp do pamięci, takie jak C++. Ale, surprise, surprise, nikt nie chce pisać frontu w C++!
Jedyne co się przyjęło to TypeScript, bo to dalej JS, tylko lepszy. A powodów, żeby pisać w czymś innym niż JS/TS jest coraz mniej, więc jeśli do tej pory nic go nie zepchnęło to już w najbliższej przyszłości się to nie zmieni. Przynajmniej tak długo, jak będziemy korzystać z webu.
2
@szatkus
Ale, surprise, surprise, nikt nie chce pisać frontu w C++!
w C++ może nie, bo to ogólnie raczej mało frontowa społeczność, ale w C# czy Javie?
Nawet są oferty pracy w C# z Blazor, a i tak jest to relatywnie świeża technologia.
5
Rzeczy, które 20 lat temu robiłem w Pascalu czy Delphi nadal potrafią być "wyzwaniem" w JavaScript. WebAssembler wydaje się być rozwiązaniem ale jeszcze dużo mu brakuje by zadowolić wszystkich. Sam WebAssembler jednak nie rozwiązuje wszystkich bolączek wynikających z dzisiejszych potrzeb.
Z jednej strony JavaScript to "Muł" z drugiej z WebAssembly zapełnia jedynie lukę wydajności i nie zintegrujesz nic tak łatwo jak z JavaScript.
Kiedyś mówili, że Java to muł dziś okazuje się, że to nie jest największy problem.
Uważam, że JavaScript ma zagwarantowaną silną pozycję na następne 15 lat. WebAssembly to super sprawa, która osobiście mnie bardzo cieszy ale to jedynie "łata" na bieżące bolączki. Choć możliwości ma nieograniczone to wątpię, że powstanie w WebAsm jakiś system okien na miarę Swing czy VCL... DOM jest tak popularny, że budowanie nowej alternatywy trochę mija się z celem...
Co do TypeScript... to wg mnie taki przejściowy język, który zniknie na rzecz JavaScript nowszych generacji,. Dla mnie nie warto marnować na niego czasu.
Wszystkie technologie, które były "łatami" czegoś popularniejszego prędzej czy później trafiają na śmietnik choć sam WebAsm jest nieco inną łatą i ma szanse przetrwać.
1
Prawda jest taka że przez długi jeszcze czas nie zostanie zastąpiony. Trzeba cofnąć pamięcią wstecz i przypomnieć sobie ile było technologii, które miały wygryźć JS i teraz albo nie istnieją albo są tak niszowe że nikt o nich nie pamięta. O Webassembly też od wielu lat trąbią i jakoś nie wiedzę, żeby wypierał JS'a z rynku. Wręcz w JS jest coraz więcej pracy. Myślę też że za dużo jest zwolenników JS żeby od tak został czymś innym zastąpiony.
3
WeiXiao napisał(a):
@szatkus
Ale, surprise, surprise, nikt nie chce pisać frontu w C++!
w C++ może nie, bo to ogólnie raczej mało frontowa społeczność, ale w C# czy Javie?
Nawet są oferty pracy w C# z
Blazor, a i tak jest to relatywnie świeża technologia.
Przypominam, że dawno temu swoje 5 minut miał GWT https://en.wikipedia.org/wiki/Google_Web_Toolkit w którym frontend pisało się w Javie.
katakrowa napisał(a):
Z jednej strony JavaScript to "Muł" z drugiej z WebAssembly zapełnia jedynie lukę wydajności i nie zintegrujesz nic tak łatwo jak z JavaScript.
Co to znaczy "Muł"? Nawet w koślawym benchmarks game zwykły JS jest zaledwie jakieś 4x wolniejszy niż super zoptymalizowany, nieczytelny i zagmatwany kod w C++: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gpp.html Weź jeszcze pod uwagę, że to są zwykle algorytmy totalnie nieobiektowe i totalnie zorientowane na mielenie danych o niskim czasie dostępu, tzn. opóźnienia ładowania danych są zminimalizowane. W typowym kodzie JSowym jest dużo tzw. pointer chasing i tego typu spowalniaczy i tam różnice będą jeszcze mniejsze.
To już wybór frameworka czy biblioteki do renderowania UI ma dużo większe znaczenie. Już podałem benchmarki wcześniej:
https://github.com/krausest/js-framework-benchmark
https://krausest.github.io/js-framework-benchmark/index.html
https://krausest.github.io/js-framework-benchmark/2021/table_chrome_95.0.4638.54.html
Zajrzyj w nie i zobaczysz, że:
- różnice w wydajności między frameworkami/ bibliotekami JSowymi są czasami bardzo duże
- rozwiązanie oparte o Rusta kompilowanego do WebAssembly (wasm-bindgen) jest ciut wolniejsze od VanillaJS (z powodu narzutu na serializację danych)
- rozwiązanie oparte o Blazora kompilowanego do WebAssembly jest prawie najwolniejsze (to dlatego, że do WebAssembly kompilowany jest nie kod użytkownika Blazora, a interpreter tego kodu)
Tutaj masz Quake skompilowane do JSa jeśli chcesz się pobawić tym: http://www.quakejs.com/
Uważam, że JavaScript ma zagwarantowaną silną pozycję na następne 15 lat. WebAssembly to super sprawa, która osobiście mnie bardzo cieszy ale to jedynie "łata" na bieżące bolączki. Choć możliwości ma nieograniczone to wątpię, że powstanie w WebAsm jakiś system okien na miarę Swing czy VCL... DOM jest tak popularny, że budowanie nowej alternatywy trochę mija się z celem...
Wspomniany GWT jest, o ile dobrze pamiętam (a pamiętam tylko skrawki artykułów), wzorowany na javowym Swingu. To miało przyciągnąć programistów Javy i pewnie przyciągnęło. Ostatecznie GWT i tak upadło. Teraz mamy Blazora od Microsoftu, czyli taka powtórka z rozrywki.
Co do TypeScript... to wg mnie taki przejściowy język, który zniknie na rzecz JavaScript nowszych generacji,. Dla mnie nie warto marnować na niego czasu.
Wszystkie technologie, które były "łatami" czegoś popularniejszego prędzej czy później trafiają na śmietnik choć sam WebAsm jest nieco inną łatą i ma szanse przetrwać.
TypeScript jest produktem Microsoftu i wydaje mi się, że MS będzie inwestował w TSa jeszcze bardzo długo i z tego powodu unikanie nauki TSa na rzecz pozostania przy czystym JSie jest raczej niemądre (o ile pisze się dużo kodu w tych *skryptach).
5
Javascript to nie tylko frontend. To też backend w Node.js, QML, aplikacje w Electronie i pewnie jeszcze sporo innych projektów, o których nie pamiętam. Na razie tendencją jest upowszechnianie się Javascriptu a nie odchodzenie od niego. Zawiła historia JS pokazuje, że ciężko stworzyć taki standard, którego wszyscy będą przestrzegać. Potrzeba było kilku lat, żeby ECMAScript się upowszechnił.
Teraz są inne czasy. Mniej przeglądarek ma własne silniki. Wydawałoby się, że łatwiej jest innym językom się upowszechnić. Tak jednak się nie dzieje. Nie ma wysypu różnych języków czy technologii. Bardziej będzie to ewolucja, niż rewolucja. Sam Google, który ma tony JS w swoich produktach, nie robi rewolucji.
3
Przypominam, że dawno temu swoje 5 minut miał GWT https://en.wikipedia.org/wiki/Google_Web_Toolkit w którym frontend pisało się w Javie.
Wspomniany GWT jest, o ile dobrze pamiętam (a pamiętam tylko skrawki artykułów), wzorowany na javowym Swingu. To miało przyciągnąć programistów Javy i pewnie przyciągnęło. Ostatecznie GWT i tak upadło. Teraz mamy Blazora od Microsoftu, czyli taka powtórka z rozrywki.
lolxd
Wtedy mieliście transpilatorek javy do jsa napisany przez Google, a teraz jest otwarty standard rozwijany przez W3C, gdzie w tworzeniu go uczestniczą ludzie z:
Google, Alibaba, MSFT, Facebook, Intel, Fastly, Huawei, Mozilla, Agora, Tencent, LG, ByteDance, itp.
oraz jest jeszcze Bytecode Alliance, które nie mam pojęcia jak dokładnie działa
The Bytecode Alliance is a nonprofit organization dedicated to creating secure new software foundations, building on standards such as WebAssembly and WebAssembly System Interface (WASI).
i tam są:
Więc sprawa wygląda trochę inaczej niż opisujesz, bo nie Microsoft se zrobił Blazora i klepcie weba, a wszyscy vendorzy przeglądarek i MAGMA + inni stworzyli otwarty standard, a że akurat tak wyszło że MS był jednym z pierwszych, którzy ruszyli tyłek i zaimplementowali na poważnie to już inna sprawa.
Na pewno wpływa to szybkość przejścia na dany tech, bo hehe google za 2 lata ubije i będzie po ptokach, a tutaj co najwyżej połowa będzie ubita np. Blazor, bo WASM nadal będzie, a łatwiej wspierać generowanie WASMa niż JSa, bo jest prostszy oraz wolniej się zmienia.
2
@WeiXiao:
Co za różnica czy kompiluje się do JSa czy WASMa? Ważne jest jak działa z poziomu docelowego programisty. Dla przykładu z każdą nową wersją Blazora poprawiana jest integracja Blazora (zarówno Blazor Server jak i Blazor WebAssembly) z JSem, np: Render Razor components from JavaScript czy nawet:
https://docs.microsoft.com/en-us/aspnet/core/blazor/components/?view=aspnetcore-6.0#generate-angular-and-react-components
Generate Angular and React components
Generate framework-specific JavaScript (JS) components from Razor components for web frameworks, such as Angular or React. This capability isn't included with .NET 6, but is enabled by the new support for rendering Razor components from JS. The JS component generation sample on GitHub demonstrates how to generate Angular and React components from Razor components. See the GitHub sample app's README.md file for additional information.
Warning
The Angular and React component features are currently experimental, unsupported, and subject to change or be removed at any time. We welcome your feedback on how well this particular approach meets your requirements.
Jeśli ktoś bardzo podnieca się kompilacją do WebAssembly to owszem da się skompilować Javę (a nawet i Scalę, Kotlina, Clojure, itd) do WASMa:
https://github.com/appcypher/awesome-wasm-langs#java
- TeaVM - an ahead-of-time translating compiler (transpiler) of Java bytecode, that's capable of emitting JavaScript and WebAssembly.
- JWebAssembly - A Java bytecode to WebAssembly compiler. It can generate the WebAssembly binary or text format. It is written in Java itself and can be integrated with other Java build tools.
- Bytecoder - A Rich Domain Model for Java Bytecode and Framework to interpret and transpile it to other languages such as JavaScript, OpenCL or WebAssembly.
- CheerpJ - A Java compiler for the web that converts any Java client application into standard HTML5/WebAssembly/JavaScript.
0
Co za różnica czy kompiluje się do JSa czy WASMa?
Wydaje mi się, że upraszcza tworzenie narzędzia, co może oznaczać że:
a) potencjalnie więcej ich powstanie
b) łatwiej będzie utrzymać bo np. WASM jest prostszy oraz ulega zmianie wolniej, co oznacza że są większe szanse że to wypali/przeżyje
c) różne charakterystyki wydajnościowe, docelowo ma być szybciej :P
No chyba że wszyscy będą używać Emscripten, to wtedy utrzymanie się przerzuca na kogoś innego w znacznym stopniu.
4
Co do:
WeiXiao napisał(a):
Więc sprawa wygląda trochę inaczej niż opisujesz, bo nie
Microsoft se zrobił Blazora i klepcie weba, a wszyscy vendorzy przeglądarek i MAGMA + inni stworzyli otwarty standard, a że akurat tak wyszło że MS był jednym z pierwszych, którzy ruszyli tyłek i zaimplementowali na poważnie to już inna sprawa.Na pewno wpływa to szybkość przejścia na dany tech, bo
hehe google za 2 lata ubije i będzie po ptokach, a tutaj co najwyżej połowa będzie ubita np. Blazor, bo WASM nadal będzie, a łatwiej wspierać generowanie WASMa niż JSa, bo jest prostszy oraz wolniej się zmienia.
to nie zrozumiałem :P Jeśli MS ubije Blazora to cały kod C# napisany stricte pod Blazora będzie można wyrzucić do kosza. Nie ma znaczenia czy Blazor kompilował do JS czy WASMa.
łatwiej wspierać generowanie WASMa niż JSa, bo jest prostszy oraz wolniej się zmienia
różne charakterystyki wydajnościowe, docelowo ma być szybciej :P
Z punktu widzenia transpilatora JS się bardzo wolno zmienia, bo generalnie od dawna jest wszystko co potrzebne do efektywnej transpilacji. Nie ma obowiązku używania każdej nowości z ostatnich wersji JSa. Transpilatory zarówno do JSa jak i WASMa celują w stare wersje tych standardów (np. ECMAScript 2015) tak by wynikowy kod odpalił się na jak największym % przeglądarek w powszechnym użyciu.
To WebAssembly ma się mocno zmienić. Teraz dla przykładu nie ma wbudowanego garbage collectora, więc trzeba pisać swojego w WASMie (przez co jest mało wydajny, działa gorzej niż ten wbudowany np. w silnik JSa napisany w C++). Dodatkowo bez GC trzeba serializować dane między JSem i WASMem (bo ten prowizoryczny GC skompilowany do WASMa nie jest kompatybilny z tym wbudowanym w silnik JSa), włączając w to wywołania funkcji operujących na DOMie z poziomu WASMa (i to jest powód dla którego np. Rust skompilowany do WebAssembly jest wolniejszy od VanillaJS w benchmarkach).
W zasadzie pełna obsługa GC w WASMie (bez robienia jakichś prowizorycznych i ograniczonych obejść) to jest główna blokada przed zaimplementowaniem kompilacji do WASMa z poziomu GraalVM native-image:
Wasm target architecture for native image #3391:
christianwimmer commented on May 5
We have thought about a WASM backend, but it is not on our list of features to implement in the near future.
One of the biggest problems is the missing GC support in WASM: neither the GC of the underlying WASM/JS VM is exposed, nor stack walking is possible to include the existing SVM GC.
Integracja z JSowymi API (manipulacja DOMem, XHR/ Fetch i cała reszta) z poziomu WASMa wymaga nieustannej serializacji parametrów. Jak dla mnie to na razie nie opłaca się brnąć w takie coś. Cała machineria stworzona z powodu braku natywnego wsparcia GC w WASMie zostanie wyrzucona, gdy GC (natywny, a więc działający zarówno z poziomu JSa jak i WASMa na tych samych obiektach) wejdzie do WASMa, więc może lepiej poczekać na porządne GC w WASMie i mieć spokój? :)
Sam WebAssembly jest konstruowany tak, by być mocno kompatybilny z JavaScriptem i tak by mieszanka JSa i WASMa miała wysoką wydajność (tzn. wywołanie jednego z drugiego ma być szybkie). Jak na razie ta kompatybilność jest słaba, ale to głównie dlatego, że trudno ją osiągnąć (czyli jeszcze sporo na to poczekamy), a interesariusze chcieli mieć jakąkolwiek działającą wersję WASMa względnie szybko, żeby móc coś w tym działać, więc wypuszczono minimum viable product czy coś takiego i na razie takie coś mamy.
Poguglałem też na szybko frazę will webassembly replace javascript. W artykułach na samej górze wyników odpowiedź brzmi: nie, WASM nie wyprze JSa. Nawet oficjalnie odpowiedź brzmi "nie":
https://webassembly.org/docs/faq/
Is WebAssembly trying to replace JavaScript?
No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. Furthermore, it is expected that JavaScript and WebAssembly will be used together in a number of configurations:
(...)
0
to nie zrozumiałem :P Jeśli MS ubije Blazora to cały kod C# napisany stricte pod Blazora będzie można wyrzucić do kosza. Nie ma znaczenia czy Blazor kompilował do JS czy WASMa.
Nie wiem co dokładnie rozumiesz przez napisany stricte pod Blazora, ani czy coś takiego jest, no bo z tego co widziałem, to tam raczej czaruje się atrybutami, ale załóżmy że chodzi o sposób osadzenia kodu czy coś
No to faktycznie można byłoby powiedzieć że jest jakiś tam narzut konwencyjny? minimalnie techniczny? od Blazora, ale czy duży? nie wiem.
@code {
[Parameter]
public RenderFragment ChildContent { get; set; }
[Parameter]
public string Title { get; set; }
private void OnYes()
{
Console.WriteLine("Write to the console in C#! 'Yes' button selected.");
}
}
Jeżeli chodzi o kod bibliotek - np. miałem napisany parser w C# który wpiąłem na stronkę, no to tutaj nie ma nic Blazor specific i jest to zwykły C#, a zatem nie ma problemu.
Z punktu widzenia transpilatora JS się bardzo wolno zmienia, bo generalnie od dawna jest wszystko co potrzebne do efektywnej transpilacji. Nie ma obowiązku używania każdej nowości z ostatnich wersji JSa. Transpilatory zarówno do JSa jak i WASMa celują w stare wersje tych standardów (np. ECMAScript 2015) tak by wynikowy kod odpalił się na jak największym % przeglądarek w powszechnym użyciu.
Fair
To WebAssembly ma się mocno zmienić. Teraz dla przykładu nie ma wbudowanego garbage collectora, więc trzeba pisać swojego w WASMie (przez co jest mało wydajny, działa gorzej niż ten wbudowany np. w silnik JSa napisany w C++). Dodatkowo bez GC trzeba serializować dane między JSem i WASMem (bo ten prowizoryczny GC skompilowany do WASMa nie jest kompatybilny z tym wbudowanym w silnik JSa), włączając w to wywołania funkcji operujących na DOMie z poziomu WASMa (i to jest powód dla którego np. Rust skompilowany do WebAssembly jest wolniejszy od VanillaJS w benchmarkach).
Integracja z JSowymi API (manipulacja DOMem, XHR/ Fetch i cała reszta) z poziomu WASMa wymaga nieustannej serializacji parametrów. Jak dla mnie to na razie nie opłaca się brnąć w takie coś.
No niestety jest jakiś punkt do którego najpierw trzeba dojść, teraz możesz wziąć gotową czystą(?) bibliotekę w C++, Ruście, xyz czy C# i po prostu użyć jej na stronie bez konieczności przepisywania czy modyfikowania czegokolwiek - robiłem tak z C#.
https://github.com/WebAssembly/gc
https://github.com/WebAssembly/proposals/issues/16
Pamiętaj też, że najwidoczniej WASM to nie tylko przeglądarka:
Wasmtime is a Bytecode Alliance project that is a standalone wasm-only optimizing runtime for WebAssembly and WASI. It runs WebAssembly code outside of the Web, and can be used both as a command-line utility or as a library embedded in a larger application.
Wasmtime strives to be a highly configurable and embeddable runtime to run on any scale of application. Many features are still under development so if you have a question don't hesitate to file an issue.
5
Nie znam Blazora. Ale co do wymienionych przez Wibowita frameworków typu GWT:
One umarły, bo to nie były frameworki do frontendu. Ilość frontendowców, która przesiadła się z JS na GWT wynosiła pewnie ze 3 osoby:-)
To były produkty dające managementowi w korpo ułudę, że ich starzy javowi backendowcy będą mogli klepać front.
To działa do dziś, bo jakieś pomioty po GWT się ciągle spotyka (np. Vaadin). Tylko czar pryska jak w końcu trzeba te nadłubane przez korpo programistów strony pokazać klientowi.
0
A co gdyby Angular, React czy Vue.js pod spodem emitowały WebAssembly?
A co gdybyś nagle chciał przerzucić jakąś bibliotekę z backendu na front i zamiast przepisywać, to po prostu podpiął ją do tego kodu lub po prostu wywołał.
Bo tam nie ma żadnej magii, weźmy przykład:
tutaj jest jakiś losowy kod
namespace random_ass_language
public int Test(int a, int b)
{
return 5;
}
public int Test2()
{
int test = 17 + Test(5, 6);
return 23;
}
I ot tak sobie to wywołuje z konsolki / jsa
2
A co gdyby Angular, React czy Vue.js pod spodem emitowały WebAssembly?
Ja nic do webassembly nie mam. To zupełnie niezależny temat.
Po prostu mam wątpliwości do blazora takie jak do javowych frameworków. Są zrobione tak, żeby być przystępne dla backendowców, przez co są koszmarnie męczące kiedy zaczyna sie realna rzeźba na froncie. Ale to wątpliwość przez domniemanie, blazora nie znam. Na pewno spokojnie można zrobić framework do pisania frontu w C#, można też teoretycznie w javie. Tylko, że w javie się nie udało z powodu właśnie targetu.
0
Są jeszcze zbudowane toolkity to przenoszenia aplikacji desktopowych na WASM, np. Uno (C#/WinRT), gdzie przenieśli Kalkulator z Windows 10 do Internetu: https://calculator.platform.uno/ albo inny Flutter (https://gallery.flutter.dev/#/). Obie mają tę wadę, że nie zachowują się jak aplikacje internetowe, tylko w zasadzie wychodzi jak aplikacje z wtyczek (aplety, Flash, Silverlight), aczkolwiek bez wtyczek, niemniej może coś z tego wyjdzie.
0
albo inny Flutter (https://gallery.flutter.dev/#/)
@Ktos: ten Flutter to jakaś tragedia. Nie miałem wcześniej styczności z tym i może się mylę, ale moje pierwsze wrażenia są takie: narzędzia deweloperskie w przeglądarce totalnie głupieją. Nawet zaznaczanie tekstu nie działa, już o tłumaczeniu Google Translatorem nie wspominając. Wtyczki przeglądarkowe bezużyteczne. Mam nadzieję że nikt w tym nie robi stron internetowych na poważnie xD
0
Tutaj masz Quake skompilowane do JSa jeśli chcesz się pobawić tym: http://www.quakejs.com/
Bez ironii - fajna wrzutka. Z tymże nie do końca to wygląda jak quake skompilowany do JS. Z tego co widzę ioquake jest kompilowany do WASM za pomocą emscripten a w JS to jest tylko jakiś glue code. Patrząc pobieżnie, zdecydowanie nie nazwałbym tego portem quake3 do JS tak jak to zrobił autor https://github.com/inolen/quakejs
1
WeiXiao napisał(a):
to nie zrozumiałem :P Jeśli MS ubije Blazora to cały kod C# napisany stricte pod Blazora będzie można wyrzucić do kosza. Nie ma znaczenia czy Blazor kompilował do JS czy WASMa.
Nie wiem co dokładnie rozumiesz przez
napisany stricte pod Blazora, ani czy coś takiego jest, no bo z tego co widziałem, to tam raczej czaruje się atrybutami, ale załóżmy że chodzi o sposób osadzenia kodu czy coś
Kod napisany stricte pod Blazora to kod, który wykorzystuje mocno API Blazora, a więc wymiana Blazora (bo np. MS właśnie go ubił) na inny framework wymagałaby dużego wysiłku i niekoniecznie byłaby opłacalna względem przepisania od zera w tym innym frameworku.
Jeżeli chodzi o kod bibliotek - np. miałem napisany parser w C# który wpiąłem na stronkę, no to tutaj nie ma nic Blazor specific i jest to zwykły C#, a zatem nie ma problemu.
(...)
teraz możesz wziąć gotową czystą(?) bibliotekę w C++, Ruście, xyz czy C# i po prostu użyć jej na stronie bez konieczności przepisywania czy modyfikowania czegokolwiek - robiłem tak z C#.
Sporo scalowych bibliotek jest skompilowanych zarówno do javowego bajtkodu, javascriptu i do kodu natywnego jednocześnie. Dla przykładu parsery: https://index.scala-lang.org/search?targetTypes=js&targetTypes=jvm&targetTypes=native&q=parse&page=1
Kolejna sprawa to integracja bibliotek napisanych w różnych językach. Czy da się posklejać biblioteki napisane w C# i Ruście w jednym projekcie kompilowanym do WASMa? Jest łatwiej czy trudniej niż w przypadku bardziej tradycyjnych środowisk docelowych?
Pamiętaj też, że najwidoczniej WASM to nie tylko przeglądarka:
JS to też nie tylko przeglądarka. Można pisać programy konsolowe w JSie i odpalać bez przeglądarki i dało się to robić nawet przed Node.jsem. Dla przykładu tutaj jest 25-letni staruszek: https://en.wikipedia.org/wiki/JScript A tu jest 24-letni staruszek do odpalania JSa z poziomu Javy: https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Pomysł odpalania języków webowych bez użycia przeglądarki jest jak widać starszy niż sam .NET.
Miałem napisane więcej tekstu, ale wyrzuciłem bo już mi się trochę znudziło dyskutowanie :) Podsumowując, moim zdaniem całe to jaranie się WASMem jest przedwczesne, bo jak na razie w kwestii tworzenia frontendu (w końcu tytuł wątku to Czy i kiedy JavaScript przestanie być językiem frontendu Internetu?) WASM nie ma jeszcze realnych zalet nad JSem (jako cel transpilacji) z powodu braków w implementacji (przede wszystkim brak uniwersalnego GC działającego w JS i WASM jednocześnie, możliwości operowania na JSowych obiektach z poziomu WASMa, itd)
several napisał(a):
Tutaj masz Quake skompilowane do JSa jeśli chcesz się pobawić tym: http://www.quakejs.com/
Bez ironii - fajna wrzutka. Z tymże nie do końca to wygląda jak quake skompilowany do JS. Z tego co widzę ioquake jest kompilowany do WASM za pomocą emscripten a w JS to jest tylko jakiś glue code. Patrząc pobieżnie, zdecydowanie nie nazwałbym tego portem quake3 do JS tak jak to zrobił autor https://github.com/inolen/quakejs
QuakeJS powstał w 2013 roku, a więc gdy WASMa jeszcze w ogóle nie było. Jeśli teraz jest kompilowany do WASMa to pewnie dlatego, że ktoś dorzucił taką możliwość obok kompilacji do JSa.
0
Kolejna sprawa to integracja bibliotek napisanych w różnych językach. Czy da się posklejać biblioteki napisane w C# i Ruście w jednym projekcie kompilowanym do WASMa? Jest łatwiej czy trudniej niż w przypadku bardziej tradycyjnych środowisk docelowych?
A jakie masz oczekiwania?
Chcesz mieć odpalone jedno IDE np. VS Coda, a w nim
|
| --- Rust
Algo1
| --- C#
Algo2
i zrobić jakiś ./build i mieć w wyniku index.html, algos.wasm czy index.html, algo1.wasm, algo2.wasm
Następnie jak chciałbyś to debugować? raz debuggerem rusta, a raz C# czy debuggerem z przeglądarki?
Czy może w ogóle pytasz tylko o to, czy da się wywołać funkcje wasmową wygenerowaną z C#, z wasmu wygenerowanego z Rusta?