การวิจารณ์ React ล่าสุดจากนักพัฒนาได้จุดประกายการอุทิศที่เต็มไปด้วยความหลงใหลในชุมชนโปรแกรมเมอร์เกี่ยวกับวิวัฒนาการและความซับซ้อนของ frontend framework สมัยใหม่ การถกเถียงมีจุดศูนย์กลางอยู่ที่ว่าสถานะปัจจุบันของ React แสดงถึงความก้าวหน้าหรือเป็นการถอยหลังจากแนวทางการพัฒนาเว็บที่เรียบง่ายกว่า
ไทม์ไลน์วิวัฒนาการของ Frontend Framework:
- ยุค jQuery: ไลบรารีสำหรับจัดการ DOM ที่กลายเป็นมาตรฐานสำหรับเว็บแอปพลิเคชันเชิงโต้ตอบ
- Angular 1: เฟรมเวิร์กหลักตัวแรกที่ให้โครงสร้างและการผูกข้อมูลแบบสองทาง
- Angular 2+: การเขียนใหม่ทั้งหมดด้วย TypeScript ทำให้มีความซับซ้อนเพิ่มขึ้น
- React: แนวทางไลบรารีที่มาพร้อม JSX เริ่มต้นง่ายกว่าแต่ความซับซ้อนของระบบนิเวศเพิ่มขึ้น
- สถานะปัจจุบัน: มีแนวทางที่แข่งขันกันหลายแบบ ( Vue , Svelte ฯลฯ) ที่พยายามแก้ไขข้อจำกัดของ React
ปัญหาความซับซ้อนหลัก
การอภิปรายเผยให้เห็นความตึงเครียดพื้นฐานในการพัฒนาเว็บสมัยใหม่ นักพัฒนาหลายคนชี้ไปที่การจัดการสถานะของ React ว่าเป็นแหล่งที่มาหลักของความสับสน แนวทางของเฟรมเวิร์กในการจัดการการไหลของข้อมูล โดยเฉพาะผ่าน React Hooks ได้รับการวิจารณ์ว่าสร้างสิ่งที่บางคนมองว่าเป็นตัวแปรโกลบอลที่ถูกประดับประดาด้วยการตั้งชื่อแบบพิธีการ
สมาชิกในชุมชนได้เน้นจุดเจ็บปวดเฉพาะกับ useEffect ซึ่งนักพัฒนามักใช้สำหรับการเริ่มต้นคอมโพเนนต์แม้ว่าจะถูกออกแบบมาสำหรับ side effects สิ่งนี้ได้นำไปสู่โค้ดที่กระจายตรรกะไปทั่วฟังก์ชันอะซิงโครนัสหลายตัว สร้างสิ่งที่บางคนเปรียบเทียบกับปัญหา callback hell เก่าที่นักพัฒนา JavaScript คิดว่าพวกเขาได้แก้ไขแล้ว
React Hooks: ฟีเจอร์ของ React ที่ช่วยให้นักพัฒนาสามารถใช้สถานะและฟีเจอร์อื่น ๆ ของ React ในคอมโพเนนต์ฟังก์ชัน useEffect: React Hook ที่ใช้สำหรับดำเนินการ side effects ในคอมโพเนนต์ฟังก์ชัน
ประเด็นวิจารณ์ด้านเทคนิคที่สำคัญที่ถูกหยิบยกมาพูดถึง:
- การจัดการ State: React Hooks สร้างการเข้าถึง state แบบ pseudo-global
- การใช้ useEffect ผิดวิธี: การใช้ side-effect hooks สำหรับการเริ่มต้น component
- ความสับสนในสถาปัตยกรรม: การแยกแยะที่ไม่ชัดเจนระหว่างรูปแบบ MVC และสถาปัตยกรรมแบบ component-based
- ภาระงาน Boilerplate ที่มากเกินไป: ความซับซ้อนของโค้ดที่เพิ่มขึ้นสำหรับงานง่ายๆ
- การติดกับ Framework: แอป React แต่ละตัวต้องการการตัดสินใจสถาปัตยกรรมแบบเฉพาะเจาะจง
ความเหนื่อยล้าจากเฟรมเวิร์กและทางเลือกอื่น
การสนทนาได้ขยายออกไปจาก React เพื่อครอบคลุมความท้าทายในการพัฒนา frontend ที่กว้างขึ้น นักพัฒนากำลังตั้งคำถามว่าความซับซ้อนเกิดจากตัวเฟรมเวิร์กเองหรือจากความยากโดยธรรมชาติของการสร้างส่วนติดต่อผู้ใช้แบบโต้ตอบ
สมาชิกในชุมชนบางคนสนับสนุนการกลับไปใช้ server-side rendering พร้อมกับการใช้ JavaScript framework แบบเลือกสรรเฉพาะในที่ที่จำเป็นจริง ๆ คนอื่น ๆ ชี้ไปที่ทางเลือกอื่นเช่น Vue.js ซึ่งรายงานว่าแก้ไขจุดเจ็บปวดหลายอย่างของ React ผ่านระบบ reactivity ที่แตกต่างกัน
HTML5 หมายถึงไม่มี JS หรือ? ดังนั้นจะต้องโหลดหน้าเต็มหลังจากคลิกทุกครั้งหรือ?
การแลกเปลี่ยนนี้จับภาพความตึงเครียดที่กำลังดำเนินอยู่ระหว่างความเรียบง่ายและการทำงานที่กำหนดการอภิปรายการพัฒนาเว็บสมัยใหม่
ภาพรวมใหญ่
การถกเถียงในที่สุดตั้งคำถามว่าชุมชนการพัฒนาเว็บได้ทำให้สิ่งที่ควรจะเป็นงานตรงไปตรงมาซับซ้อนเกินไปหรือไม่ นักวิจารณ์โต้แย้งว่าการสร้าง interactive UI ได้กลายเป็นเรื่องซับซ้อนโดยไม่จำเป็น โดยเฟรมเวิร์กพยายามแก้ปัญหาที่อาจจะแก้ไขได้ดีกว่าผ่านแนวทางที่เรียบง่ายกว่า
อย่างไรก็ตาม ผู้สนับสนุนเฟรมเวิร์กสมัยใหม่ชี้ให้เห็นว่าความซับซ้อนมักมาจากนักพัฒนาที่ใช้เครื่องมือผิดวิธีมากกว่าข้อบกพร่องโดยธรรมชาติในตัวเฟรมเวิร์กเอง พวกเขาโต้แย้งว่าการเข้าใจและการนำไปใช้เครื่องมือเหล่านี้อย่างถูกต้องสามารถนำไปสู่แอปพลิเคชันที่สามารถบำรุงรักษาและขยายได้
การอภิปรายสะท้อนการสนทนาในอุตสาหกรรมที่กว้างขึ้นเกี่ยวกับการสร้างสมดุลระหว่างประสบการณ์นักพัฒนา ประสิทธิภาพแอปพลิเคชัน และความสามารถในการบำรุงรักษาระยะยาวในระบบนิเวศที่ยังคงพัฒนาอย่างรวดเร็ว
อ้างอิง: React Still Feels Insane And No One Is Talking About It