ชุมชนนักพัฒนา frontend กำลังมีการอภิปรายอย่างเข้มข้นเกี่ยวกับการครองตลาดอย่างท่วมท้นของ React และผลกระทบที่อาจเกิดขึ้นต่อนวัตกรรม แม้ว่า React จะกลายเป็นตัวเลือกมาตรฐานสำหรับโปรเจกต์เว็บส่วนใหญ่ แต่นักพัฒนากำลังตั้งคำถามว่าการครองตลาดนี้กำลังขัดขวางการนำทางเลือกที่อาจจะดีกว่ามาใช้หรือไม่
 |
|---|
| ชุมชนนักพัฒนา frontend กำลังอภิปรายกันอย่างกระตือรือร้นเกี่ยวกับผลกระทบของการครอบงำของ React ต่อนวัตกรรม |
การถกเถียงระหว่างคุณภาพทางเทคนิคกับการเป็นตัวเลือกมาตรฐาน
ประเด็นหลักมุ่งเน้นไปที่ว่า React ยังคงชนะด้วยความเป็นเลิศทางเทคนิคหรือเพียงแค่เพราะมันกลายเป็นตัวเลือกที่ปลอดภัยและเป็นมาตรฐาน นักพัฒนาหลายคนยอมรับว่าความสำเร็จในช่วงแรกของ React สมควรได้รับ โดยเฉพาะเมื่อเปรียบเทียบกับ framework รุ่นก่อนหน้าอย่าง Angular 1.x อย่างไรก็ตาม ภูมิทัศน์ได้เปลี่ยนแปลงไปอย่างมากนับตั้งแต่ช่วงแรกของ React
ทางเลือกสมัยใหม่อย่าง Svelte, Solid และ Qwik มีข้อได้เปรียบทางเทคนิคที่น่าสนใจ Svelte กำจัดค่าใช้จ่าย runtime ผ่านการปรับปรุงประสิทธิภาพในช่วง compile-time, Solid ให้การตอบสนองแบบละเอียดโดยไม่มีต้นทุนของ virtual DOM และ Qwik บรรลุการเริ่มต้นแบบทันทีผ่านความสามารถในการกลับมาทำงานต่อได้ แต่ framework เหล่านี้ยังคงต่อสู้เพื่อให้ได้ส่วนแบ่งตลาดที่มีความหมายแม้จะมีคุณสมบัติทางเทคนิคที่ดี
การเปรียบเทียบประสิทธิภาพของเฟรมเวิร์กทางเลือก
- Svelte: ลดขนาดบันเดิลได้อย่างมาก (ตัวอย่าง: แอป React ขนาด 187KB → แอป Svelte ขนาด 9KB)
- Solid: ทำการอัปเดตได้เร็วกว่า 2-3 เท่าในสถานการณ์ที่ใช้ reactivity มากเมื่อเทียบกับ React
- Qwik: ช่วยให้เริ่มต้นได้ทันทีผ่านการโหลดแบบค่อยเป็นค่อยไปและความสามารถในการกลับมาทำงานต่อได้
- React: มีพื้นที่ครอบคลุมที่ใหญ่กว่าด้วย hooks, context, รูปแบบ memoization ที่ต้องการการจัดการอย่างระมัดระวัง
กับดักของ Network Effect
การครองตลาดของ React ได้สร้างวงจรที่เสริมตัวเองซึ่งขยายไปไกลกว่าการพิจารณาทางเทคนิค การประกาศรับสมัครงานระบุเฉพาะนักพัฒนา React แทนที่จะเป็นวิศวกร frontend ทำให้เกิดไปป์ไลน์ความสามารถที่โน้มเอียงไปหา React ตามธรรมชาติ บริษัทต่างๆ เลือก React ไม่ใช่เพราะมันเหมาะสมที่สุดทางเทคนิค แต่เพราะมันเป็นการตัดสินใจจ้างงานที่ปลอดภัยที่สุด
Network effect นี้ได้รับการขยายผลเพิ่มเติมจากการเพิ่มขึ้นของผู้ช่วยเขียนโค้ด AI ซึ่งมีข้อมูลการฝึกอบรมสำหรับ React มากกว่า framework อื่นๆ ดังที่นักพัฒนาคนหนึ่งกล่าวไว้ แม้เมื่อสั่งให้เครื่องมือ AI สร้างเว็บแอปพลิเคชัน พวกมันมักจะใช้ component ของ React เป็นค่าเริ่มต้น ทำให้เกิดการเสริมวงจรนี้
ประสบการณ์ของนักพัฒนา: ดาบสองคม
ชุมชนยังคงแบ่งแยกเกี่ยวกับประสบการณ์ของนักพัฒนาใน React ผู้สนับสนุนชื่นชมความเป็นผู้ใหญ่ ระบบนิเวศที่กว้างขวาง และความสามารถในการหานักพัฒนาที่มีประสบการณ์ได้อย่างง่ายดาย กระบวนทัศน์เชิงฟังก์ชันและสถาปัตยกรรมแบบ component-based ของ framework นี้ได้มีอิทธิพลต่อวิธีที่นักพัฒนาคิดเกี่ยวกับการสร้าง user interface
อย่างไรก็ตาม นักวิจารณ์ชี้ไปที่ความซับซ้อนของ React และภาระทางปัญญาในการจัดการ hooks, dependency arrays และ effect lifecycles การพัฒนาของ framework จาก class components ไปเป็น hooks แล้วไปเป็น server components แสดงให้เห็นการเปลี่ยนแปลงอย่างต่อเนื่องมากกว่าความมั่นคง ซึ่งขัดแย้งกับข้อโต้แย้งเกี่ยวกับ React ที่เป็นตัวเลือกเทคโนโลยีที่น่าเบื่อ
DX ของ React เป็นขยะที่แย่มาก คำพูดไม่สามารถแสดงออกได้ว่าฉันเกลียด hook rules มากแค่ไหน เมื่อมาจากพื้นฐาน Solid JS ที่ reactive primitives เป็นเพียงฟังก์ชัน Javascript ธรรมดา... ฉันครางทุกครั้งที่เจอ hook rule (อีกครั้ง)
ข้อกังวลเรื่องประสิทธิภาพและขนาด Bundle
แม้ว่าประสิทธิภาพของ React จะเพียงพอสำหรับแอปพลิเคชันส่วนใหญ่ แต่การอภิปรายเผยให้เห็นความกังวลที่เพิ่มขึ้นเกี่ยวกับค่าใช้จ่ายที่ไม่จำเป็น Virtual DOM ซึ่งครั้งหนึ่งเคยเป็นนวัตกรรมหลักของ React ตอนนี้ถูกมองโดยบางคนว่าเป็นค่าใช้จ่ายล้วนๆ ที่คอมไพเลอร์สมัยใหม่สามารถกำจัดได้ Framework ทางเลือกแสดงให้เห็นประสิทธิภาพที่ดีกว่าอย่างเห็นได้ชัดในสถานการณ์เฉพาะ โดยบางตัวบรรลุการอัปเดตที่เร็วกว่า 2-3 เท่าในแอปพลิเคชันที่ใช้ reactivity มาก
อย่างไรก็ตาม นักพัฒนาหลายคนโต้แย้งว่าความแตกต่างด้านประสิทธิภาพเหล่านี้มีนัยสำคัญเล็กน้อยสำหรับแอปพลิเคชันธุรกิจทั่วไป คำถามกลายเป็นว่าการปรับปรุงประสิทธิภาพเล็กน้อยนั้นสมควรกับความเสี่ยงที่เกี่ยวข้องกับการนำ framework ที่มีการยอมรับน้อยกว่ามาใช้หรือไม่
ต้นทุนโอกาสของนวัตกรรม
บางทีข้อโต้แย้งที่น่าสนใจที่สุดต่อการครองตลาดของ React คือต้นทุนโอกาสของทางเลือกที่ยังไม่ได้สำรวจ เมื่อทีมใช้ React เป็นค่าเริ่มต้นโดยไม่ประเมิน พวกเขาพลาดโอกาสในการค้นพบ framework ที่อาจเหมาะสมกับความต้องการเฉพาะของพวกเขามากกว่า รูปแบบนี้ส่งผลกระทบต่อสตาร์ทอัปและทีมเล็กๆ โดยเฉพาะ ซึ่งอาจได้ประโยชน์จากโซลูชันที่มีน้ำหนักเบากว่า
การอภิปรายยังเน้นให้เห็นว่าความซับซ้อนของ React สามารถเพิ่มเวลาการพัฒนาสำหรับโปรเจกต์ง่ายๆ ได้อย่างไร เครื่องมืออย่าง Phoenix LiveView, Hotwire และ Livewire เสนอทางเลือกที่น่าสนใจสำหรับทีมที่ไม่ต้องการความซับซ้อนของ framework ฝั่งไคลเอ็นต์แบบเต็มรูปแบบ
รายการตรวจสอบการประเมิน Framework สำหรับทีม
- ความต้องการด้านประสิทธิภาพ: เวลาเริ่มต้น ประสิทธิภาพการอัปเดต ลำดับความสำคัญของขนาด bundle
- ทักษะของทีม: ความเชี่ยวชาญที่มีอยู่เทียบกับเส้นโค้งการเรียนรู้และเส้นทางการย้าย
- ต้นทุนการขยายขนาด: การบำรุงรักษาระยะยาว การจัดการ dependency หนี้ทางเทคนิค
- ความเหมาะสมกับระบบนิเวศ: ความสมดุลระหว่างความเป็นผู้ใหญ่และนวัตกรรมสำหรับความต้องการของโครงการ
มองไปข้างหน้า
การถกเถียงสะท้อนความตึงเครียดที่กว้างขึ้นในการพัฒนาซอฟต์แวร์ระหว่างนวัตกรรมและความมั่นคง แม้ว่านักพัฒนาบางคนจะยินดีกับความมั่นคงที่การครองตลาดของ React ให้ แต่คนอื่นๆ กังวลเกี่ยวกับสุขภาพระยะยาวของระบบนิเวศ frontend ฉันทามติดูเหมือนจะเป็นว่า React ได้รับตำแหน่งผ่านคุณภาพทางเทคนิคในตอนแรก แต่ตอนนี้รักษาไว้ผ่าน network effects มากกว่าความเหนือกว่าทางเทคนิคที่ต่อเนื่อง
เส้นทางไปข้างหน้าน่าจะต้องการการดำเนินการโดยเจตนาจากผู้นำทางเทคนิคที่เต็มใจประเมินทางเลือกตามข้อจำกัดของโปรเจกต์มากกว่าสมมติฐานเริ่มต้น ในขณะที่ภูมิทัศน์ frontend ยังคงพัฒนาต่อไป คำถามยังคงอยู่ว่าการครองตลาดของ React จะค่อยๆ หลีกทางให้กับเครื่องมือที่เฉพาะเจาะจงมากขึ้นในที่สุด หรือ network effects จะแข็งแกร่งเกินไปที่จะเอาชนะได้
อ้างอิง: REACT WON BY DEFAULT – AND IT'S KILLING FRONTEND INNOVATION