17 Soru: Node.js'in ne zaman kullanılacağına nasıl karar verilir?

tarafından oluşturulan soru Fri, Nov 2, 2018 12:00 AM

Bu tür şeylerde yeniyim, ancak son zamanlarda ne kadar iyi olduğu hakkında çok şey duydum Node.js 'dir. Genel olarak jQuery ve JavaScript ile çalışmayı ne kadar sevdiğimi göz önünde bulundurarak, Node.js. Aklımdaki web uygulaması Bitly - biraz içeriyor - biraz içeriyor, arşivliyor.

Son birkaç gündür yaptığım bütün ev ödevlerinden aşağıdaki bilgileri aldım. Node.js

  • , normal bir web sunucusu olarak çalıştırılabilen ve birinin JavaScript programlarını çalıştırmasını sağlayan bir komut satırı aracıdır
  • harika V8 JavaScript motorunu kullanır
  • aynı anda birkaç şey yapmanız gerektiğinde çok iyidir
  • etkinliğe dayanıyor, bu yüzden tüm harika Ajax benzeri şeyler yapabilir sunucu tarafında yapılması
  • , tarayıcı ile arka uç arasında kod paylaşmamıza izin veriyor
  • MySQL ile konuşmamıza izin verir

Karşılaştığım kaynaklardan bazıları:

Node.js’nin Amazon’un EC2’sindeki neredeyse kullanıma hazır olduğunu göz önünde bulundurarak a> örnekler, PHP , Python ve Ruby . Bunun gerçekten bir dilin sahip olduğu uzmanlığa bağlı olduğunu biliyorum, ancak sorum daha genel bir kategoriye giriyor: Belirli bir çerçeve ne zaman kullanılmalı ve özellikle ne tür problemler için uygundur?

    
2199
  1. Bu soru meta üzerinde tartışılıyor ( meta.stackoverflow.com /q /332386/497418 ).
    2016-08-16 16: 34: 24Z
17 Yanıtlar                              17                         

Node.js. ile ilgili harika şeyleri özetleyerek harika bir iş çıkardınız. Benim düşünceme göre, Node.js özellikle tarayıcıdan sunucuya kalıcı bir bağlantı kurmak istediğiniz uygulamalar için uygundur. "uzun sorgulama" olarak bilinen bir teknik kullanarak, güncelleme gönderen bir uygulama yazabilirsiniz gerçek zamanlı olarak kullanıcıya. Ruby on Rails veya Django , her aktif istemci bir sunucu işlemi yediğinden, sunucuya çok fazla yük yükler. Bu durum bir tarpit saldırısına karşılık geliyor. Node.js gibi bir şey kullandığınızda, sunucunun her açık bağlantı için ayrı iş parçacıkları korumaya ihtiyacı yoktur.

Bu, tarayıcı tabanlı sohbet uygulaması , pek çok müşteriye hizmet vermek için neredeyse hiçbir sistem kaynağına ihtiyaç duymuyor, bu kadar uzun süre oylama yapmak istediğinizde, Node. js harika bir seçenek.

Ruby ve Python'un her ikisinin de bu tür bir şeyi yapmak için araçlara sahip olduğunu belirtmek gerekir ( eventmachine ve bükülmüş , ancak Node.js bunu son derece iyi ve temelden yapıyor. JavaScript, geri arama tabanlı eşzamanlılık modelinde son derece iyi bir konuma sahiptir ve burada öne çıkmaktadır. Ayrıca, JSON yerli ile hem istemciye hem de sunucuya serileştirme ve seri hale getirme oldukça şık.

Burada diğer cevapları okumak için sabırsızlanıyorum, bu harika bir soru.

Node.js’in, istemci /sunucu boşluğu boyunca çok fazla kodu yeniden kullanacağınız durumlar için de harika olduğunu belirtmek gerekir. Meteor çerçevesi bunu gerçekten kolaylaştırır ve birçok kişi bunun web geliştirmenin geleceği olabileceğini öne sürüyor. Teceor'dan, Meteor'da kod yazmanın çok eğlenceli olduğunu söyleyebilirim ve bunun büyük bir kısmı, verilerinizi nasıl yeniden yapılandıracağınızı düşünmek için daha az zaman harcamaktır, böylece tarayıcıda çalışan kod kolayca görüntülenebilir. manipüle ve geri ilet.

