HTML First

• หากใช้ ฟีเจอร์เนทีฟ ที่เบราว์เซอร์มีมาให้ก่อน ก็จะลดขอบเขตที่ต้องพึ่งพาภาษาและทูลเชนเพิ่มเติมเมื่อสร้างเว็บแอปได้
• React เพิ่มความน่าเชื่อถือในการพัฒนา UI ด้วยแพตเทิร์นอย่าง props, state และ คอมโพเนนต์ แต่ก็ย้ายศูนย์กลางของวิธีพัฒนาจาก HTML ไปเป็น JavaScript
• ในระหว่างนั้น W3C, WHATWG, IETF และ TC39 ได้เพิ่มการปรับปรุงหลายพันรายการให้กับภาษาพื้นฐานของเว็บ และเมื่อเบราว์เซอร์หลัก ๆ ผนวกรวมสิ่งเหล่านี้เข้าไป เหตุผลบางส่วนที่เคยทำให้ต้องใช้ React ก็อ่อนลง
• HTML First ไม่ได้เป็นกระแสที่มุ่งโน้มน้าวนักพัฒนาที่พอใจกับ React แต่เป็นแนวทางที่ต้องการมอบภาษาให้ผู้ที่สนใจ แนวทางที่มี HTML เป็นศูนย์กลาง ใช้จัดระเบียบความคิดและพูดคุยกับเพื่อนร่วมงาน
• นี่ใกล้เคียงกับการตั้งคำถามเชิงปฏิบัติว่า เราควรกลับมาพิจารณาอีกครั้งหรือไม่ว่าการใช้เพียงภาษาพื้นฐานของเว็บและฟีเจอร์ของเบราว์เซอร์ก็สามารถสร้างซอฟต์แวร์ที่เร็วและเข้าถึงได้ดีได้หรือไม่

---

แนวทางการพัฒนาที่ HTML First มุ่งหวัง

• HTML First ให้ความสำคัญกับ HTML, CSS, JavaScript และ ฟีเจอร์เนทีฟ ของเบราว์เซอร์เป็นลำดับแรกเมื่อสร้างซอฟต์แวร์เว็บ
• แก่นสำคัญอยู่ที่การลด ชั้น abstraction ที่เพิ่มเข้ามาบนเว็บแพลตฟอร์ม
  • ภาษาและทูลเชนเพิ่มเติมก็รวมอยู่ในชั้นที่ควรลดลงด้วย
• เป้าหมายคือวิธีพัฒนาที่วางฟีเจอร์ที่เบราว์เซอร์มีให้อยู่แล้วไว้เป็นศูนย์กลาง และค่อยวางเครื่องมือทับลงไปเฉพาะเมื่อจำเป็นเท่านั้น

การพัฒนาเว็บที่ซับซ้อนขึ้นหลัง React

• ก่อน React วิธีทั่วไปคือเขียนอินเทอร์เฟซด้วย HTML แล้วใช้เครื่องมืออย่าง jQuery มาเสริมส่วนที่ HTML ไม่รองรับโดยพื้นฐาน
  • ตัวอย่างหลักคือการส่ง คำขอแบบอะซิงโครนัส และการอัปเดต DOM
• ไลบรารีอย่าง React แก้ปัญหาหลายอย่างของการพัฒนาเว็บแบบเดิม
  • แพตเทิร์น props และ state ที่ส่งข้อมูลจากองค์ประกอบแม่ไปยังองค์ประกอบลูกอย่างชัดเจนช่วยลดบั๊กบางประเภท
  • การรวม UI, สไตล์ และพฤติกรรมเป็นคอมโพเนนต์ ทำให้ติดตั้งสิ่งที่คนอื่นสร้างไว้เข้ากับโค้ดเบสของตนเองได้ง่าย
• เพื่อให้ได้ประโยชน์เหล่านี้ ต้องเปลี่ยนจากวิธีที่ใช้ HTML เป็นหลัก ไปเป็นวิธีที่ใช้ JavaScript เป็นหลัก
  • JavaScript ถูกมองว่าเป็นภาษาที่ซับซ้อนกว่า
  • ยังต้องเรียนรู้แนวคิดและเครื่องมือจำนวนมากที่ React นำเข้ามาด้วย
• แม้ความซับซ้อนจะเพิ่มขึ้น แต่อุตสาหกรรมก็ยอมรับการแลกเปลี่ยนนี้ และไลบรารีลักษณะนี้กลายเป็นวิธีพื้นฐานในการสร้างเว็บแอป
  • ก่อน React นักพัฒนาใหม่มักเรียน HTML และ CSS ก่อน แล้วจึงเรียน JavaScript
  • หลัง React กระแสเปลี่ยนเป็นเรียน JavaScript และ React ก่อน แล้วค่อยเรียนส่วนที่เหลือ

จุดที่การปรับปรุงเว็บแพลตฟอร์มทำให้ต้องทบทวน

