Na forum 4programmers.net korzystamy z plików cookies. Część z nich jest niezbędna do funkcjonowania
naszego forum, natomiast wykorzystanie pozostałych zależy od Twojej dobrowolnej zgody, którą możesz
wyrazić poniżej. Klikając „Zaakceptuj Wszystkie” zgadzasz się na wykorzystywanie przez nas plików cookies
analitycznych oraz reklamowych, jeżeli nie chcesz udzielić nam swojej zgody kliknij „Tylko niezbędne”.
Możesz także wyrazić swoją zgodę odrębnie dla plików cookies analitycznych lub reklamowych. W tym celu
ustaw odpowiednio pola wyboru i kliknij „Zaakceptuj Zaznaczone”. Więcej informacji o technologii cookie
znajduje się w naszej polityce prywatności.
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.
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.
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.
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
Node to nie tylko JS, zresztą nawet w JSie masz całkiem znośną kontrolę typów jak masz JSDocsy
Kontrolę podczas pisania z pomocnymi bajerami typu podpowiedzi czy faktyczny dowód poprawności typów?
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
Usunąć wpis?
Tej operacji nie będzie można cofnąć.
Zakręcony Samiec
Zakręcony Samiec
1
Zamiast Node wybrałbym Python i Ruby, przyjemniejsze języki.
Usunąć wpis?
Tej operacji nie będzie można cofnąć.
Nieposkromiony Terrorysta
Nieposkromiony Terrorysta
0
W Node.js mozesz pisac w Typescripcie i tez masz kontrole typów....
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.
"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
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ą.
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 :)
Możliwe że jakoś to się wiąże nawet ze Spring Boot (Java, nie mylić z JavaScript).
Usunąć wpis?
Tej operacji nie będzie można cofnąć.
Trzeźwy Ogórek
Trzeźwy Ogórek
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.
@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.
@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.
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.
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?
nohtyp