สร้างฟรอนต์เอนด์ที่แข็งแกร่งด้วย Progressive Enhancement

• บริการของ GOV.UK ต้องทำงานแบบ HTML-first เพื่อให้ผู้ใช้ทำงานหลักให้เสร็จได้ แม้เบราว์เซอร์ อุปกรณ์ หรือสถานะการเชื่อมต่อจะแตกต่างกัน และบริการภาครัฐทั้งหมดจำเป็นต้องใช้ progressive enhancement
• HTML มี fault tolerance โดยจะละเว้นมาร์กอัปที่ไม่รู้จักและพาร์สต่อไป ทำให้มีโอกาสสูงที่จะยังคงการนำทางและฟังก์ชันพื้นฐานไว้ได้ แม้ในเบราว์เซอร์เก่าหรือหน้าเว็บที่มีข้อผิดพลาดบางส่วน
• CSS และ JavaScript เป็นเลเยอร์ที่เปราะบางกว่า: CSS อาจละเว้นชุดกฎเมื่อพบ selector ที่ไม่รู้จัก ส่วน JavaScript อาจหยุดรันโค้ดที่เหลือเมื่อเจอไวยากรณ์ที่ไม่รองรับหรือข้อผิดพลาดของ API
• ควรใช้ JavaScript เพื่อ ยกระดับ HTML และ CSS มากกว่าทดแทนฟังก์ชันหลัก และแม้แต่ autocomplete ก็ควรวางทับบนองค์ประกอบพื้นฐานอย่าง <select> เพื่อให้ผู้ใช้ทำงานต่อได้เมื่อเกิดความล้มเหลว
• เฟรมเวิร์ก JavaScript ฝั่งไคลเอนต์และ SPA อาจสร้างภาระด้านประสิทธิภาพ การเข้าถึง และการบำรุงรักษา จึงไม่จำเป็นสำหรับบริการที่เน้น GOV.UK Design System และไม่ได้มี UI ซับซ้อน

---

หลักการพื้นฐานของ Progressive Enhancement

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

เริ่มจาก HTML

• บริการภาครัฐต้อง ใช้งานได้ด้วย HTML เพียงอย่างเดียว
• ตัวอย่างบริการที่ต้องใช้งานได้ด้วย HTML เพียงอย่างเดียว ได้แก่
  • บริการเชิงธุรกรรม เช่น ฟอร์มที่ผู้ใช้ให้ข้อมูลแก่รัฐบาล
  • บริการในรูปแบบ smart answers เช่น Registering a birth abroad
  • เว็บไซต์ที่อิงเนื้อหา เช่น foreign travel advice ของ GOV.UK
• เลเยอร์ HTML มี fault tolerance โดยการออกแบบ
  • เบราว์เซอร์จะละเว้นมาร์กอัปที่ไม่เข้าใจและพาร์สต่อไปเท่าที่ทำได้
  • แม้ HTML จะมีบั๊กหรือใช้ฟีเจอร์ที่มีเฉพาะในเบราว์เซอร์รุ่นใหม่ เบราว์เซอร์เก่าก็ยังมีโอกาสสูงที่จะโหลดบริการได้
• ผู้ใช้ควรสามารถนำทางบริการได้ด้วย HTML เพียงอย่างเดียว
• ต้องใช้มาร์กอัปเชิงความหมายที่ถูกต้อง และจัด ลำดับซอร์สและโครงร่างเอกสาร อย่างเป็นตรรกะ

วิธีใช้ CSS

• สามารถใช้ CSS เพื่อจัดสไตล์ให้บริการดูเหมือน GOV.UK ได้
• เลเยอร์ CSS มี fault tolerance ค่อนข้างดี
  • เบราว์เซอร์จะละเว้น declaration รายการใดรายการหนึ่งที่ไม่เข้าใจ
  • หากใช้พร็อพเพอร์ตีที่มีเฉพาะในเบราว์เซอร์รุ่นใหม่ อาจถูกละเว้นเฉพาะ declaration นั้น
