หากคุณใช้เวลาช่วงไม่กี่ปีที่ผ่านมาวนเวียนอยู่กับ meta-framework ต่างๆ SvelteKit 2 จะให้ความรู้สึกที่ผสมผสานกันอย่างประหลาดระหว่างความโล่งใจและความระแวง โล่งใจ เพราะมันช่วยลดความซับซ้อนแทนที่จะเพิ่มมันเข้าไป ส่วนความระแวงนั้นเกิดจากการที่คุณเอาแต่รอว่าจะมีปัญหาอะไรตามมาหรือเปล่า แต่มันก็ไม่เคยเกิดขึ้นจริง เมื่อจับคู่กับ Svelte 5 stack นี้ถือเป็นหนึ่งในวิธีที่มีประสิทธิภาพที่สุดในการส่งมอบ full-stack application ในปี 2026 และตัวเลขต่างๆ ก็ยืนยันถึงประสบการณ์ของนักพัฒนาได้เป็นอย่างดี โดย Bundle มีขนาดเล็กลงประมาณ 35% เมื่อเทียบกับสิ่งที่ Svelte 4 ทำได้ นอกจากนี้ Routing, server functions และรูปแบบการทำ authentication ล้วนเป็น first-class citizens ไม่ใช่แค่ plugin ที่คุณต้องเอามาต่อกันแบบขอไปที
runes ทำให้ reactivity ชัดเจนยิ่งขึ้น
การเปลี่ยนแปลงทางความคิดที่สำคัญที่สุดมาจาก runes ของ Svelte 5 ในเวอร์ชันก่อนหน้านี้ Svelte ใช้ label $: และใช้ compiler magic มากมายในการติดตาม dependencies ซึ่งมันก็ใช้งานได้ แต่เมื่อมีอะไรพัง คุณจะต้องมานั่ง debug สายไฟที่มองไม่เห็น Runes เข้ามาแทนที่ magic เหล่านั้นด้วยฟังก์ชันที่ชัดเจน คุณสามารถบอก compiler ได้อย่างเจาะจงว่าต้องการให้ติดตามอะไร และมันก็จะทำตามนั้น
นี่คือสิ่งที่คุณจำเป็นต้องรู้
- $state จัดการตัวแปรแบบ reactive เพียงแค่ครอบค่าใดๆ ด้วย
$state()แล้ว compiler จะรู้ว่าต้องเฝ้าดูมัน - $derived คำนวณค่าจาก state อื่น หากต้องการ list ที่ผ่านการ filter หรือยอดรวมที่จัดรูปแบบแล้ว ให้ใช้
$derivedข้อแตกต่างสำคัญจาก$effectคือ$derivedใช้สำหรับค่า (values) ไม่ใช่การกระทำ (actions) - $effect ใช้สำหรับ side effects เช่น การอัปเดต document title, การวัดค่า DOM ด้วยตนเอง หรือ timer ที่ต้องมีการ cleanup มันจะทำงานหลังจาก DOM commit แล้ว คล้ายกับ lifecycle hook แต่ผูกติดกับ reactive dependencies ที่เฉพาะเจาะจง
- $props เข้ามาแทนที่รูปแบบ
export letแบบเดิมในการรับข้อมูลใน component ซึ่งมีความชัดเจนกว่าและทำงานร่วมกับ TypeScript ได้ดีกว่า
โมเดลนี้ให้ผลลัพธ์ที่ดีในการใช้งานจริง เนื่องจาก compiler ติดตามเฉพาะสิ่งที่คุณระบุไว้เท่านั้น dead code จึงยังคงเป็น dead code คุณจะไม่ต้องสงสัยอีกต่อไปว่าทำไมตัวแปรถึงไปกระตุ้นการอัปเดต และคุณจะเริ่มเชื่อมั่นในคำสั่งที่ชัดเจนของตัวเอง
Routing ด้วยโฟลเดอร์ ไม่ใช่การตั้งค่า
SvelteKit ใช้ file system ของคุณในการทำ routing โดยไม่มีไฟล์ router แยกต่างหากให้ต้องคอยดูแล เพียงแค่วางไฟล์ +page.svelte ลงใน directory นั้น directory ดังกล่าวก็จะกลายเป็น route ที่ใช้งานได้ทันที
Shared UI จะครอบคลุม route เหล่านั้นผ่าน +layout.svelte หากคุณวางไฟล์ไว้ที่ root ทุก child route จะสืบทอด layout นั้น แต่หากวางไว้ลึกขึ้นใน tree เฉพาะส่วนนั้นเท่านั้นที่จะได้รับ wrapper
Logic ฝั่ง server จะอยู่ใน +page.server.ts ซึ่งจะทำงานก่อนที่หน้าเว็บจะ render ดังนั้นจึงเป็นที่สำหรับ query database, ตรวจสอบ cookie หรือปฏิเสธผู้ใช้ที่ไม่ได้ทำการ authenticate โดยที่ types จะไหลจาก load function เข้าสู่ page component โดยอัตโนมัติ ซึ่งหมายความว่าข้อมูลของคุณจะมี type โดยไม่ต้องเขียน interface ด้วยตัวเอง
สำหรับ API endpoints แบบดิบๆ จะอยู่ในไฟล์ +server.ts ซึ่งจะ export standard HTTP handlers เช่น GET, POST, PUT, DELETE ทำให้การสร้าง REST back end ควบคู่ไปกับหน้าเว็บของคุณเป็นเรื่องที่ดูเป็นธรรมชาติ
ฟีเจอร์หนึ่งที่มักถูกมองข้ามคือ group routes โดยการครอบชื่อ folder ด้วยวงเล็บ เช่น (auth) คุณจะสามารถสร้าง shared layout ได้โดยไม่เพิ่ม segment เข้าไปใน URL สิ่งนี้เหมาะอย่างยิ่งสำหรับหน้า login และ signup ที่ต้องการโครงสร้าง (chrome) แบบเรียบง่ายเหมือนกัน แต่มี URL เป็น /login และ /signup ไม่ใช่ /auth/login
ข้อมูล, ความปลอดภัย และ progressive enhancement
Framework สมัยใหม่ชอบพูดถึงเรื่อง full-stack แต่หลายตัวกลับปล่อยให้คุณต้องเดาเองว่าจะวาง auth checks หรือ form logic ไว้ตรงไหน แต่ SvelteKit ให้ hooks ที่ชัดเจนแก่คุณ
ใช้ +page.server.ts สำหรับการดึงข้อมูล (data fetching) ฟังก์ชัน load ที่นั่นจะทำงานบน server เท่านั้น ดังนั้นข้อมูลรับรองฐานข้อมูลของคุณจะไม่รั่วไหลไปยัง browser และ SvelteKit จะสร้าง types จากค่าที่ return ออกมาจาก load function เพื่อให้ frontend ของคุณมีความถูกต้องแม่นยำเสมอ
ใช้ hooks.server.ts เพื่อควบคุมการเข้าถึงทั้งแอปพลิเคชัน มันจะทำงานในทุกๆ request ทำให้เป็นที่ที่เหมาะสมสำหรับการตรวจสอบ session, ตรวจสอบการหมดอายุของ JWT หรือการแนบ user context ไปกับ event ที่เข้ามา
สำหรับการทำ mutations ให้ใช้ form actions แทนที่จะต้องเชื่อมต่อกับ API endpoint แยกต่างหากและจัดการกับ JSON คุณสามารถกำหนด action ภายใน +page.server.ts ได้เลย ความสวยงามของมันคือ progressive enhancement หาก JavaScript โหลดไม่สำเร็จ หรือหากผู้ใช้ปิดการใช้งานไว้ ฟอร์มก็ยังสามารถส่งข้อมูลไปยัง server action และหน้าเว็บจะ re-render พร้อมกับผลลัพธ์ที่ได้ แต่หากมี JavaScript อยู่ SvelteKit จะช่วยยกระดับประสบการณ์การใช้งานโดยไม่ต้องโหลดหน้าเว็บใหม่ทั้งหมด คุณจะได้ทั้งความทนทาน (resilience) และความลื่นไหล (polish) จากโค้ดชุดเดียวกัน
กฎหนึ่งที่ควรจำไว้คือ: ให้คำนวณค่าทางคณิตศาสตร์ใน $derived ไม่ใช่ใน $effect การใช้ $effect เพื่อคำนวณค่าอาจทำให้เกิด update loops ที่ติดตามได้ยาก จงเก็บ $effect ไว้สำหรับ side effects ที่แท้จริง และปล่อยให้ $derived จัดการกับ computed state ของคุณ
SvelteKit เทียบกับ Next.js
ทั้งสองเฟรมเวิร์กสามารถนำไปใช้สร้างแอปพลิเคชันสำหรับใช้งานจริงได้ แต่ก็มีข้อแลกเปลี่ยนที่ต้องพิจารณาอย่างจริงจัง
ในเรื่องขนาดของ Bundle นั้น SvelteKit ได้เปรียบกว่า เนื่องจาก Svelte จะคอมไพล์คอมโพเนนต์ให้เป็น vanilla JavaScript และข้ามการใช้ Virtual DOM ไปโดยสิ้นเชิง ทำให้ขนาดของ runtime footprint ยังคงเล็กอยู่ ในขณะที่ Next.js ต้องแบก engine การทำ reconciliation ของ React ไปด้วย
ระบบ Reactivity ก็มีความแตกต่างกันเช่นกัน SvelteKit จะจัดการเรื่อง runes ในขั้นตอน compile time ทำให้เบราว์เซอร์ได้รับเพียงการอัปเดตแบบธรรมดา ส่วน Next.js ต้องพึ่งพา runtime hooks และการทำ reconciliation ของ React ซึ่งหมายความว่าต้องมีการประมวลผลที่ฝั่ง client มากกว่า
การเริ่มต้นเรียนรู้ (Onboarding) กับ SvelteKit นั้นทำได้ง่ายกว่า เพราะมี mental model ที่ไม่ซับซ้อน คุณไม่ต้องวุ่นวายกับการจัดการ dependency arrays ของ useEffect หรือแก้ปัญหาเรื่อง memoization เพื่อหลีกเลี่ยงการ re-render นอกจากนี้ การทำงานร่วมกับ TypeScript ก็เป็นอีกเรื่องที่ควรกล่าวถึง แม้ว่าทั้งสองเฟรมเวิร์ก