ASP.NET + Blazer vs React/Angular/Node/Vue

Czy Blazor ma szanse konkurować z JS frameworkami?

Blazor:
A component model for building composable UI
Routing
Layouts
Forms and validation
Dependency injection
JavaScript interop
Live reloading in the browser during development
Server-side rendering
Full .NET debugging both in browsers and in the IDE
Rich IntelliSense and tooling
Ability to run on older (non-WebAssembly) browsers via asm.js
Publishing and app size trimming

https://learn-blazor.com/getting-started/what-is-blazor/
http://www.talkingdotnet.com/create-a-crud-app-using-blazor-and-asp-net-core/

Dość karkołomna architektura:

Moim zdaniem lepszym rozwiązaniem byłaby kompilacja do pełnoprawnego JavaScriptu, a nie do WebAssembly + biblioteki pośredniczącej. Dla C# istnieją kompilatory do JavaScriptu (na szybko wyguglane):

• https://bridge.net/ / https://github.com/bridgedotnet/Bridge
• http://duoco.de/
• http://jsil.org/

Ponadto użycie innego języka niż *scripty nie wyklucza się z używaniem Reacta/ Angulara/ Vue/ itd Dla przykładu w Scali.js ( https://www.scala-js.org/ ) można używać wprost bibliotek JavaScriptowych ( https://www.scala-js.org/doc/interoperability/ ) i/ lub korzystać z nakładek, które pozwalają pisać znacznie bardziej idiomatyczny kod i dodają statyczne typowanie ( np https://github.com/japgolly/scalajs-react ).

Blazor zapowiada się świetnie, ale póki co nadaje się wyłącznie do zabawy, sam Microsoft nazywa go eksperymentem i odradza użycie na produkcji.
A samo WebAssembly to prawdopodobnie przyszłość programowania po stornie przeglądarki, tyle że to jest kwestia najbliższych lat, a nie tygodni czy miesięcy.

Ale co oznacza WebAssembly dla JS? a dokładniej mówiąc dla React, Vue, Angular itd.

WebAssembly spowoduje wzrost popularności C++. Czyżby wielki powrót C++ na szczyty popularności ? :D
Ciekawi mnie czy C++ dzięki WebAssembly będzie mieć również zastosowanie w programowaniu logiki biznesowej?

WebAssembly jest na razie w fazie Minimum Viable Product i jest dość ubogi. Z czasem mają nadejść funkcjonalności, które pozwolą np na tłumaczenie kodu wprost z JavaScriptu do WebAssembly bądź z innego języka do WebAssembly z pominięciem JavaScriptu. Opis rozważanych funkcjonalności jest tutaj: https://webassembly.org/docs/future-features/ Postęp idzie w ślimaczym tempie, a samo WebAssembly jak na razie jest tylko i wyłącznie ciekawostką.

WebAssembly spowoduje wzrost popularności C++. Czyżby wielki powrót C++ na szczyty popularności ? :D
Ciekawi mnie czy C++ dzięki WebAssembly będzie mieć również zastosowanie w programowaniu logiki biznesowej?

A dlaczego niby C++, a nie jakiegoś bardziej ludzkiego języka? LLVM ma backend generujący WebAssembly, więc wszystko co generuje bitkod LLVMowy może bez dużych zmian kompilować się do WebAssembly (modulo dostępne API systemowe, oczywiście).

Wibowit napisał(a):

A dlaczego niby C++, a nie jakiegoś bardziej ludzkiego języka? LLVM ma backend generujący WebAssembly, więc wszystko co generuje bitkod LLVMowy może bez dużych zmian kompilować się do WebAssembly (modulo dostępne API systemowe, oczywiście).

WebAssembly umożliwi korzystanie z zaawansowanych programów, jak Photoshop, Autocad czy gry klasy AAA w przeglądarce internetowej. Więc czemu nie zastosować C++ do napisania również backendu ? skoro dana firma ma już sztab programistów C++ piszących zaawansowane programy.

Z tej prezentacji wynika, że najbardziej prosperujące języki w przyszłości to C/C++ i Rust.
A także React.js, bo ładne UI zawsze będzie potrzebne.

WebAssembly umożliwi korzystanie z zaawansowanych programów, jak Photoshop, Autocad czy gry klasy AAA w przeglądarce internetowej. Więc czemu nie zastosować C++ do napisania również backendu ? skoro dana firma ma już sztab programistów C++ piszących zaawansowane programy.

C++ generuje duży koszt w porównaniu do bardziej produktywnych języków. Używanie jednego języka na backendzie i frontendzie nie jest zyskiem netto samo w sobie. Dopiero same cechy języka decydują o wartości takiego rozwiązania. Inaczej Node.js zagarnęłoby cały rynek aplikacji webowych.

Rust i Kotlin to przyszłościowe języki. A Python to ulubiony język programowania NASA i różnych programów kosmicznych.

Po wejściu na https://blazor-flight-finder.azurewebsites.net/ moja przeglądarka pobrała prawie 4,5 MB. Czy ten rozmiar zmniejszy się w przyszłości?

Tak, dodatkowo zostanie wprowadzony szereg optymalizaji etc. Serdecznie polecam artykuł https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/. Gdybym miał obstawiac to powiedziałbym ze TS bedzie bardzo mocno rósł i być może zastapi JS docelowo w przegladrce. Migracja kodu z JS do TS jest stosunkowo prosta pod warunkiem ze jakość jest przyzwoita ponad to juz teraz jest kompilator ts do wasm https://github.com/AssemblyScript/assemblyscript nazwijcie mnie czlowiekiem malej wiary ale osobisci nie widze tego by nagle FE devi (ktorych w mojej firmie jest w relacji 4-5 na jednego BE deva ) nagle zaczeli pisac w cpp tudziez Rust.

Od niedawna mamy wersję 0.9: https://visualstudiomagazine.com/articles/2019/03/08/blazor-0-9-0.aspx Do premiery zostało pewnie kilka miesięcy. Jak sądzicie: Blazor będzie używalny w tym roku?

A to nie jest już używalny? Co rozumiesz pod tym pojęciem?

Z tym brakiem narzekania to będzie ciężko. Ja zrobiłem prosty test i spróbowałem otworzyć https://blazor-demo.github.io/ na moim telefonie z Windows 10 mobile. Oprócz Loading... nie zobaczyłem nic. Teraz ogarnij sobie ile przeglądarek (na starszych Androidach, Windows Phonach, starszych PCtach) tego jeszcze nie wspiera.

Na moim telefonie z Androidem 8.1 Oreło odpala się nawet dość szybko. Apka jest jednak tak trywialna, że to niewiele oznacza jak na razie.

Dobra wtrace swoje 3 grosze jako ziomek ~2 lata expa (wiec to tylko moje juniorsko/midowskie zdanie). Mialem okazje pracowac przy 3 projektach w nastepujacym stacku:

*.NET ASP MVC + JQuery typowy projekt chyba jak na tamte czasy o Angularze to nawet jeszcze nie slyszalem. Poziom buderlu w projekcie nie fajny bo jak aplikacja rosla to problem z JS byl. Duzo jakis fajnych ficzerow wymagalo babrania sie w brzydkim kodzie z partial view.

*.NET ASP MVC + AngularJS - nowa firma nie moj projket tylko juz gotowy i calkiem spoko sie pracowalo jak zajarzylem Angulara. Duzym minusme bylo to ze w folderach Angularowych byl jakis porzadek nawet, tylko ze nalozenie calego C# i Angulara powodowalo ze drzewo folderow/plikow sie nie konczylo :D

*.NET CORE + Angular7 - poweim tak miodzio jesli o porzadek chodzi w VS Code mamy samego Angulara i caly front a w zwyklym Visualu cala logike backendu.

Powiem szczerze nie wyobrazm sobie powrotu z duzym komercyjnym projektem do jednego edytora. Dodatkowo porownujac mozliwosc Angulara do Razora dalem se spokoj i zapomnialem ze byl taki twor jak Razor...

@Aventus: @Aryman1983: Będzie ktoś bronił Blazora? ;)

