คุณไม่จำเป็นต้องใช้ Next.js — เหตุผลที่เราย้ายจาก Next มาสู่ React

• ผลลัพธ์ที่ได้จากการย้ายแดชบอร์ด ComfyDeploy จาก Next.js ไปเป็น React:
  • เวลา build ลดลงจาก 3 นาที → 18 วินาที
  • hot reload ดีขึ้นเป็นต่ำกว่า 200ms
  • สมาชิกในทีมพึงพอใจกันมากขึ้นอย่างชัดเจน
• ตอนแรกเริ่มต้นด้วยแอปพลิเคชันฟูลสแต็กที่ใช้ Next.js ซึ่งทำงานได้ดีด้วย type safety และโค้ดที่สะอาดจาก Drizzle และ Server Actions แต่ก็เกิดปัญหาดังต่อไปนี้:
  • มีผู้ใช้บางรายทำให้เกิดค่าใช้จ่าย API บน Vercel สูงถึง $2,000
  • ความซับซ้อนในการทดสอบ API เพิ่มขึ้น: มีทั้ง Server Actions และ API routes ปะปนกัน
  • เวลา build ช้าและสภาพแวดล้อมการพัฒนาในเครื่องไม่มีประสิทธิภาพ
  • แม้จะแก้ไขเพียงเล็กน้อยก็ทำให้เกิดการ reload SSR ทั้งหมด
• ปัญหา
  • ความซับซ้อนของ Next.js เพิ่มขึ้น: แนวทางแบบ all-in-one (full-stack) ของ Next.js ก่อให้เกิดความซับซ้อนในการพัฒนาเมื่อแอปเติบโตขึ้น
  • แดชบอร์ดของเราส่วนใหญ่ขับเคลื่อนด้วย React และไม่ได้ต้องการความสามารถฝั่งเซิร์ฟเวอร์ของ Next.js
• การเปลี่ยนจาก Next.js ไปเป็น React
  • เปลี่ยนจาก Next.js มาเป็น React โดยใช้ TanStack Router และ Rspack
    • เริ่มต้น development server: ภายใน 2 วินาที
    • เวลา build บน Vercel: 18 วินาที
  • ปรับปรุงการตั้งค่า API, ลบ dependency ที่ไม่จำเป็น, ทำให้โค้ดเรียบง่ายขึ้น และเพิ่มผลิตภาพ
• การเปรียบเทียบประสิทธิภาพ
  • Next.js 15 (ใช้โหมด Turbo)
    • build หน้าแรก: 10.4 วินาที
  • React + TanStack Router + Rspack
    • คำนวณ route: ต่ำกว่า 200ms
    • build bundle เริ่มต้น: 1.67 วินาที
• สิ่งที่ต้องแลก
  • สิ่งที่เสียไป
    • การวางโค้ด frontend และ backend ไว้ใกล้กัน: เมื่อแยก frontend และ backend ออกจากกัน ขอบเขตจึงชัดเจนขึ้น
    • ความสามารถด้าน caching ของ Next.js: เพราะมีข้อมูลที่อัปเดตแบบเรียลไทม์จำนวนมาก จึงแทนที่ด้วย caching แบบกำหนดเอง
    • การ pre-render และการโหลดเริ่มต้น: แทนที่ Static Generation ด้วย UX ที่ดีกว่า — ไม่มีการแสดงปุ่มที่กดไม่ได้อีกต่อไป
    • server components และ actions: แม้จะสูญเสีย “เวทมนตร์” ของ server components ไป แต่ก็ดีขึ้นด้วยการออกแบบ API ที่ตั้งใจมากกว่าเดิม
  • สิ่งที่ได้มา
    • การออกแบบสัญญา API ที่แข็งแรงขึ้น
    • ทำ caching เฉพาะจุดที่จำเป็น
    • ออกแบบ data flow และ state management อย่างรอบคอบ
