Wybór technologii webowej do nauki

Cześć,
programuję (niezawodowo) w .NET od ok. 5 lat. Na początku był to VB.NET, ale szybko przerzuciłem się na C#. Podczas tworzenia różnych projektów (głównie dla siebie), mogę powiedzieć, że nauczyłem się takich konceptów / technologii / narzędzi:

• Projektowanie i tworzenie baz danych - SQL Server, widoki, funkcje, procedury + SQL Server Management Studio
  • ADO.NET, a potem Entity Framework Core (choć ciągle jest to dla mnie rzecz relatywnie nowa)
• WinForms na poziome podstawowym i WPF na poziomie zaawansowanym (własne style, kontrolki - np. grafiki rezerwacji, data binding, MVVM, konwertery, ...)
• Własne biblioteki - helpery, ale także DAL dla projektów bazodanowych, czyli oddzielenie projektu WPF od bazy
• Interfejsy, rozszerzenia metod, LINQ, NLog
• GIT
• Poza .NETem: HTML, CSS (Flexbox, grid), podstawy JS, czysty PHP z mysqli oraz prymitywny AJAX : )

Specjalnie siedziałem dłużej w aplikacjach desktopowych, aby skupić się na nauce samego języka (oczywiście nie zaczynałem od GUI, ale na tym etapie byłem już komfortowy w WPF), oraz różnych narzędzi, jak EF, NLog, podział solucji na mniejsze projekty, itp.

Teraz gdy już mam wrażenie, że umiem / znam wszystkie te koncepty, pora chyba na aplikacje webowe. Nie uważam, że wszystko powinno być aplikacją internetową i sam jestem zwolennikiem desktopa, ale w końcu strony to przyszłość.

Jakiego webowego frameworka powinienem zacząć się uczyć w 2024 roku? ... no i, z jakich źródeł?

Wiem, że jest ASP.NET Core MVC, ale kilka razy czytałem już na forum komentarze innych, że został on wyparty przez WebApi + Blazor.

Liczy się dla mnie przede wszystkim możliwość znalezienia pracy w przyszłości, ale także komfort programowania : )

Z góry dziękuję za jakiekolwiek odpowiedzi!

Angular majstrze drogi. Skoro robisz w .NET to Angular przez wzgląd na spora ilość analogii wydaje sie być naturalnym wyborem.

Pracuje z Angularem ponad 4 lata już i to naprawdę porządny framework - z bogatym ekosystemem, dojrzały i wydajny (a najlepsze ma dopiero nadejść bo zejdziemy z zone.js).

Blazora i Reacta też mi dane było posmakować i nie mają startu.

rjakubowski napisał(a):

Angular majstrze drogi. Skoro robisz w .NET to Angular przez wzgląd na spora ilość analogii wydaje sie być naturalnym wyborem.

Pracuje z Angularem ponad 4 lata już i to naprawdę porządny framework - z bogatym ekosystemem, dojrzały i wydajny (a najlepsze ma dopiero nadejść bo zejdziemy z zone.js).

Blazora i Reacta też mi dane było posmakować i nie mają startu.

Dzięki za odp : )
Czyli backend w Web API, a front w Angularze?

Ja nie znam reacta ani angulara, ale w blazorze to się zakochałem :)
Ja wiem, że to młoda technologia i wiele rzeczy jeszcze w nim nie ma (trzeba robić je samemu), ale możliwość pisania w C# vs JS z nawiązką mi to wynagradza!
I ja wiem, że wydajnościowo również mogłoby być lepiej, ale... C# >>> JS!!!

Dla mnie też im mniej JS, tym lepiej :) Ale czy używając C# do frontu i do backendu, nie zaciera się za bardzo granica pomiędzy tym, co wykonuje się na serwerze, a tym co w przeglądarce?

bbhzp napisał(a):

Dla mnie też im mniej JS, tym lepiej :) Ale czy używając C# do frontu i do backendu, nie zaciera się za bardzo granica pomiędzy tym, co wykonuje się na serwerze, a tym co w przeglądarce?

