การสร้างฟรอนต์เอนด์ที่แข็งแกร่งด้วยการพัฒนาแบบค่อยเป็นค่อยไป

 (gov.uk)
1 คะแนน โดย GN⁺ 2024-09-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

วิธีสร้างฟรอนต์เอนด์ที่แข็งแกร่ง: การพัฒนาแบบค่อยเป็นค่อยไป

  • เริ่มจาก HTML

    • บริการภาครัฐควรใช้งานได้แม้มีเพียง HTML
    • ชั้นของ HTML มีความทนทานต่อความผิดพลาด จึงยังทำงานได้แม้บนเบราว์เซอร์รุ่นเก่า
    • ควรใช้ semantic markup ที่ถูกต้อง และจัดโครงสร้างเอกสารอย่างมีเหตุผล

  • การใช้ CSS

    • สามารถใช้ CSS เพื่อจัดรูปแบบบริการได้
    • ชั้นของ CSS มีความทนทานต่อความผิดพลาด เพราะสามารถละเลย declaration บางรายการได้
    • ควรหลีกเลี่ยงเทคนิคอย่าง 'CSS-in-JS'

  • การใช้ JavaScript

    • JavaScript ใช้เพื่อเพิ่มองค์ประกอบเชิงโต้ตอบ
    • ชั้นของ JavaScript ไม่มีความทนทานต่อความผิดพลาด และอาจเกิดข้อผิดพลาดได้
    • สามารถเพิ่มความเข้ากันได้ด้วยการตรวจจับความสามารถของ browser API, การใส่ polyfill, การ transpile เป็นต้น
    • JavaScript ควรทำหน้าที่เสริม HTML และ CSS

  • ทางเลือกแทน JavaScript

    • ควรพิจารณาโซลูชันที่เรียบง่ายซึ่งตอบโจทย์ผู้ใช้ได้โดยไม่ต้องใช้ JavaScript
    • ทางเลือกอาจรวมถึงการแสดง data table, การส่งออกข้อมูล, การเรนเดอร์กราฟเป็นรูปภาพไว้ล่วงหน้า เป็นต้น

  • การใช้เฟรมเวิร์ก JavaScript ฝั่งไคลเอนต์

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

  • เหตุผลที่ CSS หรือ JavaScript อาจโหลดหรือรันไม่ได้

    • อาจเกิดจากความผิดพลาดของเครือข่าย, ส่วนขยายเบราว์เซอร์, การหยุดให้บริการของผู้ให้บริการภายนอก, ความล้มเหลวของการค้นหา DNS, บั๊กจากการอัปเดตเบราว์เซอร์ เป็นต้น
    • ผู้ใช้บางรายอาจปิดความสามารถบางอย่างของเบราว์เซอร์โดยตั้งใจ

  • แอปพลิเคชันหน้าเดียว (SPA)

    • ไม่ควรสร้างบริการเป็นแอปพลิเคชันหน้าเดียว
    • SPA อาจกระทบต่อการเข้าถึง และทำให้เกิดปัญหา เช่น การจัดการโฟกัสระหว่างการย้ายหน้า และการใช้ปุ่มย้อนกลับ/ถัดไปไม่ได้

  • การทดสอบบริการ

    • องค์ประกอบที่พึ่งพา JavaScript หรือเฟรมเวิร์ก JavaScript อย่างมากควรทำงานได้ในเบราว์เซอร์และอุปกรณ์ที่หลากหลาย
    • ควรทดสอบเพื่อการเข้าถึง

  • กรณีศึกษาและคู่มือที่เกี่ยวข้อง

    • เหตุผลที่ควรใช้การพัฒนาแบบค่อยเป็นค่อยไป
    • การออกแบบสำหรับอุปกรณ์หลากหลายประเภท
    • วิธีทดสอบประสิทธิภาพฟรอนต์เอนด์
    • ทำความเข้าใจ WCAG 2.2

