ความเข้าใจผิดที่ว่าคุณไม่สามารถสร้างเว็บแอปแบบโต้ตอบได้นอกจาก Single-Page App

 (htmx.org)
15 คะแนน โดย GN⁺ 2024-11-19 | 8 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักพัฒนาบางคนมองว่าเฟรมเวิร์ก SPA (React, AngularJS ฯลฯ) เป็นสิ่งจำเป็นสำหรับการพัฒนาแอปพลิเคชันคุณภาพสูง
  • แต่ก่อนยุค SPA แอปพลิเคชันที่อิงกับ MPA ก็สามารถมอบประสบการณ์ผู้ใช้ที่ยอดเยี่ยมได้มาโดยตลอด
  • ผมได้ลองพัฒนาแพลตฟอร์มสังเกตการณ์ที่ขับเคลื่อนด้วยข้อมูลบนพื้นฐาน MPA โดยใช้ HTMX และพบว่าด้วยการปรับแต่งที่เหมาะสม MPA แบบ server-rendered ก็สามารถมอบทั้งประสิทธิภาพและประสบการณ์ผู้ใช้ที่ยอดเยี่ยมได้

ความเข้าใจผิดและความจริงเกี่ยวกับ MPA

ความเข้าใจผิด 1: MPA ช้าเมื่อมีการเปลี่ยนหน้า
  • ปัญหา: โดยปกติเบราว์เซอร์จะดาวน์โหลด JavaScript และ CSS ใหม่ทุกครั้งที่มีการเปลี่ยนหน้า
  • ทางแก้:
    • ใช้ไลบรารีอย่าง PJAX, Turbolinks, HTMX Boost เพื่อสลับเฉพาะ HTML body
    • ใช้ Service Worker เพื่อปรับปรุงการแคชหน้าและการจัดการคำขอได้
    • ตัวอย่าง: เมื่อนำ Service Worker มาใช้ เวลา DOMContentLoaded ลดลงจาก 2.9 วินาทีเหลือ 500ms
วิธีติดตั้งใช้งาน Service Worker
  1. สร้างไฟล์ sw.js: เขียนสคริปต์สำหรับจัดการแคชและคำขอเครือข่าย
  2. กำหนดรายการไฟล์ที่จะทำแคช: ระบุทรัพยากรหลัก เช่น HTML, CSS, JS
  3. ตั้งค่ากลยุทธ์การแคช: แคชทรัพยากรแบบคงที่ถาวรหรืออัปเดตเป็นระยะ
ความเข้าใจผิด 2: MPA ไม่สามารถทำงานออฟไลน์หรือเก็บคำขอไว้ตอนเครือข่ายกลับมาได้
  • สามารถใช้ Service Worker เพื่อให้แอปทำงานได้แม้ขณะออฟไลน์
  • ใช้ Workbox:
    • แคชคำขอเมื่อเครือข่ายล้มเหลว และลองใหม่ภายใน 24 ชั่วโมง
    • ตั้งค่า offline handler เพื่อส่งคอนเทนต์ทดแทนเมื่อมีคำขอ
ความเข้าใจผิด 3: MPA ทำให้หน้าจอกะพริบเมื่อเปลี่ยนหน้า
  • ทางแก้:
    • ใช้ Service Worker และ Preload API เพื่อหน่วงการวาดหน้าจอจนกว่าทรัพยากรจะพร้อม
    • ตั้งแต่ปี 2019 เป็นต้นมา เบราว์เซอร์สามารถจัดการการเปลี่ยนหน้าในโดเมนเดียวกันได้โดยไม่เกิดอาการกะพริบ
ความเข้าใจผิด 4: MPA ไม่สามารถทำเอฟเฟกต์เปลี่ยนหน้าที่หวือหวาได้
  • แม้ SPA จะเป็นที่รู้จักเรื่องแอนิเมชันเปลี่ยนหน้า แต่เบราว์เซอร์ก็เริ่มรองรับความสามารถนี้แล้ว
  • ใน Chrome 126 สามารถสร้างแอนิเมชันการเปลี่ยนข้ามเอกสารได้ด้วย CSS เพียงอย่างเดียว
  • ลิงก์เดโม