Ale to chyba dobrze, że się zaciera. Po co tworzyć sobie jakieś "granice"? Mieszanie języków to jest koszmar szczególnie, gdy backend piszesz w silnie typowanym języku (np. C#) a front w pseudo języku jakim jest JS...
Jeśli backend i front masz w C# wszystko jest proste. Masz jedną bibliotekę z obiektami, piszesz w normalnym cywilizowanym języku silnie typowanym, masz całego .NET-a... To jest piękne.

Nie każdy musi umieć/lubić/robić front, ani nie jest to koniecznie, żeby pracować z .NET (webowym), a do PoC w razie czego wystarczy czysty JS i Bootstrap (zawiało oldschoolem) albo Razor Pages.

Przecież różnice pomiędzy ASP .NET MVC i ASP .NET WebAPI od strony backendu są nieznaczne.

Największa różnica jest taka, że zamiast zwracać htmla ze stronką, to zwracasz jsona z danymi.

No i pewnie jeszcze casy typu F5 na formularzu.

Przeczytaj całe docsy ASP i będzie git

https://learn.microsoft.com/en-us/aspnet/core/?view=aspnetcore-8.0

@bbhzp: ostrożnie bym do tego podchodził bo jak trzeba zrobić na froncie coś więcej to bez JSa się nie obejdziesz. Beznadziejny jest ten interop C#/JS w Blazorze. Stąd skłaniałbym się ku Angularowi w ciemno, a korporacji które działają w stacku .NET/Angular jest zatrzęsienie

@Kofcio: nie wiem co Cie w tym bawi, ale mnie narzut statycznego typowania na froncie zabija przez to jak dynamicznym środowiskiem jest przeglądarka. Jeśli o serwer chodzi to wiadomo, że zalety przeważają, ale w przeglądarce...

rjakubowski napisał(a):

@bbhzp: ostrożnie bym do tego podchodził bo jak trzeba zrobić na froncie coś więcej to bez JSa się nie obejdziesz. Beznadziejny jest ten interop C#/JS w Blazorze. Stąd skłaniałbym się ku Angularowi w ciemno, a korporacji które działają w stacku .NET/Angular jest zatrzęsienie

Zdaję sobie z tego sprawę :) Czasu mam teraz dużo, więc spróbuję wszystkich tych technologii, ale faktycznie Angulara jest więcej niż Blazora w ogłoszeniach o pracę.

A poza tym, faktycznie Web API + jakiś inny frontend jest bardziej sensowne niż klasyczne MVC (jeśli mylę pojęcia to najmocniej przepraszam, nie znam się :P), bo potem tego samego API mogę używać w aplikacjach mobilnych a nawet w desktopie

Kofcio napisał(a):

bbhzp napisał(a):

Dla mnie też im mniej JS, tym lepiej :) Ale czy używając C# do frontu i do backendu, nie zaciera się za bardzo granica pomiędzy tym, co wykonuje się na serwerze, a tym co w przeglądarce?