• อย่างไรก็ตาม เมื่อเบราว์เซอร์พบ selector ที่ไม่เข้าใจ อาจละเว้น ชุดกฎทั้งหมด
• CSS อาจไม่โหลดได้จากหลายสาเหตุ
• เพื่อให้ไซต์ยังแสดงผลได้ถูกต้องแม้ JavaScript ไม่โหลด ควรหลีกเลี่ยงเทคนิคอย่าง CSS-in-JS

วิธีใช้ JavaScript

• สามารถใช้ JavaScript เพื่อเพิ่ม องค์ประกอบแบบโต้ตอบ ให้บริการได้
• เลเยอร์ JavaScript ไม่มี fault tolerance
  • หากใช้ไวยากรณ์ที่เบราว์เซอร์ของผู้ใช้ไม่รองรับ หรือเรียก API ที่ไม่รองรับ จะเกิดข้อผิดพลาด
  • เมื่อเกิดข้อผิดพลาด JavaScript ส่วนที่เหลือจะไม่ทำงาน
• หากออกแบบบริการโดยไม่คำนึงถึงความเป็นไปได้นี้ ผู้ใช้อาจไม่สามารถใช้บริการได้
• วิธีเพิ่มโอกาสให้ JavaScript ทำงานได้อย่างถูกต้องในหลายเบราว์เซอร์ ได้แก่
  • ใช้ feature detection กับ browser API
  • รวม polyfill สำหรับฟีเจอร์ของเบราว์เซอร์รุ่นใหม่
  • transpile JavaScript เป็นไวยากรณ์ร่วมที่เบราว์เซอร์เป้าหมายเข้าใจได้
  • ใช้การทดสอบอัตโนมัติหรือ linter
  • ทดสอบแบบ manual เป็นประจำ รวมถึงบนอุปกรณ์เก่าหรือประสิทธิภาพต่ำ
• การ transpile และ polyfill อาจเพิ่มขนาดของ JavaScript ได้มาก
  • ต้องพิจารณา trade-off ที่เกี่ยวข้อง
  • เนื่องจากสถิติการใช้งานเบราว์เซอร์เปลี่ยนไป จึงต้องทบทวนการตัดสินใจเป็นระยะ
• หากเป็นไปได้ JavaScript ควรยกระดับ HTML และ CSS ที่ให้ฟังก์ชันหลักเดียวกัน
  • autocomplete สามารถสร้างโดยยกระดับองค์ประกอบ <select> หรือองค์ประกอบพื้นฐานที่คล้ายกัน
  • แม้ JavaScript ล้มเหลว ผู้ใช้ก็ยังทำงานที่จำเป็นต่อไปได้

ทางเลือกแทน JavaScript และช่องทางเสริม

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

เฟรมเวิร์ก JavaScript ฝั่งไคลเอนต์

• หากบริการประกอบด้วยคอมโพเนนต์ของ GOV.UK Design System เป็นส่วนใหญ่และไม่มี UI ซับซ้อน ก็ไม่จำเป็นต้องใช้ เฟรมเวิร์ก JavaScript ฝั่งไคลเอนต์
• คอมโพเนนต์ของ GOV.UK Design System มี วิธี นำ JavaScript เข้าสู่บริการโดยไม่ต้องใช้เฟรมเวิร์ก
• เฟรมเวิร์ก JavaScript ฝั่งไคลเอนต์อาจช่วยเมื่อสร้าง UI ที่ซับซ้อน แต่ขณะเดียวกันก็อาจนำปัญหาหลายอย่างเข้ามา
• ปัญหาที่อาจเกิดจากการใช้เฟรมเวิร์ก ได้แก่
  • เพิ่มขนาด codebase โดยรวมและผลักภาระการประมวลผลไปยังไคลเอนต์ ทำให้เกิดปัญหาด้านประสิทธิภาพกับผู้ใช้ที่อยู่บนเครือข่ายช้าหรือใช้อุปกรณ์ประสิทธิภาพต่ำ
  • ทำให้ต้องพึ่งพาโค้ด third-party ที่นักพัฒนาไม่ได้ควบคุม และอาจต้องเปลี่ยนแปลงบริการครั้งใหญ่เพื่อให้ทันกับการเปลี่ยนแปลงของเฟรมเวิร์ก
  • เมื่อเวลาผ่านไป หากเฟรมเวิร์กเสื่อมความนิยม อาจหาคนที่มีทักษะจำเป็นในการบำรุงรักษาได้ยากขึ้น
