Webdev never svelte so good: เมื่อการพัฒนาเว็บลงตัวกว่าที่เคย

ทำไมเราถึงเริ่มนำภาษา Frontend ที่หลายคนมองว่าเป็น “Niche” มาใช้จริงในโปรเจกต์ระดับ Production

React ครองตลาดการพัฒนาเว็บมาเกือบ 10 ปีแล้ว ที่ We Do Dev Work เราได้ทำโปรเจกต์มากมายด้วย React รวมถึง NextJS ซึ่งนำระบบ Server-side มาใช้ก่อนที่ React จะทำเองเสียอีก ต้องยอมรับว่า React นั้นยอดเยี่ยมมากสำหรับการทำ Single Page Applications (SPA)!

แต่โลกของการพัฒนาเว็บนั้นมีอะไรที่มากกว่าแค่ SPA

ความสำคัญของ Server Side Rendering

ข้อบกพร่องของ React เป็นที่รู้กันดีในหมู่ชุมชนนักพัฒนา เพราะนักพัฒนาต้องการวิธีสร้างเว็บไซต์ที่เป็นมิตรต่อ SEO โดยที่ไม่ต้องแบกรับภาระ JavaScript จำนวนมหาศาล

Vercel จึงก้าวเข้ามาพร้อมทางออกและนั่นคือจุดกำเนิดของ NextJS แทนที่จะเรนเดอร์ทุกองค์ประกอบบนฝั่ง Client ตัว NextJS จะรันโค้ด JSX บางส่วนบนเซิร์ฟเวอร์และเรนเดอร์องค์ประกอบจากที่นั่น เมื่อรวมเข้ากับการทำ Caching สิ่งนี้ช่วยให้โหลดหน้าเว็บได้เร็วขึ้น ลดการใช้ทรัพยากรบนฝั่ง Client และได้คะแนน SEO ที่ดีขึ้นบนเว็บ

สิ่งที่ NextJS พลาดไป

อย่างไรก็ตาม สำหรับ Vercel แล้ว การสร้าง Framework เพียงอย่างเดียวไม่ใช่โมเดลธุรกิจที่ดีนัก เพราะต้องใช้ซอฟต์แวร์เอนจิเนียร์ฝีมือดีจำนวนมากและมักจะทำเงินไม่ได้เนื่องจากมีตัวเลือก Open Source อยู่เต็มไปหมด Vercel ไม่ได้อยู่ในธุรกิจสร้าง Framework เป็นหลัก แต่พวกเขาคือผู้ให้บริการ Serverless Cloud และนั่นคือจุดที่ NextJS เริ่มมีปัญหา…

เนื่องจาก Vercel ต้องการขายเซิร์ฟเวอร์และเก็บเงินคุณจากทุก Request ที่ส่งไปยังเซิร์ฟเวอร์เหล่านั้น พวกเขาจึงเริ่มแนะนำแนวทางที่น่ากังขาใน NextJS Framework ของตน ทุกอย่างในตอนนี้ต้องทำบนฝั่ง Server ตามเอกสารทางการของพวกเขา การทำงานฝั่ง Server ถูกทำให้เป็นเรื่องซับซ้อน (Abstracted) และการตั้งค่าเริ่มต้นมักจะใช้ทรัพยากรเซิร์ฟเวอร์มากกว่าปกติ (ลองนึกถึง NextJS Image เป็นตัวอย่าง) สิ่งนี้ทำให้การปรับแต่ง NextJS เพื่อประหยัดต้นทุนนั้นทำได้ยากมาก และมักจะมาพร้อมกับเวลาในการโหลดที่นานกว่าเมื่อเทียบกับเทคนิค Static Rendering

ถ้าจะให้สรุปสั้นๆ แบบตรงไปตรงมา: NextJS กลายเป็น Framework ที่เริ่ม *ถอยหลังลงคลอง (Enshittified)* ซึ่งเป็นการเปิดโอกาสให้ Framework ที่เป็นมิตรต่อ SEO อย่างแท้จริงกลับมามีบทบาทอีกครั้ง

• https://en.wikipedia.org/wiki/Enshittification

และนั่นคือจุดที่ Svelte เริ่มทำให้เรารู้สึกดี

