Gerçek zamanlı olmayan web uygulamaları için node.js kullanmaktan kaçınmak için iyi bir neden var mı?

Node.js'nin gerçek zamanlı web uygulamaları için ne kadar harika olduğu hakkında çok fazla konuşma gördüm - soket, Comet, AJAX-yoğun iletişim vb. Olay odaklı, asenkron, iş parçacıklı sürüş modelinin düşük ek yük ile eşzamanlılık için de iyi olduğunu biliyorum.

Ayrıca, daha basit, 'geleneksel', gerçek zamanlı olmayan uygulamalar için Node.js eğitimlerini de gördüm (örneğin, uygulama geliştirmeyi öğrenen insanlar için standart 'Merhaba Dünya' gibi görünen standart blog örneği). Ayrıca düğüm statik'in statik varlıklar sunmanıza izin verdiğini de biliyorum.

Sorum şu: ilanlar, forumlar, yukarıda belirtilen blog örneği veya dahili işletme uygulamaları için oluşturduğunuz CRUD uygulamaları türü gibi geleneksel web uygulamaları için Node.js'den kaçınmak için herhangi bir neden var mı? Sırf tüm tuhaf gerçek zamanlı işlerde üstün olduğu için, bu daha sabit kullanımlar için kontrendike mi oluyor?

Düşünebildiğim tek şey, yarasa dışında, olgun kütüphanelerin olmayışı (ki bu değişiyor olsa da).

(Soruyorum sebebi değil, aynı zamanda ben doğrulama kodunu ve etajer yeniden böylece, node.js için PHP ditching düşünüyorum çoğunlukla dil arasında geçiş empedans uyumsuzluğu üzerinden almak olmasıdır. Benim süperego beni admonishes seçim iş için en iyi araç , ancak onbeş dil öğrenmek için çok fazla zamanım yok ve tüm kullanıcı kütüphanelerini kapsamlı bir cephaneye sahip olmak için çok fazla zamanım yok.Node.js'nin bana PHP'den daha kolay bir optimizasyon yolu verebileceğine dair güven verici. Gelecekte Apache yoğun trafik hakkında düşünmeye başladığımda.)

[EDIT] Şimdiye kadarki cevaplar için teşekkürler millet; Cevap seçmeden önce başka birinin tartıştığını görmek istiyorum. @Raynos türünün cevabı ne düşündüğümü doğrular ve yorum yapanların bağlantıları düşünce için iyi bir yemek sunar, ancak 'SORUN İÇİN NODE KULLANMAYIN' gibi, başka herhangi bir Düğüme özgü cevapları olup olmadığını görmek istiyorum. '. (Yüksek CPU görevlerinin yanı sıra, biliyorum zaten :-)

geleneksel web uygulamaları için Node.js'i önlemek için iyi bir neden var mı?

Evet, web platformunda N yılınız varsa, açıkça X platformunda bir uygulamayı daha hızlı geliştirebilirsiniz.

Eğer Y yapmak istiyorsanız ve platform X'de X'i yapan önceden hazırlanmış bir Y çözümü var.

Neden bir platform diğerinde kullanmanız gerektiğine dair tüm genel sebepler.

dahili iş uygulamaları için oluşturduğunuz CRUD uygulamalarının türü?

Evet, daha hızlı bir jenerik uygulama yazmanıza izin veren başka bir platform var, raylarda yakut akla geliyor.

Ancak, dedi. Düğümle ilgili deneyimim var ve benim için kutunun dışında çok fazla özellik bulunmadığı sürece, düğüm üzerinden başka bir platform seçeceğimi iddia edemem.

Temelde basit bir soru

Tüm bunları benim için yapan bir araç var mı? Hayır, sonra aracı yazmak için en uygun platformu seçin.

Node.js'nin uygunsuz bir platform olmasının kesin bir nedeni yoktur ("javascript'ten nefret ediyorum" dışında)

Düğümle birkaç hafta çalıştıktan sonra evet derim, çok havalı. Ancak, değirmencilik web uygulamalarınızı değiştirmek için kullanmak isteyeceğiniz bir şey olması gerekmez ... ya da imo olması gerektiği gibi değildir.

