ศิลปะที่ถูกลืมของการจัดการตาราง HTML
ในภูมิทัศน์ของการพัฒนาเว็บที่วิวัฒนาการอยู่ตลอดเวลา ซึ่งเฟรมเวิร์กและไลบรารีใหม่ๆ เกิดขึ้นแทบทุกสัปดาห์ การค้นพบที่น่าประหลาดใจได้จุดประกายการอภิปรายอย่างคึกคักในหมู่นักพัฒนา: นั่นคือ HTML Tables API คุณสมบัติพื้นฐานของเบราว์เซอร์ที่นักพัฒนาสมัยใหม่หลายคนไม่เคยรู้ว่ามีอยู่มาก่อน การเปิดเผยครั้งนี้ได้สร้างช่องว่างระหว่างเจนเนอเรชันที่น่าสนใจ โดยนักพัฒนาที่มีประสบการณ์หวนนึกถึงวันแรกๆ ของการพัฒนาเว็บ ในขณะที่โปรแกรมเมอร์รุ่นใหม่กำลังเรียนรู้เกี่ยวกับความสามารถที่มีอยู่ในเบราว์เซอร์มานานหลายทศวรรษ
การอภิปรายเริ่มต้นขึ้นเมื่อมีบทความทางเทคนิคเน้นย้ำถึงเมธอดต่างๆ เช่น insertRow() และ insertCell() ซึ่งเป็น DOM API เฉพาะทางที่ออกแบบมาเพื่อสร้างและจัดการตาราง HTML อย่างเป็นโปรแกรมโดยเฉพาะ แม้เมธอดเหล่านี้จะเป็นส่วนหนึ่งของมาตรฐานเว็บมาตั้งแต่ปลายทศวรรษ 1990 แต่พวกมันกลับกลายเป็นความรู้ที่หายากในยุคที่ถูกครอบงำโดยเฟรมเวิร์กแบบประกาศและแนวทางการใช้ innerHTML
 |