• บทสรุป
  • Next.js เหมาะกับงานอย่าง landing page และ SEO แต่สำหรับผลิตภัณฑ์ส่วนใหญ่แล้วกลับเพิ่มความซับซ้อนเกินจำเป็น
  • ยังคงใช้ Next.js สำหรับงาน landing page และ SEO
  • เปลี่ยน dashboard ไปเป็น Pure React + TanStack Router + Rspack
  • API รันด้วยเซิร์ฟเวอร์ Python FastAPI บน Google Cloud Run และขยายอัตโนมัติตามความต้องการ
• สิ่งสำคัญคือการ เลือกเครื่องมือให้เหมาะสม และสำหรับเรา Next.js เป็นตัวเลือกที่มากเกินความจำเป็น

[zerocyber]

ตอนที่บริษัทของเรากำลังเตรียมรวมระบบ/ย้ายฝั่งฟรอนต์เอนด์ไปใช้ Next.js ทั้งหมด
พอมาได้อ่านบทความแบบนี้เข้าก็ทำให้คิดหลายอย่างเลย....

[nemorize]

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

[beenzinozino]

"การเลือกใช้เครื่องมือที่เหมาะสมเป็นสิ่งสำคัญ และสำหรับเรา Next.js เป็นตัวเลือกที่เกินความจำเป็น"

ดูเหมือนว่าบรรทัดสุดท้ายจะเป็นประเด็นสำคัญนะครับ

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

[iolothebard]

การต้องการ SEO หมายความว่าเนื้อหาคือหัวใจสำคัญ
แต่เมื่อ UI คอมโพเนนต์(?) และสถานะกลับยึดพื้นที่ของหัวใจสำคัญไป... ก็เลยถือกำเนิดสิ่งมีชีวิตประหลาดอย่าง SSR ISR Hydrate...

[schang124]

เห็นด้วยกับเนื้อหานี้มากครับ
ถ้าไม่ใช่กรณีที่ต้องใช้ SEO ผมจะไม่เลือกใช้ Next.js เด็ดขาด
เหมือนในบทความข้างต้น ถ้าใช้แค่ React จะมีข้อดีหลายอย่าง:

• ไม่มีความซับซ้อนและแพตเทิร์นที่ไม่จำเป็นเฉพาะตัวของ Next.js
  • ทำให้การดูแลรักษาเรียบง่ายขึ้น
• ไม่ต้องแบกรับค่าใช้จ่ายของ SSR ที่ไม่จำเป็น
• มีอิสระในการเลือกไลบรารีที่เป็นส่วนของ FE infra เช่น Router, bundler เป็นต้น

[jhj0517]

ไม่แน่ใจนัก แต่ดูเหมือนว่าเวลา build ต่างกันมากเลยนะ

[bichi]

ดูเหมือนว่ายังไม่รู้ว่า React ช้ากว่าเฟรมเวิร์กอื่นในหลายด้านอยู่ดีนะ

[slowandsnow]

ก็เพราะความเร็วไม่ใช่สิ่งสำคัญไงล่ะ ถ้าความเร็วสำคัญจริง ทุกวันนี้ก็คงไม่มีใครยังใช้ expressjs กันอยู่หรอก ชุมชนและไลบรารีมีมากกว่าแบบท่วมท้น

[devheerim]

ดูเหมือนว่าจะโฟกัสไปที่การย้ายจาก Next มาเป็น React มากกว่านะครับ 555

[bbulbum]

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

[sacru2red]

ส่วนใหญ่ย้ายไปใช้ vite กัน และตอนนี้ก็ยังใช้เฟรมเวิร์กตามความจำเป็นอยู่

[bbulbum]

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

เพราะใน react.dev เขียนไว้แบบนั้นน่ะ~

[kandk]

น่าสนใจนะครับ Next หนักกว่า React ไหมเมื่อเทียบกัน?
ผมเคยแค่ลองเซ็ตอัปโปรเจ็กต์ด้วย Next แต่ตอนนั้นเริ่มสร้างโปรเจ็กต์และพัฒนาได้ง่ายมากครับ