Unutmayın, düğüm kendi sunucusudur. Yalnızca bir node.js uygulamanızdan daha fazlasını çalıştırmak istiyorsanız, bu karmaşıklığı ortaya çıkarır. yani, bir makinede barındırılan birden fazla site / etki alanı varsa. Aynı sunucudan çalışan yarım düzine farklı alan için bir düzine PHP uygulamasına sahip olabileceğiniz bir LAMP yığını gibi değil (en azından 80 numaralı bağlantı noktasında). Düğüm için büyük olasılıkla mümkün kılan çerçeveler vardır, ancak geleneksel web platformlarına takılırsanız ihtiyaç duymadığınız karmaşıklığı da eklersiniz. (Tabii ki, ayrıca bir web sunucusunu düğümün önüne koyarak proxy'ler de kurabilirsiniz, ancak bu tür düğüm kullanmanın faydasını yitirir).

imo, Node geleneksel bir web sunucusu ile birlikte çalışmak için idealdir . Şimdi düzenlenmiş şeylere sahip olmamın yolu, apache üzerinden statik html / js / resimlerini sunmak ve düğüm uygulamasına uzun süre başvurarak 'gerçek zamanlı' veri ihtiyaçlarını karşılamaktır.

Düğümle ilgili saniyeler düşünmek için iyi bir neden teknik değildir - ne yaptığıyla ilgili harika ve şaşırtıcı.

İş dünyası ve özellikle insan sermayesi, yani bunu bilen programcılar, ne kadara mal oldukları ve bulunabilirliği Öğrenmesi o kadar zor değil, ama yeni bir teknolojide olduğu gibi, onu iyi tanıyan (veya bunu isteyen) insan sayısı, daha büyük işçi havuzlarının bir altköküdür.

Bu, sanat durumunu ilerletmek için de sormamız gereken çok iyi bir sorudur.

Node.JS'nin sınırlarının nerede olduğunu bilmek çok merak ettim (Paul d'Aoust gibi). Ne yazık ki, birçok cevap öznel yanlılığın TAMI ve geçici olarak ilgili mantığa sahiptir.

Kendime sordum: HEDEF KONUŞUYLA BİRLİKTE FİLTRE VE BU İLGİLİ SORUya CEVAP VERMEK İÇİN AŞAĞIDA GİDER Mİ?

Kalan noktalar şöyle görünüyor:

1. DüğümJS Geleneksel Çerçeveler kadar olgun değildir. Paul d'Aoust’un önerdiği gibi, bu tam olarak kaçınmak için değil, geçici inceleme ve durum tespiti için geçici bir sebep. Ödevimizi web uzmanları olarak yapmak beklenir ve teknolojinin kuruma, onların ihtiyaçlarına, geleceklerine, takıma (bize değil) en uygun olanı belirlemek bizim işimizdir. Vade netlik için bir ihtiyaç ve risk için iştah için bir karardır, fakat kaçınmamaktır.

2. Proxy Sunucusu Olarak NodeJS. Akıllıca bir öneri, tartışma öncesi, incelemeye ve değerlendirmeye değer bir şey. Düğümün bir ön uç arayüz proxy tasarım deseni olarak mevcut teknolojilerle bağlantılı olarak kullanılması kavramıdır. Fakat aynı zamanda, düğümü kullanarak AVOID'in bir nedeni değil, bunun yerine tam yerini almaktan kaçınmak için bir nedendir. Bunun yerine bir eş yaklaşım yaklaşımı tercih ediyor.

3. Hata Ayıklama Düğümü. Joyent'teki çekirdek Düğüm geliştiricileriyle yapılan görüşmelerde hata ayıklanabilirliği çevreleyen ve çekirdekten kaynaklanan sorunların kök nedenini geriye doğru takip eden çok fazla karmaşıklık var (tek diş açma ve geçmiş iş parçacıklarını görememe temelinde). Bu dikkate almaya ve değerlendirmeye değer - ancak (tekrar) büyük olasılıkla zarfı zorlayabilecek kenarlı durumlar için genel kullanımdan kaçınılmaz. Belki sizin özel ihtiyaçlarınız bu kategoriye girer ve belki onlar olmaz.

4. İnsan Kaynakları. Bu sayfadaki JS'yi kullanmaktan AVOID'in en iyi sebebi budur ve alçakgönüllü görüşüme göre bu kesin ve uygunsuz bir gerçektir. Asıl soru şu: Şirketiniz projeyi tüm yaşam döngüsü boyunca görebilecek yetenekli profesyonellere sahip mi? Değilse, NodeJS'den kaçınmanız gereken hiçbir soru yoktur. Veya bunun yerine A) doğru yeteneği bulmak, veya B) Mevcut yeteneği geliştirmek.

Şikayetler: JavaScript hakkındaki şikayetler hakkındaki gözlemim, birçoğunun Kullanıcı Hatası'ndan, dilin tutarlı bir şekilde başarısız olmasından daha fazla kaynaklandığıdır. "The Nefret JavaScript Diatribe" a karşı birçok hakaretten deşifre ettik ve çok daha fazla borçlandırmaya devam edeceğiz. Gibi sorunlar - belgeler yeterince iyi değil, yeterince seksi değil, ama insanlar bundan hoşlanmıyor, kanser, şeytan ya da çok "yazım hatası" (-CRichardson), öznel ve Doğru kurumsal karar alma için çıkarılması gereken önyargılı şikayetler.

