ถ้าไม่ใช้ React แล้วจะใช้อะไร?

(infrequently.org)

11 คะแนน โดย GN⁺ 2024-12-01 | 12 ความคิดเห็น | แชร์ทาง WhatsApp

> "Frameworkism (ลัทธิยึดติดเฟรมเวิร์ก) ใช้ไม่ได้อีกต่อไปแล้ว คำตอบไม่ใช่เครื่องมืออื่น แต่คือความกล้าที่จะทำวิศวกรรม"

ตลอด 10 ปีที่ผ่านมา ได้ผ่านประสบการณ์มากกว่า 100 โปรเจ็กต์ด้วยผลิตภัณฑ์และเทคโนโลยีสแต็กที่หลากหลายสำหรับเว็บเดสก์ท็อปและมือถือ
เวลาจำนวนมากถูกใช้ไปกับการแก้ปัญหาด้านประสิทธิภาพและการเข้าถึงที่เกิดจากเฟรมเวิร์กฝั่งฟรอนต์เอนด์อย่าง React มากกว่าการปรับปรุง Web API
แม้ React จะกลายเป็นเทคโนโลยีแบบ legacy ไปแล้ว แต่ก็ยังคงถูกนำไปใช้ในโปรเจ็กต์ใหม่
บางคนอ้างว่า React "ทันสมัย" แต่แท้จริงแล้วเป็นเพียงการทำซ้ำวิธีคิดแบบเดิมในอดีต

กฎของความซับซ้อนฝั่งไคลเอนต์ให้น้อยที่สุด

โค้ดฝั่งเซิร์ฟเวอร์ อยู่ภายใต้การควบคุมของนักพัฒนา จึงสามารถจัดการประสิทธิภาพและความพร้อมใช้งานได้อย่างมีประสิทธิผล
โค้ดฝั่งไคลเอนต์ ทำงานในสภาพแวดล้อมที่หลากหลายซึ่งนักพัฒนาควบคุมไม่ได้ จึงยากที่จะรับประกันเสถียรภาพและประสิทธิภาพ
กลยุทธ์ที่ดีที่สุดคือ ลดปริมาณโค้ดที่ส่งไปยังไคลเอนต์
- ใช้ HTML และ CSS เป็นอันดับแรกเพื่อลดการพึ่งพา JavaScript ให้น้อยที่สุด
- React และเฟรมเวิร์กที่คล้ายกันก่อให้เกิดปัญหาการซ้ำซ้อนของโค้ดโดยไม่จำเป็นและประสิทธิภาพที่ลดลง

แล้วทางเลือกคืออะไร?

การถกเถียงที่แบ่งออกได้เป็นสองคำถาม

คำถามแบบแคบ: "หากจำเป็นต้องเรนเดอร์ฝั่งไคลเอนต์ เทคโนโลยีใดควรใช้แทน React?"
- ควรพิจารณาเฟรมเวิร์กสมัยใหม่ (เช่น Svelte, Lit, FAST, Solid, Qwik, Marko, HTMX, Vue, Stencil ฯลฯ)
- อย่างไรก็ตาม แม้จะใช้เฟรมเวิร์กเหล่านี้ ก็ยังต้องควบคุม payload และความซับซ้อนฝั่งไคลเอนต์อย่างเข้มงวด JavaScript มีต้นทุนสูงกว่า HTML/CSS อย่างน้อย 3 เท่า
คำถามแบบกว้าง: "ถ้าจะทบทวนเทคโนโลยีสแต็กที่พึ่งพา React ทั้งหมดใหม่ ควรทำอย่างไร?"
- ไม่ใช่แค่แทนที่ด้วยเครื่องมือใหม่ แต่ต้องเข้าใจเป้าหมายและข้อจำกัดของสถาปัตยกรรมเดิมก่อนจะออกแบบใหม่

วิธีเข้าหาคำถามแบบแคบ

สร้าง PoC (Proof of Concept) ขนาดเล็กหลายชิ้นเพื่อประเมินความสามารถในการขยายด้านประสิทธิภาพและข้อจำกัด
การทดลองเชิงวัตถุวิสัยเหล่านี้มอบประสบการณ์ด้านวิศวกรรมที่มีความหมายให้กับสมาชิกในทีม

สถานการณ์ร่วมของทีมที่ตั้งคำถามแบบกว้าง

