สิ่งที่ควรรู้ก่อนเลือกใช้ Next.js

• บทความที่พูดถึงประเด็นเรื่องความเปิดกว้างและธรรมาภิบาลของ Next.js: การไม่มี adapter, การขาดการรองรับ serverless อย่างเป็นทางการ, การมี code path ที่ใช้ได้เฉพาะกับ Vercel, และท่าทีของ Vercel ในการรับมือกับเหตุการณ์ด้านความปลอดภัย
• การเลือกเทคโนโลยีสแตกเป็นการตัดสินใจสำคัญที่ส่งผลระยะยาวต่อความเร็วในการพัฒนา คุณภาพของโปรเจกต์ และโครงสร้างทีม
• ซอฟต์แวร์โอเพนซอร์สให้ผู้ใช้มีอิสระในการขยายและแก้ไขโค้ด พร้อมข้อดีในการหลีกเลี่ยง vendor lock-in
• แม้ Next.js จะเปิดให้ใช้งานแบบโอเพนซอร์ส แต่ก็ยังผูกพันอย่างใกล้ชิดกับโครงสร้างพื้นฐานของ Vercel ผู้สร้างมัน
• การที่บริษัทหารายได้จากโอเพนซอร์สที่ตนสร้างขึ้นไม่ใช่ปัญหา แต่ขอบเขตระหว่างโอเพนซอร์สกับบริษัทต้องชัดเจน จึงจะเป็นโมเดลที่ยั่งยืนได้

ภูมิหลังและผลประโยชน์ทับซ้อนของผู้เขียน

• ผู้เขียนทำงานที่ Netlify มานานกว่า 4 ปี และ Netlify เป็นคู่แข่งของ Vercel
• จากการสร้างโครงสร้างพื้นฐานและเครื่องมือด้วยตนเองเพื่อรองรับความสามารถทั้งหมดของ Next.js บน Netlify ทำให้ผู้เขียนเข้าใจโครงสร้างภายในของ Next.js อย่างลึกซึ้ง
• แม้จะเลี่ยงการตั้งคำถามต่อสาธารณะมาเป็นเวลานาน แต่ล่าสุดผู้เขียนมองว่าวิธีที่ Vercel รับมือกับประเด็นความปลอดภัยได้สร้างผลเสียต่อชุมชน จึงตัดสินใจเขียนบทความนี้

# ปัญหาเรื่องความเปิดกว้างและธรรมาภิบาลของ Next.js

Fact #1: การไม่มี adapter

• เฟรมเวิร์กสมัยใหม่ส่วนใหญ่สามารถตั้งค่าได้อย่างยืดหยุ่นผ่าน adapter ตามเป้าหมายการดีพลอย
• Next.js ไม่รองรับ adapter อย่างเป็นทางการ และรูปแบบ output ก็เป็นโครงสร้างเฉพาะทางแบบปิดที่ใช้บน Vercel เท่านั้น
• Vercel สร้าง Build Output API ขึ้นมาแล้ว แต่ Next.js ก็ยังไม่รองรับสิ่งนี้
• ผลลัพธ์คือผู้ให้บริการรายอื่นนอกจาก Vercel ต้องพัฒนาบน API ที่ไม่มีเอกสารรองรับ ซึ่งเปราะบางต่อการเปลี่ยนแปลงที่ไม่คาดคิด
• Cloudflare และ Netlify กำลังร่วมมือกันพัฒนา adapter สำหรับ Next.js ผ่าน OpenNext และ Vercel ก็เริ่มเข้าร่วมแล้วเช่นกัน แต่ยังไม่มีไทม์ไลน์ที่ชัดเจน

Fact #2: การรองรับ serverless อย่างเป็นทางการที่ยังไม่เพียงพอ

• วิธี self-hosting อย่างเป็นทางการของ Next.js อิงกับเซิร์ฟเวอร์ที่รันต่อเนื่องยาวนาน ทำให้ยากต่อการขยายระบบอย่างยืดหยุ่นและลดต้นทุนในสภาพแวดล้อม production จริง
• ในอดีตเคยมีโหมด serverless แต่ถูกลบออกในเดือนตุลาคม 2022 โดยแทบไม่มีคำอธิบาย
• เอกสารอย่างเป็นทางการของ React ระบุว่าสามารถดีพลอยแบบ serverless ได้ แต่ไม่มีเอกสารทางการที่อธิบายวิธีทำจริง
• ผู้ให้บริการโฮสติ้งที่ต้องการสภาพแวดล้อม serverless จึงต้อง reverse engineer Next.js และทำระบบของตนเองขึ้นมา

