ASP.NET vs Node.js

ASP.NET vs Node.js
0

Node.js zyskuje na popularności na rynku międzynarodowym, jak i w Polsce. Jest tutaj ktoś pracujący lub mający styczność z Node.js? Jakie są wasze doświadczenia z tą technologią?

Node.js czy asp.net? co jest "przyjemniejsze" w pisaniu i czytelniejsze w analizie kodu? Słyszałem, że Node.js jest "szybki w pisaniu" - wymaga mniej pisania kodu w porównaniu do starszych frameworków, jak asp.net czy Spring.

teez
  • Rejestracja:ponad 8 lat
  • Ostatnio:ponad 4 lata
  • Postów:122
0

Trochę tak.. co ma piernik do wiatraka? W korpo wybiorą ASP.NET z powodu stabilności. W startupach node.js, bo hype i dużo się o tym mówi.

Z resztą Nodejs to nie framework, a środowisko (trochę jak JRE dla javy). Ciężko określić czy pisze się na nim mniej/więcej kodu - zależy od frameworka. Ale z resztą co to za cecha? Kompletnie bym się tym nie kierował w wyborze.

edytowany 1x, ostatnio: teez
NO
  • Rejestracja:ponad 7 lat
  • Ostatnio:ponad 5 lat
  • Postów:165
1

To zależy.

Do pełnoetatowej pracy wybrałbym asp.net, ponieważ praca to zakres 8 godzin więc szybkość klepania niczego nie zmieni.

Poza tym weź pod uwagę, że kody w pracy częściej się czyta więc lepiej wybrać coś co oszczędzi nerwów.

Natomiast prywatnie do własnych projektów wybrałbym node.js z lumo https://github.com/anmonteiro/lumo

0
nohtyp napisał(a):

To zależy.

Do pełnoetatowej pracy wybrałbym asp.net, ponieważ praca to zakres 8 godzin więc szybkość klepania niczego nie zmieni.

Poza tym weź pod uwagę, że kody w pracy częściej się czyta więc lepiej wybrać coś co oszczędzi nerwów.

Natomiast prywatnie do własnych projektów wybrałbym node.js z lumo https://github.com/anmonteiro/lumo

A dlaczego do prywatnych projektów wybrałbyś node.js, a nie .net ? :)

NO
Bo szybko zrobisz w nim prototyp, i sprawdzisz czy Twój pomysł na sens.
code4tag
  • Rejestracja:ponad 7 lat
  • Ostatnio:około 5 lat
  • Postów:3
0

Szukam kogoś kto dobrze ogarnia nodejs i jest z Wrocławia. Szukam brakującego ogniwa do uzupełnienia zespołu - od zaraz.

0
code4tag napisał(a):

Szukam kogoś kto dobrze ogarnia nodejs i jest z Wrocławia. Szukam brakującego ogniwa do uzupełnienia zespołu - od zaraz.

Dlaczego do wykonania projektu wybraliście własnie node.js? :)

code4tag
  • Rejestracja:ponad 7 lat
  • Ostatnio:około 5 lat
  • Postów:3
0

Z prostego względu - urządzenie które używamy ma najbardziej zaawansowany framework właśnie w nodejs. Ba! Nodejs jest jako oficjalna składowa SDK dla tego urządzenia.

rubaszny_karp
zmieńcie urządzenia.
NO
somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:4 dni
  • Lokalizacja:Wrocław
0
Złoty Rycerz napisał(a):

Node.js czy asp.net? co jest "przyjemniejsze" w pisaniu i czytelniejsze w analizie kodu? Słyszałem, że Node.js jest "szybki w pisaniu" - wymaga mniej pisania kodu w porównaniu do starszych frameworków, jak asp.net czy Spring.

Nie wydaje mi się, aby tego kodu było jakoś znacząco mniej. Za to możliwość statycznego dowiedzenia poprawności typów w przypadku C# sprawia, że jest mniej debugowania.

Maciej Cąderek
Maciej Cąderek
Node to nie tylko JS, zresztą nawet w JSie masz całkiem znośną kontrolę typów jak masz JSDocsy
somekind
Kontrolę podczas pisania z pomocnymi bajerami typu podpowiedzi czy faktyczny dowód poprawności typów?
Maciej Cąderek
Maciej Cąderek
No Haskell to to nie jest - można osiągnąć poziom zbliżony do TypeScriptu - typy łącznie z generykami, inferencją, wsparcie IDE, możesz sobie to normalnie dodać do pipeline'a by wywaliło builda jak coś jest nie tak (dzięki tsc, który od wersji 2.3 wspiera też JSa) - choć oczywiście JSDocsy nie są tak wygodne jak dedykowana składnia
1

Zamiast Node wybrałbym Python i Ruby, przyjemniejsze języki.

0

