แทนที่ JavaScript ด้วย HTML เพียงอย่างเดียว

 (htmhell.dev)
24 คะแนน โดย GN⁺ 2025-12-29 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • แนะนำวิธีสมัยใหม่ในการ แทนที่ฟังก์ชันที่พึ่งพา JS บนเว็บด้วย HTML/CSS
  • ใช้องค์ประกอบมาตรฐานอย่าง details·summary, datalist, popover เพื่อสร้างแอคคอร์เดียน การเติมข้อความอัตโนมัติ โมดัล และการนำทางแบบออฟสกรีน
  • แนวทางนี้ช่วย ลดการดาวน์โหลด·การประเมินผล·การใช้หน่วยความจำ จึงปรับปรุงทั้งประสิทธิภาพและประสบการณ์ผู้ใช้
  • มี ตัวอย่าง CodePen, เอกสาร MDN, และข้อมูลความเข้ากันได้ของเบราว์เซอร์ สำหรับแต่ละความสามารถ
  • ควรใช้ JS เฉพาะในส่วนที่จำเป็นจริง ๆ และ ใช้ความสามารถที่พัฒนาขึ้นของ HTML/CSS ให้เต็มที่

แทนที่ฟังก์ชัน JS ด้วย HTML และ CSS

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

แอคคอร์เดียน / แผงเนื้อหาแบบขยายได้

  • สามารถสร้างแอคคอร์เดียนได้โดยไม่ใช้ JS ด้วยองค์ประกอบ details และ summary
    • ผู้ใช้คลิกเพื่อเปิดและปิดเนื้อหาได้ และกำหนดสถานะเริ่มต้นด้วยแอตทริบิวต์ open
    • หากใช้แอตทริบิวต์ name เดียวกัน จะ เปิดได้เพียงหนึ่งแผงเท่านั้น
  • สามารถตกแต่งด้วย CSS หรือใช้ JS ควบคุมการเปิด/ปิดเพิ่มเติมได้
  • แหล่งข้อมูลที่เกี่ยวข้อง: เอกสาร MDN ของ details, ตัวอย่าง CodePen, ตารางความเข้ากันได้ของเบราว์เซอร์

ช่องกรอกพร้อมคำแนะนำอัตโนมัติ

  • ใช้ input ร่วมกับ datalist เพื่อสร้าง ดรอปดาวน์กรองอัตโนมัติ
    • เมื่อพิมพ์ รายการคำแนะนำจะถูกกรองโดยอัตโนมัติ
    • รองรับชนิดอินพุตได้หลากหลาย ไม่ใช่แค่ข้อความ เช่น number, time
  • ขณะนี้ Firefox รองรับเฉพาะอินพุตแบบข้อความ และยังมีข้อจำกัดด้านการเข้าถึงบนมือถือ
  • แหล่งข้อมูลที่เกี่ยวข้อง: เอกสาร MDN ของ datalist, บทสอนจาก SitePoint, ตารางความเข้ากันได้ของเบราว์เซอร์

โมดัล / ป๊อปโอเวอร์

  • ใช้แอตทริบิวต์ popover และ popovertarget เพื่อสร้างโมดัลและป๊อปโอเวอร์โดยไม่ใช้ JS
    • มีให้เลือก 3 โหมดคือ auto, hint, manual
    • auto จะปิดเมื่อคลิกด้านนอกหรือกด ESC ส่วน manual จะปิดได้ด้วยการสั่งเองเท่านั้น
  • Firefox และ iOS ยังไม่รองรับโหมด hint
  • แหล่งข้อมูลที่เกี่ยวข้อง: เอกสาร MDN ของ popover, บล็อก Chrome, ตัวอย่าง CodePen, วิดีโอเกี่ยวกับการเข้าถึง

การนำทาง / เนื้อหาแบบออฟสกรีน

  • ใช้ความสามารถของ popover เพื่อสร้าง เมนูนำทางแบบออฟสกรีน ได้
    • ใช้องค์ประกอบ nav เพื่อสื่อความหมาย และใช้ CSS translate ในการเลื่อนเข้าออกจากหน้าจอ
    • ปิดได้เมื่อคลิกด้านนอก และสามารถตั้งค่าให้ปิดแบบแมนนวลด้วย popover="manual"
    • ใช้องค์ประกอบเสมือน ::backdrop เพื่อทำพื้นหลังให้โปร่งแสงได้
  • แหล่งข้อมูลที่เกี่ยวข้อง: MDN Popover API, บล็อก Chrome, ตัวอย่าง CodePen