• หากใช้เฟรมเวิร์ก JavaScript ต้องเป็นไปตามเงื่อนไขต่อไปนี้
  • ต้องสามารถให้เหตุผลด้วยหลักฐานได้ว่าการใช้ JavaScript ให้ประโยชน์ใดแก่ผู้ใช้
  • ต้องรู้ผลกระทบเชิงลบและสามารถบรรเทาได้
  • ต้องพิจารณาว่าประโยชน์มากกว่าปัญหาที่อาจเกิดขึ้นหรือไม่
  • ต้องใช้เฟรมเวิร์กเฉพาะกับส่วนของ UI ที่ไม่สามารถสร้างด้วย HTML และ CSS เพียงอย่างเดียว
  • ต้องออกแบบแต่ละส่วนของ UI เป็นคอมโพเนนต์แยกกัน
• การแยกคอมโพเนนต์ทำให้เมื่อการโหลด JavaScript ล้มเหลว จะล้มเหลวเฉพาะคอมโพเนนต์เดียวนั้น และส่วนที่เหลือของหน้าจะโหลดได้ตามปกติ
• ต้องใช้ JavaScript เพื่อยกระดับ HTML และ CSS เท่านั้น และแม้จะล้มเหลว ผู้ใช้ก็ยังต้องสามารถใช้บริการได้

เหตุผลที่ CSS และ JavaScript อาจล้มเหลว

• CSS และ JavaScript อาจไม่โหลดหรือไม่ทำงานได้จากหลายสาเหตุ
  • ข้อผิดพลาดของเครือข่ายชั่วคราว
  • ส่วนขยายเบราว์เซอร์ third-party เช่น ad blocker
  • downtime ของผู้ให้บริการ third-party เมื่อใช้ content delivery network
  • การ lookup DNS ล้มเหลว
  • บั๊กที่เกิดจากการอัปเดตเบราว์เซอร์
  • บั๊กของ JavaScript third-party ที่ตั้งใจให้รันบนหน้าเดียวกัน
  • กรณีที่ไฟร์วอลล์องค์กรที่หน่วยงานขนาดใหญ่ใช้งาน เช่น ธนาคารหรือหน่วยงานรัฐ บล็อก ลบ หรือเปลี่ยนแปลงเนื้อหา
  • กรณีที่ผู้ให้บริการเครือข่ายมือถือเปลี่ยนแปลงเนื้อหาเพื่อลดเวลาโหลดและการใช้แบนด์วิดท์
  • กรณีที่ไฟร์วอลล์ส่วนบุคคลหรือซอฟต์แวร์แอนติไวรัสเปลี่ยนแปลงหรือบล็อกเนื้อหา
  • กรณีที่ผู้ให้บริการอินเทอร์เน็ตแทรกโค้ดของตนเองเข้าไปในหน้าผ่านการเชื่อมต่อที่ไม่ปลอดภัย และโค้ดนั้นขัดแย้งกับโค้ดของบริการ
• ผู้ใช้บางคนอาจตั้งใจปิดฟีเจอร์ของเบราว์เซอร์
• บริการควรเคารพทางเลือกของผู้ใช้ และผู้ใช้เหล่านั้นก็ยังควรใช้งานต่อได้

เหตุผลที่ควรหลีกเลี่ยง Single Page Application (SPA)

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

เกณฑ์การทดสอบ

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

[GN⁺]

ความคิดเห็นบน Hacker News

• บอกว่า “ถ้าคุณใช้เฟรมเวิร์ก JavaScript คุณควรต้องสามารถ ให้เหตุผลรองรับ ได้ว่าการใช้ JavaScript ให้ประโยชน์อะไรกับผู้ใช้” งั้นเหรอ ทุกคนใจเย็น ๆ กันหน่อย

  • เอาจริง ๆ นะ ถ้า ความซับซ้อนของซอฟต์แวร์ พังทลายลงมา อยากให้เหล่านักพัฒนาตกงานกันหรือไง
  • ไม่ใช่แค่ใช้เฉย ๆ แต่ต้องคอยเฝ้าดูมันตลอดเพื่อให้มันทำงานต่อไปได้

