นักพัฒนา Next.js แสดงความไม่พอใจที่เพิ่มขึ้นต่อความซับซ้อนของเฟรมเวิร์กและการผูกมัดกับผู้ให้บริการ

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

ปัญหาใหญ่จาก Middleware และการบันทึกล็อก

ปัญหาหลักที่จุดประกายการสนทนานี้มีจุดศูนย์กลางอยู่ที่ middleware ของ Next.js และการบันทึกล็อกในโปรดักชัน ไม่เหมือนกับเฟรมเวิร์กเว็บแบบดั้งเดิมที่การตั้งค่าการบันทึกล็อกเป็นเรื่องง่าย Next.js นำเสนอความท้าทายที่เป็นเอกลักษณ์เนื่องจากโมเดลการทำงานที่ซับซ้อน นักพัฒนารายงานว่าใช้เวลาหลายชั่วโมงในการพยายามใช้งานฟังก์ชันการบันทึกล็อกพื้นฐานที่ทำงานได้ในสภาพแวดล้อมรันไทม์ที่แตกต่างกัน - edge functions, server-side rendering และโค้ดฝั่งไคลเอนต์

ปัญหานี้เกิดจาก Next.js ที่รันโค้ดในหลายบริบทพร้อมกัน โค้ดบางส่วนทำงานบน edge servers บางส่วนบนเซิร์ฟเวอร์ Node.js แบบดั้งเดิม และบางส่วนในเบราว์เซอร์ สิ่งนี้สร้างความสับสนเกี่ยวกับว่าล็อกปรากฏที่ไหนจริงๆ และจะรักษาการบันทึกล็อกที่สอดคล้องกันตลอดวงจรชีวิตของแอปพลิเคชันได้อย่างไร

จุดอ่อนที่พบบ่อยใน Next.js:

• ข้อจำกัดของ Middleware: ต้องใช้ไฟล์ middleware เดียว การเชื่อมต่อแบบซับซ้อน
• ปัญหาการบันทึก Log: พฤติกรรมไม่สม่ำเสมอระหว่างสภาพแวดล้อม edge/server/client
• ความสับสนเรื่อง Runtime: บริบทการทำงานของโค้ดไม่ชัดเจน (edge vs server vs client)
• การผูกมัดกับ Vercel: ฟีเจอร์ถูกปรับให้เหมาะกับการโฮสต์บน Vercel ทำให้เกิดปัญหาในที่อื่น
• ช่องว่างในเอกสาร: ขาดรายละเอียดเกี่ยวกับบริบทการทำงานและข้อควรระวัง

การถกเถียงเรื่องการผูกมัดกับ Vercel

ส่วนสำคัญของการสนทนาในชุมชนมุ่งเน้นไปที่ข้อกล่าวหาว่า Next.js ได้รับการออกแบบมาโดยเจตนาเพื่อผลักดันนักพัฒนาไปสู่บริการโฮสติ้งแบบเสียเงินของ Vercel นักพัฒนาหลายคนรายงานว่าฟีเจอร์ต่างๆ ทำงานได้อย่างราบรื่นบน Vercel แต่กลับมีปัญหาเมื่อนำไปใช้งานที่อื่น สิ่งนี้นำไปสู่ข้อกล่าวหาว่าความซับซ้อนของเฟรมเวิร์กไม่ใช่เรื่องบังเอิญแต่เป็นกลยุทธ์ทางธุรกิจ

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

นักพัฒนาหลายคนแบ่งปันเรื่องราวของการรับช่วงโปรเจ็กต์ Next.js ที่ผูกมัดแน่นหนากับโครงสร้างพื้นฐานของ Vercel จนการย้ายไปยังผู้ให้บริการโฮสติ้งอื่นกลายเป็นเรื่องเกือบเป็นไปไม่ได้ บางครั้งต้องเขียนใหม่ทั้งหมด

การเปลี่ยนแปลงที่ทำลายและความไม่เสถียรของ API

ชุมชนได้แสดงความไม่พอใจต่อรอบการปล่อยเวอร์ชันที่รวดเร็วของ Next.js และการเปลี่ยนแปลงที่ทำลายความเข้ากันได้ที่เกิดขึ้นบ่อย ด้วยเวอร์ชัน 15 ที่เพิ่งปล่อยออกมา นักพัฒนาสังเกตว่าเฟรมเวิร์กได้แนะนำเวอร์ชันหลัก 15 เวอร์ชันใน 8 ปี โดยแต่ละเวอร์ชันอาจมีการเปลี่ยนแปลงที่ไม่เข้ากันได้กับเวอร์ชันก่อนหน้า สิ่งนี้สร้างภาระการบำรุงรักษาสำหรับโปรเจ็กต์ระยะยาวและทำให้ทีมงานยากที่จะรักษาแอปพลิเคชันให้ทันสมัย