บทสรุป

  • แม้จะยอมรับพลังของ JS แต่ก็ควร ใช้เฉพาะในจุดที่จำเป็น
  • ความก้าวหน้าล่าสุดของ HTML/CSS ทำให้มี ทางเลือกแบบไม่ใช้ JS เพิ่มขึ้นมาก
  • ตัวอย่างเพิ่มเติมดูได้จากบทความในบล็อกของผู้เขียน “Replace JS with No-JS or Lo-JS Options”
  • เน้นการปรับปรุงประสบการณ์ผู้ใช้ผ่าน การลดการใช้ JS และการเพิ่มประสิทธิภาพ

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

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

 
labeldock 2025-12-29

ความพยายามแบบนี้บางครั้งก็ทำให้ผมได้ทบทวนว่าตัวเองกำลังทำ over-engineering อยู่หรือเปล่า แต่หากมองจากมุมของงานจริงที่มีข้อกำหนดมากมาย มันก็แทบไม่ต่างจากการแสดงผาดโผน
 
skageektp 2025-12-29

> สามารถทำแอคคอร์เดียนได้โดยไม่ต้องใช้ JS ด้วยองค์ประกอบ ** และ **

เหมือนว่ามีบางส่วนของเนื้อหาหายไปครับ
 
xguru 2025-12-29

แก้ไขไว้แล้ว~!
 
shakespeares 2025-12-29

ข้อจำกัดก็ค่อนข้างชัดเจนอยู่แล้ว และพอ AI ถูกใช้งานอย่างจริงจังขึ้นมา.. ยังจำเป็นต้องทำรีแฟกเตอร์แบบนี้อยู่ไหม? ได้คำนึงถึงส่วนอย่างการบล็อกเนื้อหา JS ไว้ด้วยหรือเปล่า?
 