มักรู้สึกสับสนเมื่อมีการพูดคุยเรื่องการแทนที่ React
- ส่วนใหญ่เคยตัดสินใจโดยเดินตามสถาปัตยกรรมเดิม
- ขาดความเข้าใจที่ชัดเจนต่อประสบการณ์ผู้ใช้และการตัดสินใจที่อิงข้อมูล

ความต่างระหว่างลัทธิยึดติดเฟรมเวิร์กกับแนวทางที่ยึดผู้ใช้เป็นศูนย์กลาง

ลัทธิยึดติดเฟรมเวิร์ก: เชื่อว่าถ้าเพิ่มฟีเจอร์ให้เฟรมเวิร์กมากขึ้น ทุกปัญหาจะถูกแก้ได้
- ในความเป็นจริง มักแก้ปัญหาของผู้ใช้ไม่ได้
- มองข้ามแพตเทิร์นที่ไม่เป็นแบบแผนหรือหลักฐานเชิงข้อมูล
สัจนิยม: วัดประสบการณ์ผู้ใช้และตัดสินใจบนพื้นฐานของข้อมูลจริง
- เข้าใจความต้องการและข้อจำกัดของผู้ใช้ แล้วออกแบบเทคสแต็กจากสิ่งนั้น
- จุดเริ่มต้นต้องเป็นความต้องการของผู้ใช้เสมอ

วิธีนำสัจนิยมมาใช้

ใช้ข้อมูล RUM: ใช้ตัวชี้วัดด้านประสิทธิภาพที่ยึดผู้ใช้เป็นศูนย์กลาง เช่น Core Web Vitals
ทดสอบประสิทธิภาพ: ใช้เครื่องมืออย่าง WebPageTest (WPT) เพื่อวัดเส้นทางผู้ใช้สำคัญ (critical user journeys)
เชื่อมโยงเป้าหมายทางธุรกิจกับประสบการณ์ผู้ใช้: ใช้ข้อมูลประเมินทิศทางการปรับปรุงและผลตอบแทนจากการลงทุน

ความสำคัญของแนวทางที่ขับเคลื่อนด้วยข้อมูล

แทนที่จะยอมรับเฟรมเวิร์กเพราะความเชื่อ ควรตรวจสอบผลลัพธ์ด้วยข้อมูล
เปรียบเทียบต้นทุนและผลลัพธ์จริงของการเลือกเทคโนโลยีตามกระแส
ส่งเสริมการเลือกเทคโนโลยีที่ มุ่งเน้นการเพิ่มประสิทธิภาพประสบการณ์ผู้ใช้ ผ่านตัวชี้วัดที่วัดผลได้

ไม่มีสิ่งมีค่าใดสูญหายไป

ผลของนโยบายที่สกัดการแพร่กระจายของ React

การห้ามใช้ React และแนวทางแบบยึดเฟรมเวิร์กอื่น ๆ ช่วย ลดต้นทุน และ ปรับทีมกลับมาให้ยึดผู้ใช้เป็นศูนย์กลาง
แต่หากไม่ตัดลัทธิยึดติดเฟรมเวิร์กออกไปอย่างแท้จริง ก็ยากที่จะปรับปรุงผลลัพธ์ได้อย่างเป็นรากฐาน
แม้จะหลีกเลี่ยงความผิดพลาดหนึ่งได้ แต่ถ้ายังลงทุนกับความผิดพลาดประเภทเดียวกันในรูปแบบอื่น ผลลัพธ์ก็ยังจำกัด

วิธีแก้ทั่วไปสำหรับปัญหาแบบกว้าง

ยึดผู้ใช้เป็นศูนย์กลาง

ผู้ตัดสินใจต้องรับผิดชอบโดยตรงต่อผลลัพธ์ของทางเลือกทางวิศวกรรมของตน
หากระบบทำงานได้ไม่ดีกับผู้ใช้ (โดยเฉพาะผู้ใช้ที่ถูกมองข้าม) ต้องมีเวอร์ชันทดแทนโดยไม่มีข้อแก้ตัว
มีแต่ปัญหาที่ต้องแก้ ไม่ยึดติดกับการทำให้วิธีเดิมเป็น "ของศักดิ์สิทธิ์"

แนวทางที่อิงหลักฐาน

