มีคนที่ชอบ React จริง ๆ บ้างไหม?

 (jsx.lol)
1 คะแนน โดย GN⁺ 4 시간 전 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นชุดรวมเนื้อหาที่ คัดสรรบทความวิจารณ์เกี่ยวกับ React และเครื่องมือในสาย React โดยเรียบเรียงในรูปแบบอ้างอิงจากบทความของนักพัฒนาและบล็อกเกอร์หลากหลายคน
  • มีบทความจำนวนมากที่ชี้ให้เห็นข้อจำกัดเชิงโครงสร้างของ React เช่น ประสิทธิภาพที่ลดลง ความซับซ้อนที่เพิ่มขึ้น และปัญหา hydration
  • มีเสียงวิจารณ์ว่า การเลือกใช้เทคโนโลยีโดยยึด React เป็นศูนย์กลาง ไม่ได้เกิดจากความเหมาะสมทางเทคนิคเท่ากับความเคยชินและ network effect จนสมมติฐานว่า “ทุกคนรู้จัก React” มาก่อนการตัดสินใจด้านสถาปัตยกรรม
  • ความกังวลด้านความปลอดภัยและธรรมาภิบาลรอบ React Server Components และ Next.js เพิ่มสูงขึ้น โดย CVE-2025-55182 ถูกเปิดเผยว่าเป็น ช่องโหว่ remote code execution ที่ไม่ต้องยืนยันตัวตน ระดับ CVSS 10.0
  • ความสับสนในการออกแบบ API และ วิกฤตด้านคุณภาพ ใน ecosystem ของ React รวมถึงความซับซ้อน ทำให้การบำรุงรักษาระยะยาวและการเรียนรู้ยากขึ้น และลุกลามไปสู่ข้อถกเถียงเรื่องทิศทางของ React ตั้งแต่ Hooks, ความสามารถของ UI สมัยใหม่ ไปจนถึงกระบวนการออกรุ่น

ภาพรวมของเว็บไซต์

  • เว็บไซต์คิวเรชันที่ตั้งคำถามเชิงยั่วยุว่า "Does anybody actually like React?"
  • cherry-picked collection ที่รวบรวมบทความวิจารณ์ React และเครื่องมือที่ได้รับอิทธิพลจาก React
  • มีฟังก์ชันสมัครรับ RSS

คำวิจารณ์พื้นฐานต่อตัว React เอง

  • The End

    • React แทบจะเป็นคำตอบที่ผิดอยู่เสมอ และได้กลายเป็น ค้อนที่ทำให้ทุกอย่างดูเหมือนตะปู
    • แม้จะสามารถใช้ React ได้อย่างถูกต้อง แต่ในความเป็นจริงแทบไม่ค่อยถูกใช้อย่างดี

  • JS-heavy approaches are not compatible with long-term performance goals

    • โปรเจกต์ที่เน้น JS เป็นศูนย์กลางตั้งแต่ระดับหนึ่งขึ้นไป ช้ากว่าที่โฆษณาไว้ และยิ่งช้าลงเมื่อเวลาผ่านไป
    • ต้องใช้ความพยายามในการพัฒนาและบำรุงรักษามากกว่า และมีบั๊กมากพอ ๆ กับแนวทางอื่น

  • React Still Feels Insane And No One Is Talking About It

    • อาจสรุปได้ง่ายว่า React “มันบ้าไปแล้ว” แต่ก็จำเป็นต้องพยายามทำความเข้าใจมันอย่างมีเหตุผล

  • Stop Using and Recommending React

    • จากประสบการณ์ใช้งาน React มาอย่างยาวนาน ไม่มีเหตุผลให้ใช้ และมีหลายเหตุผลให้คัดค้าน

  • Please don't use React

    • เสนอว่าควรเลิกใช้ React และไม่ควรเริ่มใช้มันตั้งแต่แรก

  • Tech Founder? Entrepreneur? This is why you should avoid React.js in your app

    • React ไม่ได้แค่ช้าเท่านั้น แต่เป็น ecosystem ที่พองตัวและมีหนี้เทคนิคฝังอยู่ใน DNA
    • พร้อมตั้งคำถามว่าทำไมถึงยังคงถูกเลือกใช้อยู่เรื่อย ๆ

ปัญหาด้านความปลอดภัยและธรรมาภิบาล

  • Critical Security Vulnerability in React Server Components

    • เมื่อวันที่ 29 พฤศจิกายน Lachlan Davidson รายงานช่องโหว่ remote code execution (RCE) ที่ไม่ต้องยืนยันตัวตน
    • เปิดเผยในชื่อ CVE-2025-55182 ระดับ CVSS 10.0

  • You should know this before choosing Next.js

    • Vercel เปิดเผยช่องโหว่ความปลอดภัยร้ายแรงของ Next.js
    • ตัวประเด็นเองเป็นเรื่องปกติ แต่ วิธีรับมือของ Vercel หละหลวมและขาดความรับผิดชอบ
    • ยิ่งทำให้ความกังวลเรื่องธรรมาภิบาลของโปรเจกต์รุนแรงขึ้น

  • Next.js 15.1+ is unusable outside of Vercel

    • Next.js ได้กลายเป็นรูปแบบของ Vercel vendor lock-in ที่ปลอมตัวมาเป็นเฟรมเวิร์กโอเพนซอร์ส