Piramit ve uzun sandık hakkında bir yazı, gevent'ten biraz yardım almanın çok kolay olduğu ortaya çıktı: TicTacToe ve Pyramid ile Uzun Çağırma .

    
1358
2014-05-14 15: 56: 33Z
  1. Evet, 'node.js'nin özellikle tarayıcıdan sunucuya sürekli bağlantı gerektiren uygulamalar için uygun olduğunu düşünmenin çok önemli olduğunu düşünüyorum. - sohbet programları veya etkileşimli oyunlar gibi 'Eğer biri mutlaka kullanıcı /sunucu iletişimine ihtiyaç duymayacak bir uygulama geliştiriyorsa, başka çerçevelerle birlikte geliştirmek iyi olacak ve daha az zaman alacaktır.
    2011-09-27 07: 03: 27Z
  2. Bunun için teşekkürler ... Harika Q ve A ;-) Hem ön hem de arka uç geliştirme için mükemmel bir teknolojiye hakim olmak konusunda da düşünürdüm birkaç farklı şeyden daha fazlası;)
    2013-01-08 11: 27: 05Z
  3. Neden uzun sorgulama kullanıyorsunuz? Geleceğe ne oldu ve soketler ?
    2016-02-11 07: 46: 43Z
  4. Kısa cevabım arka plan işlemidir. İstek ve yanıtlama (dinlenme API'si dahil) hepsine başka bir dilde ve sunucuda ulaşılabilir. Yani web projelerini düğüme dönüştürmeyi düşünenler için. Tekrar düşün aynı şey! Düğümü, imap ile e-postaları okumak, görüntü işleme, dosyaları buluta yükleme veya çoğunlukla olaya yönelik uzun veya hiç bitmeyen işlemler gibi bir arka plan işlemi olarak kullanın ...
    2016-03-20 12: 27: 35Z

Node.js'nin gerçek zamanlı uygulamalar için en uygun olduğuna inanıyorum: çevrimiçi oyunlar, ortak çalışma araçları, sohbet odaları veya bir kullanıcının (veya robot? veya sensör?) uygulamanın diğer kişiler tarafından görülmesi gereken herhangi bir şey olduğu kullanıcıları, sayfa yenilemeden hemen.

Ayrıca Socket.IO'nun Node.js ile birlikte kullanılmasının, gerçek zamanlı gecikme sürenizi uzun oy kullanmada mümkün olandan daha da azaltacağını da belirtmeliyim. Socket.IO, en kötü durum senaryosu olarak uzun oylamaya geri dönecek ve bunun yerine web soketleri veya varsa Flash bile kullanacak.

Ancak, sadece iş parçacığı nedeniyle kodun engellenebileceği herhangi bir durumdan Node.js. Ya da uygulamanın etkinliğe yönlendirilmesi gereken herhangi bir durum.

Ayrıca, Ryan Dahl bir konuşmada, bir keresinde Node.js kriterlerinin düzenli olarak eski HTTP istekleri için Nginx ile yakından karşılaştığına katıldığımı söyledi.Dolayısıyla Node.js ile derlersek, normal kaynaklarımızı oldukça etkin bir şekilde hizmet edebiliriz ve olaya dayalı olaylara ihtiyaç duyduğumuzda, kullanıma hazırdır.

Artı her zaman her şey JavaScript'tir. Lingua Franca bütün yığında.

    
409
2011-02-21 06: 43: 31Z
  1. Sadece .Net ve Node arasında geçiş yapan birinden bir gözlem, Sistemin farklı bölgeleri için farklı diller, içerik değiştirirken çok yardımcı olur. Javascript'e bakarken, İstemcide çalışıyorum, C #, App Server, SQL = veritabanı anlamına gelir. Boyunca Javascript'te çalışırken, kendimi katmanları karıştırırken ya da bağlamsal geçiş için daha uzun zaman harcadığımı gördüm. Bu muhtemelen tüm gün .NET yığını üzerinde çalışmanın ve geceleri Noding yapmanın bir eseridir, ancak bir fark yaratıyor.
    2015-09-08 15: 29: 48Z
  2. İlginç bir şekilde, ana akım ve yerel kültürler arasında hareket ederken lehçeleri değiştiren kültürlerarası bireylerin uygulamasına "kod değiştirme" denir.
    2015-09-08 15: 31: 10Z
  3. Geçen gün farklı .js dosyalarıma nasıl farklı renkler atayabileceğimi düşünüyordum. İstemci tarafı için yeşil, sunucu tarafı için mavi. Kendimi "kaybetti" alıyorum.
    2015-12-30 18: 46: 28Z

NodeJS kullanma nedenleri:

  • Javascript'i çalıştırır, böylece sunucuda ve istemcide aynı dili kullanabilirsiniz ve hatta aralarında bazı kodlar paylaşabilirsiniz (örneğin, form doğrulama için veya her iki uçta da görünümler oluşturmak için). )

  • tek iş parçacıklı olaya dayalı sistem, şu durumlarda bile olsa hızlı geleneksel çoklu iş parçacıklı Java veya ROR çerçeveleri.

  • NPM yoluyla erişilebilen paketlerinin sürekli büyüyen havuzu , dahil istemci ve sunucu tarafı kitaplıkları /modülleri, ayrıca web geliştirme için komut satırı araçları. Bunların çoğu elverişli bir şekilde github'da barındırılıyor, burada bazen bir sorunu bildirebilir ve birkaç saat içinde bulabilirsin! Standartlaştırılmış sorun bildirme ve kolay çatallama ile her şeyin tek bir çatı altında olması güzeldir.

  • Görev koşucuları, küçükleştiriciler, güzelleştiriciler dahil olmak üzere Javascript ile ilgili araçlar ve diğer web ile ilgili araçlar 'ın çalıştırıldığı varsayılan standart olmayan bir ortam haline gelmiştir. linkler, önişlemciler, paketleyiciler ve analitik işlemciler.

  • Prototip oluşturma, çevik gelişim ve hızlı ürün yinelemesi için oldukça uygun görünüyor.

NodeJS'i kullanmanın nedenleri değil :

NodeJS'yi seviyorum, hızlı ve vahşi ve eğlenceli, ancak ispatlanabilir doğruluğa ilgisinin az olduğu konusunda endişeliyim. Umarız sonunda iki dünyanın da en iyisini birleştirebiliriz. Gelecekte Düğümün yerini alacak olanı görmeye istekliyim ... :)

    
209
2017-05-23 10: 31: 35Z
  1. @ nane Evet, bu konuyu ele alabileceklerini düşünüyorum, ancak daha sonra yalnızca typeafe dilinde yazılmış kütüphaneleri kullanmak için kendinizi sınırlandırmanız gerekir kod tabanınızın tümü 'nin statik olarak yazılmadığını kabul edin. Ancak bir argüman geçerli: dilden bağımsız olarak kodunuz için iyi testler yazmanız gerektiğinden, dinamik olarak yazılmış kodlar için bile güven düzeyiniz eşit olmalıdır . Bu argümanı kabul edersek, güçlü yazma işleminin avantajları, geliştirme /hata ayıklama süresi, üretilebilirlik ve optimizasyon 'a yardım etmeye indirgenir .
    2015-08-23 16: 46: 06Z
  2. @ kervin, bazı kıyaslamaların harika olacağını kabul ediyorum, ancak çevrimiçi bulabildiğim şeyden hayal kırıklığına uğradım. Bazıları, .NET performansının Düğümlerle karşılaştırılabilir olduğunu, ancak bunun çok önemli olduğunu savundu. sen gerçekten yapıyorsun Düğüm, çok sayıda eşzamanlı bağlantıya sahip küçük iletiler sağlama konusunda harika olabilir, ancak ağır matematiksel hesaplamalar için çok iyi olmayabilir. İyi bir performans karşılaştırmasının çeşitli durumları test etmesi gerekir.
    2015-08-23 16: 59: 25Z
  3. @ joeytwiddle daha büyük karmaşık programları ve statik yazım denetlemesini işlemek söz konusu olduğunda Typescript, Node.js'ye yardımcı olmaz mıydı?
    2015-09-03 06: 33: 44Z
  4. 2015-11-03 12: 38: 08Z
  5. Rayları düğümle karşılaştırarak bir platformu bir çerçeveyle karıştırıyorsunuz. Raylar, Ruby'nin Sails ve meteor gibi Javascript için çerçeveler olduğu gibi bir çerçevedir.
    2016-02-26 15: 10: 29Z

Kısa yapmak için:

Node.js, çok sayıda eşzamanlı bağlantıya sahip uygulamalar için çok uygundur ve her istek yalnızca çok az CPU döngüsü gerektirir, çünküBir işlevin yürütülmesi sırasında t döngüsü (diğer tüm istemcilerle birlikte) engellenir.

Node.js'deki olay döngüsü hakkında iyi bir makale Mixu'nun teknoloji blogu: node.js olay döngüsünü anlama .

    
207
2014-03-14 18: 20: 25Z

Node.js. kullandığım gerçek dünyadan bir örneğim var. Çalıştığım şirket basit bir statik HTML web sitesine sahip olmak isteyen bir müşteriye sahipti. Bu web sitesi PayPal 'ı kullanarak bir öğe satmak içindir ve müşteri de bu bilgileri gösteren bir sayaç almak istedi. satılan malların miktarı. Müşterinin bu web sitesini çok sayıda ziyaretçisinin olması bekleniyor. Sayacı Node.js ve Express.js çerçevesini kullanarak yapmaya karar verdim.

Node.js uygulaması basitti. Satılan ürün miktarını Redis veritabanından alın, ürün satıldığında sayacı artırın ve sayaç değerini kullanıcılara API ile gönderin.

Bu durumda Node.js'i kullanmayı seçmemin bazı nedenleri

  1. Çok hafif ve hızlı. Üç hafta içinde bu web sitesinde 200000'den fazla ziyaret yapıldı ve en az sunucu kaynağı hepsini kullanabildi.
  2. Sayaç, gerçek zamanlı olmak için gerçekten kolaydır.
  3. Node.js yapılandırması kolaydı.
  4. Ücretsiz olarak sunulan çok sayıda modül vardır. Örneğin, PayPal için bir Node.js modülü buldum.

Bu durumda, Node.js harika bir seçimdi.

    
127
2014-03-14 18: 23: 57Z
  1. Böyle bir şeyi nasıl barındırıyorsunuz? O zaman üretim sunucusunda nodejs kurmanız gerekiyor mu? Linux'ta mı?
    2014-04-14 15: 25: 20Z
  2. nodejitsu ve Heroku gibi birkaç PaaS var. Ya da gerçekten de amazon ec2'den bir linux box üzerine düğüm kurabilirsiniz. bakınız: lauradhamilton.com/...
    2015-07-15 23: 17: 26Z
  3. 1.814.400 saniye içinde 200.000 ziyaret. Hiç alakalı değil. Bash bile en yavaş sunucuda bu kadar çok talebi yerine getirebilir. Kazı kazan sunucusu. En yavaş VM.
    2016-05-01 10: 52: 01Z

Bir sonraki projenize Düğüm kullanarak başlamak için en önemli nedenler ...

  • Tüm havalı adamlar onun içinde ... bu yüzden eğlenceli olmalı.
  • Soğutucuda Hangout yapabilir ve övünmek için çok sayıda Düğüm macera yaşayabilirsiniz.
  • Bulut barındırma maliyetleri söz konusu olduğunda bir kuruş avcısısınız.
  • Orada Rails ile yaptım
  • IIS dağıtımlarından nefret ediyorsunuz
  • Eski BT işiniz oldukça sıkıcı olmaya başlıyor ve yeni bir Start Up'da olmanızı diliyorum.

Ne bekleniyor ...

  • İhtiyacınız olmayan tüm sunucu yazılımı olmadan Express ile kendinizi güvende ve emniyette hissedeceksiniz.
  • Roket gibi koşar ve iyi ölçeklenir.
  • Hayalini kuruyorsun. Sen kurdun. Düğüm paketi repo npmjs.org , dünyadaki en büyük açık kaynak kitaplık ekosistemidir.
  • Beyniniz, yuvalanmış geri aramaların diyarında zaman çarpacak ...
  • ... Sözler 'inizi korumayı öğrenene kadar a>.
  • Sequelize edin ve Pasaport yeni API arkadaşlarınızdır.
  • Çoğunlukla eşzamansız kod hata ayıklaması umm ... terleme .
  • Tüm Noder'in Typescript 'e hakim olma zamanı.

Kim kullanıyor?

105
2016-08-16 10: 14: 20Z
  1. Evet, bu soruyu geleneksel şekilde cevaplayabilirdim. Sanırım bunu yapmaya yetkinim var ama çoğu zaten söylendi ve hafif yürekli bir eğlencenin monotonluğu bozacağını düşündüm. Diğer sorulara düzenli olarak teknik cevaplar ekliyorum.
    2014-06-14 04: 24: 25Z
  2. iç içe geçmiş geri çağırmalardan, zaman uyumsuz kod için ES6 üreteçleri kullanılarak önlenebilir
    2016-05-19 12: 25: 09Z
  3. @ CleanCrispCode: Evet, gerçekten de! ES6, C # stili async /await'u benimsemiştir, bu nedenle şimdi geleneksel try /catch'u da destekleyen daha temiz bir zaman uyumsuz Düğüm kodu açabiliriz. 2016 /17'de JS kodlayıcıları ES6'ya geçiyor.
    2016-05-20 00: 12: 29Z
  4. on binlerce kez "Bu, daha önce ihtiyaç duymadığınız tüm sunucu yazılımı olmadan Express ile kendinizi güvende ve emniyette hissedeceksiniz"
    2016-07-27 08: 19: 18Z

Silver Bullet gibi bir şey yok. Her şey onunla ilgili bazı maliyetler ile birlikte geliyor. Yağlı yemek yiyorsanız, sağlığınızı tehlikeye atacaksınız ve sağlıklı yiyecekler yağlı yiyecekler gibi baharatlarla gelmiyor. Yiyeceklerinde olduğu gibi sağlık ya da baharat istemeleri de bireysel seçimdir. Aynı şekilde Node.js, belirli senaryoda kullanılmayı düşünmektedir. Uygulamanız bu senaryoya uymuyorsa, uygulama geliştirmeniz için düşünmemelisiniz. Ben sadece düşüncelerimi aynı üzerine yazıyorum:

Node.JS Ne Zaman Kullanılmalı

  1. Sunucunuzun yan kodu çok az cpu döngüsü gerektiriyorsa. Diğer dünyada engelleme yapmayan bir işlem yapıyorsunuz ve çok fazla CPU çevrimi tüketen ağır bir algoritma /İş yok.
  2. Javascript’ten geri gelmişseniz ve aynı istemci tarafı JS gibi Tek Dişli kod yazarken rahatsanız

Node.JS kullanmıyorken

  1. Sunucu isteğiniz yoğun CPU tüketen algoritmaya /İşe bağlıdır.

Node.JS ile Ölçeklendirilebilirlik Değerlendirmesi

  1. Node.JS, temel sistemin tüm çekirdeğini kullanmaz ve varsayılan olarak tek iş parçacıklıdır, çoklu çekirdekli işlemciyi kullanmak ve çoklu iş parçacıklı hale getirmek için kendi başınıza mantık yazmanız gerekir.

Düğüm.JS Alternatifleri

Node.JS yerine kullanmak için başka bir seçenek var, ancak Vert.x oldukça ümit verici görünüyor ve bunun gibi pek çok ek özelliği var polgot ve daha iyi ölçeklenebilirlik konuları.

    
60
2016-08-13 18: 46: 35Z
  1. "Sunucu tarafı isteğiniz" Kullanmadığınızda "bölümünde listeleniyorsa, Dosya GÇ veya Soket G /Ç işlemleri gibi engelleme işlemleri içeriyorsa, emin değilim. Anlayışım doğruysa, node.js'nin güçlü yönlerinden biri, engelleme yapmadan GÇ işlemesi için güçlü asenkronize araçlara sahip olmasıdır. Dolayısıyla Node.js, IO'yu engellemek için "bir tedavi" olarak görülebilir.
    2013-05-24 13: 00: 41Z
  2. @ OndraPeterka: Node.js sunucusunun IO'yu engelleme konusunda haklısın, ancak kendi isteğini sunucuda kendiniz engelleme çağrısı yapıyorsa diğer web servisi /Dosya işlemi, Node.js burada yardımcı olmaz. Yalnızca sunucuya gelen isteklerde IO'yu engellemiyor, ancak uygulama isteği işleyicinizden giden istek için değil.
    2013-06-05 07: 28: 34Z
  3. @ ajay, nodejs.org 'dan "olmayan" G /Ç’nin engellenmesi, lütfen "NOT NOT" 2 ve 3’ünüzü kontrol edin.
    2013-06-06 08: 23: 59Z
  4. geçerli sürümde, düğüm aslında küme kullanarak çok çekirdekli desteği destekler. Bu gerçekten Düğüm uygulaması performansını en az iki kez artırıyor. Bununla birlikte, performansın küme lib'lerini sabitlerken, iki kattan daha fazla olması gerektiğini düşünüyorum.
    2013-09-12 20: 05: 17Z
  5. Ağır hesaplama için node.js dosyasını kullanabilirsiniz. fork'u kullanın. stackoverflow.com nasıl oluşturulur? /sorular /9546225 /... . Düğüm, cluster modülüyle çok sayıda çekirdeği işler. nodejs.org/api/cluster.html
    2014-05-14 19: 44: 33Z

Nem.js hakkında hiç kimsenin bahsetmediği bence bir başka harika şey ise muhteşem topluluk, paket yönetim sistemi (npm) ve sadece ekleyerek dahil edebileceğiniz modüllerin miktarıdır. onları package.json dosyanızda.

    
41
2013-06-06 17: 42: 29Z
  1. Ve bu paketlerin hepsi nispeten taze, bu nedenle hindsight avantajına sahipler ve son web standartlarına uyma eğilimindedirler.
    2013-07-19 21: 46: 12Z
  2. Tüm saygımla npm'de çok fazla paket var çünkü > npm paket puanlama mekanizmasına sahip değildir . Hindsight, CPAN 'dan gelen herkes?
    2014-02-13 13: 45: 19Z
  3. çok kötü web kitaplıkları kütüphanelerinin hiçbiri rfc 6455 belirtimlerini karşılayamaz. node.js fanboys'u, bu gerçek verildiğinde sağır, dilsiz ve kördür.
    2014-08-01 06: 32: 05Z
  4. Yorumun ne zaman yapıldığını bilmiyorum ama şu andan itibaren ws kütüphanesi bu özelliği destekliyor
    2014-11-10 04: 14: 06Z

Benim parçam: nodejs, analitik, sohbet uygulamaları, apis, reklam sunucuları vb. gibi gerçek zamanlı sistemler oluşturmak için mükemmeldir. Cehennem, ilk sohbet uygulamamı nodejs ve socket.io ile 2 saatten az bir süredir sınavda yaptım. hafta!

Düzenle

Düğümleri kullanmaya başladığımdan bu yana birkaç yıl geçti ve bunu statik dosya sunucuları, basit analizler, sohbet uygulamaları ve daha birçok şey gibi birçok farklı şey yapımında kullandım. Bu benim nodejs'i ne zaman kullanmam gerektiğidir

Ne zaman kullanılır?

Eşzamanlılık ve hıza önem veren bir sistem yaparken.

  • Yalnızca sohbet uygulamaları, irc uygulamaları, vb. gibi sunucuları sokar
  • Coğrafi konum, video akışı, ses akışı vb. gibi gerçek zamanlı kaynaklara önem veren sosyal ağlar
  • Küçük bir veri topluluğunu bir analitik webapp gibi gerçekten hızlı bir şekilde işleme koyma.
  • Yalnızca bir REST gösteriliyorsa api.

Ne zaman kullanılmayacağına

Çok yönlü bir web sunucusudır, böylece istediğiniz yerde kullanabilirsiniz, ancak muhtemelen bu yerlerde değil.

  • Basit bloglar ve statik siteler.
  • Sadece statik bir dosya sunucusu olarak.

Sadece nitpicking yaptığımı unutmayın. Statik dosya sunucuları için, apache daha yaygın olarak bulunabildiğinden daha iyidir.nodejs topluluğu yıllar içinde daha da büyüdü ve olgunlaştı ve kendi barındırma tercihiniz varsa, düğümlerin hemen hemen her yerde kullanılabileceğini söylemek güvenlidir.

    
37
2014-09-12 13: 07: 38Z
  1. Basit bloglar hala Node.js. Statik dosyalar sunmak için hala Node.js kullanabilirsiniz ve eğer yük artarsa, geçerli en iyi uygulamalara göre Nginx ters proxy ekleyin. Apache httpd sunucusu ölmekte olan bir dinozordur - bkz. bu Netcraft anketi .
    2016-01-05 09: 53: 05Z
  2. Aksi takdirde şunu söyleyebilirim: ghost.org , harika görünüyor ve NodeJ'lerin üzerine kurulmuş - işbirliği, gerçek zamanlı makale düzenleme. Ayrıca, NodeJ’lerde basit bir sayfa oluşturmak, sailsjs.org 'u kullanmak kolay, hızlı ve yapmanız gerekmez Sunucu tarafı programlama dillerinden herhangi birini öğrenerek kendinizi rahatsız edin
    2016-06-16 09: 52: 28Z

Nerede kullanılabilir

  • Çok fazla etkinlik gerektiren uygulamalar & yoğun G /Ç bağlı
  • Diğer sistemlerle çok sayıda bağlantıyı yöneten uygulamalar
  • Gerçek zamanlı uygulamalar (Node.js, gerçek zamanlı olarak sıfırdan başlayarak tasarlanmıştır ve kolay olacak şekilde tasarlanmıştır. kullanmak için.)
  • Başka kaynaklardan gelen ve gelen kaynaklardan gelen bilgi paylaşımını engelleyen uygulamalar
  • Yüksek trafik, Ölçeklenebilir uygulamalar
  • Platform API'siyle konuşması gereken mobil uygulamalar & Çok fazla veri yapmak zorunda kalmadan veritabanı analitiği
  • Ağa bağlı uygulamalar oluşturun
  • Çok sık konuşması gereken uygulamalar çok sık sona erecek

Mobil cephesinde, prime-time şirketler mobil çözümleri için Node.js'ye güvendiler. Nedenini kontrol et?

LinkedIn tanınmış bir kullanıcı. Tüm mobil yığınları Node.js. Her fiziksel makinede 15 sunucuyla 15 sunucuyu çalıştırmaktan, trafiği iki katına çıkarabilen sadece 4 örneğe gittiler!

eBay , HTTP API’leri için bir web sorgusu olan ql.io’yu başlattı. hangi çalışma zamanı yığını olarak Node.js kullanır. Her bir bağlantı yaklaşık 2kB bellek harcayarak her bir düğümde 120.000'den fazla etkin bağlantıyı işlemek için normal geliştirici kalitesinde bir Ubuntu iş istasyonunu ayarlayabildiler!

Walmart , mobil uygulamasını Düğüm kullanacak şekilde yeniden tasarladı .js ve JavaScript işlemesini sunucuya itti.

Daha fazla bilgi için: http: //www. pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

    
30
2015-12-17 17: 01: 42Z

Eşzamanlı istek işleme için en iyi düğüm -

Öyleyse, bir hikaye ile başlayalım. Son 2 yıldan beri JavaScript üzerinde çalışıyorum ve web sayfasını geliştiriyorum ve bundan keyif alıyorum. Arka uçtaki çocuklar bize Java’da yazılmış bazı API’ler veriyorlar, python (umrumda değil) ve sadece bir AJAX çağrısı yazıyoruz, verilerimizi alıyoruz ve tahmin et ne oldu! İşimiz bitti. Fakat gerçekte bu o kadar kolay değil, Elde ettiğimiz veriler doğru değilse veya bir sunucu hatası varsa, o zaman sıkışıp kaldık ve arka uç adamlarımızla posta veya sohbet üzerinden iletişime geçmeliyiz (bazen whatsApp de :).) Bu havalı değil. API’mızı JavaScript’te yazdıysak ve bu API’yı ön uçtan çağırırsak ne olur? Evet, bu oldukça havalı, çünkü API’de herhangi bir sorunla karşılaşırsak, içine bakabiliriz. Bil bakalım ne oldu ! Bunu şimdi yapabilirsin Nasıl? - Düğüm sizin için var.

