การทดลองสุดเอ็กซ์ตรีมของนักพัฒนาเว็บไซต์คนหนึ่งที่ตัดสินใจเอา CSS classes ออกจากเว็บไซต์ส่วนตัวของตนเองทั้งหมด ได้จุดประกายการถกเถียงเกี่ยวกับความซับซ้อนที่เพิ่มขึ้นของการพัฒนาเว็บสมัยใหม่ และแนวทางที่เรียบง่ายกว่าอาจจะดีกว่า
นักพัฒนาคนนี้เริ่มต้นการเดินทางที่ผิดปกตินี้หลังจากตระหนักได้ว่าตนเองไม่ได้ทำตามคำแนะนำของตัวเองเกี่ยวกับการใช้ HTML elements ในตัวให้มีประสิทธิภาพมากขึ้น แทนที่จะอาศัย CSS classes แบบดั้งเดิม พวกเขาได้ปรับโครงสร้างเว็บไซต์ทั้งหมดใหม่โดยใช้เฉพาะ HTML tag selectors, custom elements และ custom attributes
Custom Elements มาแทนที่ Traditional Classes
แนวทางนี้มุ่งเน้นไปที่การใช้ custom HTML tags เช่น note-pad
และ random-pattern
แทนการใช้ classes กับ div elements ทั่วไป Custom tags เหล่านี้ทำงานได้โดยไม่ต้องใช้ JavaScript โดยใช้ประโยชน์จากธรรมชาติของ HTML ที่เรียกว่า progressive enhancement สำหรับการสร้างรูปแบบที่หลากหลาย นักพัฒนาใช้ custom attributes ที่มี key-value pairs จริงๆ แทนการใช้หลักการตั้งชื่อที่มักเห็นในระเบียบวิธีอย่าง BEM
Custom elements: HTML tags ที่ไม่ได้เป็นส่วนหนึ่งของมาตรฐาน แต่ยังคงเป็น HTML ที่ถูกต้อง ช่วยให้นักพัฒนาสามารถสร้าง semantic elements ของตนเองได้BEM: ระเบียบวิธีการตั้งชื่อ CSS ที่ย่อมาจาก Block, Element, Modifier
การเปรียบเทียบแนวทางเทคนิค
วิธีการแบบดั้งเดิม | วิธีการแบบไร้คลาส |
---|---|
<div class="header-primary"> |
<header> พร้อมการจัดรูปแบบตามบริบท |
หลักการตั้งชื่อแบบ BEM | แอตทริบิวต์กำหนดเองที่มีคู่คีย์-ค่า |
การแยกส่วนคอมโพเนนต์ | ความสัมพันธ์ขององค์ประกอบตามบริบท |
คลาสยูทิลิตี้ | แท็ก HTML กำหนดเอง |
ปฏิกิริยาจากชุมชนแสดงผลลัพธ์ที่หลากหลาย
การทดลองนี้ให้ผลลัพธ์ที่น่าประทับใจในบางด้าน เว็บไซต์สุดท้ายมี CSS เพียงประมาณ 5KB สำหรับทั้งเว็บไซต์ และการเข้าถึงได้ (accessibility) ดีขึ้นอย่างมากเนื่องจากการเน้นไปที่ semantic markup มากขึ้น อย่างไรก็ตาม ความคิดเห็นจากชุมชนชี้ให้เห็นว่าแนวทางนี้มีข้อจำกัดที่ชัดเจน
นักพัฒนาคนหนึ่งที่ลองใช้วิธีการคล้ายกันกล่าวว่า แม้จะทำงานได้ดีกับเว็บไซต์แบบเอกสารและสอนบทเรียนที่มีค่าเกี่ยวกับฟีเจอร์ CSS สมัยใหม่ แต่กลับกลายเป็นข้อจำกัดและเปราะบางเกินไปสำหรับแอปพลิเคชันที่ซับซ้อนกว่า ในที่สุดพวกเขาก็กลับไปใช้แนวทาง component-based และ utility frameworks
มันเป็นโซลูชันที่แข็งแกร่งสำหรับบล็อกและแอปที่มีลักษณะเป็นเอกสารอย่างชัดเจน แต่สำหรับสิ่งที่เกินกว่านั้น ฉันพบว่ามันจำกัดและเปราะบางเกินไป
ผลลัพธ์ที่ได้รับ
- ขนาด CSS สุดท้าย: ประมาณ 5KB สำหรับเว็บไซต์ทั้งหมด
- ปรับปรุงการเข้าถึงได้ผ่านการมุ่งเน้น semantic markup
- โครงสร้าง HTML ที่สะอาดขึ้น
- การกำจัด class ได้ 99% (ปลั๊กอิน syntax highlighting ยังคงใช้ classes อยู่)
- การใช้ฟีเจอร์ CSS สมัยใหม่ที่เพิ่มขึ้น (nesting,
:has()
,where()
)
ความขัดแย้งเรื่องความซับซ้อนในการพัฒนาเว็บ
การถกเถียงนี้ได้เน้นย้ำรูปแบบที่น่าสนใจในการพัฒนาเว็บ - วงจรที่ต่อเนื่องระหว่างการยอมรับความซับซ้อนและการค้นพบแนวทางที่เรียบง่ายกว่า สมาชิกชุมชนบางคนชี้ให้เห็นว่า HTML ถูกออกแบบมาในตอนแรกเป็นภาษาทั่วไปสำหรับเอกสารปกติ และเว็บไซต์ส่วนใหญ่ไม่จำเป็นต้องใช้มากกว่า default elements
อย่างไรก็ตาม คนอื่นๆ โต้แย้งว่านักพัฒนาไม่ใช่คนที่ขับเคลื่อนความซับซ้อน ผู้ใช้และนักออกแบบสมัยใหม่คาดหวัง interactive interfaces ที่มีแอนิเมชันที่ลื่นไหลและประสบการณ์ทางภาพที่ขัดเกลา ผลักดันให้นักพัฒนาไปสู่โซลูชันที่ซับซ้อนมากขึ้น แม้ว่าพวกเขาอาจชอบแนวทางที่เรียบง่ายกว่า
ความท้าทายในทางปฏิบัติเริ่มปรากฏ
แม้จะมีเสน่ห์ในแง่ปรัชญา แต่ปัญหาในทางปฏิบัติหลายอย่างก็เกิดขึ้น นักพัฒนาไม่สามารถสร้างเว็บไซต์ที่ปราศจาก class ได้อย่างสมบูรณ์เนื่องจาก dependencies อย่าง syntax highlighting plugins นอกจากนี้ สมาชิกชุมชนบางคนรายงานปัญหาความเข้ากันได้กับมือถือ โดยเนื้อหาไม่แสดงผลอย่างถูกต้องบนหน้าจอขนาดเล็ก
แนวทางนี้ยังต้องการการวางแผนที่รอบคอบมากขึ้นเมื่อเปรียบเทียบกับระบบ component ที่แยกออกจากกัน นักพัฒนาต้องคิดเกี่ยวกับความสัมพันธ์ระหว่าง elements แทนที่จะปฏิบัติต่อแต่ละ component อย่างอิสระ ซึ่งอาจเป็นเรื่องท้าทายสำหรับทีมใหญ่ที่มีระดับทักษะที่หลากหลาย
การทดลองนี้แสดงถึงการสำรวจพื้นฐานการพัฒนาเว็บที่น่าสนใจ แม้ว่าอาจไม่เหมาะสมกับทุกโครงการ มันทำหน้าที่เป็นเครื่องเตือนใจว่าบางครั้งการย้อนกลับไปตรวจสอบสมมติฐานของเราเกี่ยวกับแนวปฏิบัติที่ดีที่สุดสามารถนำไปสู่ข้อมูลเชิงลึกที่มีค่าเกี่ยวกับเครื่องมือและวิธีการที่เราใช้ในชีวิตประจำวัน
อ้างอิง: This website has no class