• W3C, WHATWG, IETF และ TC39 ได้เพิ่มการปรับปรุงหลายพันรายการให้กับภาษาเนทีฟของเว็บ ในช่วงที่แนวทางแบบ React แพร่หลาย
  • การปรับปรุงเหล่านี้ถูกรวมเข้าใน Chrome, Safari, Firefox และ Edge
  • หลายรายการในนั้นตอบโจทย์เหตุผลบางส่วนที่ผู้คนเคยใช้ React โดยตรง
• เมื่อค่าใช้จ่ายในการพัฒนาซอฟต์แวร์สูงขึ้น และการปรับปรุงของเบราว์เซอร์ถูกเผยแพร่อย่างกว้างขวาง ผู้คนจำนวนมากขึ้นจึงเริ่มถามว่าชั้นที่เพิ่มเข้ามาเหล่านี้ยังจำเป็นอยู่ในปัจจุบันหรือไม่
• แนวคิดของ HTML First ยังเป็นส่วนน้อยในอุตสาหกรรม
• แนวทางนี้มุ่งช่วยให้ผู้ที่สนใจการพัฒนาที่มี HTML เป็นศูนย์กลางอยู่แล้ว ทำให้ความคิดของตนมั่นคงขึ้น และได้รับ ภาษาและแนวคิด สำหรับสื่อสารกับเพื่อนร่วมงาน
• ข้อความหลักคือ การสร้างซอฟต์แวร์เว็บที่สวยงาม รวดเร็ว ใช้งานง่าย และเข้าถึงได้ดี โดยใช้ภาษาและฟีเจอร์เนทีฟของเว็บเป็นหลักนั้น เป็นสิ่งที่เป็นไปได้ ใช้ได้จริง และสมเหตุสมผล

[GN⁺]

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

• ผมชอบไอเดียนี้นะ แต่พูดตรง ๆ คือ ตัวอย่างค่อนข้างอ่อน
  ตัวอย่างในส่วนที่ว่า “ถ้าเป็นไปได้ ให้กำหนดสไตล์และพฤติกรรมเป็นแอตทริบิวต์ HTML แบบอินไลน์” ดูเหมือนจะใช้งานจริงไม่ได้ และถ้าจะเพิ่มสไตล์เข้าไปอีก โครงสร้างก็จะกลายเป็นแค่การทำให้พารามิเตอร์สตริงที่ส่งให้ ClassList.add ยาวขึ้นเรื่อย ๆ
  โดยส่วนตัวผมว่า button:active { background: green; } อ่านง่ายกว่ามาก แต่ผู้เขียนน่าจะมองว่ามันซับซ้อนเพราะแนวทาง “Locality of Behaviour”
  ผมเห็นด้วยกับคำพูดที่ว่า “ถ้าต้องใช้ไลบรารี ให้ใช้ไลบรารีที่ใช้ประโยชน์จากแอตทริบิวต์ HTML ไม่ใช่เน้น JavaScript หรือไวยากรณ์แบบคัสตอม” แต่ “on input put me into #output” ในตัวอย่างที่แนะนำดูแปลกยิ่งกว่าไลบรารีที่ยกมาเป็นตัวอย่างที่ไม่ดีเสียอีก และดูเหมือนใช้ JavaScript ตรง ๆ โดยไม่ต้องมีเฟรมเวิร์กก็พอแล้ว
  ตัวอย่างของคำว่า “ชอบ HTML แบบ ‘ดิบ’ มากกว่าชั้นซ่อนเร้นที่คอมไพล์เป็น HTML” คือบอกว่าไม่ควรใช้ Rails ERB tag helper แต่ helper เหล่านี้ช่วยจัดการสิ่งต่าง ๆ ได้เยอะทีเดียว ซึ่งถ้าเขียนเป็นเทมเพลตขั้นต่ำเองจะรกมาก ตัวอย่างนี้ละเลยส่วนที่ใช้งานจริงอย่าง DOM ID ที่ไม่ซ้ำกัน, แท็ก Turbo และการวนซ้ำ

  • ส่วนที่ว่า “ถ้าเป็นไปได้ ให้กำหนดสไตล์และพฤติกรรมเป็นแอตทริบิวต์ HTML แบบอินไลน์” ผมก็สะดุดเหมือนกัน
    การกำหนดสไตล์กับพฤติกรรม ควรแยกจากกัน และในสเกลที่มีความหมาย วิธีเดียวที่สมเหตุสมผลคือให้ทั้งสองเชื่อมกันด้วยการอ้างอิงเท่านั้น
    ในทางเทคนิค เราอาจใส่การเชื่อมต่อฐานข้อมูล SQL ทั้งหมดกับ SQL ที่ฮาร์ดโค้ดไว้ในไฟล์ Python ยาว ๆ ไฟล์เดียวได้ แต่มันเป็นนิสัยที่ไม่ดี หลักการนี้ก็ดูคล้ายกัน