Przecież jest nadal w rozwoju. Nie ma co go skreślać czy nawet nie skreślać tylko na podstawie szybkości działania i tego ile jego pliki ważą, to bez sensu. Co do tego że się skończy jak Razor (A skończył się? Ja tu widzę właśnie jego rozwój) to ja mogę też rzucić "argument" w tym stylu- nie skończy się, przyćmi inne technologie webowe. I o, proszę mnie słuchać bo ja wiem! ;)

Poczekamy zobaczymy :-) Ja tam kibicuje, bo może będzie to alternatywa dla tych przepastnych fw jsowych. Na razie morduję się z VS2019 i nie mam czasu nawet wchodzić na bloga M$ :-)

Blazor zaczyna już dość fajnie wyglądać ;) Coś czuję, że hype będzie rósł: inna prezentacja sprzed dwóch miesięcy ma już prawie 100 tysięcy odsłon.

Fajnie, że można prosto robić w miarę UI, ale to programowanie atrybutami trochę mnie martwi, czy to już spring? chociaż z drugiej strony nie wiem jak można byłoby to prościej zrobić.

.NET Core 3 już jest, a to oznacza, że server side Blazor też jest ;) Tu Daniel Roth w najnowszej prezentacji o Blazorze ;)

Zainstalowałem sobie, utworzyłem domyślny projekt. Fajnie to wygląda. Ciekawi mnie czy warto się tego uczyć? W sensie czy w ciągu roku, dwóch zaczną powstawać aplikacje w tym.

