Node.js Hakkında Çok Benzersiz Nedir? [kapalı]

Son zamanlarda Node.js. için övgüler var. Ağ uygulamasına çok fazla maruz kalmış bir geliştirici değilim. Nodes.js 'nin çıplak anlayışından yola çıkarak, gücü şudur: olaya dayalı bir mimari sağlayan, birden fazla bağlantıyı yöneten sadece bir iş parçacığımız var.

Ancak, örneğin Java’da, NIO / AIO’yu kullanarak (yalnızca benim anladığımdan engellemeyen API’ler) API kullanarak tek bir iş parçacığı oluşturabilir ve bu iş parçacığını kullanarak birden çok bağlantı işleyebilir ve verileri uygulamak için olaya dayalı bir mimari sağlayabilirim. mantıkla başa çıkma (bazı geri aramalar vb. sağlayarak bu kadar zor olmamalı mı)

JVM'nin V8'den daha olgun bir VM olduğu göz önüne alındığında (daha hızlı çalışmasını bekliyorum) ve etkinlik tabanlı işleme mimarisinin yaratılması zor olmayan bir şey gibi görünüyor, Node.js neden bu kadar dikkat çekiyor. Bazı önemli noktaları özledim mi?

programming-languages node.js

— Adrian Shum
kaynak

Neden aşağı indirildiğini merak ediyorum ... Bu sorunun daha çok bir programlama tartışması olduğunu düşünüyorum. Ben de benzer konuları aramaya çalıştım ama sadece Nodes.js'nin gücü ile ilgili bilgiler buldum ama sorunum "kuvvetin" neden bu kadar benzersiz olduğunu anlamıyorum (ki hala bulamıyorum)

— Adrian Shum

Bu kalıbı Java'da uygulamayı deneyin. Elbette çalışıyor. Ancak bir şey göreceksiniz: Java'da çok çok ayrıntılı olacak: tonlarca geri aramaya ihtiyacınız var; bu da neredeyse her zaman yeni sınıflar oluşturmak anlamına gelir. Bu küçük bir nitpick gibi gelebilir, ama büyük bir programda çirkin ve istemeden oldukça hızlı bir şekilde alabilirsiniz.

— Joachim Sauer

Javascript geri aramaları, hantallaşmaya meyillidir - ve bu spagetti, Java'da hata ayıklamak ve yeniden yapılandırmak için Javascript IMO'dan çok daha kolaydır.

— funkybro

@AdrianShum: Bir kesik çizgi etkisi, grup zihniyetine uymayan herhangi bir şeyin indirgenmemesi gibi - Microsoft’u /’ya övmek gibi.

— gbjbaanb

Yutturmacadan bahseden kimseyi görmeme şaşırdım.

— deadalnix

Yanıtlar:

Bu kavram gerçekten birçok dilde uygulanabilir (ve dodgy_coder'da bahsedildiği gibi, en azından Ruby ve Python'da da uygulanmıştır), ancak sizin belirttiğiniz kadar önemsiz değil.

Doğru, Java engelleyici olmayan IO API'larına sahiptir. Böylece ham disk / ağ IO'larını engelleyici olmayan bir şekilde yapabilirsiniz. Ancak , bir şekilde IO'yu tamamlayan veya işleyen her API'nin de engelleyici olmayan bir şekilde uygulanması gerekir. Her XML ayrıştırıcısı, her Veritabanı sürücüsü, her dosya formatı dönüştürücüsünün engelleyici olmayan IO'yu desteklemek için yazılması gerekir. Çünkü eğer tek bir kütüphane bu düzende engelliyorsa, sunucu performansınızı taş devri değerlerine düşürür.

Node.js bu kütüphane altyapısına sahiptir, çünkü her zaman bu şekilde dizayn edilmiştir: popüler olmak için çabalayan her kütüphane asenkron bir API sağlamak zorundadır , yoksa kullanılmayacaktır.

— Joachim Sauer
kaynak

Evet. Başka bir deyişle: Node.js'in en önemli gücü ECMAScript'in en önemli zayıflığıdır: inanılmaz derecede berbat ECMAScript standart kütüphanesi. Node.js geliştiricileri zaten her tekerleği yeniden icat etmek zorunda kaldıklarından, doğru şekilde yeniden icat etme şansları vardı.

— Jörg W Mittag

Bildiğim kadarıyla ECMAScript her zaman gömülü bir dil olarak tasarlanmıştı, bu nedenle herhangi bir işletim sistemi düzeyinde API'ye ihtiyaç duyulmuyordu (hatta ağ IO'su çoğunlukla uzaklaştı. Bu eksiklik gerçekten de Node.js.