• เกณฑ์ที่ดีคือ ถ้าแอปสามารถทำงานแบบ offline-first ได้เหมือนแอปเดสก์ท็อป ก็ทำเป็น single-page application ได้
  ตัวอย่างเช่น Photopea, Google Docs/Sheets, tldraw และในกรณีแบบนี้มันอาจตอบสนองไวกว่าและดีกว่าแอปบนเบราว์เซอร์แบบหลายหน้า
  วิธีนี้จะตัดข้อเสียใหญ่ที่สุดอย่างการย้ายไปมาระหว่างหน้าและความจำเป็นต้องเชื่อมต่ออินเทอร์เน็ตออกไป
  แต่ถ้าแอปต้องใช้การเชื่อมต่ออินเทอร์เน็ตและมีหลายหน้า ก็ควรปล่อยให้เบราว์เซอร์จัดการ navigation ด้วยวิธีที่ทนทานต่อความขัดข้องจะดีกว่า

  • เป็นประเด็นที่ดี เว็บแพลตฟอร์มตอนนี้รับบททั้งเว็บไซต์และ GUI ข้ามแพลตฟอร์ม
    ถ้าต้องการอะไรแบบ GUI เดสก์ท็อปที่ใช้ออฟไลน์หรือใช้ได้บนหลายระบบปฏิบัติการ single-page application จะได้เปรียบ แต่ถ้าแค่อยากทำเว็บไซต์ single-page application อาจไม่ใช่ทางเลือกที่เหมาะที่สุด
  • “ตอบสนองไวกว่า” เป็นแนวคิดเก่าแล้ว ตอนนี้ HTML เองก็มีเครื่องมือมากมาย
    ตัว single-page application กับ ความซับซ้อน ที่ต้องใช้เพื่อสร้างมัน เป็นคนละเรื่องกัน
  • ถึงอย่างนั้นก็ต้องทดสอบเยอะ ๆ โดยเฉพาะในบริบทอย่าง gov.uk ยังมีผู้ใช้จำนวนไม่น้อยที่ใช้ โทรศัพท์รุ่นเก่า ซึ่งเบราว์เซอร์ไม่ได้รับการอัปเดตแล้ว เช่น Safari บน iOS 15