|---|
| โค้ดตัวอย่างที่แสดงวิธีการใช้ HTML Tables API สำหรับการจัดการตารางในการพัฒนาเว็บ |
ช่องว่างความรู้ระหว่างเจนเนอเรชัน
ปฏิกิริยาจากชุมชนเผยให้เห็นถึงความแตกต่างที่ชัดเจนระหว่างนักพัฒนาที่เริ่มต้นอาชีพในช่วงยุคแรกๆ ของเว็บ และผู้ที่เข้าสู่วงการนี้ในยุคหลังๆ นักพัฒนามือเก่าหลายคนแสดงความประหลาดใจที่เมธอดเหล่านี้ถูกมองว่าถูกค้นพบใหม่หรือถูกละทิ้ง เนื่องจากพวกเขาเคยใช้เมธอดเหล่านี้เป็นประจำในอาชีพช่วงต้น นักพัฒนาหนึ่งคนระบุว่าพวกเขาสร้างอินเทอร์เฟซ CRUD แรกโดยไม่ต้องรีเฟรชหน้าเว็บทั้งหน้าด้วยการใช้เมธอดการจัดการตารางเหล่านี้พอดี
ฉันเริ่มลองผิดลองถูกกับเว็บเมื่อกว่า 20 ปีที่แล้ว แต่ส่วนใหญ่ทำงานด้านแบ็กเอนด์ในช่วง 10-15 ปีที่ผ่านมา ฉันไม่รู้เลยว่าปัจจุบันโปรแกรมเมอร์ไม่รู้เรื่องนี้
ในขณะเดียวกัน นักพัฒนาที่เริ่มต้นอาชีพในยุคของ React และเฟรมเวิร์กแบบคอมโพเนนต์ กำลังเรียนรู้เกี่ยวกับ API เหล่านี้เป็นครั้งแรกอย่างจริงจัง ช่องว่างทางความรู้นี้เน้นย้ำว่าความเทคโนโลยีเว็บที่เป็นพื้นฐานสามารถถูกบดบังโดยเลเยอร์ของ abstraction ได้รวดเร็วเพียงใด แม้ว่าพวกมันจะยังคงทำงานได้เต็มที่และมีประโยชน์อย่างมาก
ประโยชน์เชิงปฏิบัติของ API ตารางเฉพาะทาง
HTML Tables API นำเสนอข้อได้เปรียบหลายประการที่นักพัฒนาหลายคนอาจพลาดไป ไม่เหมือนกับการจัดการ DOM ทั่วไปหรือแนวทางการต่อสตริง เมธอดเฉพาะทางเหล่านี้ให้อินเทอร์เฟซที่ใช้งานง่ายกว่าสำหรับการทำงานกับโครงสร้างข้อมูลแบบตาราง API นี้ช่วยให้นักพัฒนาสามารถอ้างอิงถึงเซลล์ตารางโดยตรงผ่านดัชนี แทรกแถวในตำแหน่งที่เจาะจง และจัดการส่วนต่างๆ ของตาราง เช่น ส่วนหัว ส่วนเนื้อหา และส่วนท้าย โดยไม่ต้องเรนเดอร์ตารางทั้งตารางใหม่
ลักษณะด้านประสิทธิภาพการทำงานน่าสนใจเป็นพิเศษ แม้ว่านักพัฒนาบางส่วนจะรายงานว่าการสร้างตารางผ่านสตริงและ innerHTML อาจเร็วกว่าสำหรับการเรนเดอร์ครั้งแรก แต่ API เฉพาะทางสำหรับตารางจะเด่นชัดเมื่อทำการอัปเดตแบบเพิ่มเติม เนื่องจากแต่ละการเรียก API จะปรับเปลี่ยน DOM ที่ทำงานอยู่โดยตรง นักพัฒนาสามารถหลีกเลี่ยงค่าใช้จ่ายในการแยกวิเคราะห์สตริง HTML ขนาดใหญ่เมื่อเพิ่มหรือลบแถวหรือเซลล์แต่ละเซลล์
เมธอด API หลักของตาราง HTML:
insertRow(position): แทรกแถวใหม่ที่ตำแหน่งที่ระบุinsertCell(position): แทรกเซลล์เข้าไปในแถวที่ตำแหน่งที่ระบุrows[]: การเข้าถึงแถวของตารางในรูปแบบอาร์เรย์cells[]: การเข้าถึงเซลล์ของแถวในรูปแบบอาร์เรย์
เหตุใดตารางจึงตกยุค
การอภิปรายเปลี่ยนไปสู่คำถามว่าทำไม HTML tables ถึงมีความโดดเด่นน้อยลงในการพัฒนาเว็บสมัยใหม่ ข้อสรุปชี้ไปที่ปัจจัยหลักสองประการ: การใช้ตารางในทางที่ผิดในอดีตสำหรับการจัดวางเลย์เอาต์หน้าเว็บ และการเกิดขึ้นของ CSS Grid และ Flexbox สำหรับความต้องการจัดวางเลย์เอาต์ที่แท้จริง ในช่วงต้นของเว็บ ก่อนที่ความสามารถในการจัดวางเลย์เอาต์ของ CSS จะเติบโตเต็มที่ ตารางมักถูกใช้เพื่อสร้างเลย์เอาต์หน้าที่ซับซ้อน ซึ่งเป็นแนวปฏิบัติที่ถูกเตือนไม่ให้ทำเมื่อมีทางเลือกที่ดีกว่าปรากฏขึ้น
คำวิจารณ์ที่ชอบธรรมเกี่ยวกับเลย์เอาต์ที่ใช้ตารางนี้ น่าเสียดายที่ทำให้นักพัฒนาหลายคนหลีกเลี่ยงการใช้ตารางไปเลย แม้แต่สำหรับจุดประสงค์ที่ตั้งใจไว้จริงๆ นั่นคือการแสดงข้อมูลแบบตารางจริงๆ ดังที่ผู้แสดงความคิดเห็นหนึ่งคนสังเกตเห็น นี่เป็นอะไรที่คล้ายกับ 'cargo culting ที่ล่าช้า' ที่ทุกคนหลีกเลี่ยงบางสิ่ง แต่ไม่มีใครจำได้ว่าทำไม ผลลัพธ์ที่ได้คือการพึ่งพาโครงสร้างที่ใช้ div มากเกินไป ซึ่งขาดคุณสมบัติการเข้าถึงในตัวและประโยชน์ทางความหมายขององค์ประกอบตารางที่เหมาะสม
กรณีสมัยใหม่สำหรับตารางพื้นเมือง
แม้จะมี CSS Grid และ Flexbox ให้ใช้งาน แต่ HTML tables พื้นเมืองยังคงเสนอข้อได้เปรียบที่สำคัญสำหรับการแสดงข้อมูลที่มีโครงสร้าง ตารางให้คุณสมบัติการเข้าถึงในตัวที่โปรแกรมอ่านหน้าจอสามารถตีความได้ตามธรรมชาติ รวมถึงความสัมพันธ์ระหว่างแถวและคอลัมน์ที่เหมาะสม นอกจากนี้ยังมีการนำทางด้วยแป้นพิมพ์เริ่มต้นระหว่างเซลล์และความสามารถในการจัดตำแหน่งคอลัมน์ในตัว ซึ่งจะต้องใช้ CSS แบบกำหนดเองเพื่อจำลองด้วยโครงสร้างที่ใช้ div
นักพัฒนาหลายคนระบุว่าพวกเขาเห็นนักพัฒนา frontend สมัยใหม่ใช้องค์ประกอบ div สำหรับทุกอย่าง ตั้งแต่ปุ่มไปจนถึงหัวข้อ พลาดไปซึ่งความหมายทางความหมายและพฤติกรรมในตัวที่องค์ประกอบ HTML พื้นเมืองให้มา ดังที่ผู้แสดงความคิดเห็นหนึ่งคนชี้ให้เห็น งานเพิ่มเติมที่คุณต้องทำเพื่อให้ div ปฏิบัติตัวเหมือนปุ่มได้อย่างซื่อสัตย์นั้นมากกว่าการรีเซ็ตสไตล์บางอย่างอย่างมาก หลักการเดียวกันนี้ใช้กับตารางเทียบกับโครงสร้าง div ที่ใช้กริด
ข้อดีของตาราง HTML แบบดั้งเดิม:
- มีการรองรับการเข้าถึงสำหรับโปรแกรมอ่านหน้าจอในตัว
- การนำทางด้วยคีย์บอร์ดระหว่างเซลล์แบบเริ่มต้น
- โครงสร้างเชิงความหมายสำหรับข้อมูลแบบตาราง
- ความสามารถในการจัดแนวคอลัมน์และการจัดรูปแบบ
- ไม่จำเป็นต้องใช้ JavaScript สำหรับฟังก์ชันการทำงานพื้นฐาน
ปัญหาของเฟรมเวิร์ก
แง่มุมที่น่าสนใจของการอภิปรายมุ่งเน้นไปที่ว่า JavaScript frameworks สมัยใหม่มีปฏิสัมพันธ์กับ DOM APIs ระดับล่างเหล่านี้อย่างไร เฟรมเวิร์กแบบประกาศส่วนใหญ่เช่น React, Vue และ Angular ไม่ได้ใช้เมธอดตารางเฉพาะทางภายใน แต่กลับพึ่งพาการประสาน virtual DOM ของตัวเองและการสร้างองค์ประกอบทั่วไป ซึ่งหมายความว่าแม้แต่นักพัฒนาที่ทำงานกับตารางอย่างกว้างขวางในแอปพลิเคชันที่ใช้เฟรมเวิร์ก อาจไม่เคยพบกับความสามารถพื้นฐานของเบราว์เซอร์เหล่านี้
นักพัฒนาบางส่วนแสดงความกังวลเกี่ยวกับเลเยอร์ abstraction นี้ที่สร้างการตัดขาดจากความสามารถของแพลตฟอร์มพื้นฐาน อย่างไรก็ตาม บางคนตั้งข้อสังเกตว่าแนวทางแบบคอมโพเนนต์ของเฟรมเวิร์กสมัยใหม่มักทำให้วิธีการสร้าง DOM เฉพาะเจาะจงมีความเกี่ยวข้องน้อยลง เนื่องจากเฟรมเวิร์กจัดการการจัดการ DOM จริงอยู่เบื้องหลัง
ทางเลือกสมัยใหม่ที่นิยมใช้:
- CSS Grid สำหรับการจัดวางเลย์เอาต์ (ไม่ใช่สำหรับข้อมูลแบบตาราง)
- CSS Flexbox สำหรับการจัดวางเลย์เอาต์แบบมิติเดียว
- โครงสร้างแบบ Div ที่มี ARIA roles
- ไลบรารีคอมโพเนนต์ของ JavaScript framework
- Canvas หรือ SVG สำหรับการแสดงผลข้อมูลที่ซับซ้อน
มองไปข้างหน้า
การค้นพบ HTML Tables API ใหม่ได้จุดประกายบทสนทนาเกี่ยวกับคุณสมบัติแพลตฟอร์มเว็บที่ถูกลืมอื่นๆ อะไรบ้างที่อาจคุ้มค่ากับการทบทวนอีกครั้ง ผู้แสดงความคิดเห็นหลายคนกล่าวถึง FormData API และเหตุการณ์ที่เกี่ยวข้องกับฟอร์มเป็นตัวอย่างของคุณสมบัติแพลตฟอร์มเว็บที่ได้รับการอัปเดตที่มีความหมายและสามารถใช้เป็นแรงบันดาลใจสำหรับการปรับปรุงตารางได้
การปรับปรุง API ตารางที่เป็นไปได้ที่นักพัฒนาแนะนำรวมถึงการสนับสนุนที่ดีขึ้นสำหรับการสร้างองค์ประกอบ TH (table header) โดยตรง ความสามารถในการเรียงลำดับและกรองในตัวที่สร้างไว้ในเบราว์เซอร์ และเมธอดที่ใช้งานง่ายมากขึ้นสำหรับการดำเนินการตารางทั่วไป การอภิปรายสะท้อนถึงความสนใจที่เพิ่มขึ้นในการเสริมสร้างความสามารถพื้นฐานของเบราว์เซอร์ แทนที่จะพึ่งพาไลบรารี JavaScript ทั้งหมดสำหรับรูปแบบ UI ทั่วไป
สรุป
การฟื้นตัวของความสนใจใน HTML Tables API ที่ไม่คาดคิดทำหน้าที่เป็นเครื่องเตือนใจว่าการวิวัฒนาการอย่างรวดเร็วของการพัฒนาเว็บบางครั้งอาจทิ้งความสามารถพื้นฐานที่มีประโยชน์ไว้ข้างหลัง แม้เฟรมเวิร์กสมัยใหม่จะให้ abstraction ที่ทรงพลัง แต่การทำความเข้าใจแพลตฟอร์มพื้นฐานยังคงมีคุณค่า การอภิปรายเกี่ยวกับ API ตารางได้เน้นย้ำทั้งการเปลี่ยนแปลงระหว่างเจนเนอเรชันในความรู้การพัฒนาเว็บและคุณค่าอันยั่งยืนของ HTML ที่มีความหมาย
ในขณะที่แพลตฟอร์มเว็บยังคงวิวัฒนาการต่อไป เหตุการณ์นี้ชี้ให้เห็นว่าอาจมีคุณค่าในการทบทวน API เก่าๆ เป็นระยะๆ ด้วยมุมมองใหม่ บางครั้งเครื่องมือที่เราต้องการรออยู่ในเบราว์เซอร์แล้ว ถูกบำรุงรักษาอย่างเงียบๆ และพร้อมสำหรับช่วงเวลาที่จะมาโดดเด่นอีกครั้ง บทสนทนาทำให้นักพัฒนาหลายคนทบทวนใหม่ว่าเมื่อใดควรใช้องค์ประกอบตารางพื้นเมืองเทียบกับการใช้เลย์เอาต์ CSS แบบกำหนดเอง และตระหนักว่าการเลือกเครื่องมือที่เหมาะสมมักขึ้นอยู่กับว่าคุณกำลังแสดงข้อมูลแบบตารางจริงๆ หรือกำลังสร้างเลย์เอาต์ภาพ
อ้างอิง: Abandonware of the web: do you know that there is an HTML tables API?