ต้องมีความมุ่งมั่นร่วมกันในสัจนิยมระหว่างฝ่ายบริหารกับฝ่ายวิศวกรรม
ในการตัดสินใจ หลักฐานที่ดีกว่าจะต้องมีน้ำหนักเหนือกว่าเสมอ

กลไกป้องกัน

ต้องมีนโยบายเพื่อป้องกันข้ออ้างเพ้อฝันของลัทธิยึดติดเฟรมเวิร์ก
ตัวอย่างเช่น ข้อกำหนดทางเทคนิคเรื่อง Progressive Enhancement ของ UK Government Digital Service
- องค์กรสามารถปรับนโยบายให้เข้ากับบริบทได้ (เช่น สร้างเส้นทาง escalation สำหรับกรณียกเว้น)
- แต่สิ่งสำคัญคือ การกำหนดเกณฑ์ที่ชัดเจน นโยบายที่อิงหลักฐานมีอิทธิพลอย่างมาก

การประเมินเปรียบเทียบเทคโนโลยี

อย่านำระบบใหม่ขึ้นใช้งานโดยไม่มี เส้นทางผู้ใช้สำคัญ (critical user journeys) ที่นิยามไว้อย่างชัดเจน
เส้นทางผู้ใช้สำคัญคือภารกิจที่ผู้ใช้ทำบ่อยที่สุดในระบบ
จากนั้นทำ การประเมินเปรียบเทียบ (bakeoffs) เพื่อทดสอบผลลัพธ์ของแต่ละเทคโนโลยีภายใต้ข้อจำกัด
- ผู้จัดการผลิตภัณฑ์ไม่ควรเพียงเสนอให้ทดลองลอย ๆ แต่ต้องกำหนดสมมติฐานของผลิตภัณฑ์ให้ชัดเจนและตั้งเกณฑ์ความสำเร็จ
- นี่อาจเป็นกระบวนการที่อึดอัด แต่เป็น บทบาทหลักของผู้จัดการผลิตภัณฑ์
- หาก PM เห็นว่าไม่ใช่งานของตนและลาออก ก็ต้องยอมรับ

กรณีศึกษา

เข้าใจความต่างระหว่างสัจนิยมกับลัทธิยึดติดเฟรมเวิร์กผ่านกรณีตัวอย่าง

เกณฑ์ในการเลือกเทคโนโลยี
- การเลือกเทคโนโลยีถูกประเมินจาก จำนวนการอัปเดตข้อมูลสำคัญ และ ความยาวของเซสชัน
- แอปบางประเภทมีลักษณะเป็นเซสชันยาวและมีการอัปเดตข้อมูลบ่อย
  - ในกรณีนี้ local data model อาจเหมาะสม
  - แต่ถือเป็น กรณียกเว้นที่พบไม่บ่อย
กรณีเซสชันสั้น
- เว็บไซต์ที่มีเวลาเซสชันเฉลี่ยสั้นควร ลดปริมาณ JavaScript โหลดเริ่มต้นให้ต่ำที่สุด
- เว็บไซต์ส่วนใหญ่ไม่จำเป็นต้องใช้สถาปัตยกรรม SPA
กรณีที่ต้องใช้สถาปัตยกรรม SPA
- ควรพิจารณา SPA ก็ต่อเมื่อเข้าเงื่อนไขบางอย่างเท่านั้น
  - เซสชันยาว และต้องอัปเดตข้อมูลเดิมซ้ำหลายครั้ง
- เว็บไซต์ที่ไม่เข้าเงื่อนไขนี้ไม่ควรใช้ SPA
คำถามสำคัญ
- ปัญหาไม่ได้อยู่ที่การเลือกระหว่าง JavaScript framework ตัวไหน
- ในกรณีส่วนใหญ่ ประเด็นหลักคือ ควรใช้เครื่องมือที่มุ่งไปทาง SPA ตั้งแต่แรกหรือไม่
- สำหรับเว็บไซต์ส่วนใหญ่ คำตอบชัดเจนว่า "ไม่"

เว็บไซต์เชิงข้อมูล (Informational)

