Co jest takiego wyjątkowego w Node.js? [Zamknięte]

Niedawno pojawiło się wiele pochwał dla Node.js. Nie jestem programistą, który miał duży kontakt z aplikacjami sieciowymi. Z mojego własnego zrozumienia Nodes.js wynika, że jego siła: mamy tylko jeden wątek obsługujący wiele połączeń, zapewniając architekturę opartą na zdarzeniach.

Jednak na przykład w Javie mogę utworzyć tylko jeden wątek za pomocą NIO / AIO (który nie jest blokującym interfejsem API z mojego własnego zrozumienia) i obsłużyć wiele połączeń za pomocą tego wątku, a także zapewniam architekturę opartą na zdarzeniach w celu zaimplementowania danych obsługa logiki (nie powinno to być trudne przez zapewnienie oddzwonienia itp.)?

Biorąc pod uwagę, że JVM jest jeszcze bardziej dojrzałą maszyną wirtualną niż V8 (spodziewam się, że będzie również działać szybciej), a architektura obsługi oparta na zdarzeniach wydaje się być czymś trudnym do stworzenia, nie jestem pewien, dlaczego Node.js przyciąga tak wiele uwagi. Czy przegapiłem kilka ważnych punktów?

programming-languages node.js

— Adrian Shum
źródło

Zastanawiam się, dlaczego zostało to zanegowane ... Wydaje mi się, że to pytanie jest raczej dyskusją programistyczną, więc nie wprowadziłem przepływu stosu. Próbowałem także wyszukiwać podobne tematy, ale znalazłem tylko informacje o sile Nodes.js, ale moim problemem jest to, że tak naprawdę nie rozumiem, dlaczego ta siła jest tak wyjątkowa (której wciąż nie mogę znaleźć)

— Adrian Shum

Spróbuj wdrożyć ten wzorzec w Javie. To oczywiście działa. Ale zobaczysz jedno: w Javie będzie bardzo, bardzo gadatliwie: potrzebujesz mnóstwa wywołań zwrotnych, co prawie zawsze oznacza tworzenie nowych klas. Może to zabrzmieć jak drobne szarpnięcie, ale w dużym programie może stać się brzydkie i nietypowo dość szybko.

— Joachim Sauer,

Połączenia zwrotne JavaScript są równie podatne na nieporęczność - a takie spaghetti jest znacznie łatwiejsze do debugowania i refaktoryzacji w Javie niż w JavaScript IMO.

— funkybro

@AdrianShum: jest to efekt slashdot, wszystko, co nie pasuje do sposobu myślenia grupowego, zostanie odrzucone - tak jak chwalenie Microsoft na /.

— gbjbaanb,

Jestem zaskoczony, że nikt nie wspomina o szumie.

— deadalnix

Odpowiedzi:

Chociaż koncepcja ta może być rzeczywiście zaimplementowana w wielu językach (i jak wspomniano dodgy_coder , została zaimplementowana przynajmniej w Ruby i Pythonie), nie jest tak trywialna, jak twierdzisz.

To prawda, że Java ma nieblokujące interfejsy API we / wy. Możesz więc wykonywać surowe operacje dyskowe / sieciowe we / w w sposób nieblokujący. Jednak każdy interfejs API, który w jakiś sposób pakuje lub obsługuje operacje we / wy, musi zostać zaimplementowany również w sposób nieblokujący. Każdy parser XML, każdy sterownik bazy danych, każdy konwerter formatu pliku musi być napisany w celu obsługi nieblokującego We / Wy. Ponieważ jeśli jedna biblioteka blokuje ten wzorzec, obniża to wydajność serwerów do wartości z epoki kamienia.

Node.js ma tę infrastrukturę biblioteczną, ponieważ zawsze była zaprojektowana w ten sposób: każda biblioteka, która chce stać się popularna, musi zapewnić asynchroniczny interfejs API, w przeciwnym razie nie będzie używana.

— Joachim Sauer
źródło

Tak. Innymi słowy: najważniejszą siłą Node.js jest najważniejsza słabość ECMAScript: niesamowicie kiepska standardowa biblioteka ECMAScript. Ponieważ programiści Node.js i tak musieli wymyślić na nowo każde koło, mieli szansę na jego odkrycie we właściwy sposób.

— Jörg W Mittag,

O ile wiem ECMAScript zawsze był zaprojektowany jako język osadzony, więc nie było potrzeby używania interfejsów API na poziomie systemu operacyjnego (nawet sieciowe IO było w większości oderwane). Ten brak był rzeczywiście zaletą dla Node.js.

