Astro คือการหวนคืนสู่พื้นฐานของเว็บ

 (websmith.studio)
17 คะแนน โดย GN⁺ 2025-07-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

"Astro คือเฟรมเวิร์กที่ดีที่สุดสำหรับนักพัฒนา"

  • Astro คือเว็บเฟรมเวิร์กแนวคิดใหม่ที่เหมาะกับเว็บไซต์ที่เน้นคอนเทนต์ โดยมีแนวทาง Zero JavaScript เป็นค่าเริ่มต้น พร้อมมอบประสิทธิภาพที่ยอดเยี่ยมและประสบการณ์พัฒนาที่เรียบง่าย
  • ใช้วิธีการเฉพาะตัวที่เรียกว่า Island Architecture โดยเปิดใช้ JavaScript เฉพาะส่วนที่จำเป็น และให้ส่วนที่เหลือทำงานด้วย static HTML ที่รวดเร็ว
  • เว็บไซต์ที่สร้างด้วย Astro โหลดได้เร็วกว่าแบบ React ดั้งเดิมมากกว่า 40% ซึ่งส่งผลดีจริงต่อ SEO, ประสบการณ์ผู้ใช้, อัตราการแปลงผล และอื่นๆ
  • ต่างจากเฟรมเวิร์กอื่นตรงที่แยก data logic กับ frontend component ออกจากกันอย่างชัดเจน และสามารถใช้งานร่วมกับเฟรมเวิร์กหลากหลายอย่าง React·Vue ได้
  • อย่างไรก็ตาม หากต้องการ SPA, การจัดการ state ที่ซับซ้อน, routing ขนาดใหญ่ เฟรมเวิร์กแบบเดิมอย่าง Next.js อาจเหมาะกว่า

Astro คืออะไร

  • Astro คือ เว็บเฟรมเวิร์กที่ปรากฏตัวในปี 2021 ซึ่งต่างจาก JS framework เดิมที่ออกแบบมาสำหรับแอปซับซ้อน โดย Astro ถูกออกแบบมาโดยเน้น เว็บไซต์ที่ขับเคลื่อนด้วยคอนเทนต์
  • ปรัชญาหลักคือ "คอนเทนต์มาก่อน, เซิร์ฟเวอร์มาก่อน, พื้นฐานคือ Zero JavaScript" และอีกจุดแข็งคือ tooling ที่เข้าใจง่ายและใช้งานไม่ยาก

Island Architecture

  • Astro นำแนวคิด "Island Architecture" มาใช้ โดยไม่ได้ใส่ JavaScript ให้ทั้งหน้า แต่ใส่เฉพาะบางส่วนที่จำเป็น
  • หน้าอย่างบล็อกโพสต์ที่ส่วนใหญ่เป็นข้อความจะถูกเรนเดอร์ด้วย HTML เท่านั้น และ จะโหลด JS เฉพาะส่วนที่ต้องมีปฏิสัมพันธ์ เช่น คอมเมนต์หรือ carousel
  • จึงทำให้ หน้าเว็บทั้งเร็วมากและมีขนาดเบา

ประสิทธิภาพและผลลัพธ์ที่จับต้องได้

  • เว็บไซต์ที่สร้างด้วย Astro ทำสถิติ โหลดเร็วกว่า React framework แบบดั้งเดิมมากกว่า 40%
  • การปรับปรุงประสิทธิภาพนี้ต่อยอดไปสู่ผลลัพธ์ทางธุรกิจ เช่น อันดับบนเสิร์ชเอนจิน, ความพึงพอใจของผู้ใช้, อัตราการแปลงผล
  • แม้อยู่บนอุปกรณ์ช้าหรือเครือข่ายความเร็วต่ำ ความต่างด้านความเร็วก็ยิ่งรู้สึกได้ชัดเจนขึ้น