W Node.js mozesz pisac w Typescripcie i tez masz kontrole typów....

Wibowit
  • Rejestracja:prawie 20 lat
  • Ostatnio:około 2 godziny
3

Statyczne typowanie to nie tylko sprawdzanie sporej klasy błędów automatycznie przez kompilator ale także lepsza statyczna analiza i niezawodne transformacje kodu. Siedząc nad zadaniami w projekcie w korpo zdecydowaną większość czasu spędzam na analizie i przerabianiu kodu, a nie na klepaniu nowego, więc bardziej liczą się takie rzeczy jak solidna nawigacja, refaktoring i wykrywanie błędów niż szybkość naklepania nowego kawałka kodu.

Kiedyś już podawałem wyliczenia dotyczące szybkość klepania kodu, ale przedstawię jeszcze raz. Sprawdźmy jak szybko trzeba klepać nowy kod, by naklepać milion linii kodu w ciągu 10 lat w 10-osobowym zespole (tzn 10 programistów) - jest to wariant bardzo optymistyczny (tzn moim zdaniem zakłada wysoką wydajność klepania kodu). Milion linii kodu podzielone przez 100 roboczolat (10 lat * 10 osób) daje 10 tysięcy linii kodu rocznie. Zakładając 200 dni roboczych daje to 50 linii kodu dziennie. Ile czasu może zająć samo dorzucanie 50 nowych linii kodu? Nawet zakładając, że jak prototypuję nowy kod to przepisuję go 3x to wychodzi 150 linii kodu na dzień. Te 150 linii mogę naklepać spokojnie w godzinę. Jak widać, w ogólnej perspektywie w wieloletnim projekcie szybkość klepania nowego kodu ma niewielkie znaczenie. Większe znaczenie ma szybkość wdrożenia się w projekt, przerobienia go zgodnie z nowymi założeniami i zapewnienia stabilności.

Szybkość klepania kodu liczy się jeśli na rynku otwiera się nowa nisza i chcemy być w niej pierwsi, zdążyć przed konkurencją. Wtedy mamy wyścig z czasem i np czytelność kodu ma drugorzędne znaczenie. Kod staje się syfny i prawdopodobnie trzeba go będzie w niedalekiej perspektywie czasowej zaorać. Z drugiej strony typowe korpo-projekty mają następujące cechy:

  • trwają wiele lat (np > 10 lat, a w takim czasie ekosystem Node.js zdąży się przepoczwarzyć kilka razy)
  • zespół programistów dynamicznie się zmienia, tzn ludzie ze stażem w projekcie odchodzą, a na ich miejsce przychodzą ludzie, którzy będą się w projekt dopiero wdrażać
  • cały czas trzeba naprawiać błędy i dodawać nowe funkcjonalności
  • założenia projektu się zmieniają i np okazuje się, że wolumen danych jest 10x albo 100x większy niż pierwotnie zakładano albo że trzeba wprowadzić konfigurowalność tam gdzie wcześniej opierano się na uproszczeniach
  • przepisanie projektu od zera jest równoznaczne z klęską obecnego podejścia, więc modernizację systemu trzeba przeprowadzać stopniowo równolegle z poprawkami błędów i dodawaniem nowych funkcjonalności

Kiedyś ktoś tu podawał historie o sukcesie Node.js chyba w Netfliksie, który miał stawiać wiele mikroserwisów opartych o Node.js. Szczegółów chyba jednak wielu nie było. Niedawno natomiast w mojej firmie menedżer podniecał się innym zespołem, który podobno zarządzał kilkunastoma mikroserwisami i wdrażał nowe wersje co chwilę. Menedżerowi to zaimponowało, bo my co prawda też mamy kilkanaście mikroserwisów, ale wdrażanie nowych wersji jest nieco bolesne (nie wdrażamy sobie ich ot tak, tylko przygotowujemy zestaw paczek w sumie kilka dni). Na spotkaniu z gościem z tego zespołu okazało się, że ich kilkanaście mikroserwisów to nie jest jeden rozproszony system, a kilkanaście małych niezależnych aplikacji popierdółek (a skoro są niezależne to oczywiście nie będzie problemu z podbijaniem wersji pojedynczo i bez synchronizacji między aplikacjami). Wszelakie cudowne historyjki (hype) trzeba więc weryfikować i zadać sobie przede wszystkim pytanie jakie ktoś problemy rozwiązywał, a nie jak modne jest jego narzędzie.


