"ประวัติศาสตร์ไม่ใช่อดีตประวัติศาสตร์กำลังถูกจัดฉากด้วยการพัฒนาอย่างรวดเร็วของ W3C และเบราว์เซอร์การพัฒนาแบบโมดูลาร์ส่วนหน้าจะค่อยๆกลายเป็นโครงสร้างพื้นฐานทุกอย่างจะกลายเป็นประวัติศาสตร์ในที่สุดและอนาคตจะดีขึ้น" - ฉันเห็นด้วยเป็นการส่วนตัวกับย่อหน้าสุดท้ายของข้อความต้นฉบับของ Yu Bo เนื่องจากเราพูดถึง "อนาคต" ฉันเชื่อว่าถ้าโมดูล JS Front-end ยังคงพัฒนาอย่างต่อเนื่องรูปแบบโมดูลของมันน่าจะกลายเป็นข้อกำหนดมาตรฐานสำหรับเว็บในอนาคต เช่นเดียวกับรูปแบบ JSON ในที่สุดมันก็กลายเป็นมาตรฐานและถูกนำไปใช้โดยเบราว์เซอร์
ใครมีมาตรฐานที่ดีที่สุดสำหรับโมดูลอะซิงโครนัสที่จะกลายเป็นอนาคต? SEAJS เป็นไปตามข้อกำหนด CMD RequireJS ติดตามข้อกำหนด AMD เริ่มต้นด้วยรูปแบบที่แตกต่างกันทั้งสองนี้กันเถอะ
CMD
วิธีประกาศการพึ่งพาโมดูล CMD:
การคัดลอกรหัสมีดังนี้:
กำหนด (ฟังก์ชั่น (ต้องการ) {
var a = ต้องการ ('./ a');
var b = ต้องการ ('./ b');
// รหัสเพิ่มเติม ..
-
การขึ้นอยู่กับการพึ่งพา CMD จะถูกประกาศในบริเวณใกล้เคียงและมีการประกาศผ่านวิธีการภายในที่ต้องการ อย่างไรก็ตามเนื่องจากเป็นโมดูลแบบอะซิงโครนัสตัวโหลดจึงต้องโหลดโมดูลเหล่านี้ล่วงหน้าดังนั้นก่อนที่จะใช้โมดูลจริงการพึ่งพาทั้งหมดในโมดูลจะต้องสกัด ไม่ว่าจะเป็นการสกัดแบบโหลดเดอร์หรือการตรวจสอบล่วงหน้าผ่านเครื่องมืออัตโนมัติรูปแบบการประกาศการพึ่งพาของ CMD นี้สามารถนำไปใช้ได้ผ่านการวิเคราะห์แบบคงที่ซึ่งเป็นข้อเสียของ CMD
ข้อเสียของข้อกำหนด CMD
ไม่สามารถบีบอัดได้โดยตรง: ต้องการเป็นตัวแปรท้องถิ่นซึ่งหมายความว่าไม่สามารถบีบอัดได้โดยตรงผ่านเครื่องมือการบีบอัด หากมีการเปลี่ยนตัวแปรที่ต้องการเครื่องมือโหลดเดอร์และระบบอัตโนมัติจะไม่สามารถรับการอ้างอิงของโมดูลได้
โมดูลมีการประชุมเพิ่มเติม: พารามิเตอร์พา ธ ไม่สามารถใช้งานสตริงได้และไม่สามารถใช้ตัวแปรแทนได้ไม่เช่นนั้นเครื่องมือโหลดและระบบอัตโนมัติไม่สามารถแยกเส้นทางได้อย่างถูกต้อง
อนุสัญญานอกข้อกำหนดหมายถึงเอกสารเพิ่มเติมเว้นแต่จะเป็นส่วนหนึ่งของข้อกำหนด
หมายเหตุ: การใช้การวิเคราะห์แบบคงที่ SEAJS คือการใช้ส่วนข้อกำหนดการสกัดปกติเพื่อให้ได้เส้นทางโมดูลการพึ่งพา
เอเอ็มดี
วิธีประกาศการพึ่งพาโมดูล AMD:
การคัดลอกรหัสมีดังนี้:
กำหนด (['./ a', './b'], ฟังก์ชั่น (a, b) {
// รหัสเพิ่มเติม ..
-
การพึ่งพาของ AMD ได้รับการประกาศล่วงหน้า ข้อได้เปรียบของข้อได้เปรียบนี้คือการพึ่งพาอาศัยกันไม่จำเป็นต้องมีการวิเคราะห์แบบคงที่ ทั้งตัวโหลดและเครื่องมืออัตโนมัติสามารถได้รับการอ้างอิงโดยตรง คำจำกัดความของข้อกำหนดสามารถทำได้ง่ายขึ้นซึ่งหมายความว่าการใช้งานที่มีประสิทธิภาพมากขึ้นอาจถูกสร้างขึ้นซึ่งเป็นประโยชน์ต่อทั้งตัวโหลดและเครื่องมือวิเคราะห์ระบบอัตโนมัติ
ข้อเสียของข้อกำหนด AMD
การประกาศล่วงหน้าการพึ่งพานั้นไม่เป็นมิตรในการเขียนรหัส
มีความแตกต่างระหว่างโมดูลภายในและโมดูลของ nodejs
ฉบับที่สองจะต้องมีการอธิบายอย่างละเอียด ในความเป็นจริงโมดูลอะซิงโครนัสของ CMD หรือ AMD ไม่สามารถสอดคล้องกับข้อกำหนดของโมดูลการซิงโครไนซ์ (โมดูลของ NodeJS) มีเพียงโมดูลการซิงโครไนซ์มากกว่าใคร ในการแปลง AMD เป็นโมดูลการซิงโครไนซ์นอกเหนือจากการลบแพ็คเกจของฟังก์ชั่นการกำหนดคุณต้องใช้จำเป็นต้องใช้ในหัวเพื่อประกาศการพึ่งพาในขณะที่ CMD จำเป็นต้องลบแพ็คเกจของฟังก์ชันกำหนด
สรุป
ในแง่ของข้อกำหนด AMD นั้นง่ายกว่าและเข้มงวดและมีการบังคับใช้ที่กว้างขึ้น ด้วยการโปรโมตที่แข็งแกร่งของ VeutheJS มันเกือบจะกลายเป็นมาตรฐานโมดูลอะซิงโครนัสในต่างประเทศและห้องสมุดที่สำคัญได้สนับสนุนข้อกำหนดของ AMD อย่างต่อเนื่อง
แต่จาก SEAJS และ CMD เราได้ทำสิ่งดีๆมากมาย:
1. รูปแบบคำสั่งการพึ่งพาที่ค่อนข้างเป็นธรรมชาติ
2. การรับรู้ภายในขนาดเล็กและสวยงาม
3. การออกแบบฟังก์ชั่นรอบนอกอย่างระมัดระวัง
4. การสนับสนุนชุมชนจีนที่ดีขึ้น
ถ้าเป็นไปได้ฉันหวังว่าจะได้เห็น SEAJS ยังสนับสนุน AMD และความสุขที่ดีที่สุดของนักพัฒนาคือนักพัฒนาส่วนใหญ่