วิธีสร้างเว็บไซต์แบบ HTML-first จนเพิ่มจำนวนผู้ใช้เป็นสองเท่าภายในข้ามคืน

 (mohkohn.co.uk)
1 คะแนน โดย GN⁺ 4 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • แนวทาง HTML-first ทำให้ฟอร์มสมัครใช้บริการสาธารณะทำงานได้แม้ไม่มี JavaScript และช่วยให้ผู้ใช้กรอกคำขอได้สำเร็จแม้ใช้อุปกรณ์ เบราว์เซอร์ หรือเครือข่ายที่มีข้อจำกัด
  • แอป React เดิมถูกถอดออกภายใน 3 วันเพราะคำร้องเรียนจากลูกค้า โดยปัญหามาจาก loading spinner, สถานะ JavaScript แบบ global, ปัญหาด้านการเข้าถึง และวิธีเก็บรูปภาพที่ชนข้อจำกัด 5MB ของ localStorage
  • การใช้งานใหม่สร้างบน Astro โดยแยกแต่ละขั้นของฟอร์มเป็นคนละหน้า และบันทึกข้อมูลที่ส่งกับไฟล์อัปโหลดไว้ใน backend session ทีละขั้น เพื่อป้องกันข้อมูลที่กรอกหาย
  • การตรวจสอบฟอร์มทำผ่าน web component ที่ครอบระบบตรวจสอบ HTML ในตัวเบราว์เซอร์ และใช้โครงสร้าง progressive enhancement ที่หากล้มเหลวจะถอยกลับไปใช้การตรวจสอบพื้นฐานของเบราว์เซอร์และการตรวจสอบจาก backend API
  • หลังเปิดใช้งาน จำนวนผู้ใช้ที่กรอกฟอร์มสำเร็จเพิ่มเป็นสองเท่า และยังเผยให้เห็นว่าผู้ใช้ที่หลุดออกไปเพราะ JavaScript ล้มเหลวจะไม่ถูกนับโดยแพ็กเกจวิเคราะห์ที่อิง JavaScript

ภูมิหลังของปัญหาและความพยายามก่อนหน้าที่ล้มเหลว

  • ลูกค้าเป็นบริษัทสาธารณูปโภค และการสมัครใช้บริการทำได้ผ่านฟอร์ม ASP แบบเก่าบนเว็บไซต์หรือผ่านขั้นตอนที่ทำด้วยมือ
  • ขั้นตอนแบบทำมือมีต้นทุนต่อบริษัทสูงกว่า และอยู่ในบริบทของกิจการผูกขาดที่ถูกกำกับดูแล ซึ่งหากความพึงพอใจของลูกค้าต่ำกว่า 96% อาจโดนปรับเป็นเงินหลายล้านปอนด์
  • ความพยายามก่อนหน้าในการแก้ปัญหาล้มเหลวมาแล้วสองครั้ง และในครั้งล่าสุดมีผู้รับเหมาจากต่างประเทศสร้างแอป React ขึ้นมา
  • แอป React ถูกถอดออกหลังเปิดสาธารณะได้ 3 วันเพราะคำร้องเรียนจากลูกค้า
  • แอปดังกล่าวปนกันไปด้วย loading spinner และสถานะ JavaScript แบบ global อีกทั้งยังไม่รองรับการเข้าถึงอย่างเหมาะสม
  • การอัปโหลดรูปภาพเป็นฟีเจอร์สำคัญของฟอร์ม แต่มีการพยายามเก็บทั้งรูปภาพและข้อมูลฟอร์มทั้งหมดไว้ใน localStorage ที่มีข้อจำกัด 5MB

เกณฑ์ที่กำหนดไว้สำหรับแนวทาง HTML-first

  • เว็บไซต์ใหม่สร้างด้วย Astro และเลือกใช้โครงสร้างแบบ HTML-first
  • JavaScript ถูกใช้เฉพาะภายใน web component และมีหน้าที่ค่อย ๆ เสริมประสบการณ์ให้เว็บไซต์ที่ทำงานได้ตามปกติอยู่แล้วโดยไม่ต้องพึ่ง JavaScript
  • มีการตั้งเกณฑ์ว่าบริการสาธารณะต้องใช้งานได้บนอุปกรณ์ทุกแบบเท่าที่เป็นไปได้
  • มีการตั้งเกณฑ์ว่าต้องทำงานได้แม้การเชื่อมต่อจะแย่
  • มีการตั้งเกณฑ์ว่าข้อมูลที่ผู้ใช้กรอกแล้วต้องไม่หายไปเด็ดขาด
  • กรณีศึกษาของ Terence Eden แสดงให้เห็นว่าหน้า HTML เรียบง่ายของ GOV.UK สามารถทำให้ผู้ใช้เปิดอ่านข้อมูลสวัสดิการที่อยู่อาศัยได้แม้บนเบราว์เซอร์ PlayStation Portable ที่ช้าและหน่วยความจำไม่พออยู่บ่อยครั้ง
  • หน้า GOV.UK ถูกเขียนเป็น HTML เรียบง่ายที่ออกแบบมาให้เบา และต้องทำงานได้แม้บนเบราว์เซอร์ที่แย่มาก

