สิ่งที่ React ทำให้เราลืมไปแล้ว (หรืออาจไม่เคยรู้มาก่อน)
(joshcollinsworth.com)- การทบทวนเชิงวิพากษ์ต่อ React ซึ่งเป็นไลบรารี JavaScript ยอดนิยมสำหรับสร้างส่วนติดต่อผู้ใช้ พร้อมข้อเสนอทางเลือก
- React ถูกวิจารณ์ว่าล้าสมัย และมีข้อจำกัดด้านประสิทธิภาพกับความยืดหยุ่น
- ผู้เขียนมองว่า ecosystem ของ React มีขนาดใหญ่เกินความจำเป็น และ React hooks ก็ล้าสมัยไปแล้ว
- มีข้อโต้แย้งว่าในฝั่งฟรอนต์เอนด์ ไม่จำเป็นต้องมุ่งเน้นเรื่องการเรนเดอร์และการสเกลมากขนาดนั้น
- มีข้อโต้แย้งว่า server-side rendering ไม่ได้เป็นเรื่องพิเศษอีกต่อไป และการทำ data binding แบบสองทางก็ไม่ใช่ความคิดที่แย่
- การจัดสไตล์ นั้นง่ายกว่าใน React และเฟรมเวิร์กอื่น ๆ ก็ไม่ได้เรียนรู้ยาก
- มีข้อโต้แย้งว่าทางเลือกแทน React ไม่ได้เป็นแค่ของ "ใหม่และแวววาว" แต่มีความสุกงอมและให้ประสิทธิภาพที่ดีกว่า
- แนะนำให้ลองเฟรมเวิร์กอื่น ๆ เช่น Svelte, Vue, Solid, Fresh, Astro, Preact, Qwik
- ตัวเลือกโปรดส่วนตัวของผู้เขียนคือ Svelte โดยมองว่าเรียนรู้ง่ายกว่า React และให้ประสิทธิภาพดีกว่า
- Svelte เป็นคอมไพเลอร์ ทำให้โค้ดที่ไม่ได้ใช้งานถูกตัดออกตั้งแต่ขั้นตอน build จึงได้ bundle ที่เล็กกว่า
- SvelteKit ซึ่งเป็น meta-framework ของ Svelte มีความหลากหลายและทรงพลัง รองรับการทำ static, server rendering และ edge deployment
- Vue ให้ประสิทธิภาพดีกว่า React และมีแนวทางที่เน้น UI มากกว่า โดยใช้ภาษาเทมเพลตที่ใกล้เคียง HTML ปกติมากกว่า JSX
- Solid เปรียบได้กับ React เวอร์ชันที่แรงกว่า ตัดความซับซ้อน ปัญหาด้านประสิทธิภาพ และ boilerplate ออกไป พร้อมมี meta-framework ของตัวเองคือ SolidStart
- Fresh เป็นเฟรมเวิร์กฟรอนต์เอนด์สำหรับ server rendering ที่สร้างบน Deno และใช้สถาปัตยกรรมแบบ islands ให้ JavaScript เท่าที่จำเป็นและโหลดคอนเทนต์แบบไดนามิกได้รวดเร็ว
- Astro เป็นตัวสร้างเว็บไซต์แบบ static ประสิทธิภาพสูง และมีความสามารถฝั่ง server แบบไดนามิก โดยค่าเริ่มต้นไม่ใช้ JavaScript เลย และเข้ากันได้กับเฟรมเวิร์กฟรอนต์เอนด์หลากหลาย
- Preact เป็น React เวอร์ชันที่เพรียวบางและเร็วกว่า พร้อมมีฟีเจอร์เด่นบางอย่างที่ React ไม่มี
- Qwik นำเสนอแนวทางใหม่ โดยให้โค้ดที่คล้ายกับ server-rendered React และเหมาะกับโปรเจกต์ที่มีปฏิสัมพันธ์จำนวนมาก
- ไลบรารี web components เช่น Lit, Stencil, Polymer เหมาะกับโปรเจกต์ที่ต้องการนำคอมโพเนนต์เดียวกันไปใช้ซ้ำในหลายสภาพแวดล้อม หรือเตรียมพร้อมสำหรับการเปลี่ยนเฟรมเวิร์ก
- ผู้เขียนเสนอว่าอุตสาหกรรมเทคโนโลยีอาจก้าวกระโดดอีกครั้งในการเลือกใช้เทคโนโลยีใหม่ แทนการยึดติดกับ React
21 ความคิดเห็น
บทความนี้ชวนให้รู้สึกเหมือนเป็นข้อความที่รุ่นน้องเสียมารยาทพูดว่า “รุ่นพี่ครับ~ ตอนนี้ก็ไม่ได้มีอะไรน่าสนใจแล้ว งั้นเกษียณเถอะครับ?” เลยดูน่าขันนิด ๆ
ดูเหมือนว่าการถกเถียงเกี่ยวกับบทความนี้จะเริ่มร้อนแรงเกินไปแล้ว
โปรดตรวจสอบหัวข้อการแสดงความคิดเห็นในวิธีใช้งานเว็บไซต์
กรุณาพูดคุยกันด้วยความสุภาพและใจเย็น
โปรดอย่าโจมตีผู้เขียนโดยตรง
หากมีข้อโต้แย้ง โปรดเขียนเฉพาะเนื้อหาของข้อโต้แย้งนั้น
ส่วนตัวผมคิดว่าแค่การเอาภาษาอย่าง JS มาใช้เป็นภาษาในการพัฒนาเซิร์ฟเวอร์ก็ดูไม่ค่อยเวิร์กเท่าไร
ช่วงนี้แม้จะมีตัวที่อิง TS เยอะขึ้นก็จริง แต่สุดท้ายผลลัพธ์ที่ได้ก็ออกมาเป็น JS อยู่ดี... ทั้ง Python เองก็ด้วย ทั้ง JavaScript เองก็ด้วย ในแง่มุมของภาษานี่ไม่ค่อยถูกใจเอาเสียเลย แต่คงเพราะความสะดวกเลยยังถูกใช้งานกันเยอะนะ
ให้ความรู้สึกเหมือนการทำให้ภาษากลายเป็นประชาธิปไตยเลย
รู้สึกไม่ค่อยดีที่พอ Vercel ทุ่มเทแรงกายแรงใจสร้างมันขึ้นมาแล้ว กลับถูกมองว่าเป็นเรื่องธรรมดาและไม่ใช่อะไรสำคัญนัก
พอแค่นึกถึงตอนเรียนที่ต้องเขียนเซิร์ฟเล็ตสุดนรกด้วยเอดิเตอร์ที่ไม่ช่วยจับแม้แต่ไวยากรณ์ผิด ก็รู้สึกขอบคุณทุกอย่างเลย ไม่ว่าจะเป็น React หรือ Svelte.....
พอได้ลองใช้นั่นนี่ก็จะเห็นทั้งข้อดีและข้อเสียของ React แต่การบอกว่า React ดี JSX คือจุดแข็ง และการปฏิเสธความเห็นเชิงลบเกี่ยวกับ hooks แบบปัดตกไปเลยนั้น ให้ความรู้สึกเหมือนศาสนาแบบงมงาย
ผมเขียนไว้ว่า จุดแข็งไม่ได้อยู่ที่ JSX แต่อยู่ที่ "ความสามารถในการแสดงออก" ครับ.. และพอลองไปอ่านต้นฉบับจริง ๆ ก็พบว่า ในกรณีของ hooks นั้น เขาไม่ได้วิจารณ์ตัวแพตเทิร์น hooks เอง แต่เพียงเขียนว่า มันไม่ได้เป็นจุดแข็งเฉพาะของ React อีกต่อไปแล้วประมาณนั้น ซึ่งในระดับนี้ก็พอเห็นด้วยได้ครับ เพราะคำแปลออกมาเป็นแบบนั้น ผมเลยเข้าใจผิดไปเอง
ดังนั้น ช่วยเขียนให้ชัดเจนหน่อยได้ไหมครับว่า "จุดที่กล้าฟันธง" ที่คุณเข้าใจคืออะไร?
คงไม่ได้คิดหรอกนะว่าไลบรารีหรือเฟรมเวิร์กจะมีแต่ข้อดีไม่มีข้อเสีย? ตอนใช้ React ไม่เคยรู้สึกถึงข้อเสียของมันเลยหรือไง? เห็นถามให้เขียนข้อเสียกันนัก ดูเหมือนจะไม่เคยรู้สึกเลยสินะ? ก็รู้ใช่ไหมว่าคำว่าข้อดีข้อเสียมันหมายความว่ามีทั้งข้อดีและข้อเสีย? มันมีข้อดีเยอะ แต่ข้อเสียก็เยอะเหมือนกัน ในบรรดานั้นมีเรื่องหนึ่งที่ผมเพิ่งอ่านเมื่อวาน แต่จำลิงก์ไม่ได้ บอกว่าใน server component จะใช้ context ได้แค่ภายใน server component เท่านั้น เลยทำให้ใช้ js-in-css ไม่ได้ ผมเองยังไม่ได้ลองโดยตรง เลยบอกไม่ได้เต็มปากว่านี่เป็นข้อเสียจริง ๆ 555 แล้ว hooks เหรอ? ผมคิดว่ามันเป็นผู้มอบไอเดียที่พลิกวงการจริง ๆ นะ แต่ตอนนี้น่ะ 555 มี signal ที่ฉลาดกว่า React และใช้งานง่ายกว่าด้วย ซึ่งในบทความก็มีพูดถึงครับ
อ้อ 555 ฟังเพลินดีครับ
ระหว่างนั้น Angular ก็ยังถูกลืมอยู่เหมือนกัน แงงง
ผมไม่เห็นด้วยเลยนะครับ อย่างกรณีของ JSX ก็จงใจใช้เพราะมันมีข้อได้เปรียบด้านพลังในการแสดงออกมากกว่า HTML
แล้วก็ยังสงสัยว่าทำไมความเห็นทั่วไปที่ว่าการทำ two-way data binding เป็นแนวคิดที่ไม่ดีมาตลอดถึงกลับตาลปัตรขึ้นมาได้กะทันหัน..
คำว่า ecosystem ที่ใหญ่เกินความจำเป็นนี่หมายถึงอะไรกันแน่? แล้ว hooks ล้าสมัยด้วย..
โดยส่วนตัวผมถึงขั้นสงสัยเลยว่าบทความนี้เขียนโดยโปรแกรมเมอร์ตัวจริงหรือเปล่า
ดูเหมือนว่าจะมีหลายประเด็นที่ฟังขึ้นอยู่พอสมควรนะครับ แม้ว่าตอนนี้ผมก็ยังใช้ React อยู่ก็ตาม...
ดูจะฝืนไปหน่อยหากจะอ้างเพียงแค่ว่าประสิทธิภาพต่ำ โดยไม่อธิบายอย่างเป็นรูปธรรมว่ามี trade-off ทางเทคนิคอะไรบ้าง ตัวอย่างเช่น implementation แบบ islands ที่ไม่ใช่ React นั้นไม่สามารถทำสิ่งอย่างการโหลดตามลำดับความสำคัญได้อยู่แล้ว
ตราบใดที่ยังไม่มีอย่างอื่นมาแทน e-Government Framework... React ก็ย่อมยังทรงพลังในเกาหลีอยู่ดี
ก็ไม่แน่ใจนะ กำลังยกไลบรารี่มากเกินไปมาเป็นทางเลือกของ React
เมื่อพิจารณาทุกอย่างโดยรวมแล้ว ก็น่าจะต้องชูจุดเด่นที่เหนือกว่า React ให้ชัดเจนกว่านี้ไหม
Vue กับ Nuxt ดีมากจริง ๆ แต่เสียดายที่ในประเทศเรายังมีพื้นที่ยืนค่อนข้างแคบ Svelte นี่ก็... อยู่ในสภาพที่เรียกว่าแทบจะพูดถึงพื้นที่ยืนไม่ได้เลย (T_T)...
พูดได้ถูกต้องเป็นหมื่นครั้ง
ความคิดเห็นจาก Hacker News
filter,map,reduceสะดวกกว่าการใช้วิธีอ้อมuseMemoและuseCallback