มีเหตุผลที่ดีที่จะหลีกเลี่ยง node.js สำหรับเว็บแอปที่ไม่ใช่เรียลไทม์หรือไม่?

ฉันได้เห็นการพูดคุยมากมายเกี่ยวกับ Node.js ที่ยอดเยี่ยมสำหรับเว็บแอปแบบเรียลไทม์ - สิ่งที่ต้องการซ็อกเก็ต, Comet, การสื่อสาร AJAX ที่หนักหน่วงและอื่น ๆ ฉันรู้ว่าโมเดลที่ทำงานโดยอิงเหตุการณ์แบบอะซิงโครนัสและเป็นเธรดนั้นดีสำหรับการทำงานพร้อมกันที่มีค่าใช้จ่ายต่ำ

ฉันยังได้เห็นแบบฝึกหัด Node.js สำหรับแอปที่ 'ดั้งเดิม' ที่ไม่ใช่เรียลไทม์ (เช่นตัวอย่างบล็อกมาตรฐานซึ่งดูเหมือนจะเป็นมาตรฐาน 'Hello World' สำหรับผู้ที่เรียนรู้การพัฒนาแอป) และฉันก็รู้ว่าโหนดคงที่ช่วยให้คุณให้บริการสินทรัพย์คงที่

คำถามของฉันคือมีเหตุผลที่ดีที่จะหลีกเลี่ยง Node.js สำหรับเว็บแอปแบบดั้งเดิมเช่นคลาสสิฟายด์ฟอรัมตัวอย่างบล็อกดังกล่าวหรือแอพ CRUD ที่คุณสร้างขึ้นสำหรับแอปพลิเคชันธุรกิจภายในหรือไม่ เพียงเพราะมันเก่งในทุกเวลาที่เป็นเรื่องขี้ขลาดมันห้ามใช้มันเพื่อการใช้ที่มีพลังมากกว่าหรือไม่?

สิ่งเดียวที่ฉันนึกได้ก็คือการขาดห้องสมุดผู้ใหญ่ (แม้ว่ามันจะเปลี่ยนไป)

(เหตุผลที่ฉันถามคือฉันกำลังพิจารณาการทิ้ง PHP สำหรับ Node.js ส่วนใหญ่เพื่อให้เกินความต้านทานไม่ตรงกันของการสลับระหว่างภาษา แต่ยังเพื่อให้ฉันสามารถนำมาใช้รหัสตรวจสอบและ whatnot superego ของฉัน admonishes ให้ฉันเลือก เครื่องมือที่ดีที่สุดสำหรับงานนี้ แต่ฉันไม่มีเวลามากพอที่จะเรียนรู้ภาษาต่าง ๆ สิบห้าภาษาและห้องสมุด userland ทั้งหมดของพวกเขาเพื่อให้มีคลังแสงที่ครอบคลุมนอกจากนี้ยังให้ความมั่นใจว่า Node.js อาจมอบเส้นทางการเพิ่มประสิทธิภาพที่ง่ายกว่า PHP / Apache ในอนาคตเมื่อฉันต้องเริ่มคิดถึงการจราจรหนาแน่น)

[แก้ไข]ขอบคุณสำหรับคำตอบจนถึงขณะนี้คน; ฉันแค่ต้องการดูว่าใครจะมีน้ำหนักก่อนที่ฉันจะเลือกคำตอบ คำตอบจาก @Raynos kinda ยืนยันสิ่งที่ฉันคิดและลิงก์จากผู้แสดงความเห็นก็ให้อาหารที่ดีสำหรับความคิด แต่ฉันต้องการดูว่าใครมีคำตอบเฉพาะโหนดใด ๆ เช่น 'ไม่ได้ใช้ NODE สำหรับปัญหา X ' (นอกเหนือจากงานที่มี CPU สูงฉันรู้แล้ว :-)

มีเหตุผลที่ดีที่จะหลีกเลี่ยง Node.js สำหรับเว็บแอปทั่วไปหรือไม่

ใช่ถ้าคุณมี N ปีในเว็บแพลตฟอร์ม X ดังนั้นคุณสามารถพัฒนาแอปพลิเคชั่นในแพลตฟอร์ม X ได้เร็วขึ้น