• ผมเริ่มทำเว็บตอนเป็นเด็กในยุค 90 ตอนนั้นไม่รู้ด้วยซ้ำว่า CSS หรือ JS คืออะไร และรู้แค่ว่า JS คือสคริปต์วิเศษที่คัดลอกมาแปะเพื่อทำให้อะไรบางอย่างกะพริบได้
  ต่อมาผมทำไซต์ไดนามิกด้วย PHP ให้ธุรกิจท้องถิ่น และตอนนั้นก็ได้เรียน JS กับ CSS พอสมควร
  แล้วผมก็เลิกทำเว็บ เพราะไม่ชอบที่ต้องเสียเวลามากเกินไปเพื่อให้มันทำงานบนเบราว์เซอร์แย่ ๆ อย่าง IE6
  ผมหายไปเกือบ 6 ปี แล้วกลับมาราวปี 2015 เพราะตระหนักว่าเว็บเซิร์ฟเวอร์น่าจะมีประโยชน์กับงานที่ทำอยู่
  แต่ผมช็อกเมื่อเห็นว่าโลกได้ลืมหลายสิ่งที่เคยรู้เกี่ยวกับ HTML และ CSS ไปแล้ว
  สมัยก่อนเราทำสไตล์ชีตหลายชุดให้ไซต์ ทำให้มันทำงานได้โดยไม่ต้องมี JS ก่อน แล้วค่อยเพิ่ม JS เข้าไปเป็นส่วนปรับปรุงเพิ่มเติม แต่วิธีแบบนั้นถูกลืมไปแล้ว
  ผมเห็นนักพัฒนาเว็บทำการตรวจสอบฟอร์มทั้งหมดด้วย JS เท่านั้น และฝั่งเซิร์ฟเวอร์ไม่ทำอะไรเลย ซึ่งน่าประหลาดใจที่ทุกวันนี้ก็ยังพบได้บ่อย
  ส่วนแพตเทิร์นทั่วไปที่ให้เซิร์ฟเวอร์ตรวจสอบแล้ว JS แค่แสดงผลลัพธ์นั้น ผมไม่ค่อยเห็นนัก ดูเหมือนทุกคนจะทำซ้ำทั้งสองฝั่ง หรือไม่ก็ไม่ตรวจสอบฝั่งเซิร์ฟเวอร์เลย
  พอเห็นแบบนี้แล้ว สิ่งที่ผู้คนทำบนเว็บก็ไม่ทำให้ผมประทับใจอีกต่อไป มันไม่ใช่เว็บที่ผมรู้จัก แต่เป็นแค่ “แอปพลิเคชัน” ที่สร้างด้วย JS และการยืนกรานแนวทาง web-first ก็เป็นศึกที่แพ้ไปแล้ว

  • ประสบการณ์คล้ายกัน
    ผมเริ่มจาก HTML 3.2/XHTML และ CSS ตอนเด็ก ๆ แล้วอีกไม่กี่ปีต่อมาก็ทำงาน Django + jQuery ก่อนจะเริ่มสนใจสาย infra
    ประมาณหนึ่งปีก่อนผมได้ทำงานร่วมกับทีมพัฒนาเว็บและลองดูสิ่งที่พวกเขาทำ แต่กลับไม่เข้าใจอะไรอีกแล้ว
    ความซับซ้อนมันท่วมท้น และดูเหมือนเวลาส่วนใหญ่หมดไปกับ การจัดการความซับซ้อน เช่น ลดเวลา build, แก้ปัญหา dependency, จัดการปัญหา TypeScript แปลก ๆ, จัดการข้อผิดพลาดของคอมโพเนนต์หลายตัว
    ในยุค Django+jQuery ยังมีการโฟกัสกับสิ่งที่ผู้ใช้มองเห็นและใช้งานได้จริง
  • ผมมองว่า การตรวจสอบฝั่งไคลเอนต์ ช่วยลดภาระเซิร์ฟเวอร์ได้ เพราะสามารถกันไม่ให้ส่ง request ที่ไม่จำเป็นไปยังเซิร์ฟเวอร์เพียงเพื่อเช็กว่าชื่อผู้ใช้ยาวน้อยกว่า 16 ตัวอักษรหรือไม่
    แน่นอนว่าเชื่อถือไคลเอนต์ไม่ได้เด็ดขาด ดังนั้นภายหลังต้องตรวจสอบซ้ำบนเซิร์ฟเวอร์ด้วย
    การลดโหลดของเซิร์ฟเวอร์เป็นเรื่องมีประโยชน์

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

  • แต่ถ้าเป็น HTML ล้วน ๆ สิ่งเหล่านั้นมีให้โดยปริยายในระดับหนึ่ง
    ทันทีที่ก้าวเข้าไปในอาณาเขตของ single-page application คุณต้องประดิษฐ์ล้อใหม่อีกมากเพื่อกลับไปให้ได้ระดับเทียบเท่า หรือเปลี่ยนฟีเจอร์ native ให้กลายเป็นสิ่งทดแทนด้วย JS
    ลองนึกถึงฟอร์มหลายหน้า มี single-page application สักกี่ตัวที่เก็บทุกอย่างไว้ในหน่วยความจำแล้วค่อยส่ง request เดียวตอนท้าย
    ถ้าไม่มี JS ฝั่ง backend ก็คงเก็บสถานะของแต่ละขั้นไว้ เพื่อให้ภายหลังกลับมาที่ฟอร์มหรือรีเฟรชแล้วไม่สูญหาย
  • ทำได้ก็จริง แต่มันยากกว่ามาก และข้อเท็จจริงที่ว่าส่วนใหญ่ไม่ใส่ใจก็แปลว่าการ implement มันไม่ได้จิ๊บจ๊อยนัก
    ในเมื่อเว็บไซต์ HTML พื้นฐานทำงานได้ดีด้วยค่าเริ่มต้นอยู่แล้ว ทำไมต้องบังคับให้ใช้ของห่วย ๆ แบบนั้นด้วย
  • ตรงส่วนนั้นถ้าใส่คำอย่าง “โดยไม่ต้องลงแรงเพิ่มเติม” ก็น่าจะชัดเจนขึ้น
  • ถ้าจะบอกให้เคารพแม้กระทั่งฟีเจอร์ที่ผู้ใช้ตั้งใจปิดใช้งาน แล้วจะทำให้เป็นไปได้อย่างไร
    ถ้าไม่อนุญาตให้ผู้ใช้ไปแตะประวัติ navigation หลังจากนั้นแล้ว ทางเลือกก็เหลือเพียงอย่างเดียว
    คือสร้าง ประวัติเบราว์เซอร์ ให้ถูกต้อง ณ ตอนที่บันทึกประวัติถูกใช้งาน

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

  • คงปิดโรงไฟฟ้าได้ง่าย ๆ หลายสิบแห่งเลย