โครงสร้างฟอร์มและวิธีเก็บรักษาข้อมูล

  • แต่ละเซสชันของฟอร์มต้องมี ID ที่ไม่ซ้ำกัน
  • ในทุกขั้นของ form wizard ข้อมูลที่ส่งและไฟล์อัปโหลดต้องถูกบันทึกไว้ที่ backend
  • ต้องกรอกฟอร์มให้เสร็จได้แม้ไม่มี JavaScript
  • ต้องกรอกฟอร์มให้เสร็จได้แม้ใช้เว็บเบราว์เซอร์เก่าที่ประสิทธิภาพต่ำ
  • การเข้าถึงต้องผ่านเกณฑ์ WCAG และทีมตั้งเป้าไว้ที่ระดับ AA ไม่ใช่ AAA
  • JavaScript และ CSS สมัยใหม่ควรถูกใช้เพื่อยกระดับประสบการณ์เท่านั้น
  • ในโครงสร้างสุดท้าย แต่ละขั้นของ form wizard กลายเป็นคนละหน้า และเมื่อผู้ใช้กดถัดไป ฟอร์มจะถูกส่ง
  • หาก API ตัดสินว่าข้อมูลใช้ได้ เบราว์เซอร์จะถูก redirect ไปยังขั้นถัดไป
  • รูปแบบการส่งฟอร์มแล้ว redirect เป็นแพตเทิร์นเว็บแอปแบบเก่า และได้กลับมาได้รับความนิยมสมัยใหม่เล็กน้อยจาก Remix
  • บริการนี้ไม่ใช่แอปที่แสดงข้อมูลแบบเรียลไทม์ แต่เป็นฟอร์มขนาดใหญ่ ดังนั้นแนวทางส่ง JavaScript 20MB มาก่อนการเรนเดอร์จึงไม่เหมาะสม

การตรวจสอบฟอร์มและ progressive enhancement

  • การตรวจสอบฟอร์มและการเรนเดอร์ข้อผิดพลาดของฟอร์มมักถูกมองว่าเป็นพื้นที่ที่ทีมต้องเสียเวลาหลายชั่วโมง เพราะมีไลบรารีตรวจสอบของ React เข้ามาเกี่ยวข้อง
  • แต่ในเบราว์เซอร์มีระบบตรวจสอบมาให้อยู่แล้ว และสามารถนำมาใช้ด้วยงานที่น้อยกว่าการดูแลชุดเลียนแบบคุณภาพต่ำที่ทำแยกขึ้นมา
  • HTML web component ที่สร้างขึ้นเป็น custom element แบบเรียบง่ายซึ่งครอบ HTML เดิมไว้
  • web component นี้ไม่ได้ใช้ shadow DOM และแทบไม่ได้เรนเดอร์ HTML ภายใน JavaScript เลย
  • คอมโพเนนต์นี้ครอบฟอร์ม HTML แล้วดึงการตรวจสอบแบบ HTML มาแสดงในรูปแบบที่ทันสมัย
  • มันบล็อก tooltip popup การตรวจสอบแบบ HTML และวางข้อความผิดพลาดไว้ใน element ที่ผูกกับฟิลด์ผ่าน aria-describedby
  • ปัจจุบันแนะนำให้ใช้ aria-errormessage
  • เมื่อค่าที่กรอกกลับมาอยู่ในสถานะถูกต้องระหว่างพิมพ์ การตรวจสอบจะถูกล้าง และจะประเมินใหม่อีกครั้งตอน blur และตอนส่งฟอร์ม
  • ประสบการณ์ผู้ใช้นี้ถูกส่งมาด้วยขนาดไม่ถึง 1KB และหากล้มเหลวก็จะถอยกลับไปใช้การตรวจสอบพื้นฐานของเบราว์เซอร์
  • หากการตรวจสอบพื้นฐานของเบราว์เซอร์ยังล้มเหลวอีก backend API จะเป็นผู้จัดการการตรวจสอบต่อ
  • ปัญหาการตรวจสอบจะถูกแจ้งให้ผู้ใช้ทราบเร็วที่สุดเท่าที่เบราว์เซอร์ของผู้ใช้เอื้อ และแม้จะล้มเหลวก็ยังถอยกลับไปสู่ประสบการณ์ที่ยอมรับได้เสมอ
  • ต่อมามีการเขียน web component เวอร์ชันใหม่ขึ้นใหม่ทั้งหมดตั้งแต่ต้นสำหรับการใช้งานทั่วไป โดยใช้ชื่อว่า validation-enhancer
  • ตัวอย่างการใช้งานคือ validation-enhancer ครอบฟอร์ม HTML และยังใช้ input type="email", required, aria-errormessage ตามเดิม

Email

Submit