ถ้าคุณต้องการที่จะทำ Y และแพลตฟอร์ม X มีวิธีแก้ปัญหาก่อนทำ Y ที่ทำ X แล้วทำเช่นนั้น

เหตุผลทั่วไปทั้งหมดว่าทำไมคุณควรใช้แพลตฟอร์มหนึ่งเหนืออีกแพลตฟอร์ม

ประเภทของแอพ CRUD ที่คุณสร้างขึ้นสำหรับแอพพลิเคชั่นธุรกิจภายใน

ใช่มีแพลตฟอร์มอื่นที่ให้คุณเขียนแอพพลิเคชั่นทั่วไปได้เร็วขึ้น

อย่างไรก็ตามที่กล่าวมา ฉันมีประสบการณ์เกี่ยวกับโหนดและไม่สามารถอ้างสิทธิ์ได้ว่าฉันจะเลือกแพลตฟอร์มอื่นบนโหนดยกเว้นว่าจะมีคุณสมบัติจำนวนมากนอกกรอบสำหรับฉัน

โดยทั่วไปมันเป็นคำถามง่าย ๆ

มีเครื่องมือที่ใช้สำหรับสิ่งนี้ทั้งหมดหรือไม่? ไม่จากนั้นเลือกแพลตฟอร์มที่สะดวกที่สุดในการเขียนเครื่องมือ

ไม่มีเหตุผลที่ชัดเจนว่าทำไม node.js เป็นแพลตฟอร์มที่ไม่สะดวก (นอกเหนือจากนั้น "ฉันเกลียดจาวาสคริปต์")

หลังจากทำงานกับโหนดเป็นเวลาสองสามสัปดาห์ฉันก็บอกว่าใช่มันเจ๋งมาก แต่ไม่จำเป็นต้องมีสิ่งที่คุณต้องการใช้เพื่อแทนที่แอปพลิเคชันเว็บที่หมดเวลาของคุณด้วย ... หรือ, imo ที่ตั้งใจจะเป็น

จำไว้ว่า node เป็นเซิร์ฟเวอร์ของตัวเอง สิ่งนี้จะแนะนำความซับซ้อนหากคุณต้องการเรียกใช้มากกว่าหนึ่งแอปพลิเคชัน node.js ของคุณ เช่นถ้าคุณมีเว็บไซต์ / โดเมนมากกว่าหนึ่งโฮสต์บนเครื่อง มันไม่เหมือนกับ LAMP stack ซึ่งคุณสามารถมีแอพพลิเคชั่น PHP โหลสำหรับโดเมนที่ต่างกันครึ่งโหลที่ทำงานนอกเซิร์ฟเวอร์เดียวกัน (บนพอร์ต 80 อย่างน้อย) มีเฟรมเวิร์กสำหรับโหนดที่อาจทำให้เป็นไปได้ แต่นั่นเป็นการเพิ่มความซับซ้อนที่คุณไม่ต้องการหากคุณติดอยู่กับแพลตฟอร์มเว็บแบบดั้งเดิม (แน่นอนคุณสามารถตั้งค่าพร็อกซีด้วยการวางเว็บเซิร์ฟเวอร์ไว้หน้าโหนด แต่การเรียงลำดับนั้นจะเอาชนะข้อดีของการใช้โหนด)

imo โหนดเหมาะอย่างยิ่งสำหรับการทำงานร่วมกับเว็บเซิร์ฟเวอร์แบบดั้งเดิม วิธีที่ฉันมีการจัดการสิ่งต่าง ๆ ในขณะนี้คือการให้บริการ html / js / images แบบคงที่ผ่านทาง apache และจัดการกับความต้องการข้อมูล 'เรียลไทม์' โดยการโพลแบบยาวไปยังแอปพลิเคชันโหนด

เหตุผลที่ดีที่จะนึกถึงวินาทีเกี่ยวกับโหนดนั้นไม่ได้เป็นเรื่องทางเทคนิค - มันยอดเยี่ยมและน่าทึ่งในสิ่งที่มันทำ

พวกเขาเป็นธุรกิจและทุนมนุษย์โดยเฉพาะเช่นโปรแกรมเมอร์ผู้รู้ค่าใช้จ่ายและความพร้อมใช้งาน ไม่ใช่เรื่องยากที่จะเรียนรู้ แต่เช่นเดียวกับเทคโนโลยีใหม่ใด ๆ จำนวนผู้ที่รู้ดี (หรือต้องการ) เป็นกลุ่มย่อยของกลุ่มคนงานขนาดใหญ่