• ส่วนนี้ทำให้งง: “ถ้าต้องใช้ไลบรารี ให้ใช้ไลบรารีที่ใช้ประโยชน์จากแอตทริบิวต์ HTML ไม่ใช่เน้น JavaScript หรือไวยากรณ์แบบคัสตอม”
  แต่ตัวอย่างที่แนะนำกลับเป็น _hyperscript [0] นี่คือ ไลบรารีที่เน้นไวยากรณ์แบบคัสตอม และเป็นเพียงการใส่สคริปต์ของภาษาที่ต้องเรียนใหม่ลงไปในแอตทริบิวต์ HTML เท่านั้น ไม่แน่ใจว่าเอาจริงหรือเปล่า
  [0] https://hyperscript.org

  • ดูเหมือนเขียนเป็น รายการทิปเพื่อโปรโมต hyperscript
    ตัวอย่างก็ค่อนข้างอ่อน วิธีแก้แบบล้วน ๆ คือใช้แค่ทิปแรกก็ทำได้ดีพอ ๆ กัน
  • เห็นด้วย ตัวอย่างที่ใส่ประโยค DSL ที่อ่านยากเป็นค่าของแอตทริบิวต์ชื่อ _ ดูแปลกและชวนสับสนจริง ๆ
    ผมว่าน่าจะใช้คำสั่ง JavaScript ล้วน ๆ ใน onclick หรือแอตทริบิวต์อีเวนต์อื่น ๆ ที่ชัดเจนไปเลย จะได้รู้ทันทีว่าเกิดอะไรขึ้น
  • ถ้าตามคำแนะนำของผู้เขียน Alpine.js น่าจะเป็นคำแนะนำที่ดีกว่า เพราะใช้แอตทริบิวต์ HTML กับ JavaScript ที่เข้าใจง่าย
  • hyperscript เกี่ยวข้องกับ HTMX เลยดูเหมือนมีคนอยากดันมัน แต่ในความคิดผม มันใกล้เคียงกับ ของเล่นสนุก ๆ มากกว่า
  • ผู้เขียนอาจสลับตัวอย่างที่แนะนำกับไม่แนะนำกันก็ได้

• เข้าใจเจตนาอยู่ การใช้ ฟีเจอร์ในตัว ของ HTML นั้นสะอาดและเรียบง่าย
  แต่เมื่อ 10 ปีก่อนมันก็ไม่ practical และตอนนี้ก็ยังไม่ใช่ ผมก็ไม่ได้รู้สึกว่าอย่าง htmx ดีกว่าโซลูชันที่หนักกว่าอย่าง React เป็นพิเศษ
  ทุกครั้งที่เห็นแนวทางแบบนี้ คำถามที่ถามก็เหมือนเดิมเสมอ ดรอปดาวน์, multi-select, date picker หน้าตาเป็นอย่างไร? เบราว์เซอร์ต่าง ๆ มี date picker ไหม? มี หน้าตาและพฤติกรรมสอดคล้องกันข้ามเบราว์เซอร์ไหม? ไม่ ปรับด้วย styling ให้ตรงกันได้ไหม? ก็ไม่ได้เช่นกัน
  multi-select ก็คล้ายกัน การบังคับให้ Shift/Ctrl+คลิกเพื่อเลือกหลายรายการนั้น จากมุมมองประสบการณ์ผู้ใช้ถือว่าไม่ไหวเลย องค์ประกอบพื้นฐานยังทำงานแบบนั้นอยู่และเปลี่ยนไม่ได้ ไม่ใช่แค่ multi-select แม้แต่องค์ประกอบ select ทั่วไปก็หน้าตาแย่และโดยมากปรับเปลี่ยนได้ยาก
  มีเหตุผลที่ทุกเฟรมเวิร์กใหม่ ๆ ต้องมี คอมโพเนนต์จาก third-party แบบนี้ เพราะองค์ประกอบในตัวอย่างเดียวไม่พอ เหตุผลเดียวกับที่หน้า Array ของ MDN มีฟีเจอร์ในตัวเพิ่มขึ้นทุกปี แต่ 90% ของโปรเจกต์ของผมยังพึ่งพา lodash อยู่ มันดีขึ้นกว่าเมื่อ 10 ปีก่อนก็จริง แต่ยังไม่พอ

  • ถ้าคิดเร็ว ๆ เฉพาะเรื่อง date picker เว็บไซต์ถูกออกแบบมาเพื่อผู้ใช้
    ผู้ใช้อาจใช้เบราว์เซอร์ต่างกัน แต่ผู้ใช้คนหนึ่งมีแนวโน้มจะใช้เบราว์เซอร์เดียวกันกับทุกเว็บไซต์ที่เขาเข้า
    ดังนั้นในความคิดผม สิ่งที่สำคัญกว่าการที่ date picker ของเว็บไซต์หนึ่งสอดคล้องกันในทุกเบราว์เซอร์ คือการที่มัน สอดคล้องกันในทุกเว็บไซต์ภายในเบราว์เซอร์เดียวกัน แน่นอนว่าถ้าต้องการฟีเจอร์คัสตอมก็เป็นอีกเรื่องหนึ่ง
  • ที่บอกว่า “การบังคับให้ Shift/Ctrl+คลิกเพื่อเลือกหลายรายการนั้น จากมุมมอง UX ถือว่าไม่ไหวเลย” หมายความว่าไม่ควรทำ multi-select แบบนั้นใช่ไหม? ถ้าอย่างนั้นอยากรู้ว่าควรทำอย่างไร
    เวลาต้องการเลือก 10 หรือ 15 รายการที่ต่อเนื่องกันในลิสต์ ตอนนี้ผมยังไม่รู้จัก UI ที่ดีกว่า Shift+คลิก เลย
  • “หน้าตาและพฤติกรรมสอดคล้องกันข้ามเบราว์เซอร์ไหม? ไม่” ฟังแล้วแปลกดี ถ้านึกว่าเมื่อก่อน native look and feel เคยถูกมองว่าเป็นเงื่อนไขจำเป็นของแอปเดสก์ท็อป
    ผมว่ามันคงดีกว่ามากถ้าคอมโพเนนต์ UI ของทุกเว็บไซต์ไม่ต้องไปคิดสไตล์โง่ ๆ ขึ้นมาเอง แต่ให้ใช้ native look and feel ของเบราว์เซอร์ ยกเว้นดีไซน์เฉพาะของไซต์จริง ๆ แน่นอนว่าเบราว์เซอร์ก็ต้องใส่ใจทำให้มันดูดีด้วย
  • จากประเด็นที่เหลือ องค์ประกอบ input ขึ้นชื่อว่ามีวิธีโต้ตอบที่แตกต่างกันมากในแต่ละเบราว์เซอร์ ส่วนองค์ประกอบ HTML อื่น ๆ ส่วนใหญ่มีพฤติกรรมหลักที่กำหนดไว้เป็นแบบเดียว