Tamam, sana yazabileceğini kabul etti.ur url javascript ama peki ya yukarıdaki problemim varsa. Geri kalan API için düğümü kullanmak için başka bir nedeniniz var mı?

yani işte sihir başlıyor. Evet, düğümü API’lerimiz için kullanmak için başka nedenlerim var.

Engelleme işlemini veya iş parçacığını temel alan geleneksel dinlenme API sistemimize geri dönelim. İki eşzamanlı isteğin (r1 ve r2) oluştuğunu varsayalım, bunların her birinin veritabanı işlemi gerektirdiğini varsayalım. Yani geleneksel sistemde ne olacak:

1 . Bekleme Yolu: Sunucumuz r1 istek sunmaya başlar ve sorgu yanıtını bekler. r1 tamamlandıktan sonra, sunucu r2 hizmet vermeye başlar ve aynı şekilde yapar. Dolayısıyla beklemek iyi bir fikir değil çünkü çok fazla zamanımız yok.

2 . Threading Way: Sunucumuz, r1 ve r2 istekleri için iki iş parçacığı oluşturur ve veritabanını çok hızlı bir şekilde sorguladıktan sonra amaçlarına hizmet eder. Ancak bellek tüketir, çünkü iki iş parçacığını da başlattığımızı görebilirsiniz; Aynı verileri sorguluyorsa, kilitlenme tür sorunlarıyla başa çıkmak zorundasınız. Bu yüzden beklemekten daha iyi ama yine de sorunlar var.