โครงสร้างที่เหมาะที่สุด: ใช้ semantic HTML และ Progressive Enhancement เมื่อจำเป็น
เครื่องมือที่เหมาะคือ static site generator เช่น Hugo, Astro, 11ty, Jekyll
เนื้อหาที่อัปเดตบ่อยควรใช้เครื่องมือ CMS เช่น WordPress
บล็อก เว็บไซต์การตลาด หน้าโฮมเพจบริษัท และเว็บไซต์ข้อมูลสาธารณะ ควร ลด client JavaScript payload ให้มากที่สุด
ไม่ควรใช้เฟรมเวิร์กที่ออกแบบมาสำหรับสถาปัตยกรรม SPA
ทำไม semantic markup และ Progressive Enhancement จึงเหมาะสม?
- มีลักษณะเด่นคือ เซสชันสั้น และ data model ที่เซิร์ฟเวอร์เป็นเจ้าของ
  - แหล่งที่มาของข้อมูลที่แสดงบนหน้าถูกจัดการโดยเซิร์ฟเวอร์เสมอ
  - ไม่จำเป็นต้องมี abstraction ของ client data model หรือการนิยามคอมโพเนนต์
- โครงสร้าง CMS:
  - editor สำหรับผู้เขียนที่มีทราฟฟิกต่ำแต่มีปฏิสัมพันธ์สูง
  - viewer UI สำหรับผู้อ่านที่มีทราฟฟิกสูงแต่มีปฏิสัมพันธ์ต่ำ

อีคอมเมิร์ซ (E-Commerce)

สถาปัตยกรรมที่แนะนำ: semantic HTML ที่สร้างจากเซิร์ฟเวอร์และ Progressive Enhancement
ช่องว่างด้านประสิทธิภาพระหว่าง Amazon กับคู่แข่งที่ใช้ React นั้นชัดเจน
- มากกว่า 70% ของทราฟฟิก Walmart มาจากมือถือ และ Next.js แบบ SPA ส่งผลลบต่อธุรกิจ
ทำไม Progressive Enhancement จึงเหมาะสม
- โครงสร้างทั่วไปของอีคอมเมิร์ซ:
  - หน้า landing ที่มีสินค้าที่กำลังขายและฟังก์ชันค้นหา
  - หน้าผลการค้นหาที่รองรับการกรองและเปรียบเทียบ
  - หน้ารายละเอียดสินค้า: มีสื่อ รีวิว และทางเลือกแนะนำ
  - หน้าจัดการตะกร้า ชำระเงิน และจัดการบัญชี
- สถานะที่เซิร์ฟเวอร์เป็นเจ้าของ:
  - รักษาความสดใหม่ของเนื้อหา (เช่น ราคา)
  - ลด latency ผ่านการปรับแต่งหน้าให้เบา
  - ใช้กลยุทธ์อย่าง aggressive caching, image optimization และการลดขนาดหน้า

เว็บไซต์เพื่อการเสพสื่อ (Media)

โครงสร้างพื้นฐาน: ออกแบบบนฐานของ Progressive Enhancement
- เพิ่มความซับซ้อนเมื่อจำเป็นตามการเปลี่ยนแปลงของผลิตภัณฑ์
ทำไม Progressive Enhancement และโครงสร้าง Islands จึงเหมาะสม
- องค์ประกอบแบบโต้ตอบอย่าง comment thread สามารถแยกเป็น data model อิสระได้
- สามารถใช้ Web Components เพื่อฝังลงในหน้าสถิตได้
กรณีที่ SPA เหมาะสม
- ความต่อเนื่องของการเล่นสื่อ:
  - ต้องคง mini player ระหว่างการเปลี่ยนหน้า
  - ใช้เทคโนโลยี SPA พร้อมควบคุมขนาด client JS อย่างเข้มงวด
- รองรับการเล่นแบบออฟไลน์:
  - ต้องมีลอจิกจัดการ local media cache
  - อาจพิจารณาระบบซิงก์ข้อมูลอย่าง Zero, Y.js

โซเชียลมีเดีย (Social)

โมเดลแบบไฮบริด: ปฏิสัมพันธ์น้อยบน data model ที่เซิร์ฟเวอร์เป็นเจ้าของ + การอัปเดตสื่อเป็นครั้งคราว
ทำไม Progressive Enhancement จึงเหมาะสม
- ปฏิสัมพันธ์ทั่วไป:
  - การกด "ถูกใจ" การอัปเดตเป็นระยะ ฯลฯ
  - แนวทางไฮบริดด้วย Hotwire หรือ HTMX เหมาะสม