Fact #3: การมี code path ที่ใช้ได้เฉพาะกับ Vercel

• Next.js มี code path ภายในที่ไม่เปิดเผยและทำงานได้เฉพาะเมื่อดีพลอยบน Vercel เท่านั้น (เช่น minimal mode)
• ผ่านโหมดนี้ Vercel สามารถเพิ่มประสิทธิภาพได้ เช่น การรัน middleware ที่ edge
• middleware คือความสามารถในการรันตรรกะได้อย่างรวดเร็วในเส้นทางก่อนถึง cache แต่ฟีเจอร์นี้ใช้งานได้เฉพาะบน Vercel
• Netlify ต้องตั้งทีมวิศวกรเฉพาะทางและพัฒนาระบบขึ้นเองเพื่อรองรับฟีเจอร์นี้ ซึ่งเป็นระดับทรัพยากรที่ผู้ให้บริการรายเล็กไม่สามารถทำได้
• ความจริงที่ว่า Vercel เป็นแพลตฟอร์มเดียวที่ให้ความสามารถทั้งหมดของ Next.js ได้อย่างเป็นทางการ ขัดกับปรัชญาโอเพนซอร์สของเฟรมเวิร์ก

เหตุการณ์ด้านความปลอดภัยและการตอบสนองของ Vercel

• วันที่ 21 มีนาคม 2025 มีการเปิดเผยช่องโหว่ความปลอดภัยร้ายแรงใน Next.js (CVE คะแนน 9.1) ที่ทำให้สามารถ bypass การยืนยันตัวตนได้
• ช่องโหว่นี้เกิดจากการใส่ header บางตัวในคำขอ ซึ่งทำให้ middleware ถูกปิดฤทธิ์และเข้าถึงทรัพยากรที่ควรได้รับการปกป้องได้
• มีการรายงานช่องโหว่นี้ตั้งแต่วันที่ 27 กุมภาพันธ์ แต่ Vercel เพิ่งเริ่มตรวจสอบในวันที่ 14 มีนาคม
• แม้หลังจากรับรู้ปัญหาแล้วจะปล่อยแพตช์ได้รวดเร็ว แต่กว่าจะแจ้งผู้ให้บริการรายอื่นอย่าง Netlify ก็ใช้เวลาถึง 8 วัน
• ในบทความบล็อกฉบับแรกมีการอธิบายในลักษณะที่ว่าไฟร์วอลล์ของ Vercel ได้ปกป้องลูกค้าไว้ แต่ความเป็นจริงไม่เป็นเช่นนั้น
• ส่งผลให้ผู้ให้บริการและนักพัฒนาหลายรายตอบสนองบนข้อมูลที่คลาดเคลื่อนหรือเกิดความสับสน และเป็นไปได้ว่ายังมีเว็บไซต์จำนวนมากที่ยังคงมีช่องโหว่อยู่

ความเป็นเจ้าของ Next.js ของ Vercel และความรับผิดชอบแบบโอเพนซอร์ส

• ปฏิเสธไม่ได้ว่า Vercel เป็นเจ้าของ Next.js และการสร้างรายได้จากมันก็เป็นเรื่องสมเหตุสมผล
• แต่เมื่อเปิดให้ใช้งานแบบโอเพนซอร์ส ผู้ให้บริการรายอื่นก็ควรใช้งานได้อย่างเท่าเทียมกัน และในจุดนี้ Vercel ยังทำได้ไม่ถึงความคาดหวัง
• Redis, Grafana, WordPress และโครงการอื่น ๆ ต่างก็เดินหน้าทั้งบริการเชิงพาณิชย์และโอเพนซอร์สไปพร้อมกัน โดยยังคงความเปิดกว้างและการทำงานร่วมกันได้

บทสรุป

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

[GN⁺]

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

• ฉันเคยใช้ next.js แต่พอเปลี่ยนจาก page router ไปเป็น app router ก็เลิกทำโปรเจ็กต์นั้นไปเลย ประสบการณ์กับ app router แย่มาก และหลังจากนั้นก็ไม่อยากใช้ next.js อีก
  • Vercel ทำเหมือนเป็นโอเพนซอร์ส แต่กำลังสร้างกำแพงเพื่อกักผู้ใช้ให้อยู่บนแพลตฟอร์มโฮสติ้งของตัวเอง