ปัญหาการออกแบบ API และเส้นโค้งการเรียนรู้

  • Is it Time to Regulate React?

    • ความล้มเหลวหลักของ React ถูกซ้ำเติมด้วย การออกแบบ API ที่สับสน
    • เอกสารคลุมเครือ และการถกเถียงเรื่องวิธีใช้งานที่ถูกต้องก็ไม่มีวันจบ

  • I don't have time to learn React

    • ตรงข้ามกับคำกล่าวอ้างว่า React สอน UI สมัยใหม่ได้ แต่ในความจริงกลับแทบจัดการกับ UI สมัยใหม่ไม่ได้
    • autofocus ใช้งานพัง และ custom elements ก็ใช้งานไม่ได้หากไม่ใช่เวอร์ชันทดลอง
    • หากจะใช้ฟีเจอร์สมัยใหม่อย่าง dialog, popover ก็ต้องพึ่ง useEffect
    • เพราะระบบ synthetic event จึงแทบไม่ได้เรียนรู้พฤติกรรมจริงของ DOM
    • มันไม่ใช่ UI สมัยใหม่ แต่เป็น UI ระดับปี 2013

  • The React Blog Post: Reflections and Reactions

    • ท่าทีที่เหมารวมว่าทุกปัญหาเป็นแค่ “skill issue” และบอกว่าแก้ได้ด้วยไลบรารีภายนอกนั้นดูประหลาด
    • เทคโนโลยีควรเป็นสิ่งที่กลับมาทำงานต่อได้แม้ผ่านไป 3 ปี แต่ฟรอนต์เอนด์ โดยเฉพาะ React ไม่ได้เป็นเช่นนั้น

  • React, where are you going?

    • ปัญหาสองข้อที่ทำให้ทุกวันนี้สนุกกับ React น้อยลงคือ ownership และ complexity
    • มีความกังวลว่านักพัฒนาหน้าใหม่อาจรู้สึกหวาดหวั่นกับ React

ปัญหาด้านประสิทธิภาพและประสบการณ์ผู้ใช้

  • Why use React?

    • โดยพื้นฐานแล้วมักติดอยู่กับ รูปแบบ hydration ที่ขึ้นชื่อว่าแย่
    • เป็นโครงสร้างที่คำนวณทุกอย่างด้วย JS บนเซิร์ฟเวอร์ ส่ง HTML ออกไปทันที แล้วส่ง JS ชุดเดิมไปยังฝั่งไคลเอนต์อีกครั้ง

  • How React 19 (Almost) Made the Internet Slower

    • หลังจากเกิดกระแสต่อต้านอย่างเปิดเผยและการถกเถียงอย่างดุเดือด ทีม React จึงระงับการเปลี่ยนแปลงไว้

  • An even faster Microsoft Edge

    • เปลี่ยนจาก React ไปเป็น Modern Web Components + สถาปัตยกรรมแบบ HTML-first
    • เป็นประโยชน์อย่างมากโดยเฉพาะกับผู้ใช้ฮาร์ดแวร์สเปกต่ำ

  • Switching costs

    • อยากให้มีเสียงบ่นมากขึ้นเกี่ยวกับ ประสบการณ์ผู้ใช้ที่ย่ำแย่ ซึ่ง client-side React บังคับให้ต้องยอมรับ
    • แต่ในความเป็นจริง ข้อร้องเรียนเกือบทั้งหมดกลับไปกระจุกอยู่ที่ ประสบการณ์นักพัฒนา

  • Pivoting From React to Native DOM APIs: A Real World Example

    • ทีมพัฒนาทีมหนึ่งเปลี่ยนจาก “VDOM อันครอบงำ” ของ React ไปสู่ DOM API สมัยใหม่
    • รับรู้ได้ทันทีถึง ความเร็วและการโต้ตอบที่ดีขึ้น

ปัญหาด้านมือถือและแพลตฟอร์ม

  • I Built the Same App 10 Times: Evaluating Frameworks for Mobile Performance

    • กลยุทธ์ด้านมือถือของ React โดยแก่นแล้วผลักทีมไปสู่ การยึดติดกับแพลตฟอร์ม (platform capture)
    • เว็บมอบทางเลือกที่สามารถ เผยแพร่ได้โดยตรง โดยไม่มี gatekeeper หรือค่าธรรมเนียมแพลตฟอร์ม

ปัญหาด้านระบบนิเวศและชุมชน

  • React Won by Default – And It's Killing Frontend Innovation

    • เมื่อจำเป็นต้องทำฟรอนต์เอนด์ใหม่ จุดเริ่มต้นไม่ใช่ "ข้อจำกัดคืออะไร และเครื่องมือใดเหมาะ" แต่เป็น "ใช้ React กันเถอะ ทุกคนรู้จัก"
    • วงจรเสริมแรงตัวเองที่ network effect เป็นตัวกำหนดสถาปัตยกรรม แทนที่จะเป็นความเหมาะสมทางเทคนิค

  • Conferences, Clarity, and Smokescreens

    • จากงานที่ปรึกษาและข้อมูลในอุตสาหกรรม ชุมชน React กำลังเผชิญ วิกฤตด้านคุณภาพที่ลึกและวัดผลได้
    • ผู้เข้าร่วม React Summit ไม่ได้ยินเรื่องนี้

  • Why Silicon Valley CTOs Are Secretly Moving Away from React

    • แม้จะมีนักพัฒนา React จำนวนมาก แต่ ผู้เชี่ยวชาญตัวจริงที่เข้าใจแพตเทิร์นเชิงลึกกลับหายากขึ้นและมีค่าตัวแพงขึ้นเรื่อย ๆ
    • วิศวกรที่มีประสบการณ์มากที่สุดกำลังย้ายไปใช้ tech stack อื่น เพราะเหนื่อยล้ากับความซับซ้อน

  • Increasingly miffed about the state of React releases

    • ผ่านไป 1 ปีครึ่งแล้วนับจาก React release ครั้งล่าสุด ซึ่งนานกว่ารอบการออกเวอร์ชันครั้งใดก่อนหน้านี้