• เห็นด้วยกับข้ออ้างส่วนใหญ่ แต่บทความนี้รู้สึกขัดแย้งกันเล็กน้อย เพราะแนะนำ Tailwind พร้อมกับบอกว่า “ให้หลีกเลี่ยงขั้นตอนการ build”
  การ deploy ทรัพยากร CSS/JS ขนาดมหึมาก็ขัดกับหลักการเรื่องการเปิดกว้างให้ทุกคนเข้าถึงได้เช่นกัน มีคนจำนวนมากที่ไม่มีอินเทอร์เน็ตเร็วหรือคอมพิวเตอร์ที่แรงพอ

  • ตอนนี้ไม่ได้ใช้ Tailwind แล้ว แต่จากประสบการณ์ของผม Tailwind ไม่ได้ทำให้ต้อง deploy ทรัพยากร CSS/JS ขนาดมหึมา
    ที่จริงผมไม่รู้เลยว่า Tailwind ส่งออก JavaScript ฝั่ง client อะไรบ้าง ประสบการณ์ล่าสุดของผมคือรุ่น 2.x เลยไม่แน่ใจว่ามีอะไรเปลี่ยนไปหรือไม่
    ส่วนขนาด CSS ประสบการณ์ของผมกลับตรงกันข้าม โดยปกติ output ของ Tailwind เล็กกว่า CSS ที่เขียนมือมาก
    แน่นอนว่าผมไม่ได้ต่อต้าน CSS ล้วน ๆ แต่แบบนั้นก็ทำให้เละได้ง่ายอย่างน้อยพอ ๆ กัน
  • ผมทำไลบรารี atomic CSS ที่ไม่ต้องมีขั้นตอน build ไว้แล้ว ถ้ามีใครต้องการก็อยู่ที่นี่ แน่นอนว่าสปอยล์ก่อนเลยว่าไม่มีใครต้องการ: https://casscss.github.io/cass/
  • Deno Fresh ใช้ Twind เพื่อหลีกเลี่ยงขั้นตอน build: https://twind.dev/
    แต่เท่าที่จำได้ มันไม่ได้ให้ฟีเจอร์ทั้งหมดที่ Tailwind แบบเต็มมี โดยรวมแล้วผมหงุดหงิดที่ Fresh แทบจะสร้างอยู่บน Preact และ Twind เป็นหลัก แต่ไม่ได้เปิดเผยตรง ๆ ว่าต้องยอมรับไลบรารีเหล่านั้นก่อน
  • Tailwind มี standalone CLI ที่ใช้เป็นขั้นตอน build ได้
    ผมเห็นด้วยระดับหนึ่งว่ามันดูแปลกนิดหน่อยถ้าจะแนะนำในบริบทของบทความนี้ แต่ขั้นตอน build สามารถทำให้มินิมอลสุด ๆ ได้ และข้อดีก็คือผลลัพธ์ยังเป็น CSS ที่เปิดดูตรวจสอบได้
    ผมใช้ Tailwind ในเว็บส่วนตัว ส่วนที่เหลือเป็น HTML ล้วนทั้งหมด การรัน CLI ในโหมด watch ตอนเขียนสไตล์ไม่ได้รบกวนอะไรมากนัก
  • ตัวเลือกแบบ ไม่ต้อง build ที่ดีมีสองอย่าง: โฮสต์ Tailwind v3 CDN เองโดยตรง หรือใช้ https://github.com/gnat/css-scope-inline
    ทั้งสองอย่างเร็วอย่างน่าประหลาดใจ และ parse ได้มากกว่า 10,000 รายการ

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

  • ผมไม่เข้าใจว่าทำไมแนวปฏิบัติที่ดีจะต้องดีสำหรับโปรเจกต์ใหญ่ด้วย
    ถามจริง ๆ นะครับ ผู้คนยกข้ออ้างนี้ขึ้นมาบ่อย แต่ผมไม่เคยเข้าใจเลย
    ในมุมมองของผม 95% ของเว็บคือโปรเจกต์ขนาดเล็กถึงกลาง เทคโนโลยีส่วนใหญ่ควรโฟกัสตรงนี้ ใช้ทางแก้ที่เรียบง่ายกับโปรเจกต์ที่เรียบง่าย แล้วค่อยเพิ่มความซับซ้อนทีหลัง
  • ที่ทำงานผมเคยพยายามผลักดัน frontend แบบ HTML first แต่พอจ้างนักพัฒนา frontend ทั่วไปเข้ามา พวกเขาโดยพื้นฐานแล้วไม่เข้าใจ และอยากทำทุกอย่างเป็น div พร้อมให้ VueJS ควบคุมตรรกะและเนื้อหาทั้งหมด
    สิ่งหนึ่งที่เราสูญเสียไปแบบค่อนข้างวัดได้คือ accessibility การนำลิงก์ไปทำใหม่แบบไร้เดียงสาเป็น div ที่ติด click event listener ทำให้ส่วนใหญ่ของไซต์นำทางด้วยคีย์บอร์ดไม่ได้
    เรื่องนี้ค่อนข้างน่ากังวล ถ้ากฎระเบียบเข้ามา เราจะต้องรีบลนลานกู้สิ่งที่เราทิ้งไปกลับมา
    ถึงอย่างนั้น ผมก็เห็นด้วยระดับหนึ่งว่าหาตัวอย่างไซต์ “HTML first” ที่มีชื่อเสียงได้ยาก ผมเชื่อในแนวทางนี้ แต่ยังไม่เคยเห็นกรณีที่นำไปใช้ได้ดีจริง ๆ อย่างไรก็ตาม เหตุผลอาจอยู่ที่การศึกษาอย่างเดียวก็ได้ เพราะเมื่อ HTML ทรงพลังขึ้น การศึกษาด้าน frontend development ก็ฝังแน่นกับ framework เป็นศูนย์กลางไปแล้ว
  • ถ้าคุณเป็นนักพัฒนา frontend ที่อายุน้อยกว่า jQuery การลองเริ่มโปรเจกต์ตามคำแนะนำนี้คงเป็นโอกาสดีที่จะได้เรียนรู้ว่าเราทำไมถึงใช้สิ่งอย่าง ขั้นตอน build และการพัฒนาก่อนยุค HMR นั้นลำบากแค่ไหน
    ดูเหมือนผู้เขียนไม่ได้เคยลองทำสิ่งนี้จริงในโปรเจกต์ที่มีคนมากกว่าสองคนเข้าร่วมและต้องรองรับเบราว์เซอร์ที่มีอยู่ 99% อีกทั้งดูเหมือนจะไม่ได้รันโค้ดของตัวเองด้วย อาจเป็นเพราะหน้าจอของผมไม่น่าอร่อยก็ได้ แต่ onlick ไม่ใช่ handler ของ div
  • เราลืมบทเรียนเก่า ๆ ไปแล้ว Backend first เป็นกลไกป้องกันตัวต่อคนที่เชื่อเฉพาะสิ่งที่มองเห็น และไม่เชื่อผู้เชี่ยวชาญ
    ถ้าสร้างผลิตภัณฑ์ที่ดูเหมือนใช้งานได้ แต่จริง ๆ แล้วใช้งานไม่ได้ พวกเขาจะไม่เข้าใจ แล้วเราก็จะถูกผลักให้ไปสู่เส้นทางที่สัญญาเกินจริงและส่งมอบต่ำกว่าที่สัญญา
    ข้อดีอย่างหนึ่งที่ไม่ค่อยมีคนพูดถึงของ unit test คือ มันช่วยให้โค้ดที่ผู้บริหารมองไม่เห็นได้รับการประกันคุณภาพมากขึ้นก่อนที่จะถูกเชื่อมต่อเข้าด้วยกัน มันช่วยลดช่วงเวลาชวนอึดอัดระหว่างการมีหน้าจอแรกกับการออก release
  • เห็นด้วย
    ผมทำเว็บไซต์แรกในปี 1999 ด้วย HTML ล้วน, CSS และ JS ล้วน แล้วโฮสต์บน Geocities
    หลังจากนั้นก็ทำไซต์และแอปด้วย PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript
    ตอนนี้ React, TSX components, CSS-in-TS, Effects, Context ให้ความรู้สึกเหมือนบ้านที่อยู่สบาย ในที่สุดก็เหมือนมีภาษาโปรแกรมที่สมบูรณ์สำหรับเว็บ/frontend แล้ว เป็นภาษาที่สร้างขึ้นอย่างชัดเจนเพื่อ frontend บนหลักการสมัยใหม่อย่าง functional และ reactive programming
    ตอนนี้ถึงจะสามารถทำ software development ได้ ก่อนหน้านั้น HTML, CSS, JS ล้วน, PHP ก็ใกล้เคียงกับการ hack มากกว่า Rails ดีสำหรับ full stack แต่ไม่ได้โดดเด่นใน frontend
    ถ้า web stack พร้อมสำหรับแอปด้วยเมื่อไหร่ ผมจะข้าม framework ไป ตอนนี้ยอมรับว่าอาจจะเพียงพอสำหรับไซต์แล้ว