ผลลัพธ์หลังเปิดใช้งานและข้อสรุป

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

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

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

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News

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

    • ไม่กี่ปีมานี้ฉันเพิ่งตระหนักว่า วิศวกรระดับ junior และ mid-level บางคนไม่เคยคิดอย่างจริงจังเลยว่ามันเป็นไปได้ที่จะสร้างเว็บไซต์โดยไม่ใช้ เฟรมเวิร์ก single-page app ที่หนัก ๆ
      ไม่ใช่ว่าพวกเขาโง่ ถ้าถามตรง ๆ ว่า “สร้างเว็บไซต์โดยไม่ใช้ React ได้ไหม?” แน่นอนว่าพวกเขาจะตอบว่า “ได้” แต่ถ้าขอให้เริ่มทำเว็บไซต์ใหม่ พวกเขามักจะเปิดโปรเจ็กต์ React ใหม่แบบอัตโนมัติ เพราะความคุ้นเคยและเพราะแค่อยากให้งานเสร็จ
      บางคนไม่รู้วิธีอื่นจริง ๆ พวกเขาไม่รู้แม้แต่ว่าจะตั้ง HTTP server ธรรมดาที่ส่ง HTML ล้วนได้อย่างไร หรือไม่เคยมีประสบการณ์ทำฟอร์มที่ตรวจสอบและส่งข้อมูลได้โดยไม่ใช้ JavaScript คนกลุ่มนี้ไม่ใช่คนที่เขียนโพสต์บน HN และก็ไม่เข้าร่วมการถกเถียงออนไลน์เกี่ยวกับเครื่องมือหรือเทคโนโลยีใหม่ ๆ หรือแม้แต่เครื่องมือและเทคโนโลยีเก่า ๆ พวกเขาเรียนจากบูตแคมป์หรือวิชา webapp ในมหาวิทยาลัยเพียงวิชาเดียว เท่าที่จำเป็นสำหรับหางาน แล้วหลังจากนั้นก็เรียนเฉพาะเครื่องมือที่นายจ้างต้องการ หรือที่ใครบางคนในทีมเลือกใช้ ณ ตอนนั้น
      ในฐานะคนอายุมากกว่า ฉันใช้เวลาสักพักกว่าจะสังเกตเห็นเรื่องนี้ แต่ตอนนี้ก็เข้าใจแล้ว เส้นทางอาชีพของแต่ละคนต่างกัน บางคนจึงได้เจอกับพื้นฐานที่ง่ายที่สุดของ HTML, CSS และ JavaScript ล้วน ช้ากว่าส่วนที่เป็นเฟรมเวิร์กเฉพาะซึ่งซับซ้อนกว่าของแต่ละเทคโนโลยีเสียอีก ทำให้สำหรับพวกเขา สิ่งนี้ไม่ได้ดูไม่เป็นมืออาชีพกว่า แต่กลับรู้สึกว่ายากกว่า ลึกกว่า หรือเป็นความรู้เฉพาะทางมากกว่า
      คำพูดว่า “แบบนั้นจะทำให้งานเราเพิ่มขึ้นเยอะ” ก็อาจไม่ใช่คำกล่าวที่ผิดโดยเจตนาเสมอไป หากต้องทำงานด้วยเครื่องมือที่ไม่คุ้นเคย ก็มีโอกาสมากที่มันจะรู้สึกว่าเป็นงานเพิ่มขึ้นมากจริง ๆ ต่อให้ตัวเครื่องมือนั้นซับซ้อนน้อยกว่าก็ตาม
    • ตอนเริ่มบริษัทใหม่เมื่อ 2 ปีก่อน ฉันตัดสินใจตั้งแต่แรกว่าจะไม่ใช้เฟรมเวิร์ก JavaScript แบบ single-page app ที่หนัก ๆ ฉันคงไว้ที่ HTML แบบ server-rendered ธรรมดา และใช้ JavaScript แค่ในลักษณะ progressive enhancement เท่านั้น
      แอปนั้นเร็วและเรียบง่าย แต่ก็มีต้นทุนตามมา ความสามารถในการหยิบองค์ประกอบ UI ที่ซับซ้อนจากแพ็กเกจ npm มาใช้ตรง ๆ มีจำกัด และการจะมอบประสบการณ์ผู้ใช้ที่ดีต้องใช้แรงมากกว่ามาก ทุกอย่างใช้เวลานานขึ้น และสุดท้ายประสบการณ์ผู้ใช้ก็แย่ลงด้วย ฉันใส่ใจเรื่องนี้นะ แต่บางทีก็ไม่มีเวลาพอจะเก็บรายละเอียดจนจบ
      บริษัทล้มเหลว และฉันไม่ได้คิดว่า React จะช่วยกอบกู้มันได้ แต่ฉันพูดจากประสบการณ์ตรงได้เลยว่าการยึดติดกับ “ความเรียบง่าย” ในเชิงศีลธรรมก็ไม่ได้ช่วยอะไร มันเป็นเรื่องของ trade-off เสมอ
    • ในฐานะคนที่ต้องอ่านโค้ดที่คนอื่นเขียนเยอะมาก ฉันมั่นใจเลยว่าสำหรับหลายคน การเรียนรู้วิธีใหม่ ๆ ถูกมองเหมือนเป็นเรื่องที่ยากที่สุดในโลก
    • ฉันคิดว่าปัญหาคือเราได้ฟังแค่ด้านเดียว
      มีคนบอกว่าเขาได้เสนอวิธีแก้ที่เรียบง่ายและสมเหตุสมผลกว่าสิ่งที่คนส่วนใหญ่น่าจะคิดถึง แต่คนที่รับงานต่อกลับไม่พอใจ
      เรารู้ไหมว่าโค้ดที่ส่งต่อมานั้นคุณภาพสูงหรือเปล่า? คนนั้นกำลังตอบสนองเพียงเพราะ “มันไม่ใช่ React” หรือไม่? เป็นไปได้ไหมว่าบริษัทมีเทมเพลตบังคับสำหรับวิธีสร้างแอปอยู่แล้ว?
      ไม่มีทางรู้
    • มีโอกาสสูงว่าจะเกี่ยวกับเทคโนโลยีที่ผู้คนคุ้นเคย เวลาสร้างเว็บแอปมีนักพัฒนาเว็บหลายรุ่นที่รู้จักแค่ ecosystem ของ JavaScript ดังนั้นสิ่งที่ไม่ใช่วิธีแก้แบบ JavaScript ล้วนจึงอาจดูแปลกสำหรับพวกเขา

  • ช่วงหลังไม่ค่อยได้ยินบ่อยนัก แต่ข้อเสนอ HTML Triptych ยังเป็นหนึ่งในสิ่งที่ฉันหวังว่าสักวันจะเข้าไปอยู่ในเบราว์เซอร์ วิธีที่ HTML form คุยกับ REST endpoint เป็นแพตเทิร์นที่ดี
    การตรวจสอบเพื่อช่วยผู้ใช้จัดการผ่าน input attributes ส่วนการตรวจสอบจริงทำที่อีกฝั่งของ request และ flow จะเป็น GET /form => POST /thing => GET /thing/1 ถ้าฟีเจอร์ triptych ถูกนำไปใช้จริง มันจะเป็นแพตเทิร์นที่ยอดเยี่ยม
    [0] https://triptychproject.org/

  • ฉันไม่ชอบเว็บไซต์ React เลย แต่สิ่งที่ฉันไม่เข้าใจคือ เว็บไซต์พวกนี้ไม่ทำ lazy loading กันเลยหรือไง
    แม้แต่ single-page app ขนาดใหญ่ก็ยังเร็วมากได้ ถ้าโหลดคอมโพเนนต์เฉพาะตอนที่จำเป็นต้องใช้
    ฉันผ่านมาทั้ง Angular1 -> Vue2 -> Svelte2 แล้วก็มาจบที่ web components แบบล้วน ๆ ไม่มี shadow DOM ซึ่งทั้งทำงานสนุกและเร็ว

  • ทุกวันนี้แอปส่วนใหญ่ก็ทำด้วย HTMX + Go + SQLite แบบง่าย ๆ
    รู้สึกว่าสำหรับโปรเจกต์ส่วนใหญ่มันก็เพียงพอแล้ว
    มีเว็บไซต์หนึ่งของฉันที่มีรูปเยอะและรับทราฟฟิกเดือนละ 10TB ในกรณีนี้สแตกจะเป็นแบบนี้: 1. ใช้ S3 เพราะต้องการที่เก็บข้อมูลที่เชื่อถือได้ 2. วาง Cloudflare ไว้ด้านหน้าและเปิด Tiered Cache แบบนี้ POP ต่าง ๆ จะดึงจาก Cloudflare มากกว่าจากต้นทาง แคชทุกอย่างไว้ 1 ปีทั้งฝั่งเบราว์เซอร์และ Cloudflare และตั้งกฎให้ไม่สนใจนโยบายแคชของต้นทางกับ query string โดยใช้เฉพาะอ็อบเจ็กต์แบบ immutable ที่ต้องมี revision 3. วาง BunnyCDN ไว้อีกชั้นด้านหน้า
    Cloudflare อย่างเดียวไม่ได้ทำให้รันเว็บที่มีรูปจำนวนมากได้จริง ๆ เลยลดค่าใช้จ่ายลงได้มากด้วยวิธีนี้ ตามนโยบายแล้วไม่ควรใช้กับรูปเป็นหลัก แต่ควรใช้กับ HTML, CSS, JavaScript และคอนเทนต์อื่นของเว็บไซต์
    ถ้าใช้แค่ S3 ค่าใช้จ่ายจะสูงมาก
    แต่ช่วงหลังฉันกำลังทำแอปมือถืออยู่ PWA มีข้อจำกัด เพราะระบบปฏิบัติการอาจยึดคืนพื้นที่เก็บของ IndexedDB ได้ จึงไม่สามารถให้ที่เก็บข้อมูลที่เชื่อถือได้ภายในแอปโดยไม่ต้องสมัครสมาชิกหรือมี backend เข้ามาเกี่ยวข้อง
    สุดท้ายบน Android ก็ต้องย้ายไปใช้ Flutter แต่ก็มีความเจ็บปวดอีกแบบ น่าหงุดหงิดเวลาบางครั้งอัปเดตแอปต้องค้างอยู่ที่ “อยู่ระหว่างการตรวจสอบ” นานมาก ถ้าเทียบกันแล้วเว็บแอปของแอปเดียวกันอัปเดตได้เร็วมาก
    เลยสงสัยว่าทำไมถึงไม่มีระบบปฏิบัติการมือถือที่ยอมให้สร้างแอปด้วย JavaScript, HTML, CSS และยังให้พื้นที่เก็บข้อมูลที่เสถียรได้โดยไม่ต้องออกแรงมาก ข้อดีของแอปแบบ PWA คืออัปเดตได้เร็ว

    • ระบบปฏิบัติการมือถือแบบนั้นเคยมีอยู่ แค่ต้องย้อนเวลากลับไปตอน Palm เปิดตัว webOS ในปี 2009
      การย้อนเวลาเป็นส่วนที่ง่าย หลังจากนั้นต้องหาทางหยุดการล่มสลายของ Palm และไม่ให้ webOS ถูกลืมในฐานะระบบปฏิบัติการสมาร์ตโฟน
      ถ้าปี 2009 ไกลเกินไป จะไปเสี่ยงดวงกับ Firefox OS ในปี 2012 ก็ได้
      พูดเล่นนอกเรื่องไปหน่อย แต่ก็เคยมีคนและบริษัทพยายามทำแบบนั้นจริง ๆ เพียงแต่จังหวะเวลาไม่ดีและมีหลายเหตุการณ์ซ้อนกัน จนในเส้นเวลาโลกของเรา ความเป็นจริงแบบนั้นไม่เกิดขึ้น
    • Go ดีมากสำหรับแอปฝั่งเซิร์ฟเวอร์ รู้เรื่องนี้ช้ากว่าที่ควรไปมาก
      มันให้ความรู้สึกเหมือนอยู่ในจุดลงตัวพอดี คือไม่มีภาระไร้สาระแบบ C แต่ก็หลบทางให้เราโฟกัสกับ business logic ได้เหมือน Java ไม่เหมือน Rust
      ไม่ได้ดีสำหรับทุกงาน โดยเฉพาะความสามารถในการสร้าง abstraction ที่ยังขาด ๆ แต่สำหรับแอปเซิร์ฟเวอร์ที่มี business logic เยอะ มันยอดเยี่ยมมาก ให้ความรู้สึกว่าเป็นภาษาที่เชี่ยวชาญด้านนี้ ไม่ใช่ภาษาที่พยายามทำทุกอย่าง
    • ทราฟฟิก 10TB ต่อเดือน นี่ถ้าไม่ใช่ CDN, ตัวกลางโฆษณา, เว็บโป๊ หรือเว็บอีคอมเมิร์ซขนาดใหญ่ ก็แทบนึกภาพไม่ออกเลยว่ามันจะเกิดได้ อยากรู้ว่าทำอะไรถึงมีทราฟฟิก 10TB ต่อเดือน
    • เหมือนจะเป็นคนประเภทเดียวกับฉันเลย ช่วงนี้กำลังอินกับการทำโน่นนี่ด้วย HTMX + Go + SQLite มาก มันเหมือนชุดเทคโนโลยีสุดน่าเบื่อ 3 อย่างที่เหมาะกับฉันพอดี ดีพลอยด้วย bash script ธรรมดา ๆ ไปยัง colocation server
      ฉันยังทำไลบรารีไว้สองสามตัวเพื่อ abstract ส่วนของ SQL กับ HTMX/web/OAuth ด้วย ตอนนี้แอปต่าง ๆ ของฉันคล้ายกันมากจนย้ายฟีเจอร์ข้ามกันได้ง่าย
      https://github.com/cattlecloud/webtools
      https://github.com/cattlecloud/litesql
    • ทุกวันนี้ 10TB ไม่ได้มากอะไรเลย virtual server ของ Hetzner ในยุโรปมีทราฟฟิกรวมมาให้ทุกตัวเดือนละ 20TB และส่วนเกินก็ต่ำกว่า 2 ดอลลาร์ต่อ TB ส่วน dedicated server เป็น fair use แบบไม่จำกัด ซึ่งถ้าเฉลี่ยหลายเดือนก็น่าจะประมาณ 200TB ต่อเดือน

  • มีข้อโต้แย้งกลับใน In Defence of the Single Page Application
    https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...

    • ขำตรงที่พอฉันเปิดบนอินเทอร์เน็ตมือถือ มันค้างอยู่ที่ loading spinner ไม่ไปไหน ไม่รู้ว่าเป็นปัญหาอินเทอร์เน็ตของฉันเอง หรืออาจจะไม่ใช่ แต่อาจเป็นปัญหาการรองรับบนมือถือ เลยอ่านเนื้อหาไม่ได้ด้วยซ้ำ
    • ถ้าพารอดีพัฒนาไปไกลพอ มันก็แยกไม่ออกจากความจริง
    • ตอนนั้นก็มีการคุยกันแล้ว
      In Defence of the Single Page Application - https://news.ycombinator.com/item?id=31275178 - พฤษภาคม 2022, คอมเมนต์ 32 รายการ
    • สิ่งที่ฉันเห็นมีแค่แอนิเมชัน “loading” ผ่านไป 10 วินาทีก็ยอมแพ้ เพราะงั้นมันไม่ใช่ข้อโต้แย้งกลับ แต่เป็นตัวอย่างที่ยืนยันประเด็นของบทความ

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

    • ดูเหมือน LLM ก็ยอมรับประเด็นสุดท้ายนั้นเหมือนกัน

  • เป็นบทความที่ดี แต่ทุกครั้งที่อ่านบทความสร้างแรงบันดาลใจแบบนี้ก็รู้สึกขัดแย้งอยู่เสมอ แนวคิดเรื่อง เว็บไซต์เรียบง่าย ที่ถูกต้องทั้งหมด ใช้งานได้ดี โหลดเร็ว และไม่ต้องพึ่งเบราว์เซอร์รุ่นใหม่ ฟังดูน่าชอบมาก
    แต่แล้วก็อดคิดไม่ได้ว่านี่เป็นเพราะตัวเองไม่ฉลาดพอจะเข้าใจ React หรือเทคโนโลยีเท่ ๆ ที่กำลังฮิตในแต่ละช่วงหรือเปล่า
    มันให้ความรู้สึกเหมือนมีเส้นขีดจำกัดของความเข้าใจที่ข้ามไปไม่ได้ ถ้าให้แค่เอดิเตอร์เรียบง่ายอย่าง Sublime แล้วบอกให้ทำเว็บเพจ ต่อให้มี JavaScript อยู่ด้วยก็ยังเป็นพื้นที่ที่มีความสุข แต่พอเจอ VSCode หรือ Zed พร้อมปลั๊กอิน Claude/Copilot/ChatGPT เต็มไปหมด แล้วโยน React tutorial มาให้ สมองจะละลายทันที

    • ถ้าจะให้สบายใจขึ้น คนที่ใช้พวกเฟรมเวิร์กหรู ๆ พวกนั้น ส่วนใหญ่ก็ไม่ได้ฉลาดพอจะเข้าใจมันจริง ๆ เหมือนกัน
    • คุณอาจชอบบทความนี้เกี่ยวกับความซับซ้อนและเหตุผลว่าทำไมมันถึงแย่: https://tengstrand.github.io/blog/2019-09-14-the-origin-of-c...
      การทำให้มันเรียบง่ายไม่ใช่เรื่องแย่ และบ่อยครั้งกลับต้องฉลาดพอที่จะไม่ทำให้มันซับซ้อนเกินจำเป็น
    • ฉันชอบเว็บ ฉันไม่ชอบสิ่งที่ สาวก React ทำกับเว็บ
      Embrace Extend Extinguish มีอยู่จริง และคนที่สมรู้ร่วมคิดกับมันก็สมควรถูกแทนที่ด้วย LLM ที่โกหกได้เร็วกว่าและพ่นโค้ดขยะได้ไวกว่า

  • มันทำให้นึกถึงเมื่อเกือบ 15 ปีก่อน ตอนนั้นใช้การจัดการ session ฝั่งแบ็กเอนด์ใน Grails และใช้ ฟอร์ม HTML ที่เสริมด้วย responsive CSS กับ JS “นิดหน่อย”
    สิ่งที่ต่างจากตอนนี้คือเทคโนโลยีเบราว์เซอร์ตอนนั้นยังไม่ก้าวหน้าแบบทุกวันนี้ ต้องคอยพะวงหลายเบราว์เซอร์ และยังต้องรองรับ IE7 หรือแม้แต่ IE6 ทำให้ยากและต้องทำ QA อย่างกว้างขวาง BrowserStack ก็เพิ่งมาทีหลัง
    มีเหตุผลที่ JavaScript library วิวัฒน์มาแบบนั้น ตอนนั้นยังไม่มี npm และแม้แต่ bower ก็ยังไม่มี แล้ว Backbone.js ก็ออกมาและฉันก็ชอบมัน AngularJS น่าทึ่งมาก จากนั้น Angular รุ่นถัดมาก็มี breaking change ครั้งใหญ่ แล้วต่อมาก็มี React, Polymer และอื่น ๆ
    ทุกวันนี้เบราว์เซอร์เนทีฟทำอะไรได้เยอะมากและการ progressive enhancement ก็ง่ายด้วย แต่เมื่อก่อนมันไม่ได้เป็นแบบนั้นเสมอไป การตัดสินใจใช้ React ในเวลานั้นจึงสมเหตุสมผลจากหลายปัจจัย และอาจเป็นแบบนั้นในกรณีนี้ด้วย

  • เมื่อกว่าสิบปีก่อน ฉันเคยสร้างแอปแบบนี้ที่ GOV.UK ให้กระทรวงยุติธรรม เราสร้างไลบรารี form wizard ของตัวเองเพื่อให้ตรวจสอบฟอร์มยาว ๆ เป็นขั้นตอนและแบ่งได้หลายหน้า เพราะ Ruby on Rails ไม่ได้รองรับสิ่งนี้เป็นค่าเริ่มต้น
    ตอนนั้นหลักการที่ว่าทุกคนต้องสามารถใช้บริการดิจิทัลได้ ไม่ว่าผู้ใช้จะเข้ามาจากสภาพแวดล้อมแบบใด เป็นเรื่องสำคัญมาก

    • ฉันชอบหน้า HTML พื้นฐานที่อัปโหลดเอกสารได้โดยไม่ต้องเริ่มทั้งแอปใหม่เสมอ มันเป็นแนวปฏิบัติที่ดีมากแม้ในฟอร์มทั่วไป
      สำหรับแต่ละ session ID คุณสามารถเทียบหน้าของแอปหลายหน้ากับ session ID นั้นได้ ดังนั้นถ้าจำเป็น ผู้ใช้ก็กรอกเองได้ แต่ก็ควรแยกแยะได้ด้วยข้อมูลที่มากพอ เช่น IP address, วันที่อัปโหลด, เบราว์เซอร์, ระบบปฏิบัติการ ฯลฯ อย่างไรก็ตาม session ที่แม่นยำที่สุดควรอยู่ในเบราว์เซอร์ เพื่อไม่ให้คุกกี้ของใบสมัครหนึ่งไปปะปนกับผู้สมัครอีกคน เช่น ญาติที่ใช้ PlayStation Portable
    • เว็บไซต์ gov.uk น่าประทับใจจริง ๆ มันมินิมอลและตรงจุดประสงค์มาก
      ฉันสงสัยว่าในแอปมือถือเขาใช้เทคโนโลยีอะไร เดาว่าอาจไม่ใช่ mobile app แบบเต็มตัว แต่ใช้ webview มากกว่า

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

    • อาจมองได้ว่าข้อจำกัดของแนวทาง HTML-first ช่วยบังคับให้หลีกเลี่ยงแพตเทิร์นแย่ ๆ ที่เคยใช้มาก่อน
      แต่ก็จริง การเปลี่ยนแปลงฝั่งผู้ใช้มาจากการแก้การออกแบบ ไม่ใช่จากเทคโนโลยีที่ใช้
      มันคล้ายกับ bullet point แย่ ๆ ในเรซูเม่มาก แบบที่มีคนเขียนว่า “rewrite เว็บไซต์เป็น HTML-first ทำให้ผู้เข้าชมเพิ่มขึ้น 100%” ราวกับว่าผลลัพธ์ทางธุรกิจเกิดจากการเปลี่ยนโค้ด พอถามลึกลงไป สุดท้ายก็ต้องยอมรับว่าเป็นการออกแบบเว็บไซต์ใหม่ทั้งหมดเพื่อแก้ปัญหาด้านดีไซน์หรือเพิ่มฟีเจอร์ และนั่นต่างหากที่ทำให้ผู้เข้าชมเพิ่มขึ้น
    • HTML ธรรมดาพร้อม JavaScript นิดหน่อยอาจไม่ใช่บ่อแห่งความสำเร็จโดยตรง แต่ React อยู่ใกล้บ่อแห่งความสิ้นหวังมากกว่าเยอะ อย่างแรกมักจะดูทื่อ ๆ แต่ได้ผล ส่วนอย่างหลังถ้าจะดึงศักยภาพออกมาได้ต้องมี ปริญญาเอกด้านการหลีกเลี่ยงความซับซ้อน
      JavaScript: The Good Parts ของ Douglas Crockford บางจนน่าขำอยู่แล้ว แต่ React: The Good Parts คงจะบางกว่านั้นอีก
    • แน่นอน แค่ใน React มันยากกว่า 100 เท่า และถ้าคุณล้มเหลว แฟน ๆ ก็จะโทษคุณ ไม่ใช่โทษเทคโนโลยี
    • คำตอบมาตรฐานคือบางเทคโนโลยีทำให้ด้านหนึ่งยากกว่าอีกด้านหนึ่ง ซึ่งในเชิงหลักการก็จริงระดับหนึ่ง แต่ตัวอย่างเช่น ถ้าจะบอกว่า React ทำให้ได้ผลลัพธ์ที่ดีกว่า HTML ธรรมดายากกว่า ก็ต้องมีข้อโต้แย้งรองรับจริง ๆ
      น่าสนใจตรงที่ต้นฉบับอธิบายฟอร์มสไตล์ wizard แบบหลายหน้า ซึ่งแทบไม่ค่อยเห็นเลยตลอดราว 10 ปีที่ผ่านมา แต่ทุกครั้งที่ฉันเจอ มันมักเป็นระบบองค์กรที่แย่มาก ครั้งล่าสุดที่เห็นก็เหมือนผลิตภัณฑ์ Oracle สำหรับเบิกค่าใช้จ่าย
      ปัญหาของพวกนั้นคือระหว่างทำงานมันช้ามาก ทุกปุ่มต้องรอหลายวินาที ถ้าต้องย้อนกลับไปสักหนึ่งหรือสองขั้นก็ยิ่งน่าหงุดหงิดเป็นสองเท่า ส่วน single-page app ที่ทำไม่ดีมักจะเริ่มต้นช้า ใช้เวลาโหลดนาน แต่พอโหลดเสร็จแล้ว โดยทั่วไปประสิทธิภาพมักโอเค
 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs

  • การทำสิ่งที่ใช้งานได้ดีจริง ๆ สำหรับผู้คนนั้นแน่นอนว่าต้องใช้แรงมากกว่า แต่สุดท้ายแล้วนั่นก็คือ แก่นสำคัญของงานทั้งหมด

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

  • รู้สึกขมขื่นกับช่วงที่บอกว่าต้องใช้เวลาอธิบายเรื่อง “การส่งฟอร์มและการ redirect” ให้เพื่อนร่วมงานฟัง เพราะทุกคนคุ้นกับ เว็บแอปที่ยึดฝั่งไคลเอนต์เป็นศูนย์กลาง ไปแล้ว
    ตอนนี้วงการพัฒนาเว็บอยู่ในสภาพที่น่าเสียดายจริง ๆ และมีหลายอย่างที่ต้องกลับมาสอนกันใหม่

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

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

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

  • แดกดันนิดหน่อยตรงที่ใน Firefox มีสไตล์บางอย่างทำให้เนื้อหาหลักทั้งมองไม่เห็นและเลือกไม่ได้ ผมเลยต้องสลับไปโหมดอ่าน ชื่อเรื่อง เครื่องหมายอ้างอิงสีชมพู และ code block ยังมองเห็น แต่ที่เหลือไม่เห็นเลย
    แก้ไข: ดูจากด้านล่างแล้วน่าจะเป็นปัญหาจากสภาพแวดล้อมของผมเอง ขอทิ้งไว้เพื่อบริบท
    ตัวบทความเองผมอ่านได้ดี ไม่ว่าจะเป็นนักพัฒนาหรือผู้ใช้ปลายทาง พวกเราทุกคนต่างกำลังจ่ายต้นทุนของ “ความคล่องตัว” แบบ React กันอยู่ ผมเคยคิดหลายครั้งว่าอยากให้ที่บริษัทใช้สแตกอื่นได้บ้าง
    อีกอย่างที่ประทับใจคือ ความเห็นอกเห็นใจ ของผู้เขียนและการออกแบบมันให้เป็นโครงสร้างแบบ “ทุกฝ่ายชนะ” ความใส่ใจแบบนี้สุดท้ายแล้วให้ผลตอบแทน

    • ผมก็เหมือนกัน ใช้ Firefox 152.0b9 บน Debian Trixie
    • แปลกดี แต่ Firefox ของผมเปิดไซต์นี้ได้ปกติ

  • เห็นด้วยมาก เมื่อก่อนผมเคยทำบล็อกที่มี JavaScript เยอะสุด ๆ แล้วฟีเจอร์ที่อิง JS ก็แทบทำให้เกิดการกบฏเลย
    ถึงจะยังไม่มีเวลาย้ายไปแนวทาง HTML-first แต่ภายนอกก็ทำให้มันดูคล้าย หน้าเว็บแบบ HTML-first ไว้เป็นส่วนใหญ่
    ในข้อมูลวิเคราะห์ของผมก็เห็นผลคล้ายกัน อัตราตีกลับลดจาก 80% ลงมาเหลือราว 50% แล้วผู้เข้าชมใหม่ของบทความหลังจากนั้นก็เพิ่มเกือบเท่าตัว
    พอคิดว่ามีคนจำนวนเท่าไรที่อาจจะเลี่ยงโดเมนของผมไปตลอดเพราะงานที่ทำเละเทะแบบสร้างด้วย JS ตอนแรกก็ขนลุกเลย ถ้าเป็นหน้าเว็บหรือบล็อก นี่เป็นคำแนะนำที่สำคัญที่สุดข้อหนึ่งเลย

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

  • ถ้าเติม SSE streaming กับไลบรารี morph เข้าไป ก็ยังสร้างฟีเจอร์แบบไดนามิก, เรียลไทม์ และมัลติเพลเยอร์ได้อย่างเท่มากด้วย