Şimdi burada, düğüm bunu nasıl yapacak:

3 . Nodeway: Aynı eşzamanlı istek düğüme geldiğinde, geri çağrısı ile bir olayı kaydeder ve ileriye doğru hareket eder, belirli bir istek için sorgu yanıtı beklemez. bu amaca hizmet eden düğümdeki bir olay döngüsü.) geri çağırma işleviyle bir olayı kaydeder ve r1 isteğini yerine getirmek için ilerlemeye devam eder ve olayı geri çağırma ile benzer şekilde kaydeder. Herhangi bir sorgu bittiğinde ilgili olayı tetikler ve kesintiye uğramadan geri arama işlemini tamamlanana kadar yürütür.

Öyleyse beklemek yok, iş parçacığı yok, bellek tüketimi yok - evet, dinlenme API'sini sunmanın önündeki yol bu değil.

    
20
2015-01-16 21: 00: 15Z
  1. Merhaba Anshul. Kilitlenmenin iş parçacığı şeklinde nasıl olabileceğine dair bir kaynak hazırlayabilir veya önerebilir misiniz?
    2015-03-14 17: 10: 24Z

Yeni bir proje için Node.js'i seçmem için bir neden daha şöyledir:

Saf bulut tabanlı bir geliştirme yapabilmek