• ปีนี้ผมยอมแพ้แล้ว ตอนนี้มันเป็นไปไม่ได้แล้วที่จะสู้ต่อกับ สัตว์ประหลาด React, Vue, Angular ที่มาพร้อม bundler, transpiler และสารพัดของจุกจิกพ่วงท้าย
  Node กับ npm โยนใส่แม้แต่โปรเจกต์ที่เพิ่งสร้างมาได้ไม่กี่วินาทีว่า “มีช่องโหว่ร้ายแรง 7 รายการและช่องโหว่วิกฤต 8 รายการ” ต้องดาวน์โหลดไฟล์เป็นพัน ๆ ไฟล์ และในนั้นอาจมีอะไรอย่าง wrapper สำหรับค่าบูลีนอยู่ด้วยก็ได้
  สำหรับผม ยุคที่เซิร์ฟเวอร์แบ็กเอนด์ Python คอยเสิร์ฟฟรอนต์เอนด์ไปด้วยน่าจะจบลงแล้ว

  • จงโกรธแค้น! จงโกรธแค้นต่อเครื่องจักร!
    จริง ๆ แล้วทั้งคุณและใคร ๆ ก็ไม่จำเป็นต้องมีฟรอนต์เอนด์ JavaScript หนักอึ้งที่บวมโตแบบนั้นเลย แค่ปฏิเสธมันก็พอ
    เสิร์ฟหน้าเว็บเบา ๆ จากแบ็กเอนด์หรือแคช แล้วถ้าจำเป็นจริง ๆ ก็ให้ CSS จัดการงานสวย ๆ แทน
    แล้วคุณจะได้พบกับเวลาเรนเดอร์ที่รวดเร็วและการเข้าถึงได้ทั่วโลก
  • กดปุ่มหนีออกมาเถอะ ข้อดีจำนวนมากของเว็บอยู่ใน Phoenix Liveview คุณสร้างเว็บไซต์ตอบสนองได้สวยงามโดยไม่ต้องมีของเล่น React/Node บ้าบอพวกนั้น
    แต่พูดตามตรง ตัวอย่างในบทความนี้แปลก ๆ ผมไม่เข้าใจว่าทำไมต้องเขียนแท็กเปล่า ๆ เอง แทนที่จะใช้ Phoenix form helper ที่ช่วยพิมพ์ข้อผิดพลาดและฟีเจอร์อำนวยความสะดวกหลายอย่างให้อัตโนมัติ แต่ผมเข้าใจเจตนานะ
  • ทำได้ แค่ลองใช้ htmx ดูก็พอ