ประสบการณ์นักพัฒนา (Developer Experience)

  • การตั้งค่าโปรเจกต์ ทำได้ง่าย และมีผู้ช่วยตั้งค่าที่เป็นมิตรชื่อ “Houston” คอยแนะนำ
  • Astro component สามารถมี logic ที่ทำงานเฉพาะตอน build time ได้ (เช่น data fetching, การเรียก API เป็นต้น)
  • ไม่ต้องคอยกังวลกับ state management, lifecycle หรือ hooks ที่ซับซ้อน และสามารถ ใช้ client-side JS เฉพาะเมื่อจำเป็น ได้

ความเข้ากันได้กับเฟรมเวิร์กที่หลากหลาย

  • สามารถ ใช้งาน React, Vue และเฟรมเวิร์กหลักอื่นๆ ร่วมกับ Astro ได้อย่างอิสระ
  • ตัวอย่างเช่น แดชบอร์ดผู้ดูแลใช้ React, การทำ data visualization ใช้ Vue และส่วนที่เหลือใช้ Astro

ฟีเจอร์อำนวยความสะดวกที่ “ใช้งานได้จริง”

  • สามารถ import Markdown มาใช้งานได้โดยตรงเหมือนเป็น component
  • รองรับ modern build pipeline เช่น TypeScript, Sass, image optimization, hot module replace และอื่นๆ
  • เลือกได้ทั้ง static site / SSR / hybrid rendering และปรับใช้ได้อย่างยืดหยุ่นตามลักษณะของโปรเจกต์

พื้นที่ที่ Astro โดดเด่น

  • ให้ประสิทธิภาพยอดเยี่ยมกับเว็บไซต์ที่เน้นคอนเทนต์ เช่น เว็บไซต์การตลาด, บล็อก, แคตตาล็อกอีคอมเมิร์ซ, พอร์ตโฟลิโอ
  • เหมาะอย่างยิ่งกับ สภาพแวดล้อมที่ไม่ต้องการการจัดการ client state ที่ซับซ้อน

Trade-off

  • สำหรับโปรเจกต์ที่ SPA, routing ซับซ้อน, การแชร์ state ระหว่าง component เป็นเรื่องสำคัญ เฟรมเวิร์กอื่นอย่าง Next.js อาจเหมาะสมกว่า
  • ecosystem ยังมีขนาดไม่ใหญ่มากนัก และ file-based routing อาจให้ความรู้สึกว่ามีข้อจำกัดเมื่อใช้กับโปรเจกต์ขนาดใหญ่

วิธีเริ่มต้นอย่างรวดเร็ว

  • npm create astro@latest my-site
  • หากจำเป็นให้เพิ่มเฟรมเวิร์กด้วย npx astro add react เป็นต้น
  • เพิ่มหน้าไว้ใน src/pages/ และเพิ่ม component ไว้ใน src/components/ จากนั้นเริ่มพัฒนาได้เลย

ความหมายของ Astro

  • ในช่วงที่ JS framework สมัยใหม่ยิ่งซับซ้อนขึ้นเรื่อยๆ Astro เลือกกลับไปสู่พื้นฐานของเว็บ (ประสบการณ์ที่รวดเร็ว เข้าถึงได้ง่าย และเน้นคอนเทนต์) พร้อมยังคงความสะดวกในการพัฒนาไว้
  • ปรัชญาการออกแบบแบบ “เว็บไซต์เร็วเป็นค่าเริ่มต้น, เพิ่มความ interactive เฉพาะจุดที่จำเป็น, ใช้เฟรมเวิร์กที่ต้องการได้อย่างอิสระ” เป็นสิ่งที่ทำให้นักพัฒนาพึงพอใจ
  • ตั้งแต่บล็อกไปจนถึงอีคอมเมิร์ซ จึง แนะนำ Astro อย่างจริงจังสำหรับโปรเจกต์ที่เน้นคอนเทนต์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-07-10
