ก่อนอื่นนี่เป็นบทความที่แปลจาก TJ Farewell Node.JS. ฉันได้รับผลกระทบบางอย่างหลังจากอ่านบทความนี้ แต่ฉันไม่เห็นด้วยกับมุมมองของผู้เขียน ตัวอย่างเช่นฉันคิดว่าการลงทะเบียนแพ็คเกจของ Node.js เป็นหนึ่งในข้อได้เปรียบมากมาย แต่ไปยังขาดเล็กน้อยในเรื่องนี้ เนื่องจากระดับส่วนบุคคลฉันไม่เข้าใจหลายสิ่งหลายอย่างเมื่อแปล ฉันไปที่บล็อกของผู้แต่งและ Stackoverflow เพื่อถามคำถามเพื่อรับคำตอบ ยังมีอีกหลายสิ่งที่ไม่ได้อยู่ในการแปลและฉันหวังว่าจะได้รับมุมมอง
ป.ล. ในฐานะผู้เริ่มต้น Node.js ขอบคุณ TJ สำหรับความพยายามของเขาและไปตลอดทาง
ข้อความ:
กล่าวคำอำลากับ node.js
ออกจาก Node.js Realm
ฉันต่อสู้กับ Node.js ในการผลิตมานานพอและน่าเสียดายเนื่องจากฉันไม่สนุกกับการทำงานนี้อีกต่อไปอย่างน้อยก็ในขณะนี้มันเป็นการอำลาอย่างเป็นทางการของฉัน ที่สำคัญฉันต้องการผู้ดูแล
โหนดนั้นยอดเยี่ยมมากในบางวิธี แต่มันไม่ใช่เครื่องมือที่เหมาะสมสำหรับประเภทของซอฟต์แวร์ที่ฉันสนใจเมื่อเร็ว ๆ นี้ ฉันยังคงวางแผนที่จะใช้โหนดเป็นเว็บไซต์ แต่ถ้าคุณสนใจที่จะรักษาโครงการใด ๆ เพียงแค่ฝากข้อความไว้เพื่อเขียนชื่อผู้ใช้ GitHub ชื่อผู้ใช้ NPM และชื่อโครงการเพื่อแจ้งให้เราทราบ โดยปกติสิ่งที่ฉันถามคือคุณไม่ได้เปลี่ยน API ที่มีอยู่อย่างสมบูรณ์ หากคุณต้องการทำสิ่งนี้จริงๆจะเป็นการดีกว่าที่จะเริ่มโครงการใหม่
KOA เป็นโครงการที่ฉันจะรักษาต่อไป (กับผู้ร่วมและเพื่อน)
เรื่องราวของจอกศักดิ์สิทธิ์
ฉันรัก C มาตลอด แต่ทุกคนที่ทำงานในการพัฒนา C รู้ว่ามันมีค่า แต่มีแนวโน้มที่จะเกิดข้อผิดพลาด เป็นการยากที่จะพิสูจน์การเลือกภาษาในการทำงานประจำวันเนื่องจากไม่ใช่งานที่เร็วที่สุด ความเรียบง่ายก็เป็นเหตุผลว่าทำไมมันถึงได้รับการยกย่องเสมอ แต่คุณจะไม่ไปไกลมากหากไม่มีเทมเพลตมากมาย
เนื่องจากผู้คนจำนวนมากมีส่วนร่วมในการพัฒนาระบบกระจายแนวโน้มการพัฒนาประสิทธิภาพของโหนดมากกว่าการใช้งานและความทนทานทำให้ฉันผิดหวังมากขึ้น ในช่วงสัปดาห์ที่ผ่านมาฉันได้เขียนระบบกระจายที่ค่อนข้างใหญ่ใน GO ซึ่งมีความแข็งแกร่งทำงานได้ดีขึ้นและง่ายต่อการบำรุงรักษาและมีความครอบคลุมที่ทดสอบได้ดีขึ้นเนื่องจากความงามทั่วไปและง่ายต่อการพัฒนารหัสแบบซิงโครนัส
ฉันไม่ได้บอกว่า Go เป็นจอกศักดิ์สิทธิ์มันไม่สมบูรณ์แบบ แต่ไปเป็นคำตอบที่ยอดเยี่ยมสำหรับฉันสำหรับหลายภาษาที่มีอยู่ในปัจจุบัน ในฐานะที่เป็นภาษา "รุ่นต่อไป" เหล่านี้มากขึ้นเช่น Rust และ Julia พบสถานที่และเป็นผู้ใหญ่ของตัวเองฉันมั่นใจว่าเราจะมีวิธีแก้ปัญหาที่ยอดเยี่ยมมากขึ้น
โดยส่วนตัวแล้วฉันตื่นเต้นมากที่จะไปเพราะความเร็วในการทำซ้ำฉันตื่นเต้นมากที่เห็นว่าพวกเขากระตือรือร้นที่จะไปถึงเวอร์ชัน 2.0 และจากข่าวที่ฉันได้ยินพวกเขาไม่กลัวที่จะทำลายสิ่งที่ยิ่งใหญ่ดั้งเดิม ถ้าเป็นจริงฉันมีความสุขมากขึ้นเพราะฉันเชื่อว่าถ้ามันเป็นประโยชน์ต่อภาษานี้จริงๆฉันควรจะแยกแยะสิ่งที่มีอยู่แล้วอย่างรวดเร็ว แต่ฉันก็ไม่ใช่ซอฟต์แวร์ยักษ์ที่ใช้ระบบจำนวนมากเช่นกัน : D
แก้ไขโดย: ฉันต้องตีความรายชื่อผู้รับจดหมายส่งผิดและพวกเขาไม่กระตือรือร้นที่จะทำการเปลี่ยนแปลงการทำลายล้างได้ตลอดเวลา @enneff
ทำไมต้องไป?
หากโหนดทำงานให้คุณและคุณไม่มีอะไรต้องกังวลมันก็ยังเป็นเครื่องมือที่ยอดเยี่ยม แต่ถ้าสิ่งที่รบกวนคุณอย่าลืมกระโดดออกจากกล่องของคุณและดูว่ามีอะไรอยู่นอกกรอบ - ฉันได้รับความสนใจภายในไม่กี่ชั่วโมงหลังจากเริ่มใช้ไปสร้างผลิตภัณฑ์
อีกครั้งฉันไม่ได้อยู่ที่นั่นเพื่อบอกว่าเป็นภาษาที่ดีที่สุดและคุณต้องไปกับมัน แต่สำหรับอายุของมันมันเป็นผู้ใหญ่และแข็งแกร่งมาก (ประมาณอายุเท่ากันกับโหนด) การสร้าง Type Reconstruction นั้นสนุกและเรียบง่ายเครื่องมือการบ้านและการดีบักที่จัดทำโดย Go นั้นยอดเยี่ยมและชุมชนมีกฎระเบียบที่แข็งแกร่งมากเกี่ยวกับเอกสารรูปแบบมาตรฐานและการออกแบบ API
ในขณะที่คุ้นเคยกับโหนดที่เป็นโมดูลมากและมีประสบการณ์ห้องสมุดมาตรฐานที่เน่าเปื่อยของทับทิมเมื่อฉันได้ยินเกี่ยวกับ Go ครั้งแรกฉันคิดว่าห้องสมุดมาตรฐานของมันแย่มาก หลังจากที่ฉันดำดิ่งลงในภาษานี้ฉันรู้ว่าห้องสมุดมาตรฐานส่วนใหญ่มีความจำเป็นในขั้นตอนนี้เช่นการบีบอัด, JSON, IO, บัฟเฟอร์ IO, การดำเนินงานสตริง ฯลฯ APIs ส่วนใหญ่เหล่านี้มีการกำหนดและทรงพลัง เป็นเรื่องง่ายที่จะเขียนโปรแกรมทั้งหมดเพียงแค่ใช้ไลบรารีมาตรฐานเหล่านี้
แพ็คเกจ GO ของบุคคลที่สาม
ห้องสมุด GO ส่วนใหญ่ดูคล้ายกันรหัสบุคคลที่สามส่วนใหญ่ที่ฉันเคยใช้มานั้นมีคุณภาพสูงและยากที่จะหาสิ่งเหล่านี้ในโหนดเพราะ JavaScript ดึงดูดนักพัฒนาในระดับทักษะที่แตกต่างกัน
ไม่มีรีจิสทรีสำหรับแพ็คเกจ GO ดังนั้นคุณมักจะเห็นแพ็คเกจเดียวกัน 5 หรือ 6 ชุดในเวลาเดียวกัน ในบางจุดนี้อาจทำให้เกิดความสับสน แต่มีผลข้างเคียงที่น่าสนใจและคุณต้องตัดสินใจว่าตัวเลือกใดเป็นตัวเลือกที่ดีที่สุดโดยการตรวจสอบแต่ละแพ็คเกจอย่างระมัดระวัง ผ่านโหนดมักจะมีแพ็คเกจข้อมูลจำเพาะเช่น "Redis", "MongoDB-Native" หรือ "Zeromq" ดังนั้นคุณจะหยุดอยู่ที่นั่นและอนุมานว่าพวกเขาเป็นคนที่ดีที่สุด
หากคุณกำลังทำงานแบบกระจายคุณจะพบว่าประเภทข้อมูลพื้นฐานที่น่าประทับใจของ GO นั้นมีประโยชน์มาก เราสามารถรับสิ่งที่คล้ายกันโดยเครื่องกำเนิดไฟฟ้าในโหนด แต่ในความคิดของฉันเครื่องกำเนิดความเห็นเพียงครึ่งเดียว หากไม่มีการจัดการข้อผิดพลาดอิสระการรายงานสแต็กยังคงเป็นเรื่องธรรมดาแม้ว่าจะดีที่สุดก็ตาม เมื่อโซลูชั่นเหล่านี้ทำงานได้ดีฉันไม่ต้องการรอให้ชุมชนจัดระเบียบใหม่เป็นเวลาสามปี
ในความคิดของฉันการจัดการข้อผิดพลาดของ Go นั้นโดดเด่น โหนดนั้นยอดเยี่ยมในแง่ของสิ่งที่คุณต้องคิดเกี่ยวกับความผิดพลาดทุกอย่างและตัดสินใจว่าจะทำอย่างไร อย่างไรก็ตามโหนดล้มเหลวใน:
คุณอาจโทรกลับซ้ำ
คุณไม่สามารถโทรกลับได้เลยและหลงทางในสถานะที่ไม่เสถียร (ตัวอย่างเช่นลืมที่จะส่งข้อผิดพลาดเพื่อจัดการการโทรกลับเมื่อเกิดข้อผิดพลาดโหนดจะกลืนข้อผิดพลาดโดยไม่มีข้อเสนอแนะใด ๆ )
คุณอาจได้รับข้อผิดพลาดในการซื้อกลับบ้าน
ตัวปล่อยอาจได้รับเหตุการณ์ผิดหลายครั้ง
ลืมเหตุการณ์ผิดที่จะจัดการกับมันจะทำลายทุกอย่าง
มักไม่แน่ใจว่าสิ่งที่จำเป็นในการจัดการกับข้อผิดพลาด
การจัดการข้อผิดพลาดซ้ำซ้อนมาก
การโทรกลับแย่มาก
ในการเดินทางเมื่อรหัสของฉันสิ้นสุดลงมันจะสิ้นสุดลงและคุณไม่สามารถ execute อีกครั้งในคำสั่ง นี่คือความไม่แน่นอนในโหนด คุณจะคิดว่าโปรแกรมจะดำเนินการอย่างเต็มที่จนกว่าจะมีการเรียกใช้ไลบรารีโดยไม่คาดคิดหลายครั้งหรือไม่ล้างตัวจัดการอย่างถูกต้องแล้วทำให้รหัสถูกดำเนินการอีกครั้ง มันค่อนข้างยากที่จะหาเหตุผลเหล่านี้ในรหัสการผลิตจริงทำไมต้องกังวลกับสิ่งเหล่านี้? ภาษาอื่น ๆ จะไม่ทำให้คุณได้สัมผัสกับความเจ็บปวดเหล่านี้
โหนดแห่งอนาคต
ฉันยังคงหวังว่า Node จะทำงานได้ดีหลายคนลงทุนอย่างมหาศาลในตัวเขาและมันก็มีศักยภาพนั้น ฉันคิดว่า Joyent และทีมจำเป็นต้องมุ่งเน้นไปที่การใช้งาน - หากแอปพลิเคชันของคุณเปราะบางและยากที่จะดีบัก refactor และพัฒนาประสิทธิภาพนั้นไม่มีความหมาย
ใน 4-5 ปีเราจะยังคงมีข้อผิดพลาดที่คลุมเครือนี้ "ข้อผิดพลาด: getaddrinfo eaddrinfo" และความจริงข้อนี้บอกเราว่าลำดับความสำคัญของการพัฒนาของโหนดอยู่ที่ไหน เมื่อคุณมุ่งเน้นไปที่การสร้างแกนกลางของระบบมันเป็นเรื่องง่ายที่จะพลาดสิ่งเหล่านี้ ฉันคิดว่าผู้ใช้ได้แสดงความคิดเห็นเกี่ยวกับสิ่งต่าง ๆ ครั้งแล้วครั้งเล่า แต่ไม่เคยเห็นผลลัพธ์ใด ๆ เรามักจะได้รับคำตอบเล็กน้อยสำหรับการอ้างว่าสิ่งที่เรามีนั้นสมบูรณ์แบบแล้ว ในทางปฏิบัตินี่ไม่ใช่กรณี
สตรีมถูกขัดจังหวะการโทรกลับไม่ใช่เรื่องง่ายข้อผิดพลาดไม่ชัดเจนเครื่องมือไม่ง่ายต่อการใช้งานกฎระเบียบของชุมชนมีอยู่ แต่ดูเหมือนว่าจะขาดไปเมื่อเทียบกับไป อย่างไรก็ตามเรื่องนี้ฉันอาจใช้โหนดต่อไปสำหรับงานเฉพาะบางอย่างเช่นการสร้างหน้าเว็บหรือ API หรือต้นแบบที่แยกส่วน หากโหนดสามารถแก้ไขปัญหาพื้นฐานบางอย่างได้ก็มีโอกาสที่จะยังคงมีความเกี่ยวข้อง แต่เมื่อมีวิธีแก้ปัญหาอื่นที่ทำงานได้สูงกว่าความพร้อมใช้งานเมื่อประสิทธิภาพที่สูงขึ้นและข้อโต้แย้งความพร้อมใช้งานที่สูงขึ้นไม่ได้ไปไกลเกินไป
หากชุมชนโหนดตัดสินใจที่จะโอบกอดเครื่องกำเนิดไฟฟ้าและนำไปใช้ในโหนดหลักมากและผ่านข้อผิดพลาดอย่างเหมาะสมมีโอกาสที่จะทำให้การอ้างอิงนี้สามารถอ้างอิงได้ สิ่งนี้จะปรับปรุงการใช้งานและความทนทานของโหนดอย่างสมบูรณ์
ข่าวดีก็คือฉันได้พูดคุยกับผู้ชายที่ยอดเยี่ยมและมีความสามารถซึ่งมีส่วนร่วมในรหัสหลักใน Strongloop เมื่อไม่นานมานี้ พวกเขาใช้วิธีที่ถูกต้องในการแก้ไขปัญหาเหล่านี้อย่างชัดเจนเพื่อให้โหนดในอนาคตง่ายขึ้นในการทำงานโดยการฟังการตอบสนองของนักพัฒนาต่อแพลตฟอร์มและการวางแผนเพื่อค้นหาวิธีที่เหมาะสมในการแก้ไขปัญหาเหล่านี้ ฉันไม่แน่ใจว่าความขัดแย้งระหว่างหลาย บริษัท ในการพัฒนาพร้อมกันของส่วนหลักจะสิ้นสุดลงอย่างไร แต่ฉันหวังว่าไดรเวอร์นักพัฒนาจะชนะ
นี่ไม่ได้หมายความว่ามันเป็นการโจมตีของแต่ละบุคคลผู้คนที่มีความสามารถจำนวนมากกำลังทำงานด้วยหรือบนโหนด แต่นี่ไม่ใช่สิ่งที่ฉันสนใจอีกต่อไปฉันมีช่วงเวลาที่ดีในชุมชนโหนดและพบกับคนที่น่าสนใจจริงๆ
ความหมายของเรื่องราวคือคุณไม่ควรถูก จำกัด โดยวงกลมของคุณเอง! ดูสิ่งที่อื่น ๆ และคุณอาจสนุกกับการเขียนโปรแกรมอีกครั้ง มีวิธีแก้ปัญหาที่น่าทึ่งมากมายนอกเรื่องนี้และความผิดพลาดที่ฉันทำคือฉันรอนานเกินไปที่จะเล่นกับพวกเขา!