Bir süredir Cloud9 IDE kullandım ve şimdi hayal bile edemiyorum, tüm geliştirme yaşam döngülerini kapsıyor. İhtiyacınız olan tek şey bir tarayıcı ve herhangi bir cihazda istediğiniz zaman istediğiniz yerde kodlayabilirsiniz. Kodları bir Bilgisayarda (evde olduğu gibi), sonra başka bir bilgisayarda (iş yerinde olduğu gibi) kontrol etmeniz gerekmez.

Elbette, başka diller veya platformlar için bulut tabanlı bir IDE olabilir (Cloud 9 IDE, diğer diller için de destek ekler), ancak Node.js geliştirmesini yapmak için Cloud 9 kullanmak benim için gerçekten harika bir deneyim.

    
16
2014-02-18 08: 14: 59Z
  1. Aslında Cloud9 IDE ve diğerleri (kullandığımı kodlayan) hemen hemen her tür web dilini destekler.
    2015-02-24 18: 40: 12Z
  2. Ciddi misin dostum? Bir yığın seçmek için kriterler bu mu? :) mutlu senin için çalışıyor!
    2015-03-18 20: 15: 28Z

Düğümün sağladığı bir başka şey daha, düğümün alt sürecini kullanarak birden fazla v8 düğüm noktası oluşturma yeteneğidir () her biri dokümanlar için 10 MB bellek gerektiriyor) anında, böylece sunucuyu çalıştıran ana işlemi etkilemiyor. Bu yüzden büyük sunucu yükü gerektiren bir arka plan işini boşaltmak çocuk oyuncağı haline gelir ve gerektiğinde onları kolayca öldürebiliriz.