Gdzieś czytałem, że niektórzy używają już server side Blazor do jakichś wewnątrzfirmowych aplikacji, gdzie serwer znajduje się w tym samym budynku. ;) Tu masz przykładową aplikację zrobioną w tym: https://www.matblazor.com ;) Ale raczej trzeba poczekać na WebAssembly ;)

Blazor to taki Google Web Toolkit (GWT) bis tyle, że teraz mamy C# zamiast Javy (główna różnica widoczna dla programisty) i kompilację do JS+WASM zamiast samego JSa (to akurat "szczegół" implementacyjny raczej). GWT miał pierwszą oficjalną wersję 13 lat temu (2006 rok).

Nie jestem w temacie dokładnie, ale jednym z powodów upadku GWT jest to, że było wzorowane zdecydowanie bardziej na desktopowych UI toolkitach niż na podejściu typowo HTMLowym. Problemem był też długi czas kompilacji, niewygodna integracja z nowymi bibliotekami JSowymi, itd

Mimo wszystko przez kilka lat GWT było hitem i dużo Javowych zapaleńców robiło w tym aplikacje biznesowe. Samo Google też. Na stronie http://www.gwtproject.org/ mamy:

GWT is used by many products at Google, including Google AdWords and Google Wallet. It's open source, completely free, and used by thousands of enthusiastic developers around the world.

Google Wave było oparte o GWT i jak pewnie niektórzy pamiętają, też zdechło i to bardzo szybko.

Bardzo możliwe, że Blazora spotka to samo. Najpierw ekscytacja przez kilka lat, a potem zapomnienie. Jasnowidzem (czarnowidzem?) jednak nie jestem, więc nie będę się pod tym podpisywał. Jeśli jednak miałbym obstawiać to stawiałbym na to, że za 10 lat zainteresowanie Blazorem (bądź bliżniaczymi pod względem mechaniki projektami w .NETu o ile takie będą) będzie nikłe.

Do wypowiedzi kolegi wyżej dodam tylko,

że jednym z powodów stosowania GWT jest to, że dobrze rozwiązywał problemy javaScriptu w 2006 roku: typowanie, podział projektu na pliki i moduły, statyczna analiza kodu.
To co jeszcze raczkowało w czasie wydania w js'ie wtedy.

Typescript z najnowszymi standardami rozwiązuje większość problemów.

Widzę, że niektórzy tutaj skreślają Blazora już na starcie. A czy to nie jest tak, że WebAssembly to przyszłość webu? Celem jest umożliwienie tworzenia backendu i frontendu w jednym języku, współdzielenia kodu i korzystania z tych samych bibliotek. To, że kiedyś się nie udało, nie znaczy, że nie uda się teraz. ;) Nie chodzi tu tylko o C#, ale też i o inne języki. Oczywiście Blazora pewnie nikt nie użyje za rok, w dniu wydania, ale pewnie dopiero kilka lat później, gdy przeglądarki i użytkownicy będą gotowi.

Mnie do bliższego zajęcia się Blazorem zniechęcił tooling - powolny edytor w VS z lagującym podkreślaniem błędów na czerwono, konieczność kompilowania całego projektu i odświeżania strony żeby zobaczyć zmiany kontra Ctrl+S i sekunda na hot reload z zachowaniem stanu w Reakcie oraz (zazwyczaj) w miarę szybko reagujący VS Code.

Wiele negatywnych opinii bierze się oczywiście z awersji do czegoś nowego. Sam już od dawna śledzę rozwój Blazora i bardzo cieszę się że w końcu ujrzał światło dziennie. Na razie po stronie serwera ale tylko czekać aż wersja WebAssembly będzie gotowa do produkcyjnego użycia. Niestety do tej pory nie miałem okazji nic większego w nim pisać. Niedawno zacząłem pracę licencjacką w której do frontu używam Vue ale zastanawiam się czy nie spróbować Blazora póki za dużo nie zrobiłem.