นี่เป็นคำถามที่ดีมากที่เราต้องถามเพื่อที่จะยกระดับสถานะของศิลปะ

ฉันอยากรู้มาก (เช่น Paul d'Aoust) ซึ่งมีข้อ จำกัด ของ Node.JS อยู่ น่าเศร้าที่คำตอบจำนวนมากเต็มไปด้วยอคติส่วนตัวและเหตุผลที่เกี่ยวข้องชั่วคราว

ฉันถามตัวเองว่า: เราสามารถกรอง BIAS ที่เป็นประโยชน์ออกไปแล้วตอบคำถามที่เกี่ยวข้องกับคำถามนี้ได้ไหม?

คะแนนที่เหลืออยู่ดูเหมือนจะเป็น:

1. NodeJS ไม่ได้พัฒนาเต็มที่เท่ากับกรอบงานดั้งเดิม ดังที่ Paul d'Aoust แนะนำว่านี่เป็นเพียงเหตุผลชั่วคราวที่เกี่ยวข้องไม่ใช่เพื่อการหลีกเลี่ยงอย่างเต็มรูปแบบ - แต่ควรทบทวนและตรวจสอบอย่างรอบคอบ เราคาดว่าจะทำการบ้านในฐานะผู้เชี่ยวชาญทางเว็บและเป็นหน้าที่ของเราในการกำหนดเทคโนโลยีที่เหมาะสมที่สุดสำหรับองค์กรความต้องการของพวกเขาอนาคตของพวกเขาทีมงาน (ไม่ใช่เรา) การครบกำหนดเป็นสิ่งจำเป็นสำหรับการชี้แจงและการตัดสินความอยากอาหารเพื่อความเสี่ยง แต่ไม่ควรหลีกเลี่ยง

2. NodeJS เป็น Proxy Server ข้อเสนอแนะที่ชาญฉลาดของการสนทนาก่อนหน้านี้คือการพิจารณาและการพิจารณาที่คุ้มค่า มันเป็นความคิดของการใช้โหนดในความสัมพันธ์กับเทคโนโลยีที่มีอยู่เป็นรูปแบบการออกแบบส่วนต่อประสานพร็อกซีส่วนหน้า แต่ก็ไม่ใช่เหตุผลที่ AVOID จะใช้โหนด แต่เป็นเหตุผลที่จะหลีกเลี่ยงการใช้แทนทั้งหมด แทนที่จะเลือกวิธีการที่เป็นข้อพิสูจน์

3. การดีบักโหนด ในการสนทนากับผู้พัฒนาหลักของโหนดที่ Joyent มีความยุ่งยากมากมายรอบการ debuggability และติดตามสาเหตุของปัญหาที่เกิดจากแกนกลาง (ขึ้นอยู่กับการดำเนินการเธรดเดียวและไม่สามารถดูเธรดที่ผ่านมา) นี่คือการพิจารณาและการประเมินผลที่คุ้มค่า - แต่ (อีกครั้ง) มีแนวโน้มที่จะไม่รังเกียจการใช้งานทั่วไปเท่านั้นกรณีขอบที่อาจผลักซองจดหมาย บางทีความต้องการเฉพาะของคุณอาจอยู่ในหมวดหมู่นี้และพวกเขาอาจจะไม่

4. ทรัพยากรมนุษย์ นี่คือเหตุผลที่ดีที่สุดในการหลีกเลี่ยงการใช้ JS ในหน้านี้และในความเห็นที่ต่ำต้อยของฉันมันเป็นความจริงที่ไม่สมบูรณ์และไม่สะดวก มันเป็นคำถาม: บริษัท ของคุณมีผู้เชี่ยวชาญที่มีความสามารถในมือเพื่อดูโครงการผ่านวงจรชีวิตทั้งหมดหรือไม่? หากไม่มีคำถามใด ๆ ที่คุณต้องหลีกเลี่ยง NodeJS หรือแทนที่จะพิจารณาก) ค้นหาความสามารถที่ถูกต้องหรือ B) ให้ความรู้แก่ความสามารถที่มีอยู่