• ของเก่ากลับมาเป็นของใหม่อีกครั้ง
  เราไม่ควรให้ความสำคัญกับ วิธีแก้ปัญหาที่เรียบง่ายที่สุดเท่าที่เป็นไปได้ มากกว่าสิ่งที่กำลังฮิตในวันนี้หรือ

  • เพราะการตามกระแส นักพัฒนา 99.9% จึงไร้ประโยชน์ และไม่ควรมีตำแหน่งว่า engineer
  • ไม่จำเป็นต้องเป็นแบบนั้นเสมอไป รัฐบาลสหราชอาณาจักรไม่เคยสนับสนุนการใช้ JavaScript ในบริการเว็บเลย และลงทุนอย่างมากกับ design system ที่อิง HTML/CSS โดยมี accessibility เป็นแกนหลัก
    ไม่ใช่ว่าทุกคนเป็นแบบนั้น เพียงเพราะส่วนที่เหลือของอุตสาหกรรมมัวเมา JS
  • เพิ่งดูคีย์โน้ต Rails World ของ DHH มา ถึงผมจะไม่ได้ทำ Rails แต่ก็เห็นด้วยเต็มที่กับมุมมองของเขาว่าเว็บสมัยใหม่เดินไปทางไหนแล้ว

• ทำไมในรายการนี้ถึงไม่มี Linux?
  https://www.gov.uk/service-manual/technology/designing-for-d...

  • คำตอบแบบง่าย ๆ คือ เพราะ Linux เป็น เคอร์เนล
    คำตอบที่จริงจังกว่านั้นแต่ยังอยู่ในบริบทเดียวกันคือ เพราะมีดิสโทรอยู่หลายสิบตัว และถ้ารวมฟอร์กตระกูล Mozilla เข้าไปด้วย เบราว์เซอร์ก็มีราวสิบตัว
    จะเลือกดิสโทร/เบราว์เซอร์ที่เป็นทางการสักตัวก็ได้ แต่ฐานผู้ใช้ของตัวที่เลือกแบบนั้นจะเล็กมาก
    แม้แต่ Ubuntu เอง จากตัวเลขที่พอคำนวณได้ด้วยตัวชี้วัดทางอ้อม ก็ดูเหมือนจะมีส่วนแบ่งระบบปฏิบัติการเดสก์ท็อปราว 1%
  • ทำไมมันถึงควรอยู่ในรายการนั้น? มีกรณีไหนที่เว็บเพจทำงานบน macOS กับ Windows แต่ไม่ทำงานบน Linux บ้าง
  • เพราะสัดส่วนผู้ใช้ต่ำกว่า 2% หรือเปล่า?

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

  • ในฐานะผู้ใช้ปลายทาง ผมชอบสไตล์แอปพลิเคชันที่ GOV.UK สร้างและแนะนำมากจริง ๆ
    เบา เลย์เอาต์สะอาด เข้าถึงได้ดี และโดยทั่วไปใช้ JavaScript ให้น้อยที่สุด หรือแม้ไม่มีเลยก็ยังทำงานได้
    ตรงกันข้าม ผมไม่ชอบแอปพลิเคชันหน้าเดียวส่วนใหญ่ มันทำลายฟังก์ชันเบราว์เซอร์ที่คาดหวังไว้หลายอย่าง ใช้ไม่ได้ถ้าไม่มี JavaScript และมักโหลด dependency หนัก ๆ สารพัดจากไซต์บุคคลที่สามหลายแห่ง
    แต่ สิ่งที่ผู้ใช้ชอบ กับสิ่งที่นักพัฒนาชอบและสร้างได้เร็ว มักแตกต่างกันมาก
  • อาจเป็นเพราะยังไม่เคยมีใครถูกไล่ออกเพราะสร้างแอปด้วย React ละมั้ง
    เมื่อสิ่งใดถูกยอมรับเป็นมาตรฐานอุตสาหกรรม การตัดสินใจไหลตามกระแสก็เป็นทางเลือกที่ปลอดภัย
    แถมไม่มีใครทำ developer relations ให้ HTML/CSS/JS ล้วน ๆ ด้วย
    พอค้นหาวิธีทำอะไรสักอย่าง ผลลัพธ์แทบทั้งหมดก็มีแต่เนื้อหาเกี่ยวกับเฟรมเวิร์ก
  • เพราะการสร้างเว็บไซต์ที่ช้า เปราะบาง และไม่มีประสิทธิภาพนั้นไม่มีต้นทุน
    ถ้าสร้างโปรแกรมที่รันบนคอมพิวเตอร์ของตัวเอง ก็ต้องรับต้นทุนนั้นเอง และอย่างน้อยต้องอธิบายกับฝ่ายการเงินว่าทำไมค่าใช้จ่ายคลาวด์ถึงเพิ่มขึ้น 5%
    แต่ถ้ารันซอฟต์แวร์บนอุปกรณ์ของคนอื่นเหมือนนักพัฒนาฟรอนต์เอนด์ ต้นทุนแทบไม่มี
    สัญญาณลบต้องเข้ามาผ่านช่องทางอย่างรายงานจากผู้ใช้ ticket ซัพพอร์ต หรือบางทีโพสต์บน Twitter และกระบวนการเหล่านั้นมี selection bias มาก จึงมีโอกาสสูงที่จะมองไม่เห็นภาพรวม
    สุดท้ายทั้งหมดเป็นเรื่องของ แรงจูงใจ
  • เพราะยังมีกระแสที่อยากทำสิ่งต่าง ๆ บนเว็บให้มากขึ้นด้วย
    เว็บกำลังเข้ามาแทนที่ไคลเอนต์แบบหนาแบบดั้งเดิม และไคลเอนต์พวกนั้นก็สมมติว่ามีการเชื่อมต่อเครือข่ายที่ค่อนข้างเสถียรกับสเปกแพลตฟอร์มระดับหนึ่งอยู่แล้ว
    ระบบภาครัฐ แม้จะไม่ได้พบบ่อยนัก แต่ต้องทำงานได้บน ตัวหารร่วมต่ำสุด
    สตาร์ทอัพเทคโนโลยีในตอนแรกอาจมีลูกค้าแค่ 1 รายก็ยังอยู่ได้ และเมื่อโตขึ้นก็เชื่อได้ว่าความต้องการของตัวเองจะค่อย ๆ กลายเป็นเรื่องทั่วไป
  • เพราะคนที่ชอบแนวทางแบบนี้ไม่ใช่นักพัฒนาฟรอนต์เอนด์
    จริง ๆ แล้วผมคิดว่าเป็นเพราะเป็นนักพัฒนาฟรอนต์เอนด์จึงไม่ชอบแนวทางนี้ ไม่อย่างนั้น ฟรอนต์เอนด์ ให้พัฒนาก็แทบจะไม่มีเหลือ

• แนวทางที่ผมพยายามทำตามก็เป็นแบบนี้เหมือนกัน คือส่ง HTML พร้อมข้อมูลที่ดึงไว้ล่วงหน้าจากเซิร์ฟเวอร์ สิ่งไหนทำบนไคลเอนต์ได้ก็ให้ไคลเอนต์จัดการเพื่อลดการไปกลับกับเซิร์ฟเวอร์ ใช้ CSS ขั้นต่ำเพื่อทำเลย์เอาต์แบบ responsive และใช้ JS ล้วน
  ถ้าจำเป็นก็แยกเป็นหน้าเว็บต่างหากได้
  แต่ดูเหมือนสำหรับเพื่อนร่วมงานแล้ว แค่บอกว่าใช้แต่ HTML, CSS และ JS ล้วน ๆ ก็ฟังดูแปลกและเชยไปแล้ว
  ก็ไม่ได้ขาดอะไรเป็นพิเศษนะ

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