Düğümü çok kullanıyorum ve oluşturduğumuz uygulamaların çoğunda sunucu bağlantıları gerekiyorAynı zamanda yoğun bir ağ trafiği dolayısıyla. Express.js ve yeni Koajs (geri aramaları kaldıran) gibi çerçeveler cehennem) düğüm üzerinde çalışmayı daha da kolaylaştırdı.

    
15
2014-06-08 14: 27: 17Z

Asbest longjohns donon ... ...

Dün Packt Publications ile başlığım, JavaScript ile Reaktif Programlama . Gerçekten Node.js merkezli bir başlık değil; ilk bölümler teoriyi ve daha sonra kod ağırlıklı bölümleri uygulamayı kapsamaktadır. Okuyuculara bir web sunucusu vermede başarısız olmanın uygun olacağını düşünmedim, çünkü Node.js bariz bir seçim olarak çok görünüyordu. Dava açılmadan önce kapatıldı.

Node.js. ile deneyimim hakkında çok pembe bir görüş verebilirdim. Bunun yerine karşılaştığım iyi noktalar ve kötü noktalar konusunda dürüsttüm.

Buraya alakalı birkaç alıntı ekleyeyim:

  

Uyarı: Node.js ve ekosistemi sıcaktır - sizi çok yakacak kadar yeter!

     

Matematik öğretmeni asistanlığı yaparken, bana söylenmeyen açık önerilerden biri, bir öğrenciye bir şeyin “kolay” olduğunu söylememekti. Bunun nedeni, geçmişe bakıldığında biraz açıktı: insanlara bir şeyin kolay olduğunu söylerseniz bir çözüm görmeyen biri, aptallık hissine kapılabilir (çünkü daha da aptal), çünkü sadece problemi nasıl çözeceklerini anlamamakla kalmaz, aynı zamanda anlayamayacakları kadar aptal olan problem de kolay olur!

     

Herhangi bir şeyi değiştirirseniz, derhal kaynağı yeniden yükleyen Python /Django'dan gelen insanları rahatsız etmeyen şeyler var. Node.js ile, varsayılan davranış, bir değişiklik yaparsanız, eski sürümün zamanın sonuna kadar veya sunucuyu manuel olarak durdurup yeniden başlatana kadar etkin olmaya devam etmesidir. Bu uygunsuz davranış sadece Pythonistas'ı rahatsız etmez; Ayrıca çeşitli geçici çözümler sunan yerel Node.js kullanıcılarını da rahatsız eder. StackOverflow sorusu “Node.js'deki dosyaların otomatik olarak yeniden yüklenmesi” sorusu, bu yazının yazıldığı sırada 200'ün üzerinde oy ve 19 yanıt vermiş; bir düzenleme, kullanıcıyı bir dadı komut dosyasına yönlendirir, node-süpervizör, ana sayfasını http://tinyurl.com/reactjs-düğüm-amiri . Bu sorun yeni kullanıcıları aptal hissetme fırsatı buluyor, çünkü sorunu düzelttiklerini düşünüyorlardı, ancak eski, araba davranışları tamamen değişmedi. Ve sunucuyu zıplamayı unutmak kolaydır; Bunu çok defa yaptım. Ve vermek istediğim mesaj, “Hayır, aptal değilsin çünkü Node.js'nin bu davranışı arkanı ısırdı; Sadece Node.js tasarımcılarının burada uygun davranış sağlamak için hiçbir neden göremedikleri bir durum. Düğüm amirinden veya başka bir çözümden biraz yardım alarak, onunla baş etmeye çalışın, ama lütfen aptal olduğunuzu hissetmeyin. Sorunlu sen değilsin; bu sorun Node.js’nin varsayılan davranışında. ”

     

Bu bölüm, bazı tartışmalardan sonra, kesinlikle “Kolay” izlenimini vermek istemediğim için kaldı. İşlerim sırasında işlerimi yaparken ellerimi tekrar tekrar kestim ve pürüzsüzleştirmek istemiyorum. zorlukları aşın ve sizi Node.js ve ekosisteminin iyi çalışmasını sağlamanın basit bir mesele olduğuna ve sizin için kolay olmadığı takdirde ne yaptığınızı bilmiyorsunuz. Node.js'i kullanırken iğrenç zorluklarla karşılaşmazsanız, bu harika. Bunu yaparsanız, “Ben aptalım - bende yanlış olan bir şey olmalı” hissini ortadan kaldırmazsınız, Node.js. ile ilgili kötü sürprizlerle karşılaşırsanız aptal değilsinizdir. Sen değilsin! Node.js ve ekosistemi!

Son bölümlerdeki yükselen crescendo'dan ve sonuçtan sonra gerçekten istemediğim Ek, ekosistemde ne bulabildiğim hakkında konuşup moronik bir gerçekçilik için bir geçici çözüm sağladı:

  

Mükemmel bir uyum gibi görünen ve henüz kullanılamayacak başka bir veritabanı, HTML5 anahtar /değer deposunun sunucu tarafındaki bir uygulamasıdır. Bu yaklaşım, en iyi ön uç geliştiricilerin yeterince iyi anlayabildiği bir API'nin temel avantajına sahiptir. Bu konuda, pek de iyi olmayan ön uç geliştiricilerin yeterince iyi anladığı bir API. Ancak node-localstorage paketi ile sözlük sözdizimi erişimi sunulmazken (localStorage.setItem (anahtar, değer) veya localStorage.getItem (anahtar), localStorage [anahtar] değil, varsayılan localStorage semantiği, varsayılan 5 MB kota dahil olmak üzere uygulanır; NEDEN? Sunucu tarafı JavaScript geliştiricilerin kendilerinden korunmaları mı gerekiyor?

     