— Joachim Sauer,

„każda biblioteka, która chce zyskać popularność, musi zapewnić asnyroniczny interfejs API, w przeciwnym razie nie będzie używany”. Myślę, że właśnie tego właśnie szukam. Czy jest jakiś zasób do zbadania, w jaki sposób zapewnia się asynchroniczne API dla, na przykład, parsowania XML i dostępu do DB w Node.js?

— Adrian Shum,

@AdrianShum w ogóle, poszukaj przykładów programowania sterowanych zdarzeniami. Konkretne implementacje można znaleźć w wielu językach. Oprócz modułów Node.js, możesz spojrzeć na Twisted przykłady w Pythonie, twistedmatrix.com/trac/wiki , przykłady POE w Perlu, poe.perl.org , a Ruby ma EventMachine, github.com/eventmachine/eventmachine

— mghicks

Prawdopodobnie głównym powodem jest to, że wykorzystuje JavaScript do pisania komponentów po stronie serwera do takich rzeczy, jak serwery sieciowe, aplikacje internetowe lub usługi sieciowe. Ujednolica to tradycyjny język programowania JavaScript (front-end) po stronie klienta z językiem po stronie serwera.

Masz rację - fakt, że nie jest blokujący, użycie wzorca reaktora nie jest unikalne - zostało to zrobione przed użyciem innych języków i struktur, takich jak na przykład EventMachine Ruby lub Twisted Pythona.

— dodgy_coder
źródło

bardzo niewiele technologii ma naprawdę unikalne cechy, wyjątkowość wynika z ich szczególnego połączenia wszystkich ich cech

— jk.

Zgadzam się, jest tu lista bibliotek, które obsługują ją we wszystkich głównych językach ... Wzór reaktora na Wikipedii

— dodgy_coder,

Trzy główne powody, dla których podałbym to:

Nieblokujące We / Wy / Asynchroniczne We / Wy. Jest to mieszane wszędzie w Internecie i na poprzednich plakatach. Jedną z rzeczy, które chciałbym wnieść do projektu, jest to, że zaprojektowanie kodu tak, aby wyraźnie zakładał zachowanie asynchroniczne, pomaga silnikowi kompilatora w maksymalizacji sprzętu. Tak, wiele kompilatorów JIT i procesorów hyperthreading pobiera kod synchroniczny i pomaga w równoległym wykonywaniu. Jest to oczywiście podejście oparte na najlepszym wysiłku. W przeciwieństwie do jawnego budowania aplikacji do asynchronizacji masz pewność, że silnik i sprzęt mogą zmaksymalizować czas wykonywania kodu. Trzeba przyznać, że nie mam danych, które mogłyby to udowodnić, ale myślenie w ten sposób sprawia, że czuję się ciepło.
Jedna baza kodu dla klienta i serwera. Ma to wiele zalet: pomaga zoptymalizować koszty centrum danych, przenosząc logikę biznesową z serwera na klienta; pomóc ponownie wykorzystać logikę biznesową / sprawdzanie poprawności danych; zmniejszyć złożoność umiejętności programistycznych, które muszą istnieć, aby obsługiwać produkt (w porównaniu do Pythona i javascript).
Niska bariera wejścia. Pod wieloma względami Javascirpt jest jak Basic, Pascal i Perl z zeszłego roku. Rozpoczęcie pisania kodu jest bardzo łatwe i nie wymaga dużej wiedzy na temat domeny. Pomaga to również obniżyć koszty programowania, ponieważ pozwala przyciągnąć więcej programistów jr i przyspieszyć realizację projektu. [Oczywiście musisz ominąć ideologów, którzy uważają, że języki programowania powinny być trudne, aby wyeliminować słabo działających programistów]

— cflat
źródło

Nie jestem pewien, czy poleciłbym zbudowanie zespołu Node w całości z jr. JS devs. Architektura nie jest tak naprawdę czymś, o czym musimy myśleć w projektach web / UI klasy jr, a JS zajmuje tyle czasu, jeśli chodzi o budowanie na długie dystanse, jak każdy inny język, nawet jeśli można uzyskać względnie dobre wyniki szybko przy niższym poziomie doświadczenia w mniej złożonych projektach niż jest to typowe.

— Erik Reppen,

Zgadzam się z @ErikReppen; zespół architektów w całości złożony z młodszych deweloperów (niezależnie od języka) przypomina projektowanie i budowę domu przy użyciu stolarzy, którzy są dobrzy w budowaniu krzeseł, stołów i domów dla psów.

— Wildcard