คำวิจารณ์ต่อ React Server Components

  • React Server Components: the Good, the Bad, and the Ugly

    • React แทบจะละทิ้งการพัฒนาฝั่ง client-side ไปแล้ว (นับจากยุติงานทดลองในปี 2019)
    • เป็น เฟรมเวิร์ก legacy ที่สร้างขึ้นเพื่อแก้ปัญหาระดับ Facebook ด้วยทรัพยากรระดับ Facebook ซึ่งไม่เหมาะกับกรณีใช้งานส่วนใหญ่

  • React Server Components are a bad choice (for shipping)

    • ถ้าต้องการปล่อยใช้งานอย่างรวดเร็ว ก็ไม่ควรใช้ React Server Components
    • แต่ถ้าใช้เพื่อการเรียนรู้ การทดลอง หรือการทำคอนเทนต์ ก็พอใช้ได้

การกลับไปสู่พื้นฐานและการเน้นทางเลือกอื่น

  • HTML is better than React!?

    • ข้อดีของ progressive enhancement แบบอิง HTML
      • มอบประสบการณ์ที่ใช้งานได้ให้ผู้ใช้เร็วกว่า
      • ต่อให้การเชื่อมต่อช้า เว็บไซต์ก็ไม่ดูแย่
      • แม้จะเกิดปัญหา ผู้ใช้ก็ยังใช้งานเว็บไซต์ต่อได้

  • How to build a counter component using the HTML Framework in just 1 line of code

    • คำแนะนำเชิงเสียดสีว่าให้ "หาโฟลเดอร์ node_modules แล้วลากไปทิ้งถังขยะ"

  • Liskov's Gun: The parallel evolution of React and Web Components

    • React กลายเป็น ซากที่พองโตจากคำสัญญาปลอม ๆ คำกล่าวอ้างชวนเข้าใจผิด และชั้นความเข้ากันได้ย้อนหลังที่ไม่มีที่สิ้นสุด
    • แม้แต่อัปเดตก็มักทำให้โค้ดพัง

  • Removing React is just weakness leaving your codebase

    • การหลุดพ้นจากเฟรมเวิร์กหนัก ๆ อย่าง React แล้วหันมาโฟกัสที่ พื้นฐานของเว็บ คือการประกันอนาคตให้ทั้งอาชีพและ codebase

  • Concatenating text

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

กรณีศึกษาการย้ายและการเปลี่ยนผ่าน

  • We Rewrote our React App in Svelte in Three Weeks

    • เคยมองข้ามพาดหัวที่บอกว่า Svelte เป็นเฟรมเวิร์กที่ "ถูกรักมากที่สุด" แต่ ตอนนี้เข้าร่วมฝั่ง Svelte แล้ว

  • Moving on from React

    • หลังจากเริ่มต้นผิดทางกับ React ในปี 2023 ก็ย้ายไปใช้ tech stack ที่เหมาะกับโดเมนของลูกค้ามากกว่า

  • Moving on from React, a Year Later

    • ฟรอนต์เอนด์แบบ JS-heavy ในยุค "fat client" กำลังเลือนหายไป
    • กระแส hype ของ edge application ไม่จำเป็นต่อการสร้างธุรกิจหลากหลายประเภท

  • Replacing React: How Liveview solved our performance problems

    • สำรวจ LiveView เพราะปัญหาด้านประสิทธิภาพของ React SPA
    • หลังลองสำรวจ 2 วันก็มั่นใจ และเปลี่ยน React SPA เป็น LiveView ภายในไม่กี่สัปดาห์

กระแสโดยรวมและแนวโน้มในอนาคต

  • The Neverending Story

    • เส้นทางที่ต่อเนื่องจาก Applets, ActiveX, Flash, Flex, Silverlight, Angular มาจนถึง React
    • ความล้มเหลวซ้ำแล้วซ้ำเล่าของบริษัทที่มองไม่เห็นภาพใหญ่

  • If Not React, Then What?

    • Frameworkism เทศนาว่าการรับเอาเครื่องมือเฟรมเวิร์กเพิ่มขึ้น (หรือแบบอื่น) คือหนทางปรับปรุงประสบการณ์ผู้ใช้
    • ทำให้ผู้คนหมกมุ่นกับกิจกรรมที่ดูเหมือนวิศวกรรม แต่จริง ๆ ไม่ใช่

  • Reckoning: Part 4 — The Way Out

    • อย่าไปคล้อยตามแผนสร้าง YAJSD (Yet Another JavaScript Disaster)
    • เมื่อมีข้อเสนอให้ rewrite ด้วย React วิศวกรระดับ senior ไม่ควรนิ่งเงียบ

  • After a Decade of React, Is Frontend a Post-React World Now?

    • นักพัฒนาเว็บหน้าใหม่สามารถพิจารณาอย่างจริงจังที่จะหลีกเลี่ยง React ไปเลย
    • โอกาสหางานระยะสั้นอาจลดลง แต่ก็มีโอกาส จับคู่กับนายจ้างแนวหน้า ได้

  • React, Electron, and LLMs have a common purpose: the labour arbitrage theory of dev tool popularity

    • ในองค์กรส่วนใหญ่ที่สร้างซอฟต์แวร์สำหรับเว็บ React ด้อยกว่าทางเลือกอื่นจำนวนมากอย่างเป็นกลาง

  • It feels like React is getting a bit of a kicking recently

    • คำแนะนำเกี่ยวกับ การเปลี่ยนแปลงท่าที ของชุมชนที่มีต่อ React และการตัดสินใจในโปรเจกต์

  • Kind of annoyed at React

    • แม้ยังคงเลือก React เมื่อต้องสร้างสิ่งที่ซับซ้อน แต่ก็ยังรู้สึกเสียดายว่า อยากให้การเลือกนั้นน่ายินดีกว่านี้

  • Am I the only one that thinks that the direction of React is wrong?

    • ให้ความรู้สึกเหมือน React กำลังเล่นเกมของตัวเองด้วยกฎของตัวเอง

  • Client-side JavaScript and React criticism: What comes next?

    • การอภิปรายเรื่องการปรับปรุงการใช้ JavaScript, การสอนแนวคิด progressive enhancement และแนวทางสมานฉันท์ในชุมชน

  • A Historical Reference of React Criticism

    • การสรุปเชิงประวัติศาสตร์ของคำวิจารณ์ที่มีต่อโปรเจกต์ React ตลอดหลายปีที่ผ่านมา
    • บางส่วนได้รับการแก้ไขแล้ว และบางส่วนยังคงไม่ได้รับการแก้ไข