กรณีที่ SPA เหมาะสม
- islands ที่มีปฏิสัมพันธ์ลึก:
  - ใช้ client caching สำหรับสิ่งอย่างการบันทึกร่างโพสต์
- รองรับออฟไลน์:
  - ส่ง HTML ก่อน แต่ใช้ Service Worker สำหรับการซิงก์และลอจิกออฟไลน์

แอปเพิ่มประสิทธิภาพการทำงาน (Productivity)

แอปเพิ่มประสิทธิภาพแบบเน้นเอกสารมีข้อกำหนดที่ซับซ้อน เช่น การแก้ไขร่วมกัน การรองรับออฟไลน์ และโหมดแสดงผลแบบเบา
local data model และสถาปัตยกรรมแบบ SPA อาจเหมาะสม
ทำไม SPA จึงเหมาะสม
- การอัปเดตข้อมูลบ่อยครั้ง:
  - สำหรับงานอย่างการพิมพ์คีย์หรือการลากเมาส์ ลอจิกฝั่งไคลเอนต์มีข้อได้เปรียบ
- ต้องจัดการข้อจำกัดด้านประสิทธิภาพ:
  - ควบคุมขนาด initial bundle
  - ใช้กลยุทธ์โหลดแพ็กเกจแบบหน่วงเวลา

แอปพลิเคชันประเภทอื่น ๆ (Other Application Classes)

ข้อกำหนดเฉพาะ:
- 3D CAD, โปรแกรมแก้ไขโค้ด, game streaming, เกมบนเว็บ, การตัดต่อสื่อ, ระบบทำเพลง ฯลฯ
- แต่ละประเภทควรถูกประเมินอย่างรอบคอบในลักษณะเดียวกับแอป productivity
เงื่อนไขสู่ความสำเร็จ:
- นิยามเส้นทางผู้ใช้สำคัญ
- วิเคราะห์ความลึกเฉลี่ยของเซสชัน
- ตั้งตัวชี้วัดรับประกันประสิทธิภาพ
- ควบคุมสคริปต์และทรัพยากรหลัก

ขอกล่าวถึง enterprise software สักเล็กน้อย

"แอปธุรกิจสำหรับองค์กร" มักก่อให้เกิดปัญหาด้านประสิทธิภาพที่เลวร้ายที่สุด
- dashboard, workflow system, แอปแชตองค์กร ฯลฯ เป็นตัวอย่างชัดเจน
ประสิทธิภาพคือวัฒนธรรม:
- ล้มเหลวในการนิยามและวัดเวลาโหลดเริ่มต้นรวมถึงประสิทธิภาพหลังการโต้ตอบ
- วัฒนธรรมแบบนักพัฒนาเป็นศูนย์กลางที่มองข้ามผู้ใช้คือพิษร้าย

"แต่..."

ผู้บริหารที่ผูกติดกับเฟรมเวิร์กบางตัวรวมถึง React มักเสนอเหตุผลหลากหลายเพื่อทำให้ทางเลือกเหล่านี้ดูสมเหตุสมผล
แต่การถกเถียงเหล่านี้ไม่ได้ให้ผู้ใช้เป็นศูนย์กลาง และความขาดตกนี้ก็ปรากฏซ้ำแล้วซ้ำเล่า

"...เราต้องไปให้เร็ว"

คำถาม: "คิดว่าสิ่งนั้นจะอยู่ได้นานแค่ไหน?"
โปรเจ็กต์ที่สร้างอย่างรวดเร็วบน NPM มักก่อให้เกิด ปัญหาการเข้าถึง, ประสิทธิภาพต่ำ และ ความซับซ้อนที่เพิ่มขึ้น ซึ่งสุดท้ายยิ่งทำให้ช้าลง
ต้นทุนการแก้ไขเยียวยา: การแก้ปัญหา JavaScript ใช้เวลาหลายเดือน และความเร็วในการปล่อยฟีเจอร์ก็ยิ่งลดลง
หากต้องการ Product-Market Fit ควรให้ความสำคัญกับการเข้าถึงและคุณภาพก่อน
การเลือกใช้ React เพื่อ "เดินให้เร็ว" สุดท้ายแล้ว มีต้นทุนสูงกว่าและขัดขวางการเติบโต