• ประเด็นหลักน่าจะคือ ผู้ใช้ควรกด View Source แล้วเข้าใจได้ว่าเกิดอะไรขึ้นอยู่ ถ้าเป็นเว็บไซต์ ผมเห็นด้วย
  แต่ถ้าเป็นเว็บแอป อย่างน้อยถ้าเกิน 50 บรรทัดขึ้นไป ก็มีโอกาสสูงที่จะอยากใช้ภาษาที่มี type ทางเทคนิคแล้วจะใช้ .js ที่มี type annotation ในคอมเมนต์พิเศษร่วมกับ TypeScript compiler ก็ได้ แต่ผมไม่ค่อยสนุกกับมันนัก
  เมื่อก่อนผมค่อนข้างอินกับแนวคิดนี้มาก และก็เศร้าที่ทุกวันนี้เว็บไซต์ส่วนใหญ่เป็นก้อน HTML บรรทัดเดียวยาว ๆ ที่อ่านไม่ออก การ deploy ทุกอย่างเป็นไฟล์ HTML เดียวแบบไม่มี dependency นั้นมีความงามและความสง่างามอยู่ ขอ network request แค่ครั้งเดียวพอ
  สุดท้ายผมก็สร้าง “ระบบ build” เพื่อให้แก้ไขได้สะดวกขึ้น แต่ระบบ build ของผมคือ cat นั่นคือซอฟต์แวร์แบบพกพาที่ self-contained อยู่ในไฟล์เดียวที่มนุษย์อ่านได้
  ในทำนองเดียวกัน สิ่งที่เจ๋งที่สุดของการพัฒนาเว็บคือ คุณสร้างโปรแกรมเชิงโต้ตอบตัวแรกได้ด้วย Notepad กับเบราว์เซอร์พื้นฐานเท่านั้น แค่ลากไฟล์ HTML ไปวางในเบราว์เซอร์ มันเหมือนเวทมนตร์
  เพิ่มเติม: ผมเจอข้อดีที่คาดไม่ถึงของ HTML แบบ self-contained คือซอฟต์แวร์จะมีภูมิคุ้มกันต่อ bit rot ผมลองเปิดโปรเจกต์เก่าใน Web Archive แล้วไฟล์ JS ภายนอกไม่ได้ถูกเก็บไว้ เศร้าเลย แต่ตัวนี้ JS ทั้งหมดอยู่ใน HTML จึงโหลดได้ดี ชนะ
  https://web.archive.org/web/20210508133239id_/https://andai....
  นี่เป็นการคารวะต่อ SodaPlay Constructor ในอดีต ผมสร้าง editor ไม่สำเร็จ ดูซอร์สได้ตามสบาย

  • ผมค่อนข้างสงสัยตรงส่วนนี้ ตอนนี้เรามีวิธีมากมายในการมอง “หลังม่าน” ผ่าน developer panel
    มีมุมมอง DOM, แท็บ network, มุมมอง heap และฟีเจอร์จัดรูปแบบ JavaScript ในตัวให้อ่านง่าย
    แน่นอนว่า “View Source” ยังสำคัญอยู่ แต่ผมสงสัยว่ามันยังสำคัญแบบเด็ดขาดเหมือนที่กลุ่ม HTMX พูดกันหรือไม่
  • “การ deploy ทุกอย่างเป็นไฟล์ HTML เดียวแบบไม่มี dependency นั้นมีความงามและความสง่างามอยู่ ขอ network request แค่ครั้งเดียวพอ”
    ตอนนี้มี URL แบบ data: แล้ว เรื่องนี้เลยง่ายขึ้นอีก และยังมีประโยชน์ในการหลีกเลี่ยงปัญหาของ URL แบบ file:// ที่ไม่ต้องมีแม้แต่ HTTP server ด้วย
  • เพิ่มเติม: มีข้อเสนอให้ขยาย type annotations ใน JavaScript ทำให้สามารถรัน “ส่วนย่อยที่ค่อนข้างใหญ่” ของ TypeScript ได้โดยตรงในเบราว์เซอร์ ดีเลย!
    https://github.com/tc39/proposal-type-annotations
  • ผมไม่คิดว่าผู้เขียนกำลังสนับสนุนระบบไฟล์เดียวนะ แต่แทนที่จะไม่อยากบอกก็คือ

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

  • จากมุมมองของคนที่มาจากองค์กร C# ที่มีอินเทอร์เฟซมากเกินไป ผมมองว่านี่เป็นปฏิกิริยาตอบสนองตามธรรมชาติต่อระบบที่ถูกทำให้เป็นนามธรรมมากเกินไป
    ถ้าการ “เปลี่ยนปุ่มสีแดงเด้งดึ๋งให้เป็นปุ่มสีน้ำเงินสั่น ๆ” ต้องไล่ตามเขาวงกตของอินเทอร์เฟซและคลาส 3–7 ตัว เพื่อหาว่าคลาสไหนต้องมี implementation ใหม่ และอะไรสามารถ reuse ได้ งานที่ฟังดูเหมือนใช้เวลา 10 นาที ก็จะกลายเป็นการใช้เวลาครึ่งวันนั่งด่าคอมไพเลอร์หรือนักพัฒนาคนก่อนในใจ
    แน่นอนว่าควรทำ abstraction แต่ก็ควรมี วิธีรวมพฤติกรรมไว้ในที่เดียว เพื่อไม่ให้ต้องแตะไฟล์ 6 ไฟล์เพียงเพื่อแก้คอมโพเนนต์เดียว
    https://htmx.org/essays/locality-of-behaviour/#conflict-with...
  • Tailwind ก็เป็นขั้นตอน build เช่นกัน และมี “การกระทำลึกลับจากระยะไกล” อยู่มากพอ ๆ กัน ถ้าไม่ใช่แบบนั้นก็คงใช้ inline CSS ไปแล้ว
    การใช้ Tailwind เท่ากับเชื่อว่าไลบรารีของบุคคลที่สามจะ abstract สเปก CSS แทนให้ และเชื่อว่า quasi-spec ที่ถูก abstract นั้นจะถูกปฏิบัติตามตามการตั้งค่า build
  • ถ้า “ความเป็นท้องถิ่นของพฤติกรรม” เป็นกฎที่นิยามไว้อย่างหละหลวม แล้ว การแยกความรับผิดชอบ ไม่ใช่หรือ?
    ต้องแยกอะไรออกจากกัน? จะแบ่งตามเส้นไหน? กำหนดเส้นนั้นอย่างไร? เมื่อไรจึงสมเหตุสมผลที่จะดึง concern บางอย่างออกไปไว้ในคลาส เฟรมเวิร์ก มาร์กอัป ฯลฯ อื่น? เมื่อไรควรปล่อยให้อยู่ด้วยกันดีกว่า?
    คำตอบคือ “แล้วแต่สถานการณ์”
    ถ้าไม่แยกอะไรเลยก็จะกลายเป็นสปาเกตตี และถ้าแยกให้มากที่สุดทุกที่ทุกเวลา ก็จะกลายเป็นโค้ดที่ abstract เกินไป ซึ่งดูแลรักษายากพอ ๆ กับสปาเกตตี
  • เป้าหมายหลักที่ระบุไว้คือ “ขยายกลุ่มคนที่สามารถทำงานกับ codebase ของซอฟต์แวร์เว็บได้อย่างมาก” ซึ่งค่อนข้างต่างจากคำแนะนำสำหรับโปรแกรมเมอร์ทั่วไป
    ถ้าค่า default ทำงานได้ดี การ customize ก็ไม่ใช่สิ่งจำเป็น ดังนั้นประโยชน์ด้านประสิทธิภาพของ CSS และอื่น ๆ จึงถูกจัดลำดับความสำคัญไว้หลัง ความเรียบง่าย
  • ปัญหานี้มีหลายมิติ
    ถ้ามอง HTML เป็นภาษาเอกสาร/การนำเสนอ ก็ปฏิเสธ styling ไม่ได้ CSS ไม่ได้เพิ่มแค่ styling แต่ยังเพิ่ม animation ด้วย
    อย่างไรก็ดี CSS ก็อาจมองได้ว่าเป็น aspect-oriented programming
    ปัญหาจริงที่อธิบายไว้ตรงนี้คือการขาดเครื่องมือที่ยอดเยี่ยมซึ่งทำงานข้ามภาษาและเฟรมเวิร์ก