ความคิดเห็นจาก Hacker News

  • เฟรมเวิร์กเว็บแบบดั้งเดิมมักจะ “hydrate” ทั้งหน้าเว็บด้วย JavaScript เสมอ เช่น ต่อให้เป็นโพสต์บล็อกง่าย ๆ ที่มีวิดเจ็ตโต้ตอบได้แค่อันเดียว ทั้งหน้าก็ยังถูกจัดการด้วย JavaScript ทั้งหมด ในขณะที่ Astro ใช้ static HTML เป็นค่าเริ่มต้น และทำให้เฉพาะส่วนที่จำเป็นทำงานเป็น “JavaScript islands” เท่านั้น แต่ก่อนเราเรียกวิธีแบบนี้ว่า “progressive enhancement” หรือเรียกง่าย ๆ ว่า “เว็บเพจ” และนี่คือมาตรฐานของการสร้างเว็บไซต์ จากนั้น SPA ก็เข้ามาและ progressive enhancement ก็ถูกใช้น้อยลงเรื่อย ๆ ตอนนี้เราเรียกมันว่า “JavaScript islands” แต่สุดท้ายก็คือการย้อนกลับไปสู่วิธีเดิม ผมอยากแนะนำแนวคิด progressive enhancement ให้กับนักพัฒนาเว็บรุ่นใหม่ที่สนใจ

    • บ่อยครั้งที่มีคนฟังคำอธิบายฟีเจอร์ของเครื่องมือใหม่แล้วเข้าใจผิดว่าเป็นแค่สิ่งเดิมที่เคยทำอยู่ แต่คุณค่าที่แท้จริงของ Astro คือมันเชื่อมต่อกับ JavaScript framework ได้หลากหลาย และให้แต่ละส่วนย่อยของ subtree ใน HTML ถูกจัดการแยกกันได้ โดยสถานะเริ่มต้นจะถูกเรนเดอร์เป็นสตริง แล้วค่อย hydrate ฝั่งไคลเอนต์ด้วยข้อมูลที่โหลดไว้ล่วงหน้า มันมีคุณค่าเมื่อคุณอยากใช้เฟรมเวิร์กอย่าง React/Svelte/Solid/Vue แค่บางส่วนของหน้า และอยากโหลดข้อมูลจากเซิร์ฟเวอร์ไว้ก่อน เพียงแต่วิธีนี้ไม่ใช่ “progressive enhancement” เพราะ HTML ก่อน hydration ไม่จำเป็นต้องทำงานได้สมบูรณ์ เช่น <form> จะใช้ไม่ได้หากไม่มี JavaScript ก็ได้ รายละเอียดพวกนี้เองที่ต้องมองด้วยความอยากรู้อยากเห็นมากกว่าจะประชดประชัน ถึงจะเข้าใจ

    • เห็นด้วยอย่างยิ่ง Astro เป็นเครื่องมือที่ยอดเยี่ยม แต่สิ่งที่ยากที่สุดคือการทำความเข้าใจคำศัพท์สารพัดที่นักพัฒนาซึ่งเข้าวงการหลังปี 2010 สร้างขึ้นมาเพื่ออธิบายวิธีการทำงานของเว็บ

    • มันไม่ใช่แนวคิดใหม่ แต่แนวทางปัจจุบันให้ความรู้สึกขัดเกลามากกว่า สมัยก่อนผมทำเว็บแบบ interactive ด้วย PHP และ jQuery ซึ่งเป็นยุคก่อน React และ SPA ย้อนกลับไปมองตอนนี้ ในเชิงสถาปัตยกรรมวิธีแบบเก่าดูสง่างามกว่า แต่ตอนนั้นการดีบักและ DX แย่มาก ผมไม่อยากกลับไปเสียเวลาดีบักฝั่งฟรอนต์เอนด์ด้วย PHP อีกแล้ว SPA ก็ยังมีที่ทางของมันสำหรับแดชบอร์ดซับซ้อนหรือแอปที่โต้ตอบสูง Astro ช่วยให้จัดการโค้ดเซิร์ฟเวอร์กับไคลเอนต์ไว้ในที่เดียวกัน และแยกขอบเขตได้ชัดเจน จึงไม่ต้องเสียเวลาพาร์สข้อมูลด้วย PHP แล้วส่งต่อเข้า JS ทำให้ DX ดีขึ้นมาก

    • จำได้ว่าสมัยนั้นเราเรียกมันว่า AJAX รู้สึกเหมือนกระแสหลงทางไปหมดแล้ว

    • ผมคิดว่าเว็บเฟรมเวิร์กยุคแรกจัดการกับเว็บไซต์แบบไร้สถานะและ server rendering ได้ถูกทางมากจริง ๆ

  • ส่วนตัวผมแนะนำ Astro อย่างมาก ตอนแรกคิดว่ามันเป็นแค่ "เครื่องมือที่เพิ่ม include ให้ html กับ css" แต่พอได้ใช้ทำเว็บส่วนตัวและรีโนเวตเว็บไซต์ Matrix Conference ก็พบว่าใช้งานได้ราบรื่นและสนุกมากโดยแทบไม่มีความยุ่งยาก
    ข้อดีหลักของ Astro:

    • ยังยึด html และ css เป็นศูนย์กลาง
    • หลัง build เสร็จ โดยพื้นฐานแล้วไม่ต้องใช้ js
    • เพิ่ม js แบบเลือกเฉพาะจุดได้เฉพาะที่ต้องการความ interactive
    • ฟีเจอร์ content collections ทำได้ดีและเป็นระเบียบ
    • ปรับแต่งความเร็วได้ยอดเยี่ยมมาก และทีม maintainer รู้วิธีทำเรื่องนี้ดี
    • มี Devbar สำหรับงานพัฒนา ที่ช่วยแสดงให้เห็นแบบภาพว่าตรงไหนของเว็บไซต์ยังทำให้เร็วขึ้นได้อีก (เช่น lazy load รูปภาพใต้หน้าจอ)
    • CSS minifier จะ inline CSS บางส่วนเพื่อลดจำนวน query เพิ่มเติม
    • image component จะตั้งค่า width/height อัตโนมัติเพื่อป้องกัน content layout shift และยังรองรับ responsive image

    • ถ้า Astro ยึด html และ css เป็นหลัก และเติม js เฉพาะตอนจำเป็น การสร้างไฟล์ .html, .css, .js ตรง ๆ ในไดเรกทอรีแล้ว deploy ก็น่าจะให้ประสบการณ์แบบเดียวกันอยู่แล้ว แถมอาจเร็วกว่าเพราะไม่มี dev-time overhead หรือ bloat ที่ไม่จำเป็น อีกอย่างการ inline CSS ก็ไม่เคยเป็นประเด็นด้านประสิทธิภาพที่ใหญ่จริง ๆ จากประสบการณ์กับเว็บไซต์หลายร้อยแห่ง CSS แทบไม่เคยเป็นคอขวด ปัญหาจริง ๆ มักเป็นเรื่องเครือข่ายมากกว่า

    • มีอยู่จุดเดียวที่ผมเสียดายคือพอ routing ซับซ้อนขึ้น abstraction ก็เพิ่มเร็วมากจนกลับทำให้สับสน สุดท้ายจึงเลือกแนวทางอื่น เพราะความซับซ้อนย่อมมาพร้อม friction เสมอ

    • ถ้าคุณต้องการแค่ "include สำหรับ html กับ css" ก็เปิดใช้ server-side include บนเว็บเซิร์ฟเวอร์ทั่วไปอย่าง nginx ได้เลย เป็นโซลูชันที่เสถียรมากว่า 20 ปีและแทบไม่ต้องดูแลรักษาเพิ่ม ไม่มีความเสี่ยงด้านความปลอดภัยแบบ template engine และยังลดความซ้ำซ้อนได้โดยไม่ต้องกังวลเรื่องช่องโหว่ฝั่งแบ็กเอนด์ เพราะทำแค่ include ล้วน ๆ

    • หลังจากทำแต่งาน data/backend มานาน 20 ปี ผมต้องกลับมาจับฟรอนต์เอนด์อีกครั้งเพราะโปรเจกต์หนึ่ง ตอนแรกทรมานกับ React มาก แต่พอเปลี่ยนมาใช้ Astro+Svelte กลับประสบความสำเร็จมาก โครงสร้างโค้ดคาดเดาได้และสะอาดเพราะเน้น HTML/CSS เป็นหลัก และแม้จะส่งต่องานฟรอนต์เอนด์ให้คนที่มีพื้นฐาน React ก็ยังปรับตัวได้แทบจะทันที

  • พอเห็นคำว่า "เฟรมเวิร์กแบบดั้งเดิม" ถูกใช้หมายถึงเฟรมเวิร์กแนว SPA/Virtual DOM ก็รู้สึกถึงช่องว่างระหว่างรุ่น เพราะของดั้งเดิมจริง ๆ สำหรับเว็บคือพวก Backbone, jQuery ซึ่งนั่นแหละที่ทำงานในแบบที่โพสต์นี้อธิบาย

    • ผมคิดว่า "ดั้งเดิม" สุดท้ายก็ขึ้นอยู่กับว่าคุณเกิดยุคไหน สำหรับผม อินเทอร์เน็ตแบบดั้งเดิมคือ 56k modem, ฟอรัม vbulletin, ม็อด GTA:VC, IRC ฯลฯ สำหรับคนรุ่นเก่ากว่านั้นอาจเป็น BBS ส่วนคนรุ่นใหม่กว่านั้นอาจมองว่า Discord คืออินเทอร์เน็ตแบบ "ดั้งเดิม" ปรากฏการณ์คล้ายกันนี้มีในเรื่องการเมืองด้วย ทุกคนมักคิดว่าช่วงที่ตัวเองยังหนุ่มสาวคือยุคที่ดีที่สุด

    • ผมจำได้ว่า Backbone มุ่งไปทาง client MVC สำหรับ pure SPA โดยตรง

  • ผมสงสัยว่าทำไมเฟรมเวิร์ก SSR อย่าง Astro, NextJS ฯลฯ ถึงไม่รองรับ static page ที่มีเส้นทางแบบ dynamic เหมือน SvelteKit เช่นหน้าอย่าง /todos/[todoId] ใน NextJS ไม่สามารถใส่เข้าไปใน static bundle ได้เลย แต่ SvelteKit ใช้ 404.html ทำให้แม้จริง ๆ จะเป็น 404 ก็ยังทำงานได้สมบูรณ์บน Cloudflare หรือ mobile webview ซึ่งมีประโยชน์มากโดยเฉพาะเวลา bundle สำหรับ mobile webview

    • เห็นด้วยบางส่วน แต่การออกแบบแบบนี้ก็มีข้อเสียเหมือนกัน ถ้า hard reload URL อย่าง /todos/123 ใน SPA มันจะไปขอไฟล์นั้นจากเซิร์ฟเวอร์จริง ๆ และถ้าไม่มีอยู่ก็จะได้ 404 กลับมา จากนั้นต้องให้หน้า 404 ไปจัดการโหลดข้อมูลใหม่ผ่าน client routing ซึ่งจำเป็นต้องมีการตั้งค่า HTTP server อย่าง nginx เสมอ หมายความว่าทำไม่ได้ด้วย static file ล้วน ๆ อีกทั้งตามสเปก HTTP แล้ว browser cache จะไม่เก็บ 404 response เลย ดังนั้นเวลา hard reload หรือเปิดจาก bookmark ก็จะใช้ cache ไม่ได้เลย ถ้าการตั้งค่าแบบนี้เป็นภาระ ผมกลับคิดว่าการใช้ query parameter อย่าง /todo?id=123 อาจเหมาะกว่า

    • ผมอาจจะเข้าใจผิด แต่ผมเคยทำ dynamic routing/page ใน static build ของ Next หรือ Astro ได้ เวลาที่ใช้ CMS อย่าง contentful หรือ storyblok ให้ editor สร้าง route และ component ได้อย่างอิสระ เราใช้แพตเทิร์น [...slug] เพื่อครอบคลุมทุก route และใช้ฟังก์ชัน getStaticPaths เพื่อสร้างทุกหน้าไว้ล่วงหน้า ถ้าเปิดตัวเลือก ISR/ISP ก็จะ pre-render หน้าใหม่แบบ dynamic ได้แม้จะไม่รู้ตอน build time ใน Next เรียกว่า dynamic routes ส่วนใน Astro เรียกว่า dynamic pages
      อ้างอิง: Next dynamic routes, Astro dynamic pages

    • ผมอาจเข้าใจสิ่งที่คุณถามผิด แต่ฟังก์ชัน getStaticPaths ของ Astro ดูเหมือนจะรองรับสิ่งที่คุณต้องการ
      อ้างอิง

    • ผมเองก็ชอบการ deploy แบบ static เลยขอแชร์ไว้เผื่อเป็นประโยชน์ว่า NextJS ก็รองรับการสร้าง static parameter เช่นกัน

    • ผมอาจยังไม่ได้เข้าใจ Astro หรือเฟรมเวิร์กต่าง ๆ อย่างสมบูรณ์ แต่ลองดูว่า server islands ของ Astro ใกล้เคียงกับสิ่งที่คุณต้องการหรือไม่

  • ผมรู้สึกว่าการถกเถียงเรื่องฟรอนต์เอนด์นั้นสับสนเกินไป เนื้อหาในบทความเองสุดท้ายก็วนกลับมาที่คำถามว่า “จะใช้เบราว์เซอร์เป็น HMI หรือเป็น application runtime” แต่การถกเถียงส่วนใหญ่กลับเป็นคำกล่าวกว้าง ๆ อย่าง “สดใหม่” หรือ “โหลดเร็ว” บรรยากาศการโปรโมตเฟรมเวิร์กให้ความรู้สึกเหมือนการตลาดแบรนด์ในอุตสาหกรรมแฟชั่นมากเกินไป

    • ผมว่าการเปรียบกับอุตสาหกรรมแฟชั่นนี่แหละอธิบายการถกเถียงเรื่องฟรอนต์เอนด์ได้ดีที่สุด เพราะแทบไม่มีใครถกกันอย่างเข้มงวดในเชิงเทคนิคกับคำกล่าวอย่าง “content-driven” หรือ “server-first” เลย

    • ผมไม่เข้าใจว่าทำไมถึงมองว่า “โหลดเร็ว” เป็นภาพลวง เพราะมันเป็นปัจจัยสำคัญจริง ๆ

  • ไม่นานมานี้ผมทำเว็บไซต์ให้สถาบันการแพทย์แห่งหนึ่งด้วย Astro ซึ่งง่ายกว่าสมัยทำด้วย Wordpress มาก และยังโฮสต์ฟรีบนที่อย่าง Netlify ได้ด้วย จึงไม่ต้องกังวลเรื่องโดนแฮ็ก ผมยังทำ CMS แบบเรียบง่ายบนพื้นฐาน git ให้ลูกค้าแก้คอนเทนต์เองได้ด้วย รู้สึกว่าเว็บดีเวลลอปเมนต์พัฒนาไปไกลมากจริง ๆ

    • อยากรู้ว่าคุณทำให้คนรู้จักหรือเปล่า และปกติหางานทำเว็บไซต์ให้สถาบันการแพทย์จากที่ไหน

    • ระวังไว้ว่า Netlify คิดค่าบริการแบนด์วิดท์แพงกว่า Vercel

  • จุดแข็งที่สุดของ Astro คือสามารถทำงานด้วย HTML หรือ Web Component ได้โดยไม่ต้องพึ่งเฟรมเวิร์กอื่นอย่าง React หรือ Vue แต่ Astro เองก็รองรับ SSR, ISR, SSG และ middleware เหมือนกับ Next, Nuxt เช่นกัน
    จุดต่างคือมีสถาปัตยกรรมแบบ islands ซึ่งช่วยให้ทำ micro frontend ได้
    ตัวอย่างเช่น หลายทีมในองค์กรเดียวกันอาจรับผิดชอบหน้าชำระเงิน รถเข็น และหน้าสินค้าแยกกัน แต่ก็ยังนำมารวมในหน้าเดียวกันได้ พร้อมควบคุมรูปแบบการเรนเดอร์ได้เอง และยังแชร์ global state ร่วมกันได้ ทำให้แต่ละทีมรับผิดชอบแบบครบวงจรและพัฒนา/ดีพลอยแยกส่วนกันได้
    อย่างไรก็ตาม โครงสร้างแบบนี้เป็นโซลูชันที่จำเป็นกับโปรเจกต์ขนาดใหญ่เท่านั้น ถ้าทุกทีมใช้ React กันคนละแบบก็จะมีหลายเวอร์ชันปะปนกัน แต่การแยกด้วยสถาปัตยกรรมแบบ Astro ช่วยแก้ปัญหานี้ได้
    ส่วนตัวผมยังไม่แน่ใจว่ามันจะเปลี่ยนเว็บไปทั้งหมดหรือไม่ รู้สึกเหมือน Next/Nuxt ที่ตัดการพึ่งพาเฟรมเวิร์กออกไปและเพิ่มสถาปัตยกรรมแบบ islands เข้ามา แต่ก็แนะนำให้ลองใช้ดู
    ถ้าคุณอยากย้ายออกจาก React/Vue ไปสู่ web-component หรืออยากแทนที่ Next/Nuxt แบบค่อยเป็นค่อยไป Astro เป็นตัวเลือกที่น่าแนะนำ

  • สำหรับผม Astro ไม่ได้สมบูรณ์แบบสำหรับทุกสถานการณ์ บางครั้งถ้าต้องการแค่ offline rendering ก็ไม่มีเหตุผลต้องฝืนใช้ JavaScript
    สถาปัตยกรรมแบบ islands เองก็มีข้อจำกัด และผลลัพธ์หลัง build ก็มักถูก inline มากเกินไปด้วย
    พูดตรง ๆ ว่ากระแส Astro น่าจะได้อานิสงส์จาก Vite มากกว่า ซึ่ง Vite นั้นยอดเยี่ยมจริง ๆ

    • ผมอยากถามว่า “เมื่อสถาปัตยกรรมแบบ islands ชนข้อจำกัด” นั้นหมายถึงตอนไหนบ้าง

  • ผมไม่อยากให้ Next.js ถูกแนะนำเป็นเฟรมเวิร์กมาตรฐานของ React อีกแล้ว ฟรอนต์เอนด์ควรมีการคิดเชิงวิพากษ์มากกว่านี้ Remix (React Router v7) หรือ TanStack เป็นทางเลือกที่ดีกว่ามาก

    • ผมก็เห็นด้วย Next.js เคยมีศักยภาพจริง แต่หลังจาก Vercel เข้ามาเกี่ยวข้อง ผมรู้สึกว่ามันถดถอยลงมาก ผมใช้มาตั้งแต่ v10 ผ่านช่วงความวุ่นวายของ v13 มาจนถึง v15 แล้วผิดหวังมาก React และ Next.js เปลี่ยนเร็วเกินไปจนตามไม่ทัน และหลายครั้งดูเหมือนเป็นการเปลี่ยนเพื่อเปลี่ยน มากกว่าจะเปลี่ยนเพราะจำเป็นจริง ๆ

    • ผมถึงขั้นอยากหยุดแนะนำ React เองให้เป็นเฟรมเวิร์กค่าเริ่มต้นด้วยซ้ำ เพราะสำหรับการพัฒนาฟรอนต์เอนด์ ผมคิดว่า HTML/CSS/JS ดีกว่ามาก

    • ผมคิดว่า Remix/React Router v7 คือทิศทางที่ถูกต้อง โดยเฉพาะถ้า Remix ใช้ preact และยึดเว็บมาตรฐานเป็นศูนย์กลาง เราอาจได้แนวทางสร้างเว็บไซต์ที่มั่นคงกลับมาอีกครั้ง เพียงแต่การเปลี่ยนผ่านจาก Remix ไป RR7 ไม่ได้ราบรื่นนัก จนผมต้อง rewrite โปรเจกต์ใหม่

  • ผมคิดว่าหลักการพื้นฐานของเว็บยังคงใช้ได้อยู่เสมอ สำหรับนักพัฒนาที่ใช้ PHP, Spring, Quarkus, ASP.NET MVC อาจไม่ค่อยรู้สึกว่าการพัฒนาเว็บด้วย JS framework กลายเป็นเรื่องยากขึ้นแค่ไหน เพราะบรรยากาศของอุตสาหกรรมที่ขับเคลื่อนด้วยแฟชั่นทำให้การกลับไปสู่พื้นฐานไม่ใช่เรื่องง่าย