การเปลี่ยนผ่านจาก Pages Router ไปสู่ App Router เป็นเรื่องที่ถกเถียงกันเป็นพิเศษ นักพัฒนาหลายคนพบว่า Pages Router เข้าใจง่ายและตรงไปตรงมา แต่ App Router ใหม่แนะนำความซับซ้อนเพิ่มเติมที่บางคนโต้แย้งว่าไม่จำเป็นสำหรับแอปพลิเคชันส่วนใหญ่

ประวัติเวอร์ชันของ Next.js:

• มีการปล่อยเวอร์ชันหลัก 15 เวอร์ชันในระยะเวลา 8 ปี (2017-2025)
• แต่ละเวอร์ชันหลักอาจมีการเปลี่ยนแปลงที่ทำให้เกิดปัญหาความเข้ากันได้
• เวอร์ชัน 15.5 ได้เพิ่มการรองรับ middleware ของ Node.js เพื่อแก้ไขปัญหาบางประการ

ทางเลือกอื่นที่ได้รับความสนใจ

เมื่อความไม่พอใจเพิ่มขึ้น นักพัฒนากำลังสำรวจทางเลือกอื่นมากขึ้น React Router v7 (เดิมชื่อ Remix) กำลังได้รับความนิยมสำหรับแนวทางที่เรียบง่ายกว่าต่อ server-side rendering โดยไม่มีชั้นนามธรรมที่ทำให้ Next.js ซับซ้อน SvelteKit ก็ถูกกล่าวถึงบ่อยครั้งเป็นตัวเลือกที่เป็นมิตรกับนักพัฒนามากกว่าพร้อมความสามารถในการโฮสต์เองที่ดีกว่า

นักพัฒนาบางคนกำลังกลับไปใช้แนวทางแบบดั้งเดิมมากขึ้น โดยรวมแอปพลิเคชันส่วนหน้าและส่วนหลังแยกกันโดยใช้เทคโนโลยีที่มั่นคงแล้วอย่าง Django, Rails หรือ Express.js กับแอปพลิเคชัน React แบบหน้าเดียว การแยกนี้ให้ขอบเขตที่ชัดเจนกว่าและการดีบั๊กที่ง่ายกว่าเมื่อเปรียบเทียบกับแนวทางแบบผสมผสานของ Next.js

ทางเลือกอื่นของ Next.js ที่ได้รับความนิยม:

• React Router v7 (เดิมชื่อ Remix): โมเดล request/response ที่เรียบง่ายกว่า
• SvelteKit: ความสามารถในการ self-hosting ที่ดีกว่า ประสบการณ์นักพัฒนาที่สะอาดกว่า
• Astro: การสร้างเว็บไซต์แบบ static พร้อม component islands
• การแยกแบบดั้งเดิม: backend แบบ Django/Rails + frontend แบบ React SPA
• HTMX + Alpine.js: แนวทางใช้ JavaScript น้อยที่สุดสำหรับการปรับปรุง HTML

ความเหนื่อยล้าจากเฟรมเวิร์ก JavaScript ในวงกว้าง

การวิพากษ์วิจารณ์ Next.js นี้สะท้อนแนวโน้มที่กว้างขึ้นของความเหนื่อยล้าจากเฟรมเวิร์ก JavaScript ในชุมชนนักพัฒนา นักพัฒนาที่มีประสบการณ์หลายคนกำลังตั้งคำถามว่าความซับซ้อนที่เฟรมเวิร์กสมัยใหม่แนะนำนั้นสมเหตุสมผลกับประโยชน์ที่ได้รับหรือไม่ บางคนสนับสนุนแนวทางที่เรียบง่ายกว่าโดยใช้ JavaScript, HTML และ CSS แบบดั้งเดิม หรือไลบรารีที่เบาอย่าง HTMX สำหรับการโต้ตอบที่ปรับปรุงแล้ว

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

บทสรุป

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

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

อ้างอิง: Next.js Is Infuriating