ชุมชนนักพัฒนาเว็บกำลังมีส่วนร่วมในการอภิปรายอย่างเข้มข้นเกี่ยวกับว่าฟีเจอร์ CSS สมัยใหม่อย่าง View Transitions API สามารถขจัดความจำเป็นในการใช้ Single-Page Applications (SPAs) ได้หรือไม่ การถกเถียงนี้เกิดขึ้นจากบทความล่าสุดที่อ้างว่าความสามารถดั้งเดิมของเบราว์เซอร์ทำให้ client-side routing ล้าสมัยไปแล้ว แต่นักพัฒนากำลังโต้แย้งด้วยมุมมองที่ละเอียดลึกซึ้งเกี่ยวกับเมื่อใด SPAs ยังคงมีความจำเป็น
การสนทนานี้เผยให้เห็นความแตกแยกพื้นฐานในวิธีที่นักพัฒนามองจุดประสงค์และคุณค่าของ SPAs ในการพัฒนาเว็บสมัยใหม่
ฟีเจอร์ CSS สมัยใหม่สำหรับการเปลี่ยนหน้า:
- View Transitions API: ช่วยให้สามารถสร้างการเปลี่ยนหน้าแบบ native และ declarative ระหว่างเอกสารโดยไม่ต้องใช้ JavaScript
- Speculation Rules: อนุญาตให้เบราว์เซอร์โหลดล่วงหน้าหรือเรนเดอร์หน้าเว็บตามพฤติกรรมของผู้ใช้ (การวางเมาส์หรือแตะลิงก์)
- Back/Forward Cache (bfcache): จับภาพหน้าเว็บทั้งหมดเพื่อการกู้คืนแบบทันทีระหว่างการนำทาง
- Cross-page fade transitions: สามารถทำได้ด้วย CSS เพียงอย่างเดียว ไม่จำเป็นต้องใช้ client-side routing
- Shared element transitions: สร้างแอนิเมชันของ element ระหว่างหน้าต่างๆ โดยใช้คุณสมบัติ CSS
view-transition-name
จุดประสงค์ที่แท้จริงของ SPAs เกินกว่าการเปลี่ยนผ่านที่ราบรื่น
นักพัฒนาหลายคนโต้แย้งว่าบทความต้นฉบับเข้าใจผิดเกี่ยวกับเหตุผลที่ SPAs มีอยู่ตั้งแต่แรก ชุมชนเน้นย้ำว่า SPAs ไม่ได้ถูกสร้างขึ้นมาเพื่อการเปลี่ยนผ่านหน้าเว็บที่ฉูดฉาด แต่เพื่อแก้ปัญหาพื้นฐานที่สำคัญกว่าเกี่ยวกับการจัดการสถานะของแอปพลิเคชันและประสบการณ์ผู้ใช้
ข้อมูลเชิงลึกที่สำคัญจากการอภิปรายมุ่งเน้นไปที่แอปพลิเคชันที่ใช้เซสชันหนักซึ่งผู้ใช้ใช้เวลานานในการโต้ตอบกับอินเทอร์เฟซที่ซับซ้อน ลองนึกถึงแอปพลิเคชันอย่าง Gmail , Slack หรือเครื่องมือการทำงานร่วมกันที่การรักษาสถานะฝั่งไคลเอนต์และการลดคำขอเซิร์ฟเวอร์กลายเป็นสิ่งสำคัญสำหรับประสิทธิภาพ แอปพลิเคชันเหล่านี้ได้ประโยชน์จากการโหลดโค้ดบันเดิลขนาดใหญ่ครั้งเดียว จากนั้นจึงทำงานด้วยการรับส่งข้อมูลเครือข่ายที่น้อยที่สุดสำหรับการโต้ตอบครั้งต่อไป
การถกเถียงยังเน้นย้ำว่า SPAs เป็นเลิศในสถานการณ์ที่มีสภาพเครือข่ายที่ไม่ดี สำหรับผู้ใช้ที่มีการเชื่อมต่อไม่เสถียรหรือเครือข่ายที่มีความล่าช้าสูง การดาวน์โหลดส่วนหน้าทั้งหมดครั้งเดียวและเก็บไว้ในเครื่องสามารถให้ประสบการณ์ที่ดีกว่าการดึงหน้าเว็บที่เรนเดอร์จากเซิร์ฟเวอร์ซ้ำๆ
การเปรียบเทียบประสิทธิภาพ SPA กับ MPA:
- ข้อดีของ SPA: โหลด code bundle เดียว, logic ฝั่ง client ถูก cache ไว้, การร้องขอข้อมูลผ่านเครือข่ายน้อยที่สุด, ความสามารถในการทำงาน offline ที่ดีกว่า
- ข้อดีของ MPA: การโหลดหน้าเว็บครั้งแรกเร็วกว่า, SEO ที่ดีกว่า, สถาปัตยกรรมที่เรียบง่าย, การปรับปรุงประสิทธิภาพแบบ native ของเบราว์เซอร์
- ข้อเสียของ SPA: ขนาด bundle เริ่มต้นใหญ่ (มักจะเป็น JavaScript หลายเมกะไบต์), การจัดการ state ที่ซับซ้อน, overhead จากการ hydration
- ข้อเสียของ MPA: การร้องขอข้อมูลจาก server หลายครั้งสำหรับการนำทาง, layout shifts ที่อาจเกิดขึ้น, การ rendering แบบ hybrid ที่ซับซ้อนกว่า
การแลกเปลี่ยนความซับซ้อนในการพัฒนาสมัยใหม่
สมาชิกในชุมชนชี้ให้เห็นว่าภูมิทัศน์ปัจจุบันได้เปลี่ยนไปสู่ Multi-Page Applications (MPAs) มากกว่า SPAs เฟรมเวิร์กอย่าง Next.js และ Nuxt ได้กลายเป็นตัวเลือกเริ่มต้นสำหรับโปรเจกต์ใหม่ ซึ่งแสดงถึงการเคลื่อนไหวกลับไปสู่การเรนเดอร์ฝั่งเซิร์ฟเวอร์พร้อมการปรับปรุงฝั่งไคลเอนต์แบบเลือกสรร
อย่างไรก็ตาม การเปลี่ยนแปลงนี้มาพร้อมกับความท้าทายด้านความซับซ้อนของตัวเอง นักพัฒนาสังเกตว่าการใช้สถาปัตยกรรม MPA ที่เหมาะสมกับเฟรมเวิร์กสมัยใหม่อาจยากกว่าการสร้าง SPAs แบบดั้งเดิมอย่างมาก ความจำเป็นในการจัดการขอบเขตเซิร์ฟเวอร์-ไคลเอนต์อย่างระมัดระวังและจัดการสถานการณ์การเรนเดอร์แบบไฮบริดเพิ่มชั้นของความซับซ้อนที่หลายทีมต้องดิ้นรนกับมัน
การทำ MPA นั้นยากกว่าการทำ SPA อย่างเคร่งครัด ยากกว่ามากมาย คุณต้องสังเกตความแตกต่างระหว่างเซิร์ฟเวอร์/ไคลเอนต์อย่างใกล้ชิดมากขึ้น เนื่องจากหน้าเดียวกันอาจถูกแบ่งครึ่งในแง่ของการเรนเดอร์เซิร์ฟเวอร์/ไคลเอนต์
สถาปัตยกรรมคอมโพเนนต์และประสบการณ์นักพัฒนา
นอกเหนือจากการพิจารณาด้านประสิทธิภาพ การอภิปรายเผยให้เห็นว่านักพัฒนาหลายคนให้ความสำคัญกับ SPAs เพราะสถาปัตยกรรมแบบคอมโพเนนต์และประสบการณ์การพัฒนา ความสามารถในการสร้างคอมโพเนนต์ที่นำกลับมาใช้ได้ แยกออกมาเป็นส่วนๆ พร้อมสไตล์ที่มีขอบเขตจำกัดได้กลายเป็นรากฐานสำคัญของเวิร์กโฟลว์การพัฒนาเว็บสมัยใหม่
แง่มุมนี้ของการถกเถียงสัมผัสกับคำถามที่กว้างขึ้นเกี่ยวกับผลิตภาพของนักพัฒนาและการจัดระเบียบโค้ด แม้ว่า native web components จะมีอยู่เป็นทางเลือก แต่ระบบนิเวศและเครื่องมือรอบๆ คอมโพเนนต์ที่ใช้เฟรมเวิร์กยังคงมีความสุกงอมและได้รับการยอมรับอย่างกว้างขวางมากกว่า
แนวทางการใช้งาน:
- เลือก SPA สำหรับ: แอปพลิเคชันแบบโต้ตอบ ( Gmail , Slack , เครื่องมือทำงานร่วมกัน) แอปที่ใช้ session มาก สภาพเครือข่ายที่ไม่ดี การจัดการ state ฝั่งไคลเอนต์ที่ซับซ้อน
- เลือก MPA สำหรับ: เว็บไซต์แบบคงที่ หน้าการตลาด บล็อก เว็บไซต์ที่เน้นเนื้อหา แอปพลิเคชันที่ SEO มีความสำคัญ
- แนวทางแบบผสม: การเรนเดอร์ฝั่งเซิร์ฟเวอร์พร้อมการปรับปรุงฝั่งไคลเอนต์แบบเลือกสรรโดยใช้เฟรมเวิร์กสมัยใหม่อย่าง Next.js หรือ Nuxt
การค้นหาเครื่องมือที่เหมาะสมสำหรับงาน
ฉันทามติของชุมชนดูเหมือนจะเคลื่อนไปสู่แนวทางที่ละเอียดลึกซึ้งมากขึ้น: การเลือกสถาปัตยกรรมที่เหมาะสมตามกรณีการใช้งานเฉพาะแทนที่จะใช้โซลูชันเดียวเป็นค่าเริ่มต้น เว็บไซต์แบบคงที่ หน้าการตลาด และไซต์ที่เน้นเนื้อหาได้ประโยชน์จากการเรนเดอร์ฝั่งเซิร์ฟเวอร์พร้อมการปรับปรุง CSS ในขณะเดียวกัน แอปพลิเคชันแบบโต้ตอบที่มีการจัดการสถานะที่ซับซ้อน ฟีเจอร์เรียลไทม์ หรือความสามารถออฟไลน์ยังคงสนับสนุนแนวทาง SPA
การอภิปรายยังเน้นย้ำความสำคัญของการเข้าใจความแตกต่างระหว่างเว็บไซต์และเว็บแอปพลิเคชัน นักพัฒนาหลายคนโต้แย้งว่าแนวโน้มของอุตสาหกรรมในการปฏิบัติต่อโปรเจกต์เว็บทั้งหมดเป็นแอปพลิเคชันได้นำไปสู่การสร้างไซต์ง่ายๆ ให้ซับซ้อนเกินจำเป็นด้วยความซับซ้อนที่ไม่จำเป็น
เมื่อความสามารถของเบราว์เซอร์ยังคงพัฒนาด้วยฟีเจอร์อย่าง View Transitions API และ Speculation Rules ภูมิทัศน์น่าจะเห็นการปรับปรุงเพิ่มเติม ข้อมูลเชิงลึกที่สำคัญจากการถกเถียงของชุมชนนี้คือทั้งสองแนวทางมีที่ของตัวเอง และการพัฒนาเว็บที่ประสบความสำเร็จต้องการการจับคู่สถาปัตยกรรมกับข้อกำหนดและข้อจำกัดเฉพาะของแต่ละโปรเจกต์