"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.
Zobacz pozostałe 9 komentarzy
rubaszny_karp
@Wibowit: na przykład tak że możesz nie mieć tabeli XD
Wibowit
? dodawanie tabel jest w skryptach z migracjami.
rubaszny_karp
"Dlatego kod jest zmieniany, a tuż przed odpaleniem nowej wersji aplikacji jest odpalana migracja na bazie danych" - nie masz tabeli, nie masz problemów z polami w tabeli - #nosqlteamhere
Wibowit
Jakieś tam migracje zawsze są. Nawet jak zapisuję obiekty w JSONie to przecież schemat JSONa może się zmienić i trzeba będzie tłumaczyć między jedną postacią, a drugą.
rubaszny_karp
ale migrujesz jak zmieniasz niekompatybilnie.
Aventus
  • Rejestracja:około 9 lat
  • Ostatnio:ponad 2 lata
  • Lokalizacja:UK
  • Postów:2235
3

Ja zdecydowanie wybieram .Net (szczególnie Core) nawet do mniejszych projektów. Wymieniona wcześniej statyczna analiza i silne typowanie znacznie ułatwiają życie. Ponadto nie uważam że Node.js to mniej kodu- przecież walnięcie szybkiego API w Wep API to kwestia dodania jednej klasy kontrolera. A jak ktoś nie lubi Web API zawsze można użyć Nancy czy co tam jeszcze jest.

Poza tym jeśli mam wybierać między JS a C# wybór zawsze padnie na ten drugi :)


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
vpiotr
  • Rejestracja:ponad 13 lat
  • Ostatnio:prawie 3 lata
1

O architekturze w Netflix więcej się słyszy niż o architekturze w jakiejkolwiek innej firmie.
Mają swój GitHub: https://netflix.github.io/
(patrz np. chaos monkey)
Ich architektura prezentowana jest jako przykład dla mikroserwisów:
https://www.optisolbusiness.com/insight/micro-services-architecture-spring-boot-and-netflix-infrastructure
https://www.slideshare.net/stonse/microservices-at-netflix
https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/

Nagrali nawet kilka prezentacji:

Możliwe że jakoś to się wiąże nawet ze Spring Boot (Java, nie mylić z JavaScript).

0

Ale czemu nikt nie bierze pod uwagi charakteru pracy ?
Node.js - więcej pracy w tworzeniu/rozwoju funkcjonalności.
Natomiast w .NET więcej jest pracy w utrzymaniu istniejącego kodu.

Aventus
  • Rejestracja:około 9 lat
  • Ostatnio:ponad 2 lata
  • Lokalizacja:UK
  • Postów:2235
0

@trzezwy ogorek: ciężko powiedzieć, masz jakieś statystyki? Z własnego doświadczenia trudno obiektywnie ocenić. Ja np. pracowałem przy projektach pisanych od zera i backend jest w .Net.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
0
Aventus napisał(a):

@trzezwy ogorek: ciężko powiedzieć, masz jakieś statystyki? Z własnego doświadczenia trudno obiektywnie ocenić. Ja np. pracowałem przy projektach pisanych od zera i backend jest w .Net.

Nie mam statystyk, ale wnioskuje tak z wypowiedzi użytkowników :D
dużo osób narzekało, że Java/.net to praca w utrzymaniu starych, korporacyjnych systemów.

1
Trzeźwy Ogórek napisał(a):

Ale czemu nikt nie bierze pod uwagi charakteru pracy ?
Node.js - więcej pracy w tworzeniu/rozwoju funkcjonalności.
Natomiast w .NET więcej jest pracy w utrzymaniu istniejącego kodu.

Czyli nikt już nie będzie mówił, że node się nadaje do dużych aplikacji, pisanych przez długi czas? To nawet lepiej.

somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:4 dni
  • Lokalizacja:Wrocław
5

Jestem ciekaw, co za 5-10 lat powiedzą masterzy greenfielda jak w Nodzie powstanie już tyle softu, że praca będzie głównie przy utrzymaniu.
Swoją drogą, to co to za programista, który boi się utrzymywać kod. Może lepiej takiemu zostać architektem?

0
code4tag napisał(a):

Szukam kogoś kto dobrze ogarnia nodejs i jest z Wrocławia. Szukam brakującego ogniwa do uzupełnienia zespołu - od zaraz.

Hej trafiłem tu przypadkiem, może się przydam jak jeszcze szukacie ogniwa.
fordtransit@wp.pl.

code4tag
  • Rejestracja:ponad 7 lat
  • Ostatnio:około 5 lat
  • Postów:3
0
Trusi napisał(a):
code4tag napisał(a):

Szukam kogoś kto dobrze ogarnia nodejs i jest z Wrocławia. Szukam brakującego ogniwa do uzupełnienia zespołu - od zaraz.

Hej trafiłem tu przypadkiem, może się przydam jak jeszcze szukacie ogniwa.
fordtransit@wp.pl.

jasne! Wysłałem maila na tego w odpowiedzi, jakby co zapraszam do kontaktu (dane w stopce na naszej stronie) code4tag.eu

edytowany 1x, ostatnio: code4tag

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.