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.
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
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 ? :)
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? :)
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.
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.
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:
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.
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 :)
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).
@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.
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.
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.
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?
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.
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
nohtyp