Müşteri tarafı veritabanı yetenekleri için, web sitesi başına 5 MB'lık bir kota, geliştiricilerin onunla çalışmasına izin vermek için gerçekten cömert ve kullanışlı bir nefes alma odasıdır. Çok daha düşük bir kota koyabilir ve geliştiricilere çerez yönetimi ile birlikte aksama konusunda ölçülemez bir iyileşme sunabilirsiniz. 5 MB'lık bir limit, Big Data müşteri tarafı işlemesine çok hızlı bir şekilde borç vermez, ancak becerikli geliştiricilerin çok fazla şey yapabileceği oldukça cömert bir ödenek vardır. Ancak, diğer taraftan, 5 MB son zamanlarda herhangi bir zamanda satın alınan çoğu diskin özellikle büyük bir kısmı değildir; bu, eğer siz ve bir web sitesi, disk alanını makul bir şekilde kullanmanın ne olduğu konusunda ya da bir sitenin sadece hoggish olduğu konusunda hemfikir olmanız anlamına gelir. Çok fazla ve sabit diskiniz zaten dolu olmadığı sürece bir sabit disk sürücüsü için tehlike altında değilsiniz. Belki bakiye biraz daha az ya da biraz daha fazla olsaydı daha iyi durumda olurduk, ama genel olarak müşteri tarafı bağlamında içsel gerilime değinmek iyi bir çözümdü.      

Ancak, sunucunuz için bir kod yazarken, veritabanınızı 5 MB'tan daha büyük bir ölçekten daha fazla yapmaktan başka bir korumaya gerek duymayacağınız açıkça belirtilebilir. Çoğu geliştirici, dadı görevi yapan ve 5 MB'tan fazla sunucu tarafı verilerini depolamaktan koruyan araçlara ihtiyaç duymaz ve istemez. Ve istemci tarafında altın dengeleyici bir hareket olan 5 MB'lık kota Node.js sunucusunda biraz aptalca. (Ve bu Ek'te ele alınanlar gibi birden fazla kullanıcı için bir veritabanı için, her kullanıcı hesabı için diskte ayrı bir veritabanı oluşturmazsanız, kullanıcı hesabı başına 5 MB olmadığına, biraz acı verici bir şekilde belirtilebilir; tüm kullanıcı hesapları bir araya gelir. Viral yaparsanız bu acı verebilir olabilir!) Dokümantasyon kotanın özelleştirilebilir olduğunu, ancak geliştiriciye bir hafta önce kotanın nasıl değiştirileceğini soran bir e-postanın cevapsız olduğunu belirtir. aynı şeyi soran StackOverflow sorusuydu. Bulduğum tek cevap, yapıcıya isteğe bağlı ikinci tamsayı argümanı olarak listelendiği Github CoffeeScript kaynağında. Böylece, bu kadar kolaydır ve diske veya bölüm boyutuna eşit bir kota belirleyebilirsiniz. Ancak, anlam ifade etmeyen bir özelliği göstermenin yanı sıra, araç yazarı, bir tamsayının bazı kaynak kullanımı için maksimum bir sınır belirleyeceği bir değişken veya işlev için “sınırsız” anlamına gelen 0 yorumunun çok standart bir kuralını takip etmekte tamamen başarısız olmuştur. Bu yanlış özellik ile yapılacak en iyi şey muhtemelen kotanın Sonsuz olduğunu belirtmektir:

 r2

İki yorumu sırayla değiştirme:

  

İnsanlar bir bütün olarak JavaScript'i kullanarak sürekli bir şekilde kendilerini ayağından vurdular ve JavaScript'in saygın bir dil haline gelmesinin bir parçası, Douglas Crockford'un özünde şöyle diyordu: “Bir dil olarak JavaScript'in gerçekten iyi ve bazı gerçekten kötü kısımları var. İşte güzel parçalar. Başka bir şeyin orada olduğunu unutma. ”Belki de sıcak Node.js ekosistemi,“ Node.js ekosistemi bir Batı Batı'yı kodluyor, ”diyecek olan kendi “ Douglas Crockford ”una sahip olacak Bulunması gereken bazı gerçek taşlar. İşte bir yol haritası. Neredeyse hiçbir ücret ödemeden kaçınılması gereken alanlar. HERHANGİ BİR dilde veya ortamda bulunabilecek en zengin ödemelerin bazılarının bulunduğu alanlar. ”

     

Belki başka birileri bu kelimeleri bir meydan okuma olarak alabilir ve Crockford’un liderliğini takip edebilir ve Node.js ve ekosistemi için “iyi parçalar” ve /veya “daha ​​iyi parçalar” yazabilir. Bir kopyasını alırdım!

     

Tüm projelerdeki coşku ve saf çalışma saatleri göz önüne alındığında, bu yazı sırasında yapılan olgunlaşmamış bir ekosistem hakkında herhangi bir konuşmayı sert bir şekilde yumuşatmak bir veya iki yıl ya da üç yıl içinde garanti edilebilir. “2015 Node.js ekosisteminin birkaç mayın tarlası vardı” demek gerçekten beş yıl içinde mantıklı olabilir. 2020 Node.js ekosisteminde birden fazla paradez var. ”

    
15
2015-09-04 12: 15: 48Z
  1. Öz-kötülüğün ("kitabımı satın almayı düşün") tamamen Yığın Taşması için uygun olduğundan emin değilim.
    2015-09-02 21: 14: 08Z
  2. StackEx altında başka bir yer bulabilir misiniz?Yeni başlığımın reklamını yaptığı yerde şemsiye değiştirilsin mi? Olmazsa, referansın doğrudan soruyu cevaplamaya yönelik olabileceğini düşünebilir misiniz?
    2015-09-03 11: 25: 08Z
  3. Bir cevaba kendi çalışmanıza atıfta bulunmak elbette iyidir, eğer soruyu cevaplarsa ve bunun sizin çalışmanız olduğunu açıkça belirtirseniz. Özellikle, kendi yorumumun ifadesi ilk yorumuma atıfta bulunmaktır (yine "kitabımı almayı düşün" bölümü).
    2015-09-03 13: 41: 11Z
  4. Kitabımı satın alma ile ilgili belirli bir bölümü düzenledim.
    2015-09-04 12: 16: 45Z

Uygulamanız esas olarak web apis veya diğer io kanallarını bir araya getirirse, bir kullanıcı arayüzü verir veya alırsa, node.js özellikle en fazla ölçeklenebilirliği sıkıştırmak istiyorsanız veya ana hayattaki dil javascript (ya da javascript çeşitlerinin transpelersı) dır. Mikro hizmetler oluşturursanız, node.js de sorun değil. Node.js, küçük veya basit herhangi bir proje için de uygundur.

Başlıca satış noktası, ön uç sahiplerinin tipik uç noktalardan ziyade arka uç işlerinde sorumluluk almalarına izin vermesidir. Bir başka haklı satış noktası, işgücünüzün başlamak için javascript olması.