"...Facebook ก็ใช้ได้ดีนี่"

บริษัทส่วนใหญ่ ไม่ได้เผชิญปัญหาแบบเดียวกับ Facebook
Facebook เองก็ประสบ ปัญหาด้านประสิทธิภาพจากการใช้ React แต่กลบปัญหาไว้ได้ด้วยสถานะผูกขาด
บริษัททั่วไป ไม่ควรลอกกรณีของ Facebook แบบไม่ลืมหูลืมตา

"...ทีมเรารู้จัก React อยู่แล้ว"

นักพัฒนา React ก็คือนักพัฒนาเว็บ CSS, HTML, JavaScript และการทำงานกับ DOM เป็นสิ่งจำเป็น
React เป็น ชั้นที่เรียบง่ายที่สุดและแทนที่ได้ ในเทคสแต็ก
การเรียนรู้เฟรมเวิร์กที่เล็กและเร็วกว่าอย่าง Preact, Svelte, Lit, FAST ไม่ได้มีอุปสรรคสูงมาก

"...เราต้องจ้างคนให้ง่าย"

ตอนนี้อุตสาหกรรมไอทีเป็น โอกาสดีอย่างยิ่งในการจ้างนักพัฒนาที่มีคุณภาพ
ความรู้ React ไม่ควรเป็นเกณฑ์การจ้าง
นักพัฒนาที่รู้ React ส่วนใหญ่ก็เรียนรู้ web standards ได้ไม่ยาก
ในทางกลับกัน ระบบที่ง่ายกว่ากลับให้ ROI สูงกว่า

"...ทุกคนก็ใช้มือถือแรง ๆ กันหมด"

ตลอด 10 ปีที่การใช้งานมือถือเพิ่มขึ้น สมมติฐานว่าทรัพยากรฝั่งไคลเอนต์มีราคาถูกนั้นเป็น ข้อสมมติที่ผิด ไปแล้ว
ผู้ใช้มือถือสเปกต่ำก็อาจเป็นลูกค้าหลักของผลิตภัณฑ์ได้
การเลือก React เท่ากับ สมมติว่าผู้ใช้ทุกคนใช้อุปกรณ์ราคาแพง ซึ่งเป็นเรื่องเสี่ยง

"...React คือมาตรฐานอุตสาหกรรม"

React ไม่ใช่มาตรฐานที่สม่ำเสมอ
- ทั้งแนวทางของ React เอง (class components vs functional components), การใช้ TypeScript หรือไม่, การเลือกเครื่องมือจัดการ state ฯลฯ ล้วนต่างกันไปในแต่ละโปรเจ็กต์
React stack เปลี่ยนแปลงอยู่ตลอด และคำว่า "มาตรฐาน" ก็เป็นเพียง เรื่องแต่งเพื่อความสบายใจ

"...ecosystem..."

ไลบรารีที่ใช้ได้เฉพาะกับ React มีน้อยมาก และเครื่องมือส่วนใหญ่ก็ใช้กับ Preact เป็นต้นได้
ทุกแพ็กเกจ NPM ล้วนทำหน้าที่เป็น หนี้ทางเทคนิคต่ออนาคต
dependency ที่ไม่จำเป็นอย่าง CSS-in-JS มีแต่เพิ่มต้นทุน

"...Next.js ก็เร็วพอแล้ว"

โดยพื้นฐานแล้ว Next.js พาเอาปัญหาด้านประสิทธิภาพของ React มาด้วย
เครื่องมือแบบ HTML-first (เช่น Astro, 11ty) ให้ ประสิทธิภาพที่ดีกว่า Next.js
ยังมีปัญหาเรื่องการ lock-in กับ API ของสตาร์ทอัปที่ได้รับเงินทุนจาก VC อีกด้วย

"...React Native!"

React Native ทำให้แอปมือถือช้าลงและมีค่าใช้จ่ายในการบำรุงรักษาสูง
การใช้ PWA และ Capacitor/Cordova เป็นตัวเลือกที่ดีกว่า
Facebook เองก็กำลังถอยห่างจาก React Native.

12 ความคิดเห็น

nemorize 2024-12-08

บริษัททั่วไปไม่ควรทำตามกรณีของ Facebook แบบไม่ลืมหูลืมตา

แม้แต่ Facebook เองก็ยังค่อย ๆ ถอยออกจาก React Native