• การพึ่งพาเฟรมเวิร์กที่เรียบง่ายกว่าเมื่อทำได้เป็นเรื่องสมเหตุสมผล แต่แนวคิดเรื่อง การตัดขั้นตอน build ออกไป นั้นแทบจะเป็นเรื่องตลกโดยสิ้นเชิง
  ควรทำให้ขั้นตอน build มีประสิทธิภาพมากขึ้น และถ้าจำเป็นก็ไม่ต้องรวมไว้ใน production
  อีกอย่างก็ไม่เข้าใจว่าทำไมการเพิ่ม attribute ใน HTML ถึงควรถูกให้ความสำคัญก่อน นี่คือการสร้างเอกสารแล้วโฮสต์เป็นเว็บไซต์หรือ? ในโลกแบบไหนอีกที่วิธีนั้นเป็นสิ่งที่ควรเลือก? CSS ไม่ได้ยากต่อการสำรวจ และควรส่งเสริมแนวปฏิบัติ CSS ที่ดีกว่าด้วยซ้ำ
  สคริปต์ฝั่ง frontend อาจทำให้ styling สับสนได้ แต่ถ้าไม่จำเป็นก็ไม่ต้องพึ่งวิธีนั้นอยู่แล้ว การใส่ไว้ในเอกสารสไตล์ง่ายกว่าการใส่ attribute ด้วย JavaScript จึงเป็นเรื่องที่ชัดเจนอยู่แล้ว
  คำแนะนำบางส่วนอย่างใช้เท่าที่จำเป็นนั้นสมเหตุสมผลและชัดเจน แต่ส่วนที่เหลือสับสนหรือไม่ก็ไร้สาระอย่างโจ่งแจ้ง ผมก็ไม่เข้าใจว่าทำไมถึงถือว่าการคัดลอกหน้า HTML ทั้งหน้าได้เป็นเรื่องดี พูดตรง ๆ คือไม่ได้สนใจ และต่อให้ดู HTML ของบางหน้าไม่ได้ แหล่งเรียนรู้ HTML ก็มีอยู่เป็นล้าน ๆ แห่งตามตัวอักษรอยู่แล้ว
  โดยรวมแล้วทำให้ได้แต่เอียงคอสงสัย

  • เนื้อหาจำนวนมากลักษณะนี้เป็นปฏิกิริยาต่อ ลัทธิบูชาความซับซ้อน ในวงการพัฒนาเว็บ

• บทความนี้ทั้งบทเป็น antipattern และเป็นคำแนะนำที่แย่ อ่านแล้วเหมือนเขียนโดยคนที่ไม่เคยผ่าน growing pains จากการสร้างเว็บไซต์ซับซ้อน
  ตอนแรกเราก็เคยสร้างเว็บไซต์แบบนี้เหมือนกัน แต่พอมันเริ่มพังเพราะ side effect, ชื่อคลาสที่ชนกัน และ observability ภายในที่แย่ React ก็เข้ามาช่วยไว้
  แพตเทิร์นที่ต้องการคือ progressive enhancement และ output ควรเป็น HTML ที่สะอาดและถูกบีบอัด โดยมี JavaScript เข้ามาเสริมมัน กล่าวคือจำเป็นต้องมีขั้นตอน build ซึ่งตรงข้ามกับคำแนะนำในบทความนี้โดยสิ้นเชิง

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