GN⁺ 2025-12-29
ความคิดเห็นจาก Hacker News
  • น่าเสียดายที่ไม่ได้ใส่ตัวอย่างทั้งหมดไว้แบบ inline
    ถ้าใส่ตัวอย่างการแทนที่ด้วย HTML ลงในหน้าโดยตรงแทนลิงก์ CodePen ก็น่าจะน่าเชื่อถือกว่านี้มาก
    • เห็นด้วยสุดๆ บ่อยครั้งพอกดอะไรอย่าง FooMaker v1.0 กลับไม่มีตัวอย่างการใช้งานทั่วไปให้ดู แต่โชว์แต่ เคสข้อยกเว้นแปลกๆ
    • ตอนแรกนึกว่าเป็นบทความเมื่อ 25 ปีก่อนเสียอีก GIF แบบ dithered ให้ความรู้สึกย้อนยุคมาก
    • ผมก็หงุดหงิดที่ไม่มีตัวอย่าง inline เหมือนกัน แต่ถ้านี่เป็น guest blog post ก็พอเข้าใจได้ระดับหนึ่ง
  • แท็ก <details> / <summary> มีศักยภาพสูงมากจริงๆ
    แทบจะทำได้เกือบทุกอย่าง แต่ไลบรารีคอมโพเนนต์ส่วนใหญ่กลับมองข้ามมัน
    ไม่ต้องมี aria attribute และมี accessibility มาให้โดยพื้นฐาน
    • เมื่อก่อนข้อเสียคือการค้นหาด้วย cmd+f จะหาไม่เจอถ้าข้อความอยู่ใน details ที่ปิดอยู่ แต่ตอนนี้แก้ได้ด้วย attribute hidden="until-found" และ event
    • แต่เรื่อง แอนิเมชัน ยังจัดการยาก เพราะเบราว์เซอร์ยังไม่รองรับ transition สำหรับการสลับ display โดยตรง
    • เวลาค้นหาด้วย ctrl+f ก็มีฟังก์ชันเปิด details อัตโนมัติด้วย
    • <details> ยังใช้งานได้บนเว็บที่อิง Markdown อย่าง GitHub ด้วย สามารถพับ log ยาวๆ ให้ดูเรียบร้อยได้
    • ทำด้วย CSS ล้วนก็ได้ ตัวอย่างเช่นใน เอกสาร Go101 สามารถกด "+" เพื่อขยายได้ อีกทั้งยังมี เดโม tab panel ด้วย แสดงพลังของ Modern CSS ได้ดี
  • ประเด็นสำคัญไม่ใช่ “no JavaScript” แต่คือ HTML มี ความสามารถที่ถูกลืม อยู่แล้วมากมาย (เช่น form, dialog, validation, navigation)
    ตอนเขียนหนังสือ “You Don’t Need JavaScript” สิ่งที่รู้สึกคือ หลายครั้ง JS ไม่ได้เพิ่มความสามารถใหม่ แต่เป็นการ เสริมสิ่งที่แพลตฟอร์มมีอยู่เดิม มากกว่า
    • อยากให้มีหนังสือแบบนี้เพิ่มขึ้น ไม่ใช่สอนแค่ framework แต่เน้นการแก้ปัญหาเป็นหลัก
    • แต่ก่อนเบราว์เซอร์รองรับไม่ดี นักพัฒนาจึงต้องหาทางอ้อม และสุดท้ายมันก็กลายเป็นมาตรฐานไปแล้ว ช่วงหลังฟีเจอร์ CSS ออกเร็วขึ้นมากจน masonry layout ก็เข้าสู่ขั้นทดลองแล้ว
  • ฟีเจอร์ HTML ส่วนใหญ่นั้นยอดเยี่ยม แต่ <input> และ <datalist> ยังไม่พอสำหรับการใช้งานจริง
    ผู้ใช้คาดหวังเรื่อง การยอมรับคำสะกดผิด, ข้อความช่วยอธิบาย, ประสบการณ์ใช้งานบนมือถือ ฯลฯ แต่ datalist ยังตอบโจทย์ไม่ได้
    • สิ่งที่ลำบากที่สุดคือ datalist แยกข้อความที่แสดงกับค่าจริง (value) ไม่ได้
    • ในหลายกรณี select เหมาะกว่า แต่ select ไม่มีความสามารถในการค้นหา
    • หน้าตาพื้นฐานมัน ทื่อและไม่สวย มาก
    • บน Android ดรอปดาวน์ไม่ขึ้นเลย
    • มันทำงานต่างกันไปตามอุปกรณ์ สุดท้ายก็ต้องเติม JS อยู่ดี ถ้าใช้แต่ HTML อย่างเดียวก็จะตกอยู่ใน นรกของความเข้ากันได้
  • ช่วงนี้ผมไปสัมภาษณ์งานฝั่งฟรอนต์เอนด์มาหลายที่ แต่ยังวัดกันแค่ ทักษะ JS ที่ยึด React เป็นศูนย์กลาง
    แทบไม่สนใจเลยว่าจะใช้ HTML เชิงความหมายหรือ accessibility ได้ดีแค่ไหน
    • ถ้าทีมใช้ React คนที่ใช้ DOM API ตรงๆ อาจถูกมองว่า ไม่เข้ากับทีม
    • ถ้าใช้ไฟล์ CSS แยกต่างหาก คอมโพเนนต์จะสะอาดขึ้นมาก Tailwind ก็ไม่ได้แย่ แต่ไม่อยากใช้ตอนสัมภาษณ์
    • นอก HN แทบไม่มีใครสนใจแนวคิดแบบ HTML purist เลย
  • รู้สึกขัดใจที่มีแต่ลิงก์ CodePen แล้วไม่ใส่ตัวอย่างไว้ในหน้าโดยตรง
    เป็นบทความที่บอกว่า “มาทำด้วย HTML อย่างเดียว” แต่กลับพึ่งพาบริการภายนอก ก็เลยดูย้อนแย้ง
    • ส่วนตัวคิดว่าโอเคนะ CodePen สะดวกทั้งเรื่อง bookmark และ syntax highlighting แต่ก็มีความเสี่ยงเรื่อง link rot
    • ถึงอย่างนั้นก็น่าจะมีทั้งตัวอย่าง inline และลิงก์ CodePen ให้มาทั้งคู่
    • การย้ำเรื่อง HTML ล้วน แต่กลับต้องโหลด UI ของ CodePen ขนาด 2MB มันเป็นความ ย้อนแย้งด้าน UX
  • กำลังรอฟีเจอร์ select ที่ปรับแต่งได้ ซึ่งจะมาในเร็วๆ นี้
    ตอนนี้อยู่ใน WHATWG stage 3 และน่าจะมาแทนการทำดรอปดาวน์ด้วย JS แบบ ฝันร้าย ได้
    ดู บทความใน Chrome blog ได้
  • HTML ล้วนนั้นคุ้นเคยและสบายใจ แต่ก็มีข้อจำกัดถ้าจะสร้าง เว็บแอปที่มีฟังก์ชันจริงจัง ในยุคนี้
    ผมลองทางเลือกอย่าง HTMX หรือ Phoenix LiveView แล้ว แต่มันก็ไม่ใช่คำตอบที่สมบูรณ์
    สุดท้ายเลยรู้สึกว่า การยอมรับ JS สมัยใหม่คือทางที่สมจริงกว่า
    • ใช้ JS แค่นิดเดียวก็ไปได้ไกลกว่า HTML ล้วนมาก ตอนนี้เว็บสมัยใหม่มีปัญหา การใช้ JS มากเกินไปจน usability แย่ลง อย่างหนัก
    • เหมือนจะมอง HTMX ให้ซับซ้อนเกินไป ถ้ายึดสถานะฝั่งเซิร์ฟเวอร์เป็นหลักแล้วใช้ hx-select / hx-target ก็ยังทำให้มันเรียบง่ายได้
    • แท็ก <marquee> เคยเหมาะกับการทำ เลื่อนแนวนอน บนเว็บขายของ แต่ตอนนี้กลับต้องฝืนทำด้วย JS อยากให้ HTML รองรับแพตเทิร์น UI ได้ มากขึ้นในตัวเอง
    • เคยพยายามทำเอฟเฟ็กต์ marquee ใน React แล้ว เปลืองโทเคน ไปเยอะมาก แถมก็ไม่ใช่ลูปที่สมบูรณ์ เป็นแค่ลูกเล่นแอนิเมชัน
    • ถ้าใช้ Elixir กับ Phoenix อยู่ Gleam ก็น่าพิจารณาเหมือนกัน มันคอมไพล์เป็น JS ได้
  • HTML กับ JS เป็นเครื่องมือที่มี จุดประสงค์ต่างกัน
    เว็บแอปที่ซับซ้อนจำเป็นต้องมี JS แต่ก็ยังมีหลายพื้นที่ที่ HTML อย่างเดียวก็เพียงพอ
    • อย่าง Google Earth แน่นอนว่าต้องใช้ JS แต่ระดับ Gmail ผมคิดว่า HTML ก็ทำได้ ปัจจัยที่ขวางการพัฒนา HTML คือ กระแสและการโหมโฆษณา จากฝั่งผู้ผลิตเบราว์เซอร์
    • htmx เป็นความสัมพันธ์แบบ เกื้อหนุนกับ JS แก่นของมันคือการส่งข้อมูลเป็น hypertext ที่มีโครงสร้าง แทน JSON และในทางปฏิบัติก็เคยใช้ htmx + JS เล็กน้อยสร้างแอปที่ซับซ้อนได้อย่างรวดเร็ว
    • HTML ควรมีความสามารถในตัวมากกว่านี้ เช่น รองรับ HTTP verbs, ปรับปรุง input control เป็นต้น
    • หลายเว็บที่ใช้ JS หนักๆ จริงๆ แล้ว แทนด้วย htmx ได้สบาย การเลือกเครื่องมือเป็นเรื่องของความเคยชินมากกว่า
  • เห็นด้วยกับประโยคที่ว่า “JS ไม่จำเป็นต้องมาคุม accordion หรือเมนูนำทาง”
    แต่ตอนนี้ JS กลายเป็นเครื่องมือหลักของ การเก็บข้อมูลและติดตามโฆษณา ไปแล้ว
    เลยสงสัยว่าถ้าไม่มี JS บริษัทยักษ์ใหญ่จะยังทำ ระบบเฝ้าติดตามและบริการโฆษณา ได้ในระดับเดิมหรือไม่
    สุดท้ายแล้วความรู้สึกต่อต้าน JS ก็ไม่ได้มาจากปัญหาทางเทคนิคอย่างเดียว แต่เกิดจาก ความไม่ไว้วางใจต่อระบบนิเวศโฆษณา ด้วย