ผู้ใช้มือถือสเปกต่ำก็มีโอกาสสูงที่จะเป็นลูกค้าหลักของผลิตภัณฑ์

รองรับการซิงก์และตรรกะแบบออฟไลน์ผ่าน Service Worker

React Native ทำให้แอปมือถือช้าลงและต้องเสียค่าใช้จ่ายในการดูแลรักษาสูง

การใช้ Capacitor/Cordova เป็นตัวเลือกที่ดีกว่า

555555555555 555

wildmental 2024-12-03

บทความยาวเกินไปจนประเด็นหลักพร่าเลือน

ดูเหมือนผู้เขียนจะมองว่าความเห็นที่สนับสนุนให้ใช้ React นั้นมีที่มาจากแนวคิดยึดติดกับเฟรมเวิร์กไปเสียทั้งหมด

หลังจากพูดว่าควรออกจากการยึดติดกับเฟรมเวิร์กและพิจารณาเป็นกรณี ๆ ไป ผู้เขียนกลับพยายามสร้างสูตรสำเร็จสำหรับความต้องการทางวิศวกรรมทุกประเภท

สิ่งที่เด่นชัดคือความพยายามครอบครองบทสนทนาอย่างมากเกินไปด้วยการพยายามตอบโต้ข้อคัดค้านที่คาดไว้ทั้งหมด การโต้กลับต่อข้อคัดค้านก็แคบมุมมองเกินไปมาก

กล่าวคือ สำหรับการถกเถียงที่ก้าวพ้นจากกรณีเฉพาะไปสู่ข้อถกเถียงเชิงทั่วไป ผู้เขียนดูจะขาดทั้งท่าทีและทักษะในการอภิปรายอย่างมาก

ผลก็คือ แม้ว่าฉันจะไม่ได้ชอบการใช้ React อยู่แล้ว แต่เพราะท่าทีฝ่ายเดียวของผู้เขียน กลับทำให้ฉันอยากฟังความคิดของคนที่สนับสนุนการใช้ React มากขึ้นอีกหน่อย

savvykang 2024-12-03

โดยส่วนตัวตอนนี้ผมยังคิดว่า React เป็นตัวเลือกที่ดีที่สุด เลยขอแสดงความเห็นไว้แบบนี้

ผมเริ่มต้นพัฒนาเว็บมาตั้งแต่ยุค php กับ jquery และจากมุมมองของคนที่ได้ลองทั้ง AngularJS, Angular, React แบบ class style และ React แบบ hooks ในบริษัทที่ทำงานอยู่ตอนนี้ ผมมองว่าการเปลี่ยน tech stack หลังจากที่ผ่านช่วงลองผิดลองถูกของคนที่ใช้มาก่อน และมีไลบรารีต่าง ๆ พร้อมแล้ว จะปวดหัวน้อยกว่า ถ้าอธิบายแบบ semantic versioning ก็เหมือนเลือกใช้เวอร์ชันหลักที่ใหม่รองลงมาจากล่าสุดหนึ่งขั้นนั่นแหละครับ เพราะ requirement และฟีเจอร์ระดับสูงไม่ได้เปลี่ยน จึงไม่ได้มีปัญหา แต่ถ้าไม่มีเอกสารอ้างอิงเกี่ยวกับเทคโนโลยีพื้นฐาน ก็ทำให้สร้าง productivity ได้ยากจริง ๆ นอกจากนี้ ด้วยลักษณะโปรเจกต์ของบริษัทเราที่ต่างจากบริการแบบ SaaS คือมี product cycle ยาว และมีช่วงที่ทำแค่ maintenance อย่างเดียวอยู่ด้วย จึงยิ่งทำให้เอาเทคโนโลยีใหม่ล่าสุดมาใช้ได้ยากขึ้น

ถ้าวันหนึ่ง React หันไปทาง Next.js มากขึ้น จนยุติการรองรับ SPA และบังคับให้เปลี่ยนสถาปัตยกรรม ก็คงต้องกลับมาคิดเรื่องย้ายเทคโนโลยีอีกครั้ง ส่วนถ้า Vue แพร่หลายมากกว่านี้ มันก็คงเป็นหนึ่งในตัวเลือกอย่างแน่นอน ไม่มีเหตุผลที่จะไม่ใช้