Sonunda, doğru cevap olabilir - AVOID NodeJS için iyi bir neden yoktur . Belki de bu yüzden hızlı bir büyüme, evlat edinme ve katkı yapıyor. Ancak, hepimiz için belki de buradaki cevap, NodeJS'yi daha iyi değerlendirmeye, araştırmaya ve anlamaya devam etmek - ve somut isteksizliklere bakmaktır. Node.JS'nin nerede olgunlaşmamış olduğunu tam olarak anlamaya açık olmak için - onu daha iyi hale getirmek için tam olarak nerede ihtiyacımız olduğunu buluruz. Ve bu bir nimettir.

İyi soru. Birisi, NodeJS'den kaçınmak için daha iyi bir sebep bulmaya çalışan birini merak ediyor.

Gerçek zamanlı olmayan uygulamalar için X düğümü kullanmanın bir yararı var mı:

• Ölçeklendirme : Düğüm iyi performansa sahip ancak diğer platformlar da var; PHP, Ruby, Python ve Java her ölçekte. BÜYÜK isimleri milyonlarca kullanıcıyla birlikte bulabilirsiniz.
• Ön uç ve arka uç için bir dil : Bu bir şaka, tıpkı Java'nın "Bir kez her yerde yaz" gibi
• Sıcak ve seksi : Tek geçerli nokta. Ancak hiç kimse web sitenizin sinirli teknolojiyi kullanmasını umursamıyor!

Gerçek zamanlı olmayan uygulamalar için Node over X kullanmanın avantajı:

• En İyi Uygulama : Düğüm yeni olduğu için, özellikle CRUD web uygulamaları için, diğer platformlardan daha az en iyi uygulamalara sahiptir.
• Javascript Dili : İnsanlar Javascript'i sevmiyor. Node.js sıcakken, Javascript değildir. Bu yüzden insanlar istemci tarafı için bile Javascript yazmaktan kaçınmak için Coffeescript'i yarattı.
• Gelişme Hızı : Rails ve Django dahil ancak bunlarla sınırlı olmamak üzere eski ve sıkıcı çerçeveler, CRUD web siteleri için uzun yıllar boyunca iyi test edilmiş ve geliştirilmiştir. Düğümde benzer uygulamaları uygulayabilseniz de, büyükbabanız çerçevesinde yapmanız çok daha kolay.
• Kararlılık : Düğümün web çerçeveleri daha hızlı bir şekilde daha iyi hale geliyor. Değişiyorlar ve yakın gelecekte daha fazla API uyumsuzluğuna sahip olacaklar.
• Kütüphaneler ve araçlar : Daha fazla kullanıcılı eski teknolojilerin daha fazla kütüphanesi ve aracı vardır.

Cevabım kesinlikle 2015 yılında geçerli olmayacak. 2014 yılında, gerçek zamanlı olmayan web uygulamaları için Düğüm atla, ancak bir göz atın.

Her web çerçevesinin güçlü bir noktası vardır. Bu nokta için kullanırken mutlu olacaksınız. Gerçek zamanlı olmayan web uygulamaları, Düğüm'ün web çerçeveleri için güçlü bir nokta değildir.

Node.js çok popüler bir platformdur ve çok sayıda ilginç özelliği vardır, falan filan, ama bir aracın kullanımı kişisel bir tercihtir. Node.js'ye dört kez verdim ve bundan memnun değildim. İşte nedenlerim. Lütfen bu nedenlerden bazılarının eski olduğunu veya sadece kişisel olduğunu unutmayın: P

• Farklı dil / sözdizimi tercih ettim (Python, Scala'yı seviyorum, en sevdiğim dil Prolog yani evet).
• Kullandığım çerçeveler ve kütüphaneler için dokümantasyon kalitesi Java, Scala, Python kütüphaneleri için iyi değil.
• Düğüm tasarımcıları, olay modeli, gözlemci veya gelecek işlemleri yerine geri aramalara oldukça takıntılıdır.
• 2005'te geri geliştirilen Ruby, Python, Java'da yapmak istediklerim için hazır çözümler var, sadece config dosyasını düzenlemeliyim.

HTTP durumsuzdur, dolayısıyla gerçek zamanlı olmayan bir web uygulaması gibi bir şey yoktur ve bu nedenle her şey için düğümü kullanamamanız için hiçbir neden yoktur.

Bununla birlikte, düğüm belirli bir uygulama mimarisi türü için daha uygundur. PHP biraz kod içeren html dosyalarıdır. Düğüm isteğe bağlı olarak bir miktar html içeren koddur.

Bu, uygulamanızın herhangi bir istemci tarafı komut dosyası olmadan standart html formları olması durumunda PHP'nin daha kolay olacağı anlamına gelir. Düğüm şablonlama araçlarına sahiptir, ancak açıkçası PHP gibi olgun bir şey değildir.

Çok sayıda istemci tarafı komut dosyanız varsa ve verileri ajax ile kaydederseniz, sunucuda statik bir html istemcisi çağırma işlevine sahip olursunuz. Bu tam olarak düğümün iyi olduğu şeydir. CRUD uygulamalarının genellikle inşa edilme şekli olmasa da, doğru çerçeveyle oldukça hoş bir şey üretebilirsiniz.