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

Odpowiedz Nowy wątek
Wesoły Ogrodnik
2018-05-17 13:14
Wesoły Ogrodnik
0

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/[...]sing-blazor-and-asp-net-core/

Pozostało 580 znaków

2019-07-12 18:45

Rejestracja: 4 lata temu

Ostatnio: 4 godziny temu

0

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ć.

edytowany 1x, ostatnio: WeiXiao, 2019-07-12 18:45

Pozostało 580 znaków

2019-09-24 09:07

Rejestracja: 2 lata temu

Ostatnio: 14 godzin temu

1

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

Pozostało 580 znaków

2019-09-24 09:57

Rejestracja: 6 lat temu

Ostatnio: 5 godzin temu

Lokalizacja: Nowa Ruda

0

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.

A skąd mamy wiedzieć? Każdy może powiedzieć co innego. - PerlMonk 2019-09-24 09:59

Pozostało 580 znaków

2019-09-24 10:03

Rejestracja: 2 lata temu

Ostatnio: 14 godzin temu

0

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 ;)

Pozostało 580 znaków

2019-09-24 10:30

Rejestracja: 15 lat temu

Ostatnio: 7 godzin temu

1

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.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit, 2019-09-24 10:32
Co do ostatniego akapitu - to samo można powiedzieć o każdej (innej) bibliotece/frameworku dla frontendu. - AreQrm 2019-09-24 18:08
W zasadzie tak. Więc w sumie najlepiej unikać przerośniętych frameworków frontendowych, by nie ugrzęznąć później w takiej legacy krowie. - Wibowit 2019-09-24 21:40

Pozostało 580 znaków

2019-09-24 13:08

Rejestracja: 3 lata temu

Ostatnio: 9 godzin temu

0

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.

Pozostało 580 znaków

2019-09-24 13:35

Rejestracja: 2 lata temu

Ostatnio: 14 godzin temu

0

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.

edytowany 2x, ostatnio: nobody01, 2019-09-24 13:39
Jak chcesz front i backend pisac w jednym jezyku to bierz JS i mozesz w node.js pisac backend :D. Ja tam trzymam kcuki za blazora ale raczej nie spodziewam sie rozpierdzielu na rynku. Juz sie z tym TypeScriptem na froncie przyzwyczailem i calkiem dobrze mi sie z nim zyje :D - Akihito 2019-09-24 14:28
@Akihito: Porownujesz node.js do .NET Core? :P - nobody01 2019-09-24 14:45
@nobody01: nie pisalem to nie wiem :D ale wiem ze masz taki JS i mozesz pisac front, backend, mobilki i nawet desktopy w nim ;) - Akihito 2019-09-24 23:21

Pozostało 580 znaków

2019-09-24 15:23

Rejestracja: 5 lat temu

Ostatnio: 8 godzin temu

Lokalizacja: Rzeszów

0

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.

edytowany 1x, ostatnio: mad_penguin, 2019-09-24 15:24

Pozostało 580 znaków

2019-09-24 15:29

Rejestracja: 4 lata temu

Ostatnio: 5 godzin temu

Lokalizacja: UK

2

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.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
edytowany 1x, ostatnio: Aventus, 2019-09-24 15:30
ale piszesz w vue tak pure js czy uzywasz do niego type scriptu? - Akihito 2019-09-24 23:13
Sam Vue na razie. Z TS już miałem do czynienia ale jakoś nie urzekł mnie. Co jest zabawne bo ogólnie zdecydowanie preferuję silne typowanie. - Aventus 2019-09-24 23:25

Pozostało 580 znaków

2019-09-24 17:00

Rejestracja: 15 lat temu

Ostatnio: 7 godzin temu

0

Jaka znowu awersja do nowego? Transpilacja do JSa to nie jest nowa rzecz, istnieje co najmniej te kilkanaście lat. Lista języków transpilowanych do JSa: https://github.com/jashkenas/[...]-languages-that-compile-to-js Jest na tej liście sporo języków używanych do backendu jak np Java, C#, Kotlin, Python, Haskell, Clojure itd

Do C# są rozwiązania wydane na długo przed Blazorem, np Bridge.NET

Niby mocną stroną Blazora ma być mocne ukierunkowanie się na WASMa, ale czy to niby jest bezdyskusyjnie zaletą? WASM wcale nie jest potrzebny do tego, by używać jednego języka na froncie i backendzie jak pokazuje lista transpilowanych języków. Abstrakcje i tak będą cieknąć, więc upychanie semantyki .NETowej do WASMa raczej będzie się okazyjnie sypać przy skomplikowanej interakcji z API przeglądarkowym.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0