ในโลกของการพัฒนาเว็บที่มีการเปลี่ยนแปลงอยู่ตลอดเวลา การถกเถียงที่เผ็ดร้อนได้กลับมาอีกครั้งเกี่ยวกับข้อดีของการใช้ JavaScript แบบธรรมดาเทียบกับ frameworks ยอดนิยมอย่าง React, Vue หรือ Svelte การอภิปรายนี้มุ่งเน้นไปที่รูปแบบที่เรียกว่า Writing JavaScript Views the Hard Way ซึ่งสนับสนุนการจัดการ DOM โดยตรงด้วย JavaScript แบบดั้งเดิมแทนที่จะพึ่งพาชั้นการทำงานแบบนามธรรมที่ frameworks มอบให้
 |
|---|
| GitHub repository สำหรับ "Writing JavaScript Views the Hard Way" แสดงให้เห็นถึงโปรเจคสำคัญในการถกเถียงระหว่างการใช้ JavaScript แบบธรรมดากับการใช้เฟรมเวิร์ค |
ความน่าดึงดูดของการไม่ใช้ Framework
นักพัฒนาหลายคนในชุมชนแสดงความกระตือรือร้นที่จะเลิกใช้ frameworks และหันมาใช้วิธีการแบบ JavaScript ธรรมดา พวกเขากล่าวถึงประโยชน์ด้านประสิทธิภาพที่สำคัญ การดีบั๊กที่ง่ายขึ้น และการเชื่อมต่อกับแพลตฟอร์มเว็บโดยตรงมากขึ้น นักพัฒนาคนหนึ่งได้แบ่งปันประสบการณ์ล่าสุดของพวกเขาในการสร้างแอปพลิเคชันด้วย TypeScript ธรรมดาร่วมกับ Vite โดยสังเกตว่าพวกเขาเริ่มตั้งคำถามกับ 'แนวปฏิบัติที่ดีที่สุด' ของ front end มากขึ้นหลังจากได้เห็นประโยชน์ของวิธีการโดยตรง ความน่าดึงดูดนี้ขยายไปไกลกว่าข้อได้เปรียบทางเทคนิคเพียงอย่างเดียว แต่รวมถึงประโยชน์ด้านการศึกษา เนื่องจากการทำงานกับ DOM โดยตรงบังคับให้นักพัฒนาเข้าใจเทคโนโลยีเว็บพื้นฐานได้ลึกซึ้งยิ่งขึ้น
ผมไม่สามารถสรุปได้ว่ามันขยายได้ ไม่ว่าจะหมายความว่าอย่างไร แต่ผมสามารถสรุปได้ว่ามีประโยชน์มหาศาลในแง่ของประสิทธิภาพ มันสนุก สอนคุณได้มาก การดีบั๊กนั้นง่าย การเข้าใจสถาปัตยกรรมเป็นเรื่องง่าย คุณไม่จำเป็นต้องมีปริญญาเอกในเทคนิคการเรนเดอร์/การจดจำ/อื่นๆ
ข้อดีของ "การเขียน JavaScript Views แบบยากๆ"
- ประสิทธิภาพ: ได้ประสิทธิภาพใกล้เคียงกับค่าที่ดีที่สุดโดยมีการทำงานที่ไม่จำเป็นน้อยที่สุด
- ไม่มีการพึ่งพาภายนอก: ไม่จำเป็นต้องอัปเกรดหรือจัดการไลบรารีภายนอก
- ความสามารถในการพกพา: โค้ดสามารถใช้ได้กับเฟรมเวิร์คใดก็ได้
- การบำรุงรักษา: ปฏิบัติตามข้อกำหนดที่เคร่งครัดสำหรับการจัดระเบียบโค้ดที่คาดการณ์ได้
- การรองรับเบราว์เซอร์: เข้ากันได้กับเบราว์เซอร์ทั้งหมด (พร้อมตัวเลือกความเข้ากันได้สำหรับเบราว์เซอร์รุ่นเก่า)
- การดีบั๊กที่ง่ายขึ้น: การติดตามสแต็คที่ไม่ซับซ้อนทำให้การตรวจสอบปัญหาง่ายขึ้น
- แนวทางเชิงฟังก์ชัน: ใช้ฟังก์ชันธรรมดาโดยไม่มีลำดับชั้นของคลาสที่ซับซ้อน
DOM ในฐานะแหล่งที่มาของความจริง
รูปแบบที่น่าสนใจที่ปรากฏในการอภิปรายคือการใช้ DOM เองเป็นแหล่งที่มาของความจริงสำหรับสถานะของแอปพลิเคชัน แทนที่จะรักษาตัวแปรสถานะแยกต่างหาก นักพัฒนาบางคนสนับสนุนให้อ่านและเขียนไปยังองค์ประกอบของ DOM โดยตรงผ่าน getters และ setters แทนที่จะเก็บตัวแปร JavaScript แยกต่างหากที่ต้องซิงโครไนซ์กับ DOM วิธีการนี้ขจัดความจำเป็นในการรักษาสถานะในสองที่ แต่ก็ทำให้เกิดความกังวลเกี่ยวกับช่องโหว่ที่อาจเกิดขึ้นจากส่วนขยายของเบราว์เซอร์ที่อาจแก้ไข DOM โดยไม่คาดคิด หรือความท้าทายในการจัดการกับสถานะที่ซ้ำซ้อนในหลายๆ คอมโพเนนต์ของ UI
ความกังวลเรื่องการบำรุงรักษา
ในขณะที่วิธีการแบบ Hard Way สัญญาว่าจะมีความเรียบง่าย นักพัฒนาหลายคนแสดงความสงสัยเกี่ยวกับการบำรุงรักษาในสภาพแวดล้อมของทีมและแอปพลิเคชันขนาดใหญ่ รูปแบบนี้พึ่งพาข้อตกลงร่วมกันมากกว่าโครงสร้างที่บังคับใช้ ซึ่งอาจนำไปสู่ความไม่สอดคล้องกันเมื่อสมาชิกในทีมที่แตกต่างกันมีส่วนร่วมในโค้ด ดังที่ผู้แสดงความคิดเห็นคนหนึ่งชี้ให้เห็นว่า รูปแบบการออกแบบนี้ขึ้นอยู่กับข้อตกลงเท่านั้น ซึ่งหมายความว่านักพัฒนาสามารถเบี่ยงเบนจากข้อตกลงได้ตามต้องการ ซึ่งแตกต่างจาก frameworks ที่บังคับใช้รูปแบบบางอย่างผ่าน API และเครื่องมือของพวกเขา
การจัดการสถานะ: ความท้าทายที่แท้จริง
ประเด็นที่เกิดขึ้นซ้ำๆ ในความคิดเห็นคือความยากที่แท้จริงในการพัฒนา frontend ไม่ใช่การสร้างองค์ประกอบ DOM แต่เป็นการจัดการสถานะและการทำให้ UI ซิงค์กับสถานะนั้น Reactive frameworks มีอยู่เพื่อแก้ปัญหานี้โดยเฉพาะ เมื่อแอปพลิเคชันมีความซับซ้อนมากขึ้น การติดตามว่าส่วนใดของ UI ต้องอัปเดตเมื่อสถานะเปลี่ยนแปลงจะยิ่งยากขึ้น นักพัฒนาคนหนึ่งสังเกตว่าปัญหาพื้นฐานคือเมื่อสถานะบางอย่างเปลี่ยนแปลง UI ทั้งหมดที่ขึ้นอยู่กับสถานะนั้นต้องได้รับการอัปเดต และการรักษาฟังก์ชันอัปเดตเหล่านี้ด้วยตนเองจะยิ่งยากขึ้นเมื่อแอปพลิเคชันมีขนาดใหญ่ขึ้น
โครงสร้างของคอมโพเนนต์แบบ "Hard Way"
- Template: ใช้
document.createElement('template')สำหรับโครงสร้าง HTML - ฟังก์ชันโคลน: สร้างอินสแตนซ์ใหม่ของเทมเพลต
- ฟังก์ชัน Init: ตั้งค่าอินสแตนซ์ของคอมโพเนนต์ด้วย:
- ตัวแปร DOM (การอ้างอิงถึงอิลิเมนต์)
- ตัวแปรสถานะ (ค่าข้อมูล)
- ฟังก์ชันอัปเดต DOM (สำหรับการเปลี่ยนแปลงอิลิเมนต์)
- ฟังก์ชันอัปเดตสถานะ (สำหรับการเปลี่ยนแปลงข้อมูล)
- ฟังก์ชันอัปเดต (สำหรับการรับ props จาก parent)
ข้อพิจารณาด้านความปลอดภัย
นักพัฒนาหลายคนแสดงความกังวลเกี่ยวกับช่องโหว่ด้านความปลอดภัยที่อาจเกิดขึ้นในวิธีการเขียนเทมเพลตด้วยมือ การใช้ template literals เพื่อสร้างสตริง HTML สามารถนำไปสู่ช่องโหว่ cross-site scripting (XSS) หากไม่มีการตรวจสอบข้อมูลที่ผู้ใช้ป้อนอย่างเหมาะสม แม้ว่าการทำความสะอาดข้อมูลฝั่งเซิร์ฟเวอร์จะช่วยได้ แต่หลายคนโต้แย้งว่า frameworks สมัยใหม่ให้การป้องกันที่ดีกว่าโดยจัดการสิ่งนี้โดยอัตโนมัติ การอภิปรายได้เน้นให้เห็นว่านักพัฒนาสามารถแนะนำปัญหาด้านความปลอดภัยได้ง่ายเพียงใดเมื่อสร้าง HTML ด้วยตนเอง โดยเฉพาะผู้ที่ไม่เคยมีประสบการณ์ในยุคการพัฒนาเว็บก่อนที่จะมี framework
โดยสรุป แม้ว่าวิธีการแบบ Hard Way จะนำเสนอประโยชน์ที่น่าสนใจสำหรับกรณีการใช้งานบางอย่าง—โดยเฉพาะอย่างยิ่งในแง่ของประสิทธิภาพ การควบคุม และโอกาสในการเรียนรู้—ชุมชนยังคงแบ่งแยกว่าเหมาะสมสำหรับแอปพลิเคชันการผลิตในระดับใหญ่หรือไม่ การถกเถียงในที่สุดสะท้อนถึงความตึงเครียดระหว่างความเรียบง่ายและโครงสร้าง ระหว่างการควบคุมโดยตรงและความสะดวกแบบนามธรรม ซึ่งเป็นลักษณะของการพัฒนาเว็บมาหลายปี เมื่อเบราว์เซอร์ยังคงพัฒนาและนำเสนอ API ดั้งเดิมที่ทรงพลังมากขึ้น การสนทนานี้น่าจะยังคงพัฒนาต่อไปเช่นกัน