การร้องเรียน: การสังเกตข้อร้องเรียนของฉันเกี่ยวกับ JavaScript ก็คือผลลัพธ์จำนวนมากมาจากข้อผิดพลาดของผู้ใช้มากกว่าที่เกิดจากความล้มเหลวของภาษาที่สอดคล้องกัน เราได้ debunked การเรียกร้องจำนวนมากจาก "The Hate JavaScript Diatribe" และเราจะทำการ debunk อีกมากมาย ปัญหาเช่น - เอกสารไม่ดีพอมันไม่เซ็กซี่ แต่คนไม่ชอบมันเป็นมะเร็งมันเป็นมารหรือมันเกินไป "พิมพ์ง่าย" (-CRichardson) เป็นอัตวิสัยและ ข้อร้องเรียนแบบเอนเอียงที่จำเป็นต้องถูกกำจัดออกเพื่อการตัดสินใจที่ถูกต้องขององค์กร

ในท้ายที่สุดคำตอบที่ถูกต้องอาจจะเป็น - ไม่มีเหตุผลที่ดีที่จะหลีกเลี่ยง NodeJS บางทีนี่อาจเป็นเหตุผลว่าทำไมมันถึงมีการเติบโตอย่างรวดเร็วการยอมรับและการสนับสนุน แต่สำหรับพวกเราทุกคนบางทีคำตอบที่นี่คือการประเมินวิจัยและทำความเข้าใจกับ NodeJS ให้ดีขึ้น - และมองหา aversions ที่เป็นรูปธรรม ในการแสวงหาการเปิดรับความเข้าใจอย่างถ่องแท้ที่โหนด JS นั้นยังไม่บรรลุนิติภาวะ - เราพบสิ่งที่เราต้องการเพื่อให้ดีขึ้น และนั่นคือพร

คำถามที่ดี. ฉันยังคงอยากรู้อยากเห็นสำหรับใครบางคนที่จะหาเหตุผลที่ดีกว่าที่จะหลีกเลี่ยง NodeJS - มากกว่าสิ่งเหล่านี้

มีประโยชน์ใด ๆ ของการใช้โหนดเหนือ X สำหรับแอปพลิเคชันที่ไม่ใช่เรียลไทม์:

• มาตราส่วน : โหนดมีประสิทธิภาพที่ดี แต่แพลตฟอร์มอื่นก็มีเช่นกัน PHP, Ruby, Python และ Java ทุกระดับ คุณสามารถค้นหาชื่อบิ๊กที่มีผู้ใช้หลายล้านคนกำลังใช้พวกเขา
• หนึ่งภาษาสำหรับส่วนหน้าและส่วนหลัง : มันเป็นเรื่องตลกเหมือนจาวา "เขียนเมื่อใดก็ได้"
• ร้อนแรงและเซ็กซี่ : จุดที่ถูกต้องเท่านั้น แต่ไม่มีใครสนใจว่าเว็บไซต์ของคุณกำลังใช้เทคโนโลยีหงุดหงิด!

ประโยชน์ของการใช้ X over Node สำหรับแอปพลิเคชันที่ไม่ใช่เรียลไทม์:

• วิธีปฏิบัติที่ดีที่สุด : เนื่องจากโหนดเป็นโหนดใหม่จึงมีแนวปฏิบัติที่ดีที่สุดน้อยกว่าแพลตฟอร์มอื่น ๆ โดยเฉพาะสำหรับเว็บแอปพลิเคชัน CRUD
• ภาษา Javascript : คนไม่ชอบ Javascript แม้ว่า Node.js จะร้อน แต่จาวาสคริปต์ก็ไม่ได้เป็นเช่นนั้น นี่คือสาเหตุที่ผู้คนสร้าง Coffeescript เพื่อหลีกเลี่ยงการเขียนจาวาสคริปต์แม้สำหรับฝั่งไคลเอ็นต์
• ความเร็วในการพัฒนา : เฟรมเวิร์คที่เก่าและน่าเบื่อรวมถึงและไม่ จำกัด เฉพาะ Rails และ Django นั้นได้รับการทดสอบและพัฒนามาอย่างดีในหลาย ๆ ปีสำหรับเว็บไซต์ CRUD ในขณะที่คุณสามารถใช้แอพพลิเคชั่นที่คล้ายกันในโหนดมันง่ายกว่าที่จะทำในกรอบของคุณปู่
• เสถียรภาพ : กรอบงานเว็บของโหนดดีขึ้นเรื่อย ๆ หมายความว่าพวกเขากำลังเปลี่ยนแปลงและจะมีความเข้ากันไม่ได้ของ API เพิ่มเติมในอนาคตอันใกล้
• ไลบรารีและเครื่องมือ : เทคโนโลยีเก่าที่มีผู้ใช้มากขึ้นจะมีไลบรารีและเครื่องมือมากขึ้น