• ฉันรู้สึกกังวลกับ Vercel อยู่เสมอเล็กน้อย ตอนพยายาม self-host Next.js บน VPS ก็เจอกับกับดักเล็ก ๆ ที่พวกเขาวางไว้
  • วิธีที่พวกเขาจัดการช่องโหว่นี้ยิ่งทำให้ฉันกังวลมากขึ้น
  • คำอธิบายช่วงแรกที่อ้างว่าไฟร์วอลล์ของ Vercel "ปกป้องลูกค้าเชิงรุก" ทิ้งความรู้สึกที่ไม่ดีไว้
  • มีความล่าช้าในการแจ้งแพลตฟอร์มอื่น ซึ่งแสดงให้เห็นว่า Vercel มีแรงจูงใจน้อยที่จะป้องกันไม่ให้มีการนำช่องโหว่เข้ามาใน Next.js
• ฉันเตือนทุกคนให้หลีกเลี่ยง next.js V0 อาจทำให้การยอมรับเพิ่มขึ้นอย่างมาก
  • นักพัฒนาใหม่จำนวนมากไม่อยากคิดเรื่อง deployment และ system administration
  • ถ้าคุณรู้แค่ React ข้อดีก็คือได้ใช้ SSR โดยไม่ต้องเรียนมัน
• เหตุผลที่ฉันเลิกใช้ next.js คือในโปรเจ็กต์เล็ก ๆ การเปลี่ยนแปลงใช้เวลา 6-7 วินาทีกว่าจะปรากฏในเบราว์เซอร์
  • ตอนนี้ฉันใช้ React SPA กับ Vite
• ปีที่แล้วเราได้ย้ายจาก Next.js ไป Vike ประสบการณ์นักพัฒนาดีขึ้นมาก
  • ความต้องการส่วนใหญ่ตอบโจทย์ได้ด้วยการ pre-render หน้าเพจ
• ฉันมีความรู้สึกปน ๆ กับ Next.js ด้านหนึ่งมันคือบริษัทที่สร้างเฟรมเวิร์กร่วมกับนักลงทุน
  • เพราะเป็นไลเซนส์ MIT, Netlify หรือบริษัทอื่นสามารถ fork แล้วทำทางเลือกที่ดีกว่าได้
  • ถ้าคุณเป็นนักลงทุนของ Vercel ก็ไม่มีเหตุผลที่จะช่วยคู่แข่งให้เพิ่มความเสี่ยงในการลงทุน
  • Vercel สนับสนุนโอเพนซอร์ส แต่ก็พยายามคงแรงเสียดทานไว้เพื่อให้แพลตฟอร์มโฮสติ้งของตัวเองเป็นตัวเลือกที่ดีที่สุด
• ฉันกำลังอยู่ในกระบวนการเลือก React stack สำหรับบริษัทที่ฉันทำงานอยู่ และนึกไม่ออกเลยว่าทำไมถึงควรเลือก Next.js แทนทางเลือกอื่น
  • ถ้าต้องการ SSR, Remix หรือ React Router v7, TanStack เป็นตัวเลือกที่สมเหตุสมผลกว่า
• ฉันไม่มั่นใจว่าแนวทาง serverless เป็นค่าเริ่มต้นที่ดี มันเพิ่มความซับซ้อนโดยไม่จำเป็น
  • ฉันไม่ชอบใช้ JavaScript ในฝั่งแบ็กเอนด์
  • การโฟกัสกับ server components และ Next.js ทำให้ฉันรู้สึกเหมือนเป็น tunnel vision
  • มีความเป็นไปได้สูงว่าแนวทาง serverless เป็นสาเหตุของการสื่อสารแบบมีสิทธิพิเศษผ่าน HTTP headers
• มันมีเวลา build สำหรับการพัฒนาที่แย่มากที่สุด และมีคำบ่นจำนวนมากมาหลายปีแล้วแต่ก็ยังไม่ถูกแก้ไข
• Vercel และ NextJS ไม่ควรมีอยู่
  • ตอนลองใช้ Next ครั้งหนึ่ง ฉันเจอ hydration errors จำนวนมากใน production
  • เฟรมเวิร์กนี้ทำให้ทุกอย่างซับซ้อนขึ้นเพื่อแลกกับผลประโยชน์ที่อาจได้จากการเรนเดอร์บนเซิร์ฟเวอร์
  • ทั้งเฟรมเวิร์กเหมือนถูกสร้างขึ้นมาเป็นฉากหน้าที่ดีเพื่อขายบริการคลาวด์ราคาแพงของพวกเขา

[ahwjdekf]

ผู้เขียนสังกัด Netlify และก็พูดเองว่าเป็นคู่แข่งโดยตรงกับ Vercel แบบนี้ดูจะขาดความเป็นกลางไปหน่อยนะ

[preserde]

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

[alpharoom]

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