Ale to chyba dobrze, że się zaciera. Po co tworzyć sobie jakieś "granice"? Mieszanie języków to jest koszmar szczególnie, gdy backend piszesz w silnie typowanym języku (np. C#) a front w pseudo języku jakim jest JS...
Jeśli backend i front masz w C# wszystko jest proste. Masz jedną bibliotekę z obiektami, piszesz w normalnym cywilizowanym języku silnie typowanym, masz całego .NET-a... To jest piękne.

źle, przesyłasz wynik SELECT * FROM TABELA juz nie tylko z bazy do aplikacji ale i przez internet na front i tam potem filtrujesz i dzielisz na strony
widziałam takie cuda
potem zdziwienie że js, do którego ten c# czy inna java jest kompilowany roi w przeglądarce cuda z twoim intem czy wybranym kodowaniem, bo przecież nic o js nie wiesz i nawet zdebugować za bardzo nie potrafisz
i przede wszystkim brakuje jawnego opisu co jest wysyłane między backendem a frontendem

Miang napisał(a):

źle, przesyłasz wynik SELECT * FROM TABELA juz nie tylko z bazy do aplikacji ale i przez internet na front i tam potem filtrujesz i dzielisz na strony
widziałam takie cuda
potem zdziwienie że js, do którego ten c# czy inna java jest kompilowany roi w przeglądarce cuda z twoim intem czy wybranym kodowaniem, bo przecież nic o js nie wiesz i nawet zdebugować za bardzo nie potrafisz

Ale co to ma do zacytowanego fragmentu i tematu w ogóle? Myślisz, że jak będziesz pisał front w innym języku/technologii to problemy zaczną się same rozwiązywać?
Poza tym nie do końca rozumiem w czym masz problem z tym zapytaniem, bo potem piszesz o int-ach i wybranym kodowaniu i nie wiem czy problem jest z wydobywaniem wszystkich wartości z bazy czy może chodzi o coś innego - co?
Jeśli masz problem z wydobywaniem wszystkich danych z tabeli to przejście na JS nie rozwiąże tego problemu bo to dotyczy przyjętych założeń a nie języka programowania.

Miang napisał(a):

i przede wszystkim brakuje jawnego opisu co jest wysyłane między backendem a frontendem

Jeśli piszesz tylko w C# to właśnie nie masz tego problemu bo na froncie i backendzie masz te same klasy i dużo trudniej popełnić błąd.

Kofcio napisał(a):

Miang napisał(a):

Ale co to ma do zacytowanego fragmentu i tematu w ogóle? Myślisz, że jak będziesz pisał front w innym języku/technologii to problemy zaczną się same rozwiązywać?

po pierwsze najlepiej jakby front pisała inna osoba

Poza tym nie do końca rozumiem w czym masz problem z tym zapytaniem, bo potem piszesz o int-ach i wybranym kodowaniu i nie wiem czy problem jest z wydobywaniem wszystkich wartości z bazy czy może chodzi o coś innego - co?

potem . w osobnym paragrafie, a Ty to łączysz w jedno nie wiem dlaczego. wymieniam wady js, wady z którymi można sobie poradzić będąc świadomym że ma się kod w js. wady których nie zauważysz pisząc w innym języku, który takich nie ma ale będzie skompilowany do js
problem mam z tym że koder wyciąga wszystko z bazy bo o WHERE nie słyszał
problem mam z tym że gostek jest nie tylko frontendowcem i backendowcem ale i bazadanowcem a co jest do wszystkiego to jest do niczego

Jeśli masz problem z wydobywaniem wszystkich danych z tabeli to przejście na JS nie rozwiąże tego problemu bo to dotyczy przyjętych założeń a nie języka programowania.

a kto ma to zauważyć? koder nie musi?

Miang napisał(a):

i przede wszystkim brakuje jawnego opisu co jest wysyłane między backendem a frontendem

Jeśli piszesz tylko w C# to właśnie nie masz tego problemu bo na froncie i backendzie masz te same klasy i dużo trudniej popełnić błąd.

łatwiej, bo nie widzi się specyfiki tego kodu który jest w przeglądarce

@bbhzp: Kiedyś stałem w tym samym miejscu co Ty.

Jak mówi klasyk: to zależy co chcesz osiągnąć.

Ja bym dodał: i zależy też ile masz czasu do przepalenia na naukę i eksperymenty.

Na stricte dotnetowe rozwiązanie będziesz potrzebował mniej, niż na .NET + front end framework.

Jeśli chodzi o zawodową karierę w .net to najpopularniejsze połączenie to .net i Angular. Blazor jeszcze długo nie osiągnie takiej pozycji (jeśli w ogóle).

Dziękuję wszystkim za odpowiedzi, idę w .NET + Angular : ). Polecacie jakieś kursy, książki, strony, czy po prostu sama dokumentacja i robienie projektów?

Ja się Angulara uczyłem od tego Pana na Udemy. Ma też swoje filmiki na YT
Angular - The Complete Guide (2024 Edition)

Podbijam, .NET + Angular to w korpo bardzo popularny stack, tak jak pisano wyżej obie technologie maja wiele podobnych konceptów.

Ogólnie nie musisz sie też skupiać koniecznie na froncie, możesz rozwinąć też swoje backendowe umiejętności o jakieś chmury, mikro serwisy itd.