สรุปโดย GN⁺

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

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

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

 
GN⁺ 2024-09-30
ความคิดเห็นจาก Hacker News

  • เมื่อใช้ JavaScript framework ต้องสามารถพิสูจน์ได้ว่ามันให้ประโยชน์อะไรกับผู้ใช้

    • ถ้าเป็นแอปที่สามารถทำงานแบบออฟไลน์ได้เหมือน desktop app ก็ควรทำเป็น single-page application (SPA)
    • ตัวอย่างเช่น Photopea, Google Docs/Sheets, tldraw
    • ถ้าเป็นแอปที่ต้องใช้อินเทอร์เน็ตและมีหลายหน้า ก็ควรให้เบราว์เซอร์จัดการการนำทาง

  • ประเด็นที่ถูกชี้ว่าเป็นข้อเสียของ SPA

    • ผู้ใช้เทคโนโลยีสิ่งอำนวยความสะดวกอาจไม่รับรู้การเปลี่ยนบริบทเมื่อมีการย้ายหน้า
    • ไม่สามารถจัดการ focus ได้เมื่อมีการย้ายหน้า
    • ไม่สามารถใช้ปุ่มย้อนกลับและไปข้างหน้าของเบราว์เซอร์ได้
    • หากการเชื่อมต่อเครือข่ายหลุด จะไม่สามารถกู้คืนจากข้อผิดพลาดได้
    • แต่ปัญหาเหล่านี้ก็สามารถแก้ได้ใน SPA เช่นกัน

  • อยากให้อินเทอร์เน็ตทั้งโลกทำตามคำแนะนำนี้

  • ควรให้ความสำคัญกับโซลูชันที่เรียบง่ายก่อน

  • สงสัยว่าทำไม Linux ถึงไม่อยู่ในรายการ

  • ดูเหมือนว่าหลายคนจะชอบแนวทางนี้

    • สงสัยว่าทำไมเทรนด์ทั่วไปถึงนิยมใช้ JavaScript และ framework อย่าง React โดยไม่จำเป็น

  • ใช้ HTML และข้อมูลที่ดึงมาจากเซิร์ฟเวอร์ล่วงหน้า และให้ฝั่งไคลเอนต์จัดการสิ่งที่ทำได้บนไคลเอนต์

    • ใช้ CSS ให้น้อยที่สุดและใช้ vanilla JS
    • สำหรับเพื่อนร่วมงานอาจดูเชย แต่ก็ไม่ได้พลาดอะไร

  • SPA หลายตัวมีปัญหา แต่ไม่ได้หมายความว่า SPA ทุกตัวมีปัญหา

    • ถ้าดูตัวอย่างอย่าง VitePress และ SolidJS ก็ทำงานได้ดี
    • แทบไม่มีใครที่ไม่ใช้ JS
    • แม้แต่อุปกรณ์สเปกต่ำก็ไม่มีปัญหาในการประมวลผล JS
    • ปัญหาเรื่องการเข้าถึงไม่ได้เกี่ยวข้องกับการใช้ SPA หรือไม่ใช้ SPA
    • Svelte ยังมีฟีเจอร์เตือนเรื่อง accessibility ในตัวด้วย

  • server-side rendering ก็ไม่ได้ดีเสมอไป

    • ต้องระมัดระวังเมื่อใช้ client-side JavaScript framework
    • codebase อาจใหญ่ขึ้น และมีงานที่ต้องประมวลผลฝั่งไคลเอนต์มากขึ้นจนเกิดปัญหาด้านประสิทธิภาพ
    • อาจต้องพึ่งพา third-party code จนดูแลรักษายากขึ้น
    • เมื่อใช้ JavaScript framework ต้องสามารถพิสูจน์ได้ว่ามันให้ประโยชน์อะไรกับผู้ใช้
    • ต้องตระหนักถึงผลกระทบด้านลบและสามารถบรรเทาได้
    • ควรใช้ framework เฉพาะในส่วนที่ไม่สามารถสร้างได้ด้วย HTML และ CSS เพียงอย่างเดียว
    • ควรออกแบบแต่ละส่วนของ user interface ให้เป็น component แยกกัน
    • แม้ JavaScript จะไม่ถูกโหลด ส่วนที่เหลือของหน้าก็ควรโหลดได้ตามปกติ