คำตอบของฉันจะไม่ถูกต้องแน่นอนในปี 2558 ในปี 2014 ข้าม Node สำหรับแอปพลิเคชันเว็บที่ไม่ใช่เรียลไทม์ แต่คอยจับตาดูมัน

กรอบเว็บทุกเว็บมีจุดแข็ง คุณจะมีความสุขในขณะที่ใช้งานสำหรับจุดนั้น เว็บแอ็พพลิเคชันที่ไม่ใช่เรียลไทม์ไม่ใช่จุดแข็งของเฟรมเวิร์กเว็บของโหนด

Node.js เป็นแพลตฟอร์มยอดนิยมและมีคุณสมบัติที่น่าสนใจมากมาย blah blah blah แต่การใช้งานเครื่องมือเป็นเรื่องส่วนตัว ฉันให้ Node.js สี่ครั้งและฉันก็ไม่พอใจกับมัน นี่คือเหตุผลของฉัน โปรดทราบว่าเหตุผลบางประการนั้นล้าสมัยหรือเป็นเรื่องส่วนตัว: P

• ฉันชอบภาษา / ไวยากรณ์ที่แตกต่างกัน (ฉันชอบ Python, Scala, ภาษาโปรดของฉันคือ Prolog ดังนั้นใช่)
• คุณภาพของเอกสารประกอบสำหรับเฟรมเวิร์กและไลบรารีที่ฉันใช้นั้นไม่ดีเท่าห้องสมุด Java, Scala และ Python
• นักออกแบบของ nodejs ค่อนข้างหมกมุ่นอยู่กับการเรียกกลับแทนรูปแบบเหตุการณ์ผู้สังเกตการณ์หรือฟิวเจอร์ส
• มีโซลูชันพร้อมสำหรับสิ่งที่ฉันต้องการทำใน Ruby, Python, Java ที่พัฒนาแล้วในปี 2005 ฉันแค่ต้องแก้ไขไฟล์กำหนดค่า

HTTP เป็นไร้สัญชาติดังนั้นจึงไม่มีสิ่งใดเป็นเว็บแอปที่ไม่ใช่เรียลไทม์ดังนั้นจึงไม่มีเหตุผลที่คุณไม่สามารถใช้โหนดสำหรับทุกสิ่ง

ที่กล่าวว่าโหนดเหมาะกว่าสำหรับสถาปัตยกรรมแอปพลิเคชันบางประเภท PHP เป็นไฟล์ html ที่บรรจุโค้ดไว้เล็กน้อย โหนดเป็นรหัสทางเลือกที่มีบิตของ html

ซึ่งหมายความว่าหากแอปของคุณเป็นรูปแบบ HTML มาตรฐานโดยไม่มีสคริปต์ฝั่งไคลเอ็นต์ PHP จะง่ายขึ้น โหนดมีเครื่องมือสร้างเท็มเพลต แต่เห็นได้ชัดว่าไม่เหมาะสำหรับผู้ใหญ่อย่าง PHP

หากคุณมีสคริปต์ฝั่งไคลเอ็นต์จำนวนมากและบันทึกข้อมูลด้วย ajax คุณจะต้องจบลงด้วยฟังก์ชั่นการเรียกไคลเอ็นต์ HTML แบบคงที่บนเซิร์ฟเวอร์ นี่คือสิ่งที่โหนดดี ในขณะที่ไม่ใช่วิธีที่แอพ CRUD มักจะถูกสร้างขึ้นคุณสามารถสร้างสิ่งที่ดีงามด้วยกรอบที่เหมาะสม