- ปัจจุบัน การนำ React มาใช้เกิดจากการเป็นค่าเริ่มต้น ไม่ใช่ความเหนือกว่าทางเทคนิค และสิ่งนี้กำลังชะลอนวัตกรรมของระบบนิเวศฟรอนต์เอนด์
- หลายทีมเลือก “React ที่ทุกคนรู้จัก” โดยไม่พิจารณาข้อจำกัดของงาน ทำให้ ผลของเครือข่าย (network effect) กลายเป็นตัวกำหนดการตัดสินใจด้านสถาปัตยกรรมมากกว่าความเหมาะสมทางเทคนิค
- เฟรมเวิร์กเชิงนวัตกรรม อย่าง Svelte, Solid และ Qwik มอบโมเดลด้านประสิทธิภาพที่ดีกว่า แต่กลับถูกเบียดออกจากการแข่งขันกระแสหลักเพราะอัตราการยอมรับที่ยังต่ำ
- React มีข้อดีมากมาย แต่ปัญหาคือ กรอบความคิดแบบ React-first ที่เพิ่มต้นทุนค่าเสียโอกาสและปิดกั้นพื้นที่ในการพิจารณาทางเลือกที่ดีกว่า
- เพื่อให้ระบบนิเวศมีสุขภาพดี จำเป็นต้องมีความหลากหลายและการแข่งขัน โดยสารหลักคือ ควรเลือกเฟรมเวิร์กตามข้อจำกัดและความเหมาะสม ไม่ใช่เลือกเพราะเป็นค่าเริ่มต้น
ชัยชนะของ React จากการเป็นค่าเริ่มต้น และข้อจำกัดของมัน
- React ไม่ได้ถูกเลือกเพราะความได้เปรียบทางเทคนิคอีกต่อไป แต่ในหลายกรณี ถูกนำมาใช้เพราะเป็นตัวเลือกเริ่มต้น
- สิ่งนี้ตอกย้ำพฤติกรรมที่ทีมต่าง ๆ ใช้ React โดยอัตโนมัติ โดยไม่ประเมินข้อจำกัดของโปรเจกต์
- เฟรมเวิร์กทางเลือกอย่าง Svelte, Solid และ Qwik แม้จะมีข้อได้เปรียบด้านประสิทธิภาพเหนือ React ในบางสถานการณ์ ก็ยังไม่ได้รับการประเมินอย่างจริงจัง
- ปัญหาไม่ได้อยู่ที่ React เองเท่านั้น แต่คือ กรอบความคิดแบบ React-first ที่สร้างโครงสร้างซึ่งขัดขวางนวัตกรรม
เพดานของนวัตกรรม
- Virtual DOM ของ React เหมาะสมในปี 2013 แต่ในปัจจุบันกลับกลายเป็นโอเวอร์เฮดที่ไม่จำเป็น
- Hooks แก้ปัญหาของ class component ได้ก็จริง แต่ก็ได้นำความซับซ้อนใหม่ ๆ เช่น dependency array และ stale closure เข้ามาด้วย
- Server Components และ React Compiler พยายามปรับปรุงประสิทธิภาพ แต่ก็เป็นเพียงวิธีหลบเลี่ยงข้อจำกัดของโมเดล React
- ในทางกลับกัน Runes ของ Svelte, fine-grained reactivity ของ Solid และ Resumability ของ Qwik แสดงให้เห็นถึงศักยภาพที่สูงกว่าด้วยโมเดลที่แตกต่างโดยสิ้นเชิง
หนี้ทางเทคนิค
- เมื่อเลือก React เป็นค่าเริ่มต้น จะเกิด ต้นทุนรันไทม์ที่ไม่จำเป็นและภาระในการจัดการ re-render
- นักพัฒนาต้องใช้เวลากับเรื่องอย่าง dependency ของ effect หรือการจัดการ hydration แทนที่จะโฟกัสกับคุณค่าทางธุรกิจ
- ใน benchmark นั้น Solid แสดงประสิทธิภาพการอัปเดตที่เร็วกกว่า React 2–3 เท่า
- การคิดแบบยึดแพตเทิร์นของ React เป็นศูนย์กลาง ทำให้พื้นฐานของเว็บอ่อนแอลงและยิ่งเพิ่มแรงเฉื่อยทางสถาปัตยกรรม
เฟรมเวิร์กทางเลือก
-
Svelte: การปฏิวัติของคอมไพเลอร์
- Svelte จัดการงานส่วนใหญ่ในระดับ compile time และตัด virtual DOM ออกไป
- คอมโพเนนต์จึงใกล้เคียงกับโครงสร้างพื้นฐานของเว็บมากขึ้น และ โอเวอร์เฮดขณะรันจริง ลดลงอย่างมาก
- แต่การรับรู้อย่างว่า “มีโอกาสงานน้อย” ทำให้อัตราการนำไปใช้ยังต่ำ
- กรณีศึกษาหลายแห่ง เช่น The Guardian, Wired และ Shawn Wang พิสูจน์ว่า หลังนำ Svelte มาใช้ ขนาด bundle และเวลาโหลดลดลงอย่างมาก พร้อมกับผลิตภาพของนักพัฒนาที่ดีขึ้น
- ตัวอย่างเช่น Shawn Wang ลดขนาดเว็บไซต์จาก 187KB บน React เหลือ 9KB บน Svelte
-
Solid: แนวทางดั้งเดิมของ reactivity แบบละเอียด
- Solid มอบ reactivity ที่แม่นยำระดับละเอียด (fine-grained reactivity) ควบคู่กับไวยากรณ์ JSX
- ผ่าน signal มันเข้าถึงเฉพาะ DOM ที่มีการเปลี่ยนแปลงโดยตรง และหลีกเลี่ยงคอขวดจาก reconciliation ได้อย่างสิ้นเชิง
- มีจุดเด่นด้านประสิทธิภาพสูงและการจัดการสถานะที่กระชับ
- แม้กรณีการนำไปใช้ยังมีจำกัด แต่จากประสบการณ์ของทีมที่เริ่มใช้ในระยะแรก พบทั้งความมีประสิทธิภาพและความเรียบง่ายของโค้ดที่ดีขึ้นอย่างมาก
-
Qwik: นวัตกรรมของ Resumability
- แทนที่จะใช้ traditional hydration, Qwik โดดเด่นด้วย resumability ที่ทำให้เริ่มต้นได้ทันที
- มันโหลดเฉพาะความสามารถที่จำเป็นแบบค่อยเป็นค่อยไป และสามารถ serialize ได้ทั้งสถานะและโค้ด
- แสดงผลงานยอดเยี่ยมบนเว็บไซต์ขนาดใหญ่ เซสชันระยะยาว และเครือข่ายที่ช้า
- แม้ยังมีหลายทีมที่ไม่ได้ลองใช้ แต่ทีมที่นำไปใช้รายงานว่าทั้ง เวลาโหลดเริ่มต้นและประสิทธิภาพการใช้ทรัพยากร ดีขึ้นอย่างมาก
-
ความซับซ้อนของ React API และความเรียบง่ายของเฟรมเวิร์กทางเลือก
- React API มีแนวคิดที่ซับซ้อนอย่าง hook, context, reducer, memoization ฯลฯ ทำให้ภาระด้านการรับรู้ของนักพัฒนาสูง
- หากใช้ผิดพลาด ก็เสี่ยงเกิดบั๊กจากปัญหา dependency หรือเพิ่มภาระด้านการออกแบบเกินจำเป็น
- ตัวอย่างเช่น เหตุขัดข้องของ Cloudflare เมื่อวันที่ 12 กันยายน 2025 ก็เกิดจากการตั้งค่า dependency array ของ
useEffectผิดพลาด - ในทางกลับกัน ทางเลือกอย่าง Svelte, Solid และ Qwik ใช้ API ที่เล็กและโฟกัสกว่ามาก โดยเน้น ความเรียบง่ายและหลักการพื้นฐานของเว็บ
- แม้ทั้งสามเฟรมเวิร์กนี้จะมีความได้เปรียบทางเทคนิคเพียงพอ แต่ในความเป็นจริงกลับแทบไม่ได้ถูกทดลองเลย เพราะวัฒนธรรมที่มอง React เป็นค่าเริ่มต้น
คุกของผลเครือข่าย
- การครองตลาดของ React กำลังสร้างกำแพงที่ยิ่งเสริมตัวเอง
- ตลาดงานมองหาแต่ “นักพัฒนา React” และแต่ละองค์กรก็ทำให้ ไลบรารีคอมโพเนนต์และพฤติกรรมการพัฒนา แข็งตัวไปตาม React
- ผู้นำที่ต้องการหลีกเลี่ยงความเสี่ยงจึงย่อมเลือก React ที่ดูปลอดภัย และสถาบันการศึกษาก็ปรับตาม
- โครงสร้างแบบนี้คือคุณลักษณะของ ระบบนิเวศที่การแข่งขันอย่างมีสุขภาพดีหายไปแล้ว
การทำลายผลเครือข่าย
- หากต้องการหลุดพ้นจากสิ่งนี้ จำเป็นต้องมี การเลือกอย่างตั้งใจ
- ผู้นำด้านเทคนิคต้องละทิ้งแรงเฉื่อยและตัดสินใจโครงสร้างตามความต้องการ ส่วนองค์กรสามารถจัดสรรงบประมาณสำหรับโครงการนำร่องเพื่อทดลองทางเลือกได้
- ฝั่งนักพัฒนาเองก็ไม่ควรยึดติดกับกระบวนทัศน์เดียว แต่ควรเรียนรู้แนวคิดของเฟรมเวิร์กที่หลากหลาย
- สถาบันการศึกษาควรเพิ่มการสอนแนวคิดแบบ agnostic ต่อเฟรมเวิร์ก และผู้มีส่วนร่วมในโอเพนซอร์สก็สามารถช่วยสนับสนุนระบบนิเวศขนาดเล็กได้
การเปลี่ยนแปลงจะไม่เกิดขึ้นเอง แต่ต้องสร้างขึ้นอย่างตั้งใจ
เช็กลิสต์สำหรับประเมินเฟรมเวิร์ก
เมื่อเริ่มโปรเจกต์ใหม่ สามารถใช้เกณฑ์ต่อไปนี้ในการประเมินได้
- ความต้องการด้านประสิทธิภาพ: เวลาโหลดเริ่มต้น ประสิทธิภาพการอัปเดต ขนาด bundle รวมถึงมีการ optimize ระดับ compile time หรือไม่
- ศักยภาพของทีมและเส้นโค้งการเรียนรู้: พิจารณาประสบการณ์เดิม และมีทางเลือกอย่าง Solid ที่เข้ากันได้กับ React ด้วย
- ความสามารถในการขยายและต้นทุนการเป็นเจ้าของ: ประเมินต้นทุนระยะยาวรวมถึงการบำรุงรักษา การจัดการ dependency และหนี้ทางเทคนิค
- ความเหมาะสมของระบบนิเวศ: สมดุลระหว่างความสุกงอมและนวัตกรรม ทดลองนำร่องในงานที่ไม่ใช่แกนหลักและทดสอบ ROI
ข้อโต้แย้งที่พบบ่อยและการตอบโต้
- ความสุกงอมของระบบนิเวศ: ระบบนิเวศที่เก่าแก่กว่าไม่ได้แปลว่าเหมาะกับปัญหาของวันนี้โดยอัตโนมัติ หากพึ่งพาแพ็กเกจจากภายนอกมากเกินไป ก็จะเกิดภาระการดูแล ช่องโหว่ด้านความปลอดภัย และ bundle ที่พองใหญ่ขึ้น ตรงกันข้าม ระบบนิเวศขนาดเล็กอาจโฟกัสกับรากฐานของเว็บได้มากกว่า และด้วยความก้าวหน้าของเครื่องมือ AI ก็สามารถพัฒนาโซลูชันเฉพาะทางได้ง่ายและรวดเร็ว
- ปัญหาการจ้างงาน: อุปสงค์เองคือสิ่งที่กลายเป็นเกณฑ์การจ้างงาน สามารถทดลองทางเลือกในงานที่ไม่ใช่แกนหลักก่อน แล้วเสริมทักษะที่ขาดผ่านการเรียนรู้หน้างานได้
- ไลบรารีคอมโพเนนต์: ใช้ design system ที่ไม่ผูกกับเฟรมเวิร์ก หรือใช้ Web Component ก็ช่วยลด lock-in และยังรักษาผลิตภาพได้
- ความเสถียร: React เองก็เปลี่ยนแปลงอย่างต่อเนื่องเช่นกัน ทั้ง hooks, Server Components เป็นต้น เฟรมเวิร์กทางเลือกหลายตัวกลับให้ API ที่สม่ำเสมอกว่าเสียอีก
- ความจำเป็นของการพิสูจน์ในกรณีใช้งานขนาดใหญ่: ครั้งหนึ่ง jQuery ก็เคยเป็นตัวอย่างระดับโลก ความสำเร็จในอดีตไม่ได้รับประกันว่าจะยังใช้ได้กับอนาคต
ผลเสียต่อทั้งระบบนิเวศและอุตสาหกรรม
- วัฒนธรรมแบบมี React เพียงหนึ่งเดียวกำลัง ทำให้พัฒนาการของเว็บโดยรวมช้าลง
- พรสวรรค์และเงินทุนไหลไปกับการแก้ปัญหาของ React เป็นหลัก ขณะที่นวัตกรรมเฉพาะของแพลตฟอร์มกลับถูกเลื่อนออกไป
- สถาบันการศึกษาก็เพิ่มการสอนทักษะที่ย้ายใช้ต่อได้ยาก เพราะหลักสูตรเน้น การหางานได้ทันที
- การพัฒนาของแพลตฟอร์มเว็บเองถูกสกัดด้วยคำตอบแบบ “มี React ก็พอแล้ว” และการขาดความหลากหลายของระบบนิเวศจะย้อนกลับมาเป็นความเสียหายระยะยาวต่อทุกฝ่าย
ระบบนิเวศที่พึงประสงค์ซึ่งเราสร้างได้
- ความหลากหลาย คือเงื่อนไขจำเป็นของระบบนิเวศที่มีสุขภาพดี
- เมื่อต่างกระบวนทัศน์แข่งขันและแลกเปลี่ยนกัน นวัตกรรมจึงเกิดขึ้น
- นักพัฒนาก็เติบโตจากการเรียนรู้วิธีคิดที่หลากหลาย และแพลตฟอร์มเว็บเองก็พัฒนาจากจิตวิญญาณแห่งการท้าทายที่หลากหลายเช่นกัน
- การทุ่มทั้งหมดให้กับเฟรมเวิร์กเดียวคือการสร้าง single point of failure เมื่อถึงขีดจำกัด การเติบโตก็หยุดลง และโอกาสที่ดีกว่าก็หายไปด้วย
- ในแต่ละโปรเจกต์ ควรเลือกโดยยึดข้อจำกัดทางเทคนิคและความเหมาะสมเป็นศูนย์กลาง และจำเป็นต้องมีท่าทีที่ไม่พึ่งพา React ในฐานะค่าเริ่มต้นเพียงอย่างเดียว
- มีเพียงความหลากหลายเท่านั้นที่รับประกันนวัตกรรมที่แท้จริงได้
- ถึงเวลาแล้วที่จะเลิกปลูกแต่ “เมล็ดเดียวกัน (React)” และร่วมกันทำให้ระบบนิเวศเว็บแข็งแกร่งและสร้างสรรค์ยิ่งขึ้น ผ่านการทดลองกับเฟรมเวิร์กที่หลากหลายกว่าเดิม
- ทางเลือกอยู่ในมือของพวกเรา
19 ความคิดเห็น
นักพัฒนารุ่นจูเนียร์จะเลือก React ก็เป็นเรื่องที่หลีกเลี่ยงไม่ได้ แต่ปัญหาคือนักพัฒนารุ่นซีเนียร์กลับหยุดคิดถึงทางเลือกอื่นไปเสียแล้ว
ก็จริงที่ว่า React กับ Java เป็นขยะตกยุคที่กินบุญเก่ามานานเกินไป ทั้งที่ตอนนี้มีทางเลือกที่ดีกว่าเยอะมากแล้ว 555
มีการทดลองกันมามากแล้วในยุคเฟรมเวิร์กโกลาหลครั้งก่อน...
แต่ในการทำงานจริงก็ไม่มีความจำเป็นต้องรื้อของเดิมที่ใช้อยู่ทิ้ง และถึงจะเป็นงานใหม่
ก็แทบไม่มีใครเห็นด้วยที่จะทิ้งของที่เคยใช้ได้ดีอยู่แล้วไปเรียนรู้ใหม่แล้วค่อยย้ายไปใช้ อีกทั้งยังมีปัญหาเรื่องการจ้างคนด้วย..
หวังว่า Solid จะไปได้สวยนะ..... ไม่รู้เหมือนกันว่าจะโค่นการผูกขาดของ React ได้ยังไง
ตลอดเกือบ 10 ปีที่ผ่านมา ในระบบนิเวศ FE มีเครื่องมือมากมายนับไม่ถ้วนหลั่งไหลออกมา ผ่านวงจรเกิดขึ้น ตั้งอยู่ ดับไป จนตอนนี้เพิ่งจะเริ่มมีเสถียรภาพขึ้นมาบ้าง แต่กลับจะให้ลองก่อความโกลาหลครั้งใหญ่อีกครั้งงั้นหรือ..
เป็นบทความที่มีอคติมากเกินไปไม่ใช่หรือ?
"เฟรมเวิร์กที่ล้ำสมัยอย่าง Svelte, Solid, Qwik มอบโมเดลประสิทธิภาพที่ดีกว่า แต่กำลังถูกเบียดออกจากการแข่งขันกระแสหลักเพราะขาดการยอมรับ"
หากไม่มีเกณฑ์ที่สอดคล้องกันในการทำความเข้าใจความหมายของคำว่า "นวัตกรรม"
ก็ดูเหมือนว่าสมมติฐานตั้งต้นจะผิดตั้งแต่แรก
พอเห็นบทความแบบนี้แล้วก็รู้สึกว่าเหมือนจะไม่ได้โฟกัสกับการสร้างผลิตภัณฑ์ แต่หมกมุ่นอยู่กับวิศวกรรมซอฟต์แวร์มากเกินไป สุดท้ายแล้วอะไร ๆ ก็พอ ๆ กัน สิ่งสำคัญคือต้องทำผลิตภัณฑ์ให้ดี แต่กลับเอาแต่ตามหาฟ্রेमเวิร์กใหม่ ๆ สถาปัตยกรรมใหม่ ๆ แล้วก็ทำโอเวอร์เอนจิเนียริง พอบอกว่าอันนี้ดีกว่าก็จะเปลี่ยนกันอีก ผมคิดว่าสิ่งสำคัญไม่ใช่ว่าของใหม่ดีกว่า แต่คือไม่ว่าจะใช้อะไรก็ควรใช้มันให้ดีแล้วส่งผลิตภัณฑ์ออกมาให้ได้
ก็ช่วยไม่ได้ เพราะบิ๊กเทคในประเทศรับคนโดยอิงจาก React (next.js) เป็นหลักอยู่แล้ว
ขนาด vue.js ที่ถือว่าเป็นตัวหลักเอง ตำแหน่งที่บิ๊กเทคเปิดรับก็ยังมีไม่มากนัก
เพิกเฉยต่อระบบนิเวศไม่ได้จริง ๆ... ตอนนี้ไลบรารี third-party หรือโอเพนซอร์สที่ออกมาใหม่ส่วนใหญ่รองรับ React อย่างเป็นทางการ แต่เฟรมเวิร์กอื่นมีแค่การรองรับจากคอมมูนิตี้เท่านั้น สุดท้ายถ้าจะเอาหลายอย่างมาประกอบกันใช้งาน React ก็เลยหลีกเลี่ยงไม่ได้ที่จะกลายเป็นตัวเลือกที่ปลอดภัยที่สุด...
มีสาขาไหนที่ทดลองได้หลากหลายเท่าฟรอนต์เอนด์อีกล่ะ...
ด้วยความทุ่มเทของทีมพัฒนา React ที่ Facebook ทำให้การพัฒนาเว็บแอปมีความท้าทายมากขึ้น ไม่ได้เป็นตัวร้ายอะไรนัก.. เพราะช่วยปิดฉากยุค
php jqueryลงได้ความเห็นจาก Hacker News
ผมคิดว่าไม่ใช่แค่ React กลายเป็นค่าเริ่มต้น แต่เพราะมันมีประสิทธิภาพมากและออกแบบมาดีจนกลายเป็นมาตรฐานโดยพฤตินัย และตอนนี้ก็เลยกลายเป็นตัวร้ายไปด้วย
ผมรู้สึกว่าคำกล่าวที่ว่า React ทำให้นวัตกรรมช้าลงนั้นฟังดูเหลือเชื่อมาก
React แทบเป็นตัวเลือกเดียวที่มั่นคงและสมเหตุสมผล ท่ามกลางเฟรมเวิร์กแนว "ขอร่วมวงด้วย" จำนวนมากและงานออกแบบที่ชวนสับสน
ขอโต้แย้งแบบถ่อมตัว
ผมไม่เคยสร้างแอปอินเทอร์แอกทีฟที่ซับซ้อนด้วย React เลย เคยทำแค่เว็บง่าย ๆ ไม่กี่ครั้งที่ทีมเลือก React ไว้ก่อนแล้ว
ผลคือ React กลับย่อขนาดลงมาใช้กับเว็บง่าย ๆ ได้ไม่ค่อยดีนัก
ถ้าเป็นหน้าเข้าสู่ระบบธรรมดา ก็เก็บสถานะไว้ใน DOM ตรง ๆ แล้วส่งค่าด้วย
<form>ก็พอ ส่วนการแสดง/ซ่อนรหัสผ่านก็ใช้ JS นิดหน่อยได้แต่ถ้าจะทำด้วย React ต้องเรียนรู้ทั้ง JSX, hooks, วงจรชีวิตของคอมโพเนนต์, dev build, production packaging และอีกหลายอย่าง
เฟรมเวิร์กอื่นอย่าง Vue หรือ Alpine ใช้แบบ "ค่อยเป็นค่อยไป" ได้ และเริ่มต้นได้ทันทีผ่าน CDN
React ก็อ้างว่าใช้แบบค่อยเป็นค่อยไปได้ แต่ด้วยธรรมชาติของ JSX มันต้องมีขั้นตอน build/compile จึงไม่มีวิธีเริ่มผ่าน CDN แบบตรงไปตรงมาในเอกสารทางการ
จะฝืนทำก็ไม่ถึงกับเป็นไปไม่ได้ แต่สุดท้ายต้องส่งคอมไพเลอร์ไปที่ฝั่งไคลเอนต์ด้วย ซึ่งในทางปฏิบัติแย่มาก
เว็บส่วนใหญ่ไม่ได้อยู่ในระดับ Facebook, Spotify หรือ Netflix ด้วยซ้ำ (แถม Netflix ก็เคยประกาศว่ากำลังถอยห่างจาก React) ดังนั้นจึงยากจะเห็นด้วยกับคำกล่าวที่ว่า React มีประสิทธิภาพมากและออกแบบมาดีขนาดนั้น
ตอน React ออกมาเมื่อ 12 ปีก่อน มันปฏิวัติวงการจริง ๆ
แต่ไม่นานก็มีเฟรมเวิร์กคล้าย ๆ กันออกมาหลายตัว และหลังจากนั้นมันก็อยู่ในระดับ "ใช้ได้โอเค" มากกว่าจะเป็นศูนย์กลางของนวัตกรรม
ตอนนี้มันกำลังพยายามแก้ปัญหาจากการออกแบบ Virtual DOM ที่เริ่มล้าสมัย ขณะเดียวกันก็มี boilerplate เพิ่มขึ้นเรื่อย ๆ และเสน่ห์ก็น้อยลงเมื่อเทียบกับทางเลือกสมัยใหม่
ความหมายของชื่อบทความมันกลับด้านอยู่
ความจริงคือรู้สึกว่า "นวัตกรรม" ต่างหากที่ยังตามสูตรสำเร็จของ React ไม่ทัน
ผมก็อยากตั้งคำถามเหมือนกันว่าต้องการนวัตกรรมมากแค่ไหน
จริง ๆ แล้วการทำซ้ำและปรับปรุงทีละนิดมักดีกว่าและถูกกว่าด้วยซ้ำ
ผมชอบทั้งบทความนี้และมุมมองแบบพหุนิยมในช่วงปี 2015~16
ผมอยากบอกทีมว่า "ลองทำ use case ย่อยแยกต่างหากด้วย Svelte กันเถอะ" แต่เช็กลิสต์สำหรับประเมินกลับทำงานตรงข้ามกับสิ่งที่บทความนี้เสนอ
ประสิทธิภาพ: ใน 99% ของแอปแทบไม่รู้สึกถึงความต่าง สุดท้ายก็เลือก React
ความชำนาญของทีมและเส้นโค้งการเรียนรู้: ทุกคนรู้แค่ React และไม่รู้จัก Qwik อะไรแบบนั้น ก็เลยเลือก React ตามธรรมชาติ
การขยายระบบ, ต้นทุนการปฏิบัติการ: แทบไม่ต่างกัน
อีโคซิสเต็ม: React ใหญ่กว่าและเสถียรกว่ามาก เลือก React
ยิ่งไปกว่านั้น ตอนนี้เครื่องมือ AI ก็รองรับ React ได้ดีมาก และนักพัฒนาก็แทบจะเรียนรู้โดยมี React เป็นศูนย์กลางอยู่แล้ว
สุดท้าย React จึงเลี่ยงไม่ได้ที่จะเป็นตัวเลือกที่สมเหตุสมผล
ผมคิดว่า Web components คือทางออกจากภาวะผูกขาดของเฟรมเวิร์กนี้
ทุกเฟรมเวิร์กยกเว้น React สนับสนุน web components อย่างจริงจัง คำตอบคือใช้ระบบนิเวศของคอมโพเนนต์และยูทิลิตีที่เข้ากันได้ แทนที่จะให้แต่ละฝั่งต้องสร้าง React ecosystem ของตัวเองขึ้นมาใหม่
หลายคนมองว่า web components เป็นคู่แข่งของเฟรมเวิร์ก แต่จริง ๆ แล้วมันคือการกำหนดอินเทอร์เฟซระหว่าง implementation ของคอมโพเนนต์กับเบราว์เซอร์ เพื่อให้ประกอบใช้งานร่วมกันได้และเชื่อถือได้
บน API ระดับล่างแบบนี้ก็ยังสามารถมีนวัตกรรมด้านการสร้างคอมโพเนนต์ได้หลายแบบอยู่ดี ไม่ว่าจะเป็นแบบไม่ต้อง build, JSX, template, ไวยากรณ์เฉพาะทาง, คอมไพเลอร์ ฯลฯ รวมถึงนวัตกรรมด้านการประกอบคอมโพเนนต์และการจัดการสถานะด้วย
เราจะเอาชนะการผูกขาดของ React ได้ก็ต่อเมื่อสามารถพูดได้ว่า "เฟรมเวิร์ก Flugle ตัวใหม่ของเราใช้งานร่วมกับเฟรมเวิร์กไหนก็ได้ และมีเครื่องมืออัตโนมัติเพียบ!"
ผมเองก็ใช้ web components ผ่าน wrapper เพื่อหลีกเลี่ยง boilerplate
ด้วยวิธีนี้ผมได้ประโยชน์จาก web components ราว 80% โดยใช้แรงน้อยมาก
GitHub ที่เกี่ยวข้อง: ZjsComponent และดูลิงก์ไปยังกระทู้ HN เก่าด้วย (HN discussion)
มันไม่สมบูรณ์แบบ แต่สำหรับผมไม่มีวิธีไหนที่ง่ายและเร็วไปกว่านี้ในการสร้างคอมโพเนนต์ HTML ใหม่
ถ้าไม่มีทางเลือกที่เทียบได้กับ React Native แค่ web components อย่างเดียวก็ยังไม่พอ
เทคโนโลยีเบราว์เซอร์ยังไม่เร็วพอจะไปถึงระดับแอปเนทีฟ
คุณค่าที่ใหญ่ที่สุดของ React คือมันช่วยรวมการพัฒนา GUI ข้ามแพลตฟอร์มไว้ด้วยกันได้
ผมเคยสร้างแอปธุรกิจด้วย lit web components
การที่ทุกพร็อพเพอร์ตีต้องเป็นชนิด string ทำให้ไม่สะดวกมาก และเทียบกับไลบรารีคอมโพเนนต์ที่เน้น real-time ไม่ได้เลย
ที่บริษัทใหญ่ของเรา แอปภายในต้องใช้ไลบรารี React กลางของบริษัทเท่านั้น
ไม่ใช่แค่ "ค่าเริ่มต้นเลยเป็น React" แต่เป็นสถานะที่ "ใช้ได้แค่ React"
ผมคิดว่าทางออกคือเขียนไลบรารีกลางนั้นใหม่เป็น web components เพื่อให้ใช้เฟรมเวิร์กที่ต้องการได้
สงสัยว่ามีใครใช้ web components กับ React UI library ได้ดีจริงไหม
เวลาสร้างไลบรารีคอมโพเนนต์ให้เข้ากับ design system บางตัว การพึ่งไลบรารีแบบ headless อย่าง RAC ก็ค่อนข้างน่าพอใจ
ผมเข้าใจว่า web components อาจเป็นตัวเสริมได้ แต่ยังไม่ค่อยแน่ใจว่าในทางปฏิบัติแล้วมันเหมาะจะใช้ตรงไหนที่สุด
จริง ๆ แล้วบทความนี้ไม่ได้พูดเรื่องประสิทธิภาพของ React แต่พูดว่า "ผลประโยชน์ทางสังคม" ของมันมีมากกว่าทางเลือกอื่นมาก จนตัวเลือกอื่นเกิดได้ยาก
พูดอีกแบบคือ ถึง React จะไม่ได้โดดเด่นด้านเทคนิค มันก็กลายเป็นตัวเลือกเริ่มต้น และผมก็เห็นด้วยว่า network effect มีอิทธิพลต่อการตัดสินใจมากกว่าความเหมาะสมทางเทคนิค
ถึงอย่างนั้น สำหรับทีมต่าง ๆ React ก็ยังมีข้อได้เปรียบที่ชัดเจนเมื่อเทียบกับทางเลือกอื่นอยู่เรื่อย ๆ
ในความเป็นจริง ทีมที่เก่งส่วนใหญ่รู้ดีว่าจะเลือกทางเลือกอื่นเฉพาะในกรณีที่ตัวเองเป็นข้อยกเว้นจริง ๆ เท่านั้น
ผมเคยมีส่วนร่วมในการตัดสินใจ tech stack ทั้งในหลายบริษัทและสตาร์ตอัป แต่ไม่เคยได้ยินใครยก "ข้อดีของตัวเฟรมเวิร์กเอง" มาเป็นเหตุผลในการเลือก React
เหตุผลมีแต่ความคุ้นเคย ความง่ายในการจ้างคน และอีโคซิสเต็มเท่านั้น
ผู้คนมักสมมติว่านักพัฒนาเว็บตัดสินใจอย่างมีเหตุผล แต่จากประสบการณ์ของผมมันไม่เป็นแบบนั้น
คนเราถูกอคติแบบมนุษย์ เช่น “social proof” หรือ “authority” ชักจูงได้ง่าย
ผมไม่เคยได้ยินใครบอกว่า "ใช้ React เพราะมันดี"
มีแต่บอกว่า "เพราะจ้างคนง่าย"
React มีจุดแข็งในการแก้ปัญหาที่ซับซ้อน
แต่ไม่ใช่ทุกปัญหาจะซับซ้อน และถ้าใช้เครื่องมือที่ซับซ้อนเป็นค่าเริ่มต้น ก็จะนำความซับซ้อนที่ไม่จำเป็นและความยืดหยุ่นที่ลดลงเข้ามาในโปรเจกต์
ความไม่เสถียรของอีโคซิสเต็มที่ต้องคอยดูแลเพราะฟีเจอร์เก่าหรือฟีเจอร์ในอนาคตก็ไม่ใช่ปัญหาที่จำกัดอยู่แค่ React เช่นกัน
ต่อจากนี้ผมหวังว่าจะได้เห็นกระแสใหม่ที่ก้าวข้ามพาราไดม์ web app ของคนรุ่นปัจจุบัน
มีเหตุผลพอจะกังวลกับวัฒนธรรมเดี่ยวในฝั่งฟรอนต์เอนด์ (React ครองตลาด) แต่สิ่งที่ผมสงสัยคือเมื่อ 10 ปีก่อน สถานการณ์จริง ๆ กลับตรงข้ามกันโดยสิ้นเชิง
มีเฟรมเวิร์กใหม่ ๆ โผล่ใน HN ทุกสัปดาห์ ความวุ่นวายจาก Angular 1.x ไป 2.0 และถึงขั้นมีคำว่า "JavaScript fatigue" ออกมา เพราะการพัฒนาฟรอนต์เอนด์มันเหนื่อยมาก
ตอนนี้ React ได้กลายเป็นมาตรฐานที่ชัดเจนไปแล้ว และนั่นทำให้เราสบายใจที่จะโฟกัสกับการพัฒนาบริการได้
ไม่ใช่ว่าผมจะยกย่อง React หรอกนะ (ผมเองก็ไม่ชอบ hooks) แต่ก็รู้สึกขอบคุณที่ตอนนี้ไม่ใช่ยุคแบบปี 2015 แล้ว
และก็น่าสนใจที่เมื่อเวลาผ่านไป บรรยากาศก็ค่อย ๆ เปลี่ยนอีกครั้ง
ผมจำยุคที่มีไลบรารี JavaScript แนว boutique โผล่มาแบบบ้าคลั่งได้
การที่ React กลายเป็นกระแสหลัก ผมถือว่าเป็นชัยชนะอย่างหนึ่ง
ผมคิดว่าเราควรระวังการทิ้งสิ่งที่คุ้นเคยและมั่นคงไปแบบฝืน ๆ เพื่อสิ่งที่คลุมเครืออย่าง "นวัตกรรม"
เห็นด้วยสุด ๆ
ช่วงปี 2009~2015 ผมทำงานค่อนข้างล้ำหน้าอยู่มาก สร้าง UX ในเบราว์เซอร์ที่ใกล้ระดับแอปเนทีฟไว้เยอะ
จุดแข็งคือมาตรฐานเว็บและการใช้มันโดยตรงให้มากที่สุด จากนั้นผมก็ย้ายไปทางแบ็กเอนด์และมองการผงาดขึ้นมาของ React จากระยะไกล
React ดูไม่มีประสิทธิภาพสำหรับผม และข้อจำกัดของ JSX ที่บังคับให้ "ทุกอย่างต้องเป็น expression" ก็ชวนอึดอัด
ถึงอย่างนั้น ผมก็ให้เครดิต React มากที่นำการเปลี่ยนพาราไดม์สำคัญด้าน state management เข้ามา
การเปลี่ยนจากโมเดลสถานะแบบเก่าไปเป็นการไหลของข้อมูลแบบทางเดียวและ immutable เป็นกระบวนการที่หนัก แต่สุดท้ายก็มีความหมาย
แม้จะเป็นยุคที่สับสน แต่ก็เป็นความจริงว่า React สร้างนวัตกรรมและเปลี่ยนวิธีคิดเรื่องการออกแบบเว็บแอปไปมาก
แต่ถ้าเทียบกับ SolidJS ตอนนี้ Solid ให้ข้อดีแบบเดียวกันได้กระชับกว่า ประสิทธิภาพดีกว่า และดูแลง่ายกว่ามาก
มันให้ทั้ง JSX, server components และ reactive state management ได้ดีกว่า และนักพัฒนา React ก็ย้ายไปใช้ได้ง่าย
แนวคิดเรื่องโครงสร้างแอปก็แทบเหมือนเดิม จึงได้ประโยชน์เกือบทั้งหมดที่ React ให้ แต่ในรูปแบบที่ดีกว่า เร็วกว่า และขนาด bundle เล็กลงอย่างมาก
ถึงอย่างนั้น ทั้งตลาดก็ยังเทไปทาง React จนสุดท้ายก็ต้องฝืนใช้มันต่อไป
SolidJS เองก็ยังมีจุดเจ็บปวดอยู่
ปัญหาใหญ่ที่สุดคือดูได้ยากว่า prop ตัวไหนเป็น signal หรือไม่เป็น
ระบบ type ก็ช่วยได้ไม่มาก
ใน React ถ้ามีการเปลี่ยน reference ก็ชัดเจนเลยว่าฝั่งรับ prop จะ re-render แต่ใน Solid มันไม่ค่อยแน่ว่าการเปลี่ยนแปลงนั้นจะถูกสังเกตหรือไม่
ผมคิดว่าคนส่วนใหญ่ก็พอใจกับการใช้สิ่งที่ตัวเองคุ้นเคย
มีนักพัฒนาจำนวนมากที่ไม่อยากถูกบังคับให้ใช้ React แต่สุดท้ายก็ต้องใช้สิ่งที่ตัวเองถนัดที่สุดอยู่ดี
เวลาเรามีจำกัด และก็ต้องเลือกสิ่งที่คุ้มค่าเพื่อเหลือเวลาให้ครอบครัว งานอดิเรก และชีวิตด้านอื่นด้วย
ไม่จำเป็นต้องยึดติดกับ React เสมอไป
บริษัทของผม (ซึ่งแทบมีแค่ผมคนเดียว) ก็มีเฟรมเวิร์กที่พัฒนามาในช่วง 10 ปีที่ผ่านมา และผมก็เปิดซอร์สภายใต้ MIT license แล้ว
ลิงก์ Q.js
อยากฟังความเห็นครับ
Hooks แก้ข้อเสียของ class component ได้ แต่ก็นำความซับซ้อนชุดใหม่เข้ามาด้วยเช่นกัน เช่น dependency array, stale closure และการใช้งานผิด ๆ
แต่ปัญหาเหล่านี้ก็ไม่ได้เกิดเพราะ hooks อย่างเดียว เพราะสมัยคอมโพเนนต์แบบ class ก็มีเหมือนกัน
dependency array ก็คล้ายกับบั๊กสมัยก่อนที่พลาดการเปลี่ยนแปลงของ props หรือ state
stale closure ก็เกิดแบบเดียวกันได้ในอาร์กิวเมนต์ตัวที่สองของ setState
การใช้ lifecycle methods อย่าง
componentDidMount,componentWillMountฯลฯ อย่างผิดวิธีก็เกิดบ่อยเช่นกันผมคิดว่าเอกสารประเภท "ใช้ Effect เฉพาะเมื่อจำเป็นจริง ๆ" ก็คงจำเป็นมาตั้งแต่ยุคนั้นแล้ว
hooks ช่วยลดโอกาสผิดพลาด ทำให้มองเห็นโอกาสเหล่านั้นได้ง่ายขึ้น และยังเตือนให้ด้วย จึงถือว่าช่วยให้ดีขึ้นอย่างชัดเจน
ปัญหา dependency array แก้ได้ง่ายมากด้วยการใช้กฎ react-hook ใน eslint
การใช้ fast-check กับการทดสอบ prop ช่วยป้องกันบั๊กจากการเปลี่ยนแปลงเล็กน้อยได้มากจริง ๆ
ชุมชน JavaScript น่าจะหยุดนวัตกรรมไปสักสองสามปีก็ได้
มีนวัตกรรมมากเกินไป แต่เนื้อหาสาระกลับไม่ค่อยมี
ตอนนี้ฝั่งเบราว์เซอร์ควรเข้ามารับหน้าที่เรื่องการพัฒนาคอมโพเนนต์สำหรับเว็บอย่างสมเหตุสมผล
ถ้ามีสิ่งอย่าง combobox ที่มี backend รองรับหรือ date picker มาตรฐานในระดับเบราว์เซอร์ ก็ไม่ต้องคอยหมกมุ่นกับนวัตกรรมเรื่องการจัดการสถานะของคอนโทรล UI พื้นฐานพวกนี้ซ้ำ ๆ
ผมคิดว่าปัญหาคือเบราว์เซอร์ไม่ได้ทำหน้าที่ดั้งเดิมของมันได้ดีพออีกต่อไป
Google มีอิทธิพลผ่าน Chrome มากจนเกือบผูกขาด ทำให้มาตรฐานเว็บแทบไม่คืบหน้านอกจากเรื่องที่ Google สนใจและยอมลงทรัพยากรพัฒนา
Safari กับ Firefox ช่วยถ่วงดุลได้ระดับหนึ่ง แต่ถ้าจะพัฒนาให้กลายเป็นแพลตฟอร์มที่แตกต่างอย่างแท้จริง ก็ต้องมีใครสักคนถือบทบาทผู้นำแล้วผลักดันไป
สุดท้ายฝั่ง JS ก็เลยอยู่ในสถานการณ์น่าเสียดายที่ต้องคอยแฮ็กแก้ปัญหาเหมือนบัดกรีชิป NAND เพราะไม่มีการรองรับในระดับแพลตฟอร์ม
ผมรู้สึกว่าช่วงหลังเบราว์เซอร์กับ CSS ช่วยปรับปรุง/แก้ use case ที่เดิมทีต้องพึ่ง JS มาอย่างต่อเนื่อง
อยากให้แนวโน้มแบบนี้ขยายต่อไป
อาจถึงขั้นลองคิดเรื่องแยกเบราว์เซอร์ออกเป็น 5~6 ประเภท เช่น ชอปปิง, ธนาคาร, โซเชียล ฯลฯ
เพื่อให้แต่ละบริการแข่งขันกันเรื่องนวัตกรรมที่ฝั่งแบ็กเอนด์เท่านั้น และให้ฟรอนต์เอนด์มอบประสบการณ์ที่เป็นมาตรฐานเดียวกัน ซึ่งน่าจะเป็นประโยชน์ต่อผู้ใช้มากกว่า
การที่แต่ละบริษัทพัฒนาฟรอนต์เอนด์คล้าย ๆ กันแยกกันเองซ้ำไปซ้ำมานั้นสิ้นเปลืองมาก
ร้านแซนด์วิชควรแข่งกันทำแซนด์วิชให้ดีกว่า ไม่ใช่มาสร้างฟรอนต์เอนด์คล้าย ๆ กันเพื่อแย่งผู้ใช้แอปเพิ่มอีก 8%
ที่จริงแล้วพอมองว่าเฟรมเวิร์กต่าง ๆ ทำอะไรได้บ้างบนแพลตฟอร์มที่ซับซ้อนแบบนี้ (HTML/CSS/JS) ก็มีแต่ความน่าทึ่ง
'เว็บ' เหมาะกับยุคที่เน้นเอกสาร/ข้อความและฟอร์มง่าย ๆ มากกว่า แต่ตอนนี้มันเป็นรากฐานที่ไม่ค่อยเหมาะกับแอปอินเทอร์แอกทีฟซับซ้อนแล้ว
สักวันหนึ่งมันคงต้องถูกยกเครื่องใหม่ทั้งหมด
React ไม่ได้ชนะเพราะ "ดีที่สุด" แต่ชนะเพราะมันกลายเป็น "ค่าเริ่มต้นที่ปลอดภัย"
ทุกคนรู้จัก React จ้างคนก็ง่าย และอีโคซิสเต็มก็ใหญ่ เลยทำให้มันเป็นตัวเลือกที่มั่นคง
ผลคือมีนวัตกรรมน้อยลง และทางเลือกที่เบากว่าอย่าง Svelte หรือ Solid ก็แทบไม่ได้ถูกลองด้วยซ้ำ
React ยังทำงานได้ดีอยู่ แต่ผมคิดว่าในความเป็นจริงมันถูกใช้เพราะแรงเฉื่อยมากกว่าความเหมาะสม
เห็นด้วยกับความเห็นของผู้เขียน อย่างไรก็ตาม แรงเฉื่อยในการใช้ React ก็ไม่ได้ผิดอย่างที่พูดกันนัก ถ้าทางเลือกอย่าง Svelte ที่กล่าวถึงเปรียบได้กับ iPhone 17 ผมมองว่า React ก็คงประมาณ iPhone 15 หรือ 16 ยังใช้งานได้คุ้มกับต้นทุน และยังไม่รู้สึกว่าจำเป็นต้องเปลี่ยน ในช่วงที่ฝั่งฟรอนต์เอนด์สับสนวุ่นวาย การที่เราเลือก React มาตลอดก็ไม่ได้เป็นการตัดสินใจอย่างมีสติตามความเห็นของผู้เขียน แต่เป็นเพราะพอลองใช้หลายอย่างแล้วรู้สึกว่า React ใช้งานได้ดีที่สุดเลยถูกเลือกมาเอง ถ้าวันหนึ่ง React เริ่มไม่สะดวกและมีอย่างอื่นที่ดูใช้งานได้ดีกว่า ผมคิดว่าต่อให้ไม่ตั้งใจท้าทายหรือทดลองเป็นพิเศษ การย้ายไปใช้อย่างอื่นก็จะเกิดขึ้นอย่างเป็นธรรมชาติ
เมื่อดูกรณีสงครามมาตรฐานเทปวิดีโอระหว่าง VHS กับ Betamax ก็เหมือนว่าของที่เหนือกว่าทางเทคนิคไม่ได้ถูกเลือกในตลาดเสมอไป
ปัญหาไม่ได้อยู่ที่ฟรอนต์เอนด์สร้างนวัตกรรมมากเกินความจำเป็นจนเกินไปหรอกหรือ
ค่อนข้างเห็นด้วยครับ
เพราะเมื่อฝั่งแบ็กเอนด์มีรูปแบบที่เป็นมาตรฐานอย่างชัดเจน จนถึงขั้นมี Electronic Government Framework ขึ้นมา ก็มีส่วนที่ช่วยเพิ่มประสิทธิภาพการทำงานได้อย่างแน่นอน เลยคิดว่า React เองก็คงกำลังค่อย ๆ เปลี่ยนไปในทิศทางแบบนั้นเหมือนกัน
ใช่ครับ ผมคิดว่าความสำคัญของ React คือการวางรากฐานทั้งด้านการออกแบบแบบคอมโพเนนต์และพฤติกรรมการเรนเดอร์ที่คนส่วนใหญ่พอจะเข้าใจร่วมกันได้ค่อนข้างมาก แต่ React เองก็เป็นเฟรมเวิร์กระดับล่างเกินไปสำหรับการสร้างเว็บแอปด้วยตัวมันเอง เลยคิดว่าอย่างน้อยถ้ามี router กับ form ให้มาเป็นค่าเริ่มต้นก็คงดี และในกรณีของ state กับ effect ก็อดคิดไม่ได้ว่าถ้ารองรับการเปรียบเทียบแบบลึกเป็นค่าเริ่มต้น และสามารถเขียน logic ได้ด้วยแค่โครงสร้างข้อมูลกับฟังก์ชันเท่านั้น มันจะออกมาเป็นอย่างไร เพราะข้อจำกัดของการเปรียบเทียบแบบตื้นของ JavaScript ทำให้สุดท้ายต้องเขียนคลาสผ่านไวยากรณ์ custom hook อยู่ดี
จะเรียกว่าระดับล่างก็ไม่เชิง... ถ้าจะทำฟอร์ม แค่ใช้แท็ก
inputของ HTML ก็น่าจะพอแล้ว แต่กลับต้องไปรู้เรื่อง state, JSX, คอมโพเนนต์แบบ uncontrolled/controlled โดยไม่จำเป็น แถมยังต้องเขียนโค้ดเพิ่มอีกมาก ผมเลยคิดว่าสิ่งเหล่านั้นน่าจะเป็นแรงจูงใจของบทความต้นฉบับเห็นด้วยครับ