[cichol]

"เรียบง่าย" <= เบื้องหลังสิ่งนี้มีมนตร์(?) ที่ซ่อนอยู่ซึ่งทำให้เกิด trade-off มากมายเพื่อให้บรรลุสิ่งนี้

[beenzinozino]

เห็นด้วยครับ ใต้ Next.js มี dependency จำนวนมหาศาลซ่อนอยู่...

[GN⁺]

ความคิดเห็นจาก Hacker News

• หลายคนโฟกัสมากเกินไปกับการที่ไอเดียของตัวเองจะสเกลไปถึงผู้ใช้ระดับพันล้านคนได้หรือไม่ เลยมีกรณีใช้ Kubernetes ทั้งที่เว็บไซต์มีผู้เข้าชมแค่ 5 คน หรือเห็นนักศึกษาใช้ Next.js ทำเว็บไซต์ที่จริง ๆ เขียนด้วย HTML + CSS แบบง่าย ๆ ก็ได้

• เคยสร้างโปรเจกต์ด้วย Next.js แต่รู้สึกว่าใช้งานซับซ้อน API สำหรับเข้าถึงคุกกี้ระหว่างฝั่งไคลเอนต์กับเซิร์ฟเวอร์ก็ต่างกัน แถมยังต้องเข้าถึงตัวแปรสภาพแวดล้อมผ่าน process.env.NEXT_PUBLIC_* อีก ทำให้งง อยากเขียนโค้ดที่ทำงานได้ทั้งฝั่งไคลเอนต์และเซิร์ฟเวอร์โดยแก้ไขให้น้อยที่สุด แต่ทำไม่ได้ รู้สึกว่าการเรียนรู้และโอเวอร์เฮดไม่คุ้มกับสิ่งที่ Next.js ให้มา

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

• ใช้งานมาตั้งแต่ Next.js v14 ออก และพอใจมาก ใช้ RSCs แล้วทำให้หลายส่วนของแอปยังทำงานได้ดีแม้ปิด JS ฝั่งไคลเอนต์ไว้ มีพลังความเรียบง่ายแบบแอป PHP และยังผสาน type system กับคอมโพเนนต์ฝั่งไคลเอนต์แบบ interactive ที่อิงสถานะเข้าไปใน "ระดับใบ" ของ tree มุมมองได้อย่างลื่นไหล

• ด้วย Rails และ Hotwire ทำให้หลุดพ้นจากความสับสนวุ่นวายใน ecosystem ของ React ได้ มีตัวเลือกมากเกินไปทั้งไลบรารีจัดการสถานะ meta-framework และไลบรารี data fetching ไม่จำเป็นต้องทำให้งานง่าย ๆ อย่างการแสดงข้อมูลจากเซิร์ฟเวอร์บนหน้าเว็บกลายเป็นเรื่องซับซ้อน

• ทำงานอยู่กับ CMS (PayloadCMS) ที่ใช้ NextJS และ NextJS คือเทคโนโลยีที่แย่ที่สุดเท่าที่เคยใช้มา

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

• ใช้ Next.js เพื่อทำ SEO และเพิ่มประสิทธิภาพสำหรับการครอว์ล ถ้าหน้าเว็บไม่จำเป็นต้องให้ถูกครอว์ล เช่น dashboard หลังล็อกอิน ก็ไม่จำเป็นต้องใช้ Next.js และ React แบบล้วนก็น่าจะง่ายกว่า

• แปลกใจที่ Next.js กลายเป็นตัวเลือกเริ่มต้นพื้นฐานไปแล้ว รู้สึกว่าเปลี่ยนไปมากเมื่อเทียบกับ 2~3 ปีก่อน

• กำลังพยายามใช้ Vike มาแทนแอป NextJS และพอใจดี สามารถสร้างในแบบที่ต้องการได้โดยไม่ถูกรบกวน

[aer0700]

แอปที่มีผู้ใช้แค่ 5 คนแต่ใช้ k8s... สุดยอดจริงๆ