Hooks และแนวคิดทางเลือก

  • Why Signals Are Better Than React Hooks

    • Hooks ของ React ใช้ให้ถูกต้องก็ยาก และจะใช้ให้ได้ประสิทธิภาพดียิ่งยากกว่า
    • เป็นต้นเหตุของ คุณภาพโค้ดและประสิทธิภาพที่ลดลง ในแอปพลิเคชันจำนวนมาก

คำวิจารณ์เชิงเปรียบเปรย

  • What Is React.js?

    • วิดีโอที่ เปรียบ React กับศาสนาคริสต์ ผ่านความแปลกประหลาดของผู้สนับสนุน ความจริงจังกับตัวเองเกินเหตุ และเอกสารที่ไม่มีวันจบ

บทความที่เกี่ยวข้อง

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

 
bichi 5 분 전

React ก็เป็นแค่ศรัทธา (ลัทธิงมงาย)
 
bichi 4 분 전

ก็เหมือน Ant Mill นั่นแหละ //
 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • มีหลายอย่างที่ไม่ชอบใน React React เป็นเฟรมเวิร์กสำหรับวาด interactive HTML บนหน้าจอ ไม่ได้มีไว้เพื่อทำการเขียนโปรแกรมที่ซับซ้อนมากอะไรขนาดนั้น
    อย่างแรกคือมันพึ่งพาแนวคิดและคำศัพท์ที่ซับซ้อนมากเกินไป ถ้าเทียบกับ Vue แล้ว useEffect ก็เทียบได้กับ watch และ useMemo ก็เทียบได้กับ computed
    อย่างที่สองคือวิธีคิดแบบ “ฉลาด” ที่ไม่จำเป็นนี้ไม่ได้หยุดอยู่แค่คำศัพท์ แต่แทรกซึมไปทั้ง ecosystem ด้วย Redux สมัยก่อนแค่จะเพิ่มตัวเลขขึ้นหนึ่งยังต้องเขียนโค้ดเยอะมากกระจายหลายไฟล์ และดูเหมือนเป็นเพราะผู้เขียนชอบแนวคิดวิทยาการคอมพิวเตอร์ที่ดูฉลาด ๆ ส่วน VueX ในช่วงเวลาเดียวกันก็แค่เพิ่มเลขนั้นขึ้นไปตรง ๆ ได้เลย โชคดีที่ทุกวันนี้ ecosystem ของ React มีตัวจัดการ state ที่ยังมีสติอยู่มากขึ้นแล้ว
    อย่างที่สามคือ React ไม่ได้มีเครื่องมือทำงานกับ CSS มาให้เป็นพื้นฐาน
    อย่างที่สี่คือ React ไม่ได้ทำ optimization ให้เอง ต้องรู้ว่าเมื่อไรควรหรือไม่ควรใช้ useEffect กับ useMemo และควรใช้อย่างไร อีกทั้งยังมีเรื่องเล่าปากต่อปากเกี่ยวกับการ optimize React อยู่มาก ทั้งที่เป้าหมายหลักก็คือการ rerender นี่แหละ ใน Vue ตัวเฟรมเวิร์กจะผลักให้ใช้เครื่องมือของมันและจัดการ optimize ส่วนใหญ่ให้ภายใน ดังนั้นเลยไม่เคยรู้สึกว่าต้องมา optimize แอป Vue ด้วยมือ
    อย่างที่ห้าคือตัวเรื่องเล่าปากต่อปากนั้นเองก็เป็นปัญหา API ของ React และ “วิธีเขียน React ที่ถูกต้อง” เปลี่ยนใหญ่ ๆ มาหลายรอบเกินไป จนตอนนี้แยกได้ยากมากว่าอะไรยังถูกต้องและอะไรไม่ใช่แล้ว
    สรุปได้ว่า React สนใจไอเดีย วิทยาการคอมพิวเตอร์ และ abstraction ระดับสูงมากเกินไป แต่สนใจเรื่องการทำให้วาด interactive HTML บนหน้าจอได้ง่ายจริง ๆ น้อยเกินไป
    ผมใช้ React, Vue และ Svelte มาเยอะทั้งหมด แต่พอใช้ React ก็ต้องคอยกังวลกับเรื่องที่ถ้าเป็น Vue หรือ Svelte มันคงจัดการให้ไปแล้วอยู่เรื่อย ๆ ในแง่ประสิทธิภาพทั้งสามตัวก็คล้ายกัน
    เคยเขียนเรื่องที่เกี่ยวข้องไว้ก่อนหน้านี้ด้วย: https://www.brachkow.com/notes/what-i-like-in-vue/

  • ในฐานะคนที่ผ่านกระแสหลักของ JavaScript มาตลอดราว 16 ปีที่ผ่านมา ก็ถือว่าชอบ React ในความหมายหนึ่ง
    React คือ เฟรมเวิร์ก JavaScript ที่แย่ที่สุด ถ้าไม่นับทุกตัวอื่นที่เราเคยลองมา
    ไม่ว่าเมื่อไรก็จะเลือก React มากกว่ายุค Angular 1 แน่นอน และจะเลือก MVC หนัก ๆ ของ Angular 1 มากกว่าวิธีแบบ Backbone ที่ต้องประกอบทุกอย่างเองใหม่ตั้งแต่ต้นทุกครั้ง ขณะที่โครงสร้าง MVC ขั้นต่ำของ Backbone ก็ยังดีกว่าโครงสร้าง JQuery soup แบบคลาสสิก ในยุคนั้นก็จะเลือกการจัดการ DOM และการเสริม standard library ของ JQuery ทันทีมากกว่า native API
    React เองก็มี trade-off แต่เรามาถึงจุดนี้ได้หลังจากอยู่กับทางเลือกอื่นจำนวนมากที่ใช้ไม่ได้มาเป็นเวลานาน

    • ผมใช้ React อย่างสบายใจและจะเลือกมันมากกว่าสิ่งที่มาก่อนหน้า แต่ถ้างานต้องการแค่นั้น ก็จะไม่เลือก React แทน htmx/data-star กับ server-side rendering และถึงจะมีหน้าเว็บซับซ้อนขึ้นมาอีกไม่กี่หน้าก็เหมือนกัน
    • แต่ไม่เข้าใจว่าทำไมต้อง React แทน Vue เรื่องที่น่าอึดอัดที่สุดคือสุดท้าย Vue ก็ขยับไปในทิศทางของ React โครงสร้างคอมโพเนนต์ดั้งเดิมของ Vue ที่มีทั้ง HTML template, JavaScript state และ CSS style อยู่ด้วยกันนั้นดีมากจริง ๆ วิธีดึงข้อมูลด้วย URL ภายในคอมโพเนนต์ก็ตรงไปตรงมามาก
    • เห็นด้วย ผมผ่านมาจาก HTML แบบ cgi-bin ที่เขียนด้วยมือ ไป JQuery, Angular v1 และ React แล้ว React ก็เป็นเครื่องมือที่พร้อมจะหยิบมาใช้ มันทำสิ่งที่ผมต้องการจะทำได้
    • ชอบ React มากกว่า Angular แต่ชอบ Vue มากกว่า React
    • สงสัยว่าเคยใช้ Svelte ไหม ไม่ค่อยเข้าใจว่าทำไมใครถึงจะชอบ React มากกว่าได้ ข้อดีอย่างเดียวของ React ในสายตาผมคือมันเป็นเหมือน IBM ของฝั่ง frontend เลือก React แล้วไม่มีใครโดนไล่ออก

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

    • ในที่ทำงานแทบไม่เคยมีโอกาสเลือกเฟรมเวิร์กหรือไลบรารีเองเลย เกือบตลอดเวลาคือต้องมารับช่วงงานที่มีคนเริ่มไว้เมื่อหลายปีก่อน หรือไม่ก็ถูกผูกอยู่กับองค์กรที่มีตัวเลือกเคร่งครัด ส่วนตัวแล้วผมคงไม่เลือก React
      React ชนะเพราะมันกลายเป็น ตัวเลือกปริยาย และคนก็มักชอบสิ่งที่คุ้นมือและตรงกับรสนิยมของตัวเอง
    • React มีข้อดีอยู่ แต่ก็มักถูกเลือกเพราะ แรงเฉื่อย มากกว่าจะเป็นเครื่องมือที่ดีที่สุดสำหรับงานนั้น เหตุผลอย่าง “ทุกคนใช้ React กัน เราเลยขยายฐานคนสมัครงานและฐานฟรีแลนซ์ได้สูงสุด” หรือ “โปรเจกต์ React ดูดีในเรซูเม่” มักมีผล
    • ที่จริงกลับถูกบังคับให้ใช้ React และ Next.js มากกว่า เพราะผู้ให้บริการ SaaS หลายเจ้าจับมือกับ Vercel และเปิดจุดขยายระบบไว้แค่ทางนั้น
      ถ้าอยากใช้อย่างอื่นก็ต้องลงมือทำ integration เอง หรือหาโปรเจกต์โอเพนซอร์สที่มีคนทำไว้แล้ว หรือไม่ก็ถาม AI
      ทำกับโปรเจกต์งานอดิเรกยังพอได้ แต่ในสภาพแวดล้อมการทำงานจริงนึกภาพได้ยาก
    • ไม่เข้าใจว่าคำว่าไม่มีใครบังคับให้ใช้ React หมายถึงอะไร มันมีโลกใหม่แสนวิเศษแบบที่ทุกคนไปเรียน Lisp แล้วเอาไปใช้กับทุกอย่างที่อยากทำได้ โดยที่วัฒนธรรมองค์กรไม่มีผลต่อการเลือกเทคโนโลยีเลย อยู่ที่ไหนกันแน่

  • ชอบ React และก็เคยลองฝั่ง HTMX/Hotwire อย่างจริงจังมาแล้ว
    เคยอยากทำปุ่มย้อนกลับที่ถ้ามาจากกล่องจดหมายก็ให้ถอยกลับด้วย Browser API แต่ถ้าไม่ใช่ก็ส่งไปที่ลิงก์กล่องจดหมายเพื่อคงตำแหน่งการเลื่อนเอาไว้ ต้องผูกพฤติกรรมใน HTML เพื่อเรียกฟังก์ชันย้อนกลับ แล้วใน controller ก็ต้องตัดสินว่าหน้าก่อนหน้าคือหน้าไหน จากนั้นค่อยส่งทั้งปุ่มย้อนกลับแบบ JavaScript เปิดใช้งานหรือ hard link ลงมา ทำให้ logic กระจายอยู่ใน 3 ไฟล์
    ใน React, JavaScript ภายในคอมโพเนนต์สามารถตรวจได้ว่าหน้าที่แล้วมาเป็นกล่องจดหมายหรือไม่ แล้วตามค่านั้นก็แสดง JSX ของปุ่มย้อนกลับหรือลิงก์ได้ ทุกอย่างจบใน ไฟล์เดียว สำหรับฉัน แค่โมเดลเอนทิตีเชิงแนวคิดเดียวก็พอ แต่แนวทางอื่นกลับต้องยัดฟีเจอร์นี้ลงไปใน 3 เอนทิตีแบบฝืน ๆ
    ถ้าถามว่าช้ากว่าไหม ก็ช้ากว่าแน่นอน แต่ก็ทำให้มีความสุข ถ้าคุณกำลังทุกข์กับ React codebase สุดรกของบริษัท ก็ต้องโทษเพื่อนร่วมงาน React เองไม่ใช่ปัญหา ถ้าไม่มี React ก็น่าจะแย่กว่านี้แน่

    • เพราะงั้นเลยเกลียด React single-page app ดูเหมือนจะหาวิธีงี่เง่ามาทำให้ ปุ่มย้อนกลับและปุ่มนำทาง ของเบราว์เซอร์พังอยู่ตลอด
      นอกจากกรณีอย่างการเสริมฟอร์มเป็นครั้งคราวแล้ว โดยรวมก็ยังชอบ htmx/server rendering และพฤติกรรมแบบเนทีฟมากกว่าเสมอ
    • มองว่า HTMX ควรใช้เฉพาะงานที่เกี่ยวกับ data state เท่านั้น สิ่งที่ไม่ได้ขึ้นกับ resource state อย่างปุ่มย้อนกลับอัจฉริยะ ไม่ควรไปคำนวณในฝั่งแบ็กเอนด์
      ถ้าเป็นแนวทาง htmx ที่แนะนำ ก็แค่ผูกปุ่ม onclick เข้ากับ inline JavaScript หรือถ้าไม่ชอบก็เรียกฟังก์ชันอย่าง goBackOrInbox ได้
      function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
      ถ้าใช้แพตเทิร์นแบบนี้บ่อย ๆ ก็ทำให้เป็นพารามิเตอร์โดยรับเส้นทางที่จะย้ายไปเป็นอาร์กิวเมนต์ได้
    • คิดว่าวิธีที่ดีที่สุดในการแก้ปัญหาปุ่มย้อนกลับคืออย่าทำให้มันซับซ้อนเกินไป และทำให้แน่ใจว่าสิ่งที่อยากย้อนกลับจริง ๆ เท่านั้นที่จะเข้าไปอยู่ใน ประวัติเบราว์เซอร์ เหมือนนิยามปัญหาเองกำลังตะโกนว่า “ถ้าวางโครงสร้างให้ดีกว่านี้ มันจะกลายเป็นปัญหาที่ไม่ต้องแก้”
    • ตรงนั้นตรงนี้อาจมีส่วนที่ซับซ้อนอยู่บ้าง แต่ก็น่าจะทำด้วย Web Components ได้ไม่ใช่หรือ

  • เขียน React มานาน แล้วตอนนี้ที่บริษัทกำลังทำโปรเจ็กต์ Vue ขนาดใหญ่ แต่ก่อนทุกคนบอกเสมอว่า Vue เป็นตัวเลือกที่ง่ายกว่าและเข้าถึงง่ายกว่าระหว่างสองตัวนี้ แต่ตอนนี้เริ่มมองต่างออกไป
    React ดูสง่างามตรงที่คอมโพเนนต์โดยแก่นแท้แล้วเป็นแค่ฟังก์ชัน และนอกเหนือจากนั้นก็ไม่ได้มีอะไรเยอะ ถ้าไม่นับ ecosystem ของ Next.js นี่ถือว่าสง่างามที่สุดอย่างหนึ่งที่เคยเห็นในงานพัฒนาฟรอนต์เอนด์
    ส่วน Vue กลับให้ความรู้สึกปะปน เหมือนมีร่องรอยของการที่นักพัฒนาแบ็กเอนด์ซึ่งไม่อยากเรียน JavaScript ให้จริงจังเข้ามายอมรับและสรรเสริญมัน และผลลัพธ์ก็ให้ความรู้สึกเหมือนส่วนผสมประหลาดที่ประกบกันไม่ค่อยสนิท

    • ไม่เคยเข้าใจมุมมองแบบนี้เลย React component ไม่ใช่แค่ฟังก์ชันธรรมดา แต่เป็นฟังก์ชันที่มี context ที่ถูกฉีดเข้ามาแบบเหมือนเวทมนตร์ ซึ่งเข้าถึงผ่าน hooks และ hooks เหล่านี้ก็ต้องการการรับประกันสารพัดอย่าง ถ้าไม่ตระหนักถึงมันก็จะได้ผลลัพธ์ที่ debug ยากมาก เลยมองว่าไกลจากคำว่าสง่างามมาก
      เคยใช้ framework หลัก ๆ มาหมดแล้ว และตอนนี้กำลังทำ Angular web app ขนาดใหญ่ ใน Angular คอมโพเนนต์ถูกแสดงเป็นคลาส เทมเพลต และสไตล์ ตัว event listener ส่วนใหญ่ก็แค่เรียกเมธอดของคลาส และสถานะก็เรียบง่ายได้เหมือน property ของคลาส มันเป็นธรรมชาติกว่ามากและมีหลุมน้อยกว่ามาก แน่นอนว่าไม่ใช่ศูนย์
    • อยากรู้ว่าใช้ Vue มานานแค่ไหนแล้ว ฉันเองเมื่อหลายปีก่อนก็มอง Vue จากพื้นฐาน React แล้วคิดคล้าย ๆ กัน แต่ตอนนี้กลับชอบ Vue มากกว่า React และทั้งโปรเจ็กต์ส่วนตัวกับโปรเจ็กต์งานก็เลือก Vue ก่อนเสมอ
      ประสบการณ์ใช้งานต่างกันเล็กน้อย มีบางอย่างที่ React ทำได้ง่ายกว่า และบางอย่างที่ Vue ทำได้ง่ายกว่า แต่การที่ Vue ใช้ signals เป็นข้อดีใหญ่มากสำหรับฉัน

  • มากกว่าตัว React เอง ฉันสนใจคำถามที่ว่า วิธีที่ดีที่สุดในการเขียน UI ด้วยโค้ด คืออะไรกันแน่
    ฉันเป็นแฟน React และใช้ React กับเว็บแอปแทบทุกตัวที่ทำ แต่ปัญหาใหญ่และชัดที่สุดคือการเขียน UI ด้วย React มันยังไม่ให้ความรู้สึกเป็นธรรมชาติเท่ากับการเขียนเครื่องมือบรรทัดคำสั่งด้วย Go หรือแอปเรียลไทม์ด้วย Elixir
    ภาษาบางภาษาเหมาะกับงานบางประเภทอย่างน่าประหลาดใจและแทบไม่มีแรงเสียดทานเลย แต่เรื่อง UI นั้นยังไม่มีใครพิชิตได้จริง ๆ ไม่ว่าจะเป็น Swift, JSX/HTML, Svelte หรือเฟรมเวิร์กยอดนิยมแนวเดียวกันตัวไหนก็ตาม ล้วนให้ความรู้สึกเหมือนกำลังเลี่ยงปัญหาบางส่วนอยู่ ภาษา/ผู้ออกแบบเฟรมเวิร์กดูเหมือนจะต้องยอมใส่ไวยากรณ์ที่รุงรัง แปลก หรือชวนปวดหัวเข้าไปสักจุดหนึ่งเพื่อให้ตรงกับความต้องการ
    อินเทอร์เฟซที่เป็นธรรมชาติของ UI นั้นเป็นเรื่องของภาพ ดังนั้นเครื่องมืออย่าง Figma อาจเป็นส่วนสำคัญของคำตอบ ถึงอย่างนั้นก็ยังรู้สึกว่ามีบางอย่างขาดไป น่าจะมีวิธีที่เข้าใจกว่าในการแสดงสิ่งที่เป็นภาพออกมาเป็นโค้ด วิธีแก้ปัจจุบันอธิบายให้ชัดได้ยาก แต่รู้สึกเหมือนขาดอะไรไปนิดเดียวอยู่เสมอ

    • รู้สึกคล้ายกัน ตอน React ออกมาใหม่ ๆ ฉันชอบมันมาก เพราะเมื่อเทียบกับตัวเลือกอื่นในตอนนั้นมันให้ความรู้สึกว่าเกือบสมบูรณ์แบบ
      ตอนนี้ฉันก็ยังชอบ React มากกว่าแทบทุกอย่าง รวมถึง Svelte, Vue และ Solid แต่ช่วงหลังเริ่มใช้ Crank(https://crank.js.org/) และมันดูเหมือนจะเข้าใกล้ทิศทางที่ฉันอยากไปมากขึ้นอีกก้าวหนึ่ง เพียงแต่จนถึงตอนนี้ฉันใช้มันแค่กับโปรเจกต์เล่น ๆ เลยยังพูดยากว่ามันจะขยายได้ดีแค่ไหนทั้งในด้านประสิทธิภาพและประสบการณ์นักพัฒนา
    • เห็นด้วยมากกับประโยคที่ว่า “ภาษาบางภาษาเหมาะกับงานบางประเภทอย่างน่าประหลาดใจและแทบไม่มีแรงเสียดทาน แต่เรื่อง UI นั้นยังไม่มีใครพิชิตได้จริง ๆ” ถ้าไปดูหนังสือ[1] ที่พูดถึงปัญหานี้ตั้งแต่ต้นยุค 90 ก็ยังใช้ได้อยู่จนถึงทุกวันนี้
      บทวิเคราะห์ที่ดีที่สุดเท่าที่ฉันเคยเห็นอยู่ในบทความของ Chatty ชื่อ “Programs = Data + Algorithms + Architecture: consequences for interactive software engineering”[2] อ่านค่อนข้างยาก แต่คุ้มค่ามาก
      ถ้าสรุปสั้น ๆ ปัญหาคือ สถาปัตยกรรม หรือพูดให้เฉพาะกว่านั้นคือความไม่สอดคล้องกันระหว่างภาษาและสถาปัตยกรรม รูปแบบสถาปัตยกรรมแบบ call/return ที่ภาษาการเขียนโปรแกรม “อเนกประสงค์” ชักนำให้ใช้ ไม่เข้ากับสถาปัตยกรรมที่ส่วนติดต่อผู้ใช้ต้องการ และจริง ๆ แล้วขัดแย้งกันด้วย
      ฉันก็เคยเขียนเรื่องนี้ไว้ใน “Can Programmers Escape the Gentle Tyranny of call/return?”
      แนวทางปัจจุบันคือสร้าง Objective-Smalltalk[4] ขึ้นมาก่อน ในฐานะภาษาการเขียนโปรแกรมที่ทำให้การแสดงรูปแบบสถาปัตยกรรมทางเลือกเป็นเรื่องง่าย
      ตอนนี้ฉันกำลังใช้มันสร้างเฟรมเวิร์ก UI ชื่อ interscript และรวม HTMXNative กับองค์ประกอบเสริมอีกหลายอย่างไว้ด้วย
      ดูเหมือนว่ามันจะไปได้ค่อนข้างดี
      [1] ตัวอย่างเช่น “Languages for developing user interfaces” ของ Myers และคณะ https://api.taylorfrancis.com/content/books/mono/download?id...
      [2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
      [3] https://2020.programming-conference.org/details/salon-2020-p...
      [4] https://objective.st
    • ในฐานะวิศวกร เรามักมองทุกปัญหาแล้วคิดว่า “มีวิธีแก้ที่สมบูรณ์แบบอยู่แล้ว แค่เรายังหาไม่เจอ”
      แต่พอเวลาผ่านไปก็เริ่มยอมรับคำตอบที่อุดมคติน้อยลงได้ บางทีอาจไม่มีวิธีแก้แบบนั้นอยู่เลยก็ได้ พื้นที่ของปัญหามันซับซ้อนเกินไป จนอาจไม่มีวิธีแก้ทั่วไปที่มนุษย์ใช้งานได้จริงและครอบคลุมได้ทุกแบบ และถ้ามีสักสาขาที่น่าจะเป็นแบบนั้น ก็คงเป็นเรื่อง UI นี่แหละ

  • ใช่แล้ว React คืออินเทอร์เฟซที่เข้าใจง่ายที่สุดอย่างห่างชั้น ซึ่งผสานสไตล์แบบประกาศเจตนาและแบบคำสั่งได้สำเร็จ เมื่อมองรวมทุกเฟรมเวิร์ก UI ในทุกภาษา ฉันคิดว่าไม่มีอะไรเข้าใกล้ JSX ได้เลย

    • Flutter, SwiftUI, Jetpack Compose และแพลตฟอร์มอื่นอีกมาก ต่างก็ทำ React ขึ้นมาในแบบของตัวเองในฐานะเฟรมเวิร์ก UI
    • ถ้ามันเข้าใจง่ายขนาดนั้น ฉันก็ไม่รู้ว่าทำไมแอป React แทบทุกตัวถึงมี บั๊กด้านประสิทธิภาพ

  • ฉันชอบ Svelte มาก และใช้ SvelteKit กับแอปที่ซับซ้อนกว่า
    รู้สึกว่ามันเป็นการพัฒนาที่ดีกว่ามากในหลายกรณีที่เมื่อก่อนฉันคงเลือก React
    Svelte ดูเหมือนจะเรียนรู้ง่ายกว่ามากสำหรับคนที่รู้พื้นฐานของการพัฒนาเว็บ, HTML, CSS และ JavaScript อยู่แล้ว แต่ช่วงนี้ฉันเห็นคนเริ่มเรียนพัฒนาเว็บจาก React บ่อยมาก ซึ่งรู้สึกว่าลำดับมันกลับด้านไปหน่อย
    ส่วนตัวฉันทำแอปมือถือด้วย SvelteKit + Capacitor และเขียนการตั้งค่าไว้ที่นี่: https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor
    สำหรับหน้า landing page แบบง่าย ๆ ฉันชอบ Astro มากกว่า

    • ฉันเองก็หยิบ Svelte + SvelteKit ก่อนเสมอ การใช้ Kit กับแอปง่าย ๆ อาจจะเกินความจำเป็น แต่ถ้ามันซับซ้อนขึ้นมาโดยไม่คาดคิดก็จะดีที่มีมันอยู่
      เห็นด้วยว่าทุกวันนี้คนเริ่มต้นพัฒนาเว็บด้วย React มันให้ความรู้สึกกลับด้าน Svelte จัดการ HTML เหมือนเป็นภาษาแม่ จึงช่วยกันปัญหานี้ได้ดี ถ้าเริ่มเรียนพัฒนาเว็บด้วย Svelte(Kit) ก็น่าจะได้เรียนรู้ พื้นฐาน มากกว่าการเริ่มด้วย React
    • สำหรับฉันคอมโบ Svelte + Astro เหมาะที่สุด ดีมากสำหรับเว็บเอกสารและหน้าที่มีปฏิสัมพันธ์แบบเลือกใส่ได้

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

  • หนึ่งในงานนำเสนอที่ผมชอบมากจริง ๆ คือ https://www.youtube.com/watch?v=h9SDuTSy7ps จากประสบการณ์ของผม สถาปัตยกรรมของ React ดีมากจริง ๆ และค่อนข้างเหมาะกับการสร้างแอปพลิเคชันขนาดใหญ่
    แต่น่าเสียดายที่ปัญหาใหญ่ที่สุดของ React คือมันบังคับให้คุณต้องเข้าไปอยู่ใน ecosystem ของ JS/TS สำหรับผม JavaScript/TypeScript ไม่ใช่ระบบที่อยากจัดการโดยตรงอย่างไม่ต้องสงสัย แต่ใกล้เคียงกับเป้าหมายของการคอมไพล์มากกว่า
    ผมพอใจกับ Elm มาก ชุมชนเล็กมากจริง ๆ และบางครั้งก็ต้องสร้างไลบรารีเอง TEA อาจรู้สึกไม่เป็นธรรมชาติบ้างเป็นบางครั้งถ้ามาจาก React แต่ผมตื่นเต้นเสมอเวลาทำงานกับ Elm เพราะไม่ต้องกังวลกับสถานะที่แฝงอยู่และคาดไม่ถึงแบบ useEffect
    ยิ่งไปกว่านั้น Claude ดูเหมือนจะรับมือกับ Elm ได้ดีกว่า React อย่างน้อยก็ใน codebase ใหญ่ ๆ ที่น่ากลัว

    • จากประสบการณ์ของผม Elm แทบจะตายไปแล้ว ใช้ React กับ TypeScript ที่ยังมีไลบรารีใช้งานได้ต่อเนื่องน่าจะดีกว่า ก็เคยมีความพยายามที่จะทำให้ TypeScript คอมไพล์เป็นเนทีฟได้เหมือนกัน
    • ผมชอบ TEA แต่ยังไม่แน่ใจว่ามันขยายไปอย่างไรในแอปที่มีคอมโพเนนต์ใช้ซ้ำหรือหน้าที่ซับซ้อนพอสมควร เลยสงสัยว่ามีแนวทางที่เป็นที่ยอมรับในการจัดการเรื่องนี้ไหม
      สถานะดูเหมือนเป็นของต้องห้ามใหญ่ ๆ เลย เลยรู้สึกเหมือนมีความขัดแย้งกันนิดหน่อย ผมก็เลยสงสัยว่าสุดท้ายแล้วแอป Elm ทุกตัวหมายความว่าจะกลายเป็นแอป React + Redux แบบ global ทั้งก้อนแต่ไม่มี side effect หรือเปล่า อยากรู้รายละเอียดมากขึ้นว่าอะไรทำให้ Elm สนุก และปกติทำงานกันอย่างไร ลิงก์ก็ยินดี