— Joachim Sauer

“Popüler olmak için çabalayan her kütüphane asenkron bir API sağlamak zorundadır, yoksa kullanılmayacaktır” Ben tam olarak aradığım şey olduğunu düşünüyorum. Node.js'de örneğin XML ayrıştırma ve DB erişimi için eşzamansız api'nin nasıl sağlandığına bakacak bir kaynak var mı?

— Adrian Shum,

@AdrianShum genel olarak, olay odaklı programlama örnekleri arayın. Özel uygulamalar birçok dilde bulunabilir. Node.js modüllerinin yanı sıra Python'daki Twisted örneklerine, twistedmatrix.com/trac/wiki , Perl'deki POE örneklerine, poe.perl.org ve Ruby'de EventMachine, github.com/eventmachine/eventmachine var

— mghicks

Muhtemelen asıl sebep, web sunucuları, web uygulamaları veya web servisleri için sunucu tarafı bileşenleri yazmak için JavaScript kullanmasıdır. Bu, geleneksel ön uç (istemci tarafı) geliştirme dili JavaScript'i sunucu tarafı diliyle birleştirir.

Haklısınız - bloke edici olmaması, reaktör modelini kullanmak benzersiz değil - örneğin Ruby'nin EventMachine veya Python's Twisted gibi diğer dilleri ve çerçeveleri kullanmadan önce yapıldı.

— dodgy_coder
kaynak

çok az sayıda teknoloji gerçekten benzersiz özelliklere sahip, benzersizlik, tüm özelliklerinin özel kombinasyonlarından geliyor

— jk.

Kabul, burada tüm ana dilleri destekleyen kütüphanelerin listesi var ... Wikipedia'daki Reactor Pattern

— dodgy_coder 19:12

Vereceğim üç ana sebep:

Blokajsız IO / Asenkron IO. Bu, web'de ve önceki posterlerde her yerde toplanır. Katkıda bulunacağım bir şey, kodunuzu, eşzamansız davranışları açıkça üstlenecek şekilde tasarlamanın, derleyici motoruna donanımı en üst düzeye çıkarmasına yardımcı olması. Evet, birçok JIT derleyicisi ve hiper iş parçacığı işlemcisi eşzamanlı kod alır ve uygulamanın paralelleştirilmesine yardımcı olur. Bu elbette en iyi çaba yaklaşımıdır. Buna karşılık, asenkron uygulama için açık bir şekilde uygulama yapılması, motorun ve donanımın kodunuzun yürütme süresini en üst düzeye çıkarmasını sağlar. Kuşkusuz, bunu ispatlamak için ölçülebilir verilerim yok, ama bu şekilde düşünmek için içimde sıcak hissettiriyor.
İstemci ve sunucu için tek kod tabanı. Bunun birçok avantajı vardır: iş mantığını sunucudan istemciye taşıyarak veri merkezi maliyetlerini optimize etmeye yardımcı olur; iş mantığının / verilerin doğrulanmasının yeniden kullanılmasına yardımcı olun; Ürünü desteklemek için var olması gereken geliştirici becerilerinin karmaşıklığını azaltmak (vs. Python ve javascript).
Girişe düşük bariyer. Javascirpt, birçok açıdan, yester-yılın Basic, Pascal ve Perl'i gibidir. Kod yazmaya başlamak çok kolaydır ve başa çıkmak için çok fazla alan bilgisi gerektirmez. Bu aynı zamanda daha fazla jr geliştiricisi getirerek ve bir projeye ayak uydurarak gelişim maliyetlerinizi azaltmanıza yardımcı olur. [Elbette, düşük seviyeli işleyen geliştiricileri ayıklamak için programlama dillerinin zor olması gerektiğine inanan ideologları geçmeniz gerekir]

— cflat
kaynak

Tamamen jr ile bir Node ekibi kurmayı tavsiye edeceğimden emin değilim. JS devs. Mimari daha jr-derece web / UI projelerinde düşünmek zorunda olduğumuz bir şey değil ve JS, göreceli olarak sonuçlar alabilmenize rağmen, diğer dillerin yaptığı gibi uzun mesafe için inşa etme konusunda gerçekten başarılı olmak için uzun sürüyor tipik olandan daha az karmaşık projelerde daha düşük bir deneyim seviyesinde hızlı.

— Erik,

@ErikReppen ile aynı fikirdeyim; Tamamen küçüklerin geliştirdiği bir mimarlık ekibi (dilden bağımsız olarak), sandalyeler, masalar ve köpek evleri inşa etmede iyi olan marangozlar kullanarak bir ev tasarlamak ve inşa etmek gibidir.

— Wildcard