Jeśli chodzi o backend, popularność zyskuje MinimalAPI. Jest to technologia w ASP.NET Core która niesamowicie upraszcza tworzenie webowego API.
Do tego Blazor, EF Core, i masz komplet.
Co do kursów, ja zakochałem się w kanale Juliio Casala. Gość nie dość, że mówi bardzo zrozumiałą angielszczyzną (co nie jest regułą), to w dodatku ma niesamowity talent do bardzo jasnego tłumaczenia zagadnień. I w dodatku na swoim kanale ma sporo kompletnych darmowych kursów lepszych od wielu płatnych:

Inny świetny kanał wart poznania, to jest I Am Tim Corey:

Przecież Minimal APIs, MVC, i Web API to są małe różnice, polegające głównie na tym gdzie jest kod i co zwraca (html vs json). Naucz się kontrolerów/actionów, routingu, atrybutów lub generalnie całego ASP to Minimal/MVC/Web będą pierdółkami

WeiXiao napisał(a):

Przecież Minimal APIs, MVC, i Web API to są małe różnice, polegające głównie na tym gdzie jest kod i co zwraca (html vs json). Naucz się kontrolerów/actionów, routingu, atrybutów lub generalnie całego ASP to Minimal/MVC/Web będą pierdółkami

Nie prawda. Minimal API to jest ZUPEŁNIE coś innego niż MVC. Tam nie ma w ogóle nic takiego, jak kontrolery, a zwracać możesz, co chcesz. Oczywiście w granicach możliwości. Z reguły JSON-a.
Minimal API jest o WIELE prostsze. Definiuje obsługę endpointów bezpośrednio w samych endpointach przez wywołanie metod, lub w lambdach. Odpada cały młyn z kontrolerami i routingiem.

W Minimal API obsługa endpointu wygląda mniej więcej tak:

app.MapGet("prefiks", () => ObsługaEndpointa);

Gdzie prefiks to jest końcówka adresu. To jest cała obsługa instrukcji Get. Nie trzeba dopisywać żadnego routingu itp.
A teraz napisz mi to w MVC z obsługą kontrolera. Zobaczysz różnicę.

@Ajgor: tak i wsparcie dla middleware niepełne, mess pieroński przy dużym API i szereg innych dobrodziejstw. Dobre do ToDo appki albo mikro mikroserwisu

Ajgor napisał(a):

WeiXiao napisał(a):

Przecież Minimal APIs, MVC, i Web API to są małe różnice, polegające głównie na tym gdzie jest kod i co zwraca (html vs json). Naucz się kontrolerów/actionów, routingu, atrybutów lub generalnie całego ASP to Minimal/MVC/Web będą pierdółkami

Nie prawda. Minimal API to jest ZUPEŁNIE coś innego niż MVC. Tam nie ma w ogóle nic takiego, jak kontrolery, a zwracać możesz, co chcesz. Oczywiście w granicach możliwości. Z reguły JSON-a.
Minimal API jest o WIELE prostsze. Definiuje obsługę endpointów bezpośrednio w samych endpointach przez wywołanie metod, lub w lambdach. Odpada cały młyn z kontrolerami i routingiem.

W Minimal API obsługa endpointu wygląda mniej więcej tak:

Kopiuj

app.MapGet("prefiks", () => ObsługaEndpointa);

Gdzie prefiks to jest końcówka adresu. To jest cała obsługa instrukcji Get. Nie trzeba dopisywać żadnego routingu itp.
A teraz napisz mi to w MVC z obsługą kontrolera. Zobaczysz różnicę.

Ja wiem jak wygląda Minimal API, jednakże nadal te różnice są naprawdę niewielkie na poziomie konceptualnym, serio.

To że nie masz żadnego kontrolera nad tym i odpada ci trochę boilerplate to tylko ułatwienie, skrócenie i wywalenie boilerplate kodu, ale mechanizmy i koncepty są takie same.

Nadal masz routing, dependency injection, middlewares, authentication/authorization, parameter binding, filtry itd itd.

Odpada cały młyn z routingiem.

Nie. Routing (mechanizm) nadal występuje i nawet w docsach ASP nt. routingu masz przykłady z użyciem Minimal APIs.

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/routing?view=aspnetcore-8.0

A co masz na myśli przez młyn?