Ancak, belirli bir noktanın ötesinde, modülerliği, okunabilirliği ve akış kontrolünü zorlamak için korkunç bir saldırı olmadan kodunuzu ölçeklendiremezsiniz. Yine de bazı insanlar bu saldırıları severler, özellikle olay odaklı bir javascript arka planından geliyorlar, tanıdık veya affedilebilir görünüyorlar.

Özellikle, uygulamanızın senkronize akışlar gerçekleştirmesi gerektiğinde, geliştirme işleminiz açısından sizi yavaşlatan yarı-pişmiş çözümler üzerinde kanamaya başlarsınız. Eğer uygulamanızın yoğun hesaplama bölümleri varsa, dikkatle toplayın (sadece) node.js. Belki de http://koajs.com/ veya diğer yenilikler, başlangıçta node.js kullandığımda veya yazdığım zamankilerle karşılaştırıldığında, başlangıçta dikenli olanları hafifletiyor.

    
9
2015-03-18 21: 41: 27Z
  1. Node.js uygulamalarını ölçeklendirmek için pek çok yaklaşım var ve "yarı pişmiş çözümler", "korkunç saldırılar" ve "korkunç API" iddiaları. Bunları genişletmek ister misiniz?
    2015-03-09 02: 40: 00Z
  2. Okuyucunun egzersizi olarak bırakıyorum, ancak akış kontrolü için sözde çözümlere bakmak yeterli.
    2015-03-09 11: 39: 28Z
  3. Bu gerçekten bir cevap değil. Mevcut çözümlerin "korkunç saldırılar" olduğunu iddia ediyorsunuz, ancak bunların hiçbirini belirtmiyorsunuz. Node.js uygulamalarını ölçeklendirmek için doğru yöntemleri anlamadığınızı veya farkında olamayacağınızı düşündünüz mü?
    2015-03-09 19: 11: 37Z
  4. Cevabımı biraz güncelledim. Belki hala şikayetleriniz var, ancak bunun yanlış olduğunu düşünüyorsanız, cevapta bunun eksikliğini belirtmek yerine ayrıntılarla yorum yapmalısınız. Bu topluluk imo için daha verimli olurdu.
    2015-03-18 21: 38: 02Z

ve neden js düğümünü kullandığımız birkaç nokta paylaşabilirim.

  1. Sohbet gibi gerçek zamanlı uygulamalar için, işbirliğine dayalı düzenleme daha iyi, yangın olayı ve sunucudan gelen müşterilere verinin olay temeli olduğu için nodejs ile devam ediyoruz.
  2. İnsanların çoğunun fikir sahibi olduğu javascript temeli olduğu için basit ve anlaşılması kolaydır.
  3. Güncel web uygulamalarının çoğu açısal js ve omurgaya doğru gidiyor, düğümü ile istemci tarafı koduyla her iki wi'nin de etkileşimi kolaydırjson verisini kullanacağım.
  4. Çok sayıda eklenti mevcut.

Dezavantajları: -

  1. Düğüm çoğu veritabanını destekleyecektir, ancak en iyisi karmaşık birleştirmeleri ve diğerlerini desteklemeyen mongodb'dur.
  2. Derleme Hataları ... herhangi bir hata anlaşması uygulaması, manuel olarak gitmemiz ve herhangi bir otomasyon aracı kullanmamız gerektiğinde çalışmayı durdurursa, geliştirici her istisna dışında her türlü istisnayı işlemelidir.

Sonuç: - Nodejs basit ve gerçek zamanlı uygulamalar için en iyisidir ... Eğer çok büyük bir iş mantığına ve karmaşık işlevselliğe sahipseniz daha iyi nodejs kullanmamalısınız. Sohbet ve işbirlikçi işlevsellik ile birlikte bir uygulama oluşturmak istiyorsanız, düğüm belirli bölümlerde kullanılabilir ve uygunluk teknolojinizle devam etmelidir.

    
- 2
2016-08-09 15: 02: 47Z
  1. Düğüm, hızlı prototipler için mükemmeldir, ancak bir daha karmaşık bir şey için bir daha asla kullanmam. 20 yıl boyunca bir derleyici ile ilişki geliştirdim ve kesinlikle özlüyorum.

  2. Düğüm, bir süredir ziyaret etmediğiniz kodu korumak için özellikle acı vericidir. Tür bilgisi ve derleme zamanı hata tespiti İYİ ŞEYLER. Neden hepsini dışarı atıyorsun? Ne için? Ve bir şey güneye gittiğinde, yığın izleri oldukça sık kullanışsız bırakıyor.

- 3
2015-01-06 10: 45: 25Z
  1. Derleme zamanı denetimi alamazsanız, JSDoc, geri döndüğünüzde işlerin daha mantıklı olması için istediğiniz herhangi bir tür bilgiyi eklemenizi sağlar. Düzgün bir şekilde ayrışmış (küçük) fonksiyonlar, iyi tanımlanmış ortamları (kapatma) nedeniyle, kırılması genellikle oldukça kolaydır. Hatalı yığın izleri, aralarında zaman uyumsuz bir geri çağırma ile mantığınızı bölmediğinizden emin olmak için bazı yeniden faktörlendirmelerle çözülebilir. Eşzamansız geri aramalarınızı aynı kapanışta tutmak, mantıklı davranmayı ve bakım yapmayı kolaylaştırır.
    2014-10-17 20: 16: 51Z
  2. 30 yılını derlenmiş dillerle geçirdim, ancak yalnızca bir yıl kullandıktan sonra JavaScript artık benim tercihim. Sadece çok verimli - Java C # C ++ veya C'den çok daha az kodla daha fazlasını yapabilirim. Ama bu farklı bir zihniyet. Yazılmamış değişken aslında birçok durumda bir avantajdır. JSLINT esastır. Eşzamanlı olarak eşzamanlı olmayan şeyler yapmanız gerektiğinde, geri aramalar, iş parçacığı kullanmak zorunda olduğunuz herhangi bir dilden çok daha güvenli, daha kolay ve sonuçta daha verimlidir. Ve yine de JavaScript'i bilmek zorundasınız çünkü tarayıcının dili.
    2015-05-29 16: 19: 28Z
  3. Ortaya çıkan endişelere sempati duyuyorum ve kesinlikle evrensel olarak uygulanmadıklarına rağmen, bu sorunların ele alınması için bazı çabalar olduğunu belirtiyorum. Javascript kodunun statik analizinden türetme işlemi sağlayabilen Tern adında harika bir proje var. ve kütüphaneler. Çeşitli editörler için eklentileri vardır. Ayrıca Typescript, JSDoc ve BetterJS de var. Ve sonra Go , birçok -javasca dilleri derleme !
    2015-11-26 04: 13: 15Z
if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }
kaynak yerleştirildi İşte