Svelte คือ Framework ที่คอมไพล์แอปพลิเคชันให้กลายเป็นโค้ด HTML และ JavaScript โดยตรง มันไม่ต้องพึ่งพา Library ขนาดใหญ่ (เช่น Virtual DOM) ที่ต้อง Import เข้าไปใน Client Application นอกจากนี้ยังมีฟีเจอร์ Server-side rendering, Components, Folder-structure based routing และฟีเจอร์อื่นๆ ที่คุ้นเคยจาก React และ NextJS

การเลือกใช้ Svelte นั้นขึ้นอยู่กับตัวโปรเจกต์! แนวทางของ Svelte ให้โค้ดที่สะอาดกว่าและขนาด Bundle ที่เล็กกว่า ทำให้เหมาะมากสำหรับโปรเจกต์ที่เน้นประสิทธิภาพ (Performance) และการดูแลรักษาโค้ด (Maintainability) แต่สำหรับความต้องการทางธุรกิจที่ซับซ้อน การจัดการ State ส่วนกลาง และการเชื่อมต่อกับ Third-party ที่หลากหลาย React ก็ยังคงเป็นตัวเลือกที่น่าสนใจกว่า

ในโปรเจกต์แรกที่เราใช้ Svelte ซึ่งก็คือเว็บไซต์ของเราเอง (www.wedodevwork.com) เราให้ความสำคัญกับประสิทธิภาพเป็นอันดับแรก เราเลือกใช้แนวทาง Static Site โดยใช้ Svelte Static Adapter ซึ่งสามารถ Deploy ได้ในราคาประหยัดบน Cloud Distribution Network เราพบว่าการเปลี่ยนมาใช้ Svelte นั้นง่ายมาก เพราะนักพัฒนาของเราคุ้นเคยกับ TailwindCSS อยู่แล้ว และ Svelte ก็ใช้ไวยากรณ์ HTML ภายในชุดโค้ดด้วย

สิ่งที่ทำให้ Svelte ยอดเยี่ยมสำหรับ SEO คือความเรียบง่ายในการโหลดข้อมูล การโหลดข้อมูลเกิดขึ้นได้ทั้งบน Server หรือทั้ง Server และ Client คุณสามารถโหลดข้อมูลในทุก Request (โดยใช้ Hooks) แต่โดยทั่วไปจะทำเพียงครั้งเดียวและข้อมูลสามารถอัปเดตใหม่ได้ (Invalidate) เมื่อมีการเปลี่ยน Dependency หรือเรียกฟังก์ชัน “invalidate” นอกจากนี้คุณยังสามารถทำ Streaming Response ด้วย Promise ซึ่งช่วยให้คุณเรนเดอร์เนื้อหาอย่าง Loading Bars ในขณะที่รอข้อมูลตอบกลับได้

อนาคตของเรากับ Svelte

ชุมชนของ Svelte ยังถือว่าเล็กเมื่อเทียบกับ React ส่งผลให้เครื่องมือและ Library จาก Third-party ยังมีจำกัด และในขณะที่ Svelte กำลังเติบโต ตัวอย่างโค้ด Open Source ที่ยังมีไม่มากนักอาจทำให้ประสบการณ์การเขียนโค้ดแบบ “Vibe-coding” (การใช้ AI ช่วยเขียน) ยังไม่ลื่นไหลเท่าที่ควร เราไม่เกี่ยงที่จะต้องค้นคว้าเอกสารเพิ่มเติมเพื่อเติมเต็มส่วนที่ขาดหาย แต่นั่นหมายความว่าเราต้องลงทุนกับเวลาในการเรียนรู้ที่มาพร้อมกับการนำ Svelte มาใช้ นอกจากนี้การจ้างนักพัฒนา React หน้าใหม่มาดูแล Codebase ขนาดใหญ่ที่มีอยู่เดิมก็ยังทำได้ง่ายกว่า

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

หากคุณต้องการสร้างบางอย่างด้วย Svelte (หรือ React) ติดต่อเราได้เลย We Do Dev Work พร้อมช่วยคุณสร้างและปรับแต่งเว็บแอปพลิเคชันให้มีประสิทธิภาพสูงสุด