ความเข้าใจผิด 5: ใน HTMX หรือ MPA ทุกการกระทำของผู้ใช้ต้องประมวลผลบนเซิร์ฟเวอร์
  • HTMX ถูกออกแบบมาให้มีเพียงบางงานเท่านั้นที่ประมวลผลบนเซิร์ฟเวอร์
  • หากจำเป็น สามารถเพิ่มความสามารถแบบโต้ตอบฝั่งไคลเอนต์ด้วย WebComponents หรือเฟรมเวิร์ก JavaScript ได้
  • ยังสามารถใช้แนวทางแบบ SPA เฉพาะกับบางคอมโพเนนต์ได้
ความเข้าใจผิด 6: การจัดการ DOM ช้า จึงจำเป็นต้องใช้ React/Virtual DOM
  • Virtual DOM จะแสดงความแตกต่างด้านประสิทธิภาพเฉพาะในแอปพลิเคชันที่ซับซ้อนมากเป็นพิเศษเท่านั้น
  • สำหรับแอปพลิเคชันทั่วไปส่วนใหญ่ การจัดการ DOM โดยตรงก็เร็วเพียงพอแล้ว
  • เอกสารอ้างอิง: "Virtual DOM is pure Overhead"
ความเข้าใจผิด 7: แม้เป็นฟังก์ชันโต้ตอบเล็กน้อยก็ยังต้องใช้ JavaScript
  • เทคโนโลยีเบราว์เซอร์สมัยใหม่ทำให้สามารถสร้างฟังก์ชันได้หลากหลายโดยไม่ต้องใช้ JavaScript
    • ใช้ HTML checkbox และ CSS เพื่อทำฟังก์ชัน toggle ได้
    • ผสานกับ HTMX เพื่อโหลดข้อมูลแบบ asynchronous เมื่อคลิกได้
ความเข้าใจผิดสุดท้าย: หากไม่มี SPA โค้ดฝั่งไคลเอนต์จะกลายเป็นสปาเกตตีโค้ด
  • แม้ในยุคสปาเกตตีโค้ด ก็ยังมีซอฟต์แวร์ที่สร้างประสิทธิผลได้มากมายถูกพัฒนาขึ้น
  • ในช่วง MVP ระยะแรก โครงสร้างที่เรียบง่ายอาจได้เปรียบมากกว่า

บทสรุป

  • ณ ปี 2024 เบราว์เซอร์ได้พัฒนาไปมากโดยผสานบทเรียนจากการปฏิวัติ SPA เข้าไว้ด้วยกัน
  • ด้วยเครื่องมือพื้นฐานของเบราว์เซอร์เพียงอย่างเดียว (HTML, CSS, JavaScript) ก็สามารถสร้างแอปพลิเคชันแบบโต้ตอบและทำงานออฟไลน์ได้
  • ขอแนะนำให้เชื่อในศักยภาพของเบราว์เซอร์ และลองกลับมาใช้งานมันอีกครั้ง

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

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

 
pcj9024 2024-11-20

ถ้าลองพัฒนางานกับนักพัฒนาฝีมือพอๆ กันทั่วไป ก็จะรู้ทันทีว่านี่เป็นคำพูดที่เพ้อฝันแค่ไหน ดูเหมือนว่าคนที่เขียนบทความนี้จะรายล้อมไปด้วยอัจฉริยะ หรือไม่ก็ทำงานอยู่คนเดียว... (ดูได้จากการที่ยังยก angularjs ที่ตกยุคไปแล้วมาพูดถึงตอนนี้) และการพัฒนาก็ไม่ได้ทำกันด้วยอัจฉริยะเท่านั้น
บางคนอาจดูแคลนว่าเป็นการ "รวมกลุ่มกันเอง" แต่ความเปลี่ยนแปลงนั้นเกิดขึ้นจากคนธรรมดามาโดยตลอด
พอเห็นอะไรแบบนี้แล้ว ก็ทำให้คิดขึ้นมาก่อนเลยว่า htmx ไม่ควรถูกยอมรับเด็ดขาด
 
konh2e 2024-11-20

เป็นประเด็นที่ถูกพูดถึงซ้ำ ๆ อยู่เรื่อย ๆ ในช่วงหลังมานี้
มีวิดีโอที่ Rich Harris เคยพูดถึงความเห็นของตัวเองเกี่ยวกับประเด็นนี้เมื่อหลายปีก่อน
https://www.youtube.com/watch?v=860d8usGC0o&t=635s

ถ้าจำไม่ผิดก็พอสรุปได้ว่า วิธีการอัปเดตโดยอิงกับ partial HTML อาจทำให้เกิดความไม่สอดคล้องกันระหว่างหน้าจอกับข้อมูลได้
 
kwj9211 2024-11-19

คุณยังเชื่อสเปกของเบราว์เซอร์อยู่อีกหรือ...?

ถ้าจะพูดให้ชัด ผมคิดว่า SPA เป็นวิธีพัฒนาแอปที่พึ่งพาพฤติกรรมของเบราว์เซอร์น้อยกว่าวิธีอื่นอยู่บ้าง

เป็นความจริงที่เบราว์เซอร์ตามความเป็นไปได้อันยอดเยี่ยมของ SPA มาได้ค่อนข้างมาก และมันก็ดูเข้ากับรูปแบบการสื่อสารที่ HTTP ถูกออกแบบไว้แต่เดิมมากกว่า แต่ผมก็อดคิดไม่ได้ว่านั่นอาจเป็นเพราะ Chrome มีสถานะกึ่งผูกขาดในโลกของเบราว์เซอร์โดยพฤตินัย เลยมีช่องว่างให้ทำแบบนั้นได้... ไม่แน่ใจเหมือนกันว่าสิ่งนี้จะอยู่ได้นานแค่ไหน ไม่ว่าจะเป็นช่องว่างนั้นหรือส่วนแบ่งตลาดก็ตาม...
 
clickin 2024-11-19

ถ้าเป็นการจัดการ DOM จากฝั่งเซิร์ฟเวอร์บนพื้นฐาน websocket แบบ phoenix liveview มันก็เป็นคนละกระบวนทัศน์กัน
ตอนที่ลองใช้ htmx ผมก็รู้สึกว่าไอเดียที่ต้องให้เซิร์ฟเวอร์ส่ง HTML ที่แตกเป็นชิ้น ๆ ลงมามันไม่ได้ถูกใจขนาดนั้น
โดยเฉพาะในส่วนของ CSS ถ้ากำหนด class แล้วส่งลงมา ฝั่งเซิร์ฟเวอร์ก็จะไม่มีทางรู้ว่าในหน้าจอกำลังใช้ CSS อะไรอยู่ เลยให้ความรู้สึกเหมือนเป็นการบังคับใช้ CSS กลางร่วมกันไปโดยปริยาย
 
colus001 2024-11-20

ผมเคยลองทำ UI ที่ค่อนข้างซับซ้อนด้วย Phoenix LiveView เมื่อหลายปีก่อน แต่การทำอินเทอร์แอ็กชันง่าย ๆ กลับยุ่งยากมาก และเพราะ LiveView หนึ่งตัวถูกประมวลผลเป็นหนึ่ง Elixir process ทำให้การโต้ตอบกับคอมโพเนนต์ข้าง ๆ ทำได้ยากมาก สุดท้ายก็ยอมแพ้แล้วกลับไปใช้ React ครับ
 
silveris23 2024-11-19

ผมว่า liveview ดูเหมือนอนาคตเลยนะ…
 
clickin 2024-11-20

LiveView ยังพึ่งพาเครือข่ายค่อนข้างมากด้วย เลยมีจุดอ่อนชัดเจนในกรณีที่เซิร์ฟเวอร์อยู่ไกลจนค่า ping สูง หรืออยู่ในประเทศกำลังพัฒนาที่โครงสร้างพื้นฐานอินเทอร์เน็ตไม่ค่อยดี
 
GN⁺ 2024-11-19
ความคิดเห็นจาก Hacker News

  • มีความสงสัยว่าทำไมบทความถึงไม่กล่าวถึงวิธีจัดการ asset แบบ CSS และ JS ที่เป็น static โดยอาศัย browser cache ตอนที่เคยสร้างเว็บช้อปปิ้งด้วยแนวทาง MPA ในอดีต การเปลี่ยนหน้าแทบสังเกตไม่เห็นเลย

  • บางคนมองว่ายุคการพัฒนาเว็บด้วย PHP และ jQuery มีประสิทธิภาพในการทำงานมากที่สุด และตั้งคำถามว่ากระบวนทัศน์ในอดีตอาจมีประสิทธิผลกว่าการใช้เทคโนโลยีสมัยใหม่อย่าง React หรือไม่ เว็บไซต์ขนาดใหญ่อย่าง Amazon หรือ Steam ก็ยังคงสร้างด้วยวิธีเรนเดอร์ HTML จากฝั่งเซิร์ฟเวอร์แล้วเสริม JS เข้าไป

  • มีความเห็นที่ขอคำอธิบายว่ากลยุทธ์ service worker ดีกว่า HTTP cache header แบบเดิมอย่างไร แม้จะลด network round-trip ได้ แต่ก็ให้ความรู้สึกเหมือนกำลังประดิษฐ์ทุกอย่างขึ้นใหม่เพื่อการปรับแต่งเล็กน้อย

  • ชื่อเรื่อง "You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths" ให้ความรู้สึกเหมือนจงใจเรียกคลิก เพราะส่วนที่ถูกละไว้ทำให้ความหมายไม่ครบ

  • สิ่งที่อันตรายที่สุดในการเขียนโปรแกรมคือความเบื่อของนักพัฒนาและการไม่รู้จักอดีต

  • มีความเห็นที่ไม่เข้าใจว่าทำไมในยุคของเว็บเซิร์ฟเวอร์ Node.js ยังต้องมีการแบ่งขั้วระหว่างฝั่งเซิร์ฟเวอร์กับฝั่งไคลเอนต์ (SPA) โดยตั้งคำถามว่าเราจะไม่สามารถให้เซิร์ฟเวอร์เตรียมงานส่วนใหญ่ไว้ก่อน แล้ว serialize ส่งไปยังไคลเอนต์เพื่อให้ทำงานเป็น SPA ต่อได้หรือ

  • มีแนวโน้มที่จะมอง SPA และ MPA เป็นทีมที่อยู่คนละฝั่งกัน แต่ก็อาจแยกได้เป็นวิธีใช้ web stack อย่างเป็นธรรมชาติกับวิธีแบบ "แฮ็ก" ปัจจุบัน SPA เป็นวิธีแบบแฮ็ก แต่ในอดีตก็เคยมี CGI, Java applet และ Flash มาก่อน โดยวิธีแบบแฮ็กมีบทบาทในการขยายข้อจำกัดของวิธีที่เป็นธรรมชาติ

  • ก่อนจะตัดสินใจเลือก tech stack มักมีนักพัฒนาจำนวนมากที่ยังเข้าใจผิดว่าตัวเองกำลังเขียนอะไรอยู่ หากไม่ได้ต้องการการโต้ตอบระดับสูงมาก เฟรมเวิร์กฝั่งเซิร์ฟเวอร์ก็มักเพียงพอสำหรับงานส่วนใหญ่

  • มีการโต้แย้งต่อความเชื่อที่ว่า "ถ้าไม่ใช่ single-page app ก็สร้างเว็บแอปแบบ interactive ไม่ได้" โดยมองว่า SPA ให้การควบคุมมากกว่า และลดโอกาสที่จะต้องทำโค้ดบางส่วนใหม่

  • พาดหัวบน HN ดูดุดันกว่าพาดหัวจริงมาก นี่เป็นบทความเชิงเรียงความจากการพูดของ Tony Alaribe ที่งาน BigSkyDevCon ซึ่งพูดถึงเทคนิคในการทำให้เว็บแอปที่ไม่ได้อิงกับ SPA เร็วและลื่นไหล พร้อมแนะนำเทคโนโลยีใหม่ ๆ และมีความเห็นว่านี่คือการบรรยายที่ดีที่สุดของงานประชุม