ชุมชนนักพัฒนาเว็บกำลังมีการถกเถียงกันอย่างเข้มข้นเกี่ยวกับว่าวงจรไม่สิ้นสุดของ CSS framework และ methodology ต่างๆ กำลังแก้ปัญหาที่ถูกต้องหรือไม่ ในขณะที่นักพัฒนายังคงสร้างเครื่องมือใหม่ๆ เช่น Tailwind CSS , CSS-in-JS solutions และ utility-first frameworks หลายคนกำลังตั้งคำถามว่าการจัดรูปแบบ (styling) เคยเป็นปัญหาจริงที่ขัดขวางการพัฒนาเว็บหรือไม่
ความแตกต่างระหว่าง Document และ Application
จุดโต้แย้งหลักมุ่งเน้นไปที่วัตถุประสงค์การออกแบบเดิมของ CSS โดย CSS ถูกสร้างขึ้นเพื่อจัดรูปแบบเอกสาร - หน้าเว็บธรรมดาที่มีหัวข้อ ย่อหน้า และเลย์เอาต์พื้นฐาน แอปพลิเคชันเว็บในปัจจุบันเป็นสิ่งที่แตกต่างกันอย่างมาก ประกอบด้วยระบบคอมโพเนนต์ที่ซับซ้อน การเปลี่ยนธีมแบบไดนามิก และอินเทอร์เฟซแบบโต้ตอบที่ CSS ไม่ได้ถูกออกแบบมาเพื่อจัดการ ความไม่ตรงกันพื้นฐานนี้ทำให้เกิดการแก้ปัญหาชั่วคราวมานานหลายปีและเครื่องมือที่ซับซ้อนมากขึ้นเรื่อยๆ
สมาชิกชุมชนชี้ให้เห็นมุมมองทางประวัติศาสตร์ที่น่าสนใจ: แอปพลิเคชันเดสก์ท็อปจากหลายทศวรรษที่ผ่านมาสามารถเปลี่ยนธีมและมีความสอดคล้องกันได้มากกว่าเว็บแอปในปัจจุบัน ระบบปฏิบัติการในช่วงปลายทศวรรษ 1990 และต้นทศวรรษ 2000 มีการจัดธีมทั้งระบบที่ทำงานได้กับทุกแอปพลิเคชัน ซึ่งดูเหมือนเป็นเวทมนตร์เมื่อเปรียบเทียบกับแนวทางที่กระจัดกระจายในปัจจุบันที่ทุกเว็บไซต์คิดค้น UI pattern พื้นฐานใหม่
บริบททางประวัติศาสตร์: การออกแบบธีมของเดสก์ท็อปเทียบกับเว็บ
แอปพลิเคชันเดสก์ท็อป (ทศวรรษ 1990-2000):
- การใช้ธีมแบบเดียวกันทั่วทั้งระบบสำหรับทุกแอปพลิเคชัน
- องค์ประกอบ UI ที่สอดคล้องกัน
- อินเทอร์เฟซที่ผู้ใช้สามารถปรับแต่งได้ (ธีม Windows 98, XP )
- การควบคุมมาตรฐานของ OS ที่ตรงกับความต้องการของผู้ใช้
แอปพลิเคชันเว็บสมัยใหม่:
- แต่ละเว็บไซต์มีการจัดรูปแบบที่กำหนดเอง
- อินเทอร์เฟซผู้ใช้ที่ไม่สอดคล้องกัน
- ตัวเลือกการปรับแต่งสำหรับผู้ใช้ที่จำกัด
- การสร้างรูปแบบ UI พื้นฐานใหม่ในแต่ละเว็บไซต์
คำถามใหญ่เรื่องความซับซ้อน
บางทีการถกเถียงที่เข้มข้นที่สุดหมุนรอบคำถามว่าแอปพลิเคชันเว็บสมัยใหม่ต้องการความซับซ้อนจริงหรือไม่ นักพัฒนาหลายคนโต้แย้งว่าแอปพลิเคชันเว็บส่วนใหญ่เป็นเพียงฟอร์มที่ซับซ้อน - การดำเนินการ CRUD ที่ถูกแต่งแต้มด้วยอินเทอร์เฟซที่หรูหรา Gmail , ซอฟต์แวร์ภาษี, เครื่องมือจัดการโครงการ และพอร์ทัลประกันสุขภาพล้วนสรุปลงมาเป็นการกรอกฟอร์มและส่งข้อมูล แต่กลับถูกสร้างด้วย component framework ที่ซับซ้อนและระบบจัดการ state
99.9% ของแอปพลิเคชันที่ฉันใช้งานเป็นเพียงชุดของการดำเนินการ CRUD ง่ายๆ บางครั้งพวกเขาเพิ่มความซับซ้อนและความฉูดฉาดที่ไม่จำเป็น... แต่เมื่อพูดถึงแอปธุรกิจจริงๆ พวกเขาทั้งหมดก็เป็นเพียงการอัปเดตบันทึกข้อความในฐานข้อมูลด้วยความเร็วของมนุษย์
มุมมองนี้ท้าทายสมมติฐานทั้งหมดที่ว่าแอปพลิเคชันเว็บต้องการโซลูชันการจัดรูปแบบที่ซับซ้อน หากแอปส่วนใหญ่เป็นเพียงฟอร์มที่ปรับปรุงแล้ว ทำไมไม่ใช้ HTML form แบบดั้งเดิมกับ CSS ง่ายๆ?
 |
|---|
| การแสดงภาพของเลย์เอาต์เว็บแบบตารางแสดงให้เห็นความเรียบง่ายของแอปพลิเคชันเว็บ สะท้อนถึงการถกเถียงเกี่ยวกับความซับซ้อนของการออกแบบสมัยใหม่ |
วงจรเครื่องมือที่ไม่สิ้นสุด
การถกเถียงในชุมชนเผยให้เห็นความหงุดหงิดกับการเปลี่ยนแปลงอย่างต่อเนื่องของ CSS methodology แต่ละแนวทาง - ไม่ว่าจะเป็น BEM naming conventions, CSS Modules, utility classes ของ Tailwind หรือ CSS-in-JS solutions - ล้วนแก้ปัญหาเฉพาะในขณะที่สร้างปัญหาใหม่ นักพัฒนาพบว่าตัวเองต้องประเมิน trade-off อย่างต่อเนื่องแทนที่จะมุ่งเน้นไปที่การสร้างฟีเจอร์
นักพัฒนาที่มีประสบการณ์บางคนสนับสนุนแนวทางที่ง่ายกว่า: ใช้ utility classes เฉพาะสำหรับเลย์เอาต์ ใช้ scoped styles สำหรับคอมโพเนนต์ และรักษา global styles ชุดเล็กๆ สำหรับองค์ประกอบทั่วไป กลยุทธ์แบบผสมผสานนี้ดูเหมือนจะได้รับความนิยมในหมู่ทีมที่เบื่อหน่ายกับความซับซ้อนของ framework
ข้อดีข้อเสียของระเบียบวิธี CSS
| แนวทาง | ข้อดี | ข้อเสีย |
|---|---|---|
| BEM | การตั้งชื่อที่คาดเดาได้ | ตัวเลือกที่ยาวเยิ่นเกินไป |
| CSS Modules | การจำกัดขอบเขต | การปรับธีมขณะรันไทม์ที่จำกัด |
| Utility-first CSS ( Tailwind ) | การพัฒนาที่รวดเร็ว | มาร์กอัปที่ยุ่งเหยิง |
| CSS-in-JS | การจัดเก็บร่วมกันและความยืดหยุ่น | ต้นทุนประสิทธิภาพขณะรันไทม์ |
| Cascade Layers | การควบคุมที่มากขึ้น | เส้นโค้งการเรียนรู้ของทีม |
เบราว์เซอร์ในฐานะแพลตฟอร์มแอปพลิเคชัน
คำถามเชิงปรัชญาที่ลึกซึ้งกว่าเกิดขึ้นเกี่ยวกับว่าเบราว์เซอร์ควรพัฒนาไปในทิศทางที่แตกต่างหรือไม่ สมาชิกชุมชนบางคนโต้แย้งว่าพื้นฐานที่เน้นเอกสารของเว็บทำให้มันไม่เหมาะสมโดยพื้นฐานสำหรับการพัฒนาแอปพลิเคชัน พวกเขาชี้ไปที่เทคโนโลยีเช่น WebAssembly ว่าอาจเสนอเส้นทางสู่ประสบการณ์แอปพลิเคชันที่เหมือน native มากขึ้น โดยปราศจากข้อจำกัดของ HTML และ CSS
อย่างไรก็ตาม คนอื่นๆ โต้แย้งว่าการพัฒนาของเว็บจากเอกสารง่ายๆ ไปเป็นแอปพลิเคชันที่ซับซ้อนนั้นเป็นประโยชน์จริงๆ แนวทาง gradual enhancement ได้สร้างแพลตฟอร์มที่เข้าถึงได้ ตรวจสอบได้ และไม่ขึ้นกับแพลตฟอร์มในแบบที่ application framework ที่สร้างขึ้นเพื่อจุดประสงค์เฉพาะมักจะไม่เป็น
การหาความสงบกับความไม่สมบูรณ์
การถกเถียงในที่สุดชี้ให้เห็นว่าชุมชนนักพัฒนาเว็บอาจได้ประโยชน์จากการยอมรับว่าไม่มีโซลูชันที่สมบูรณ์แบบสำหรับความท้าทายในการจัดรูปแบบ แทนที่จะแสวงหา framework กระสุนเงินลูกต่อไป นักพัฒนาอาจได้รับการบริการที่ดีกว่าโดยการเข้าใจความต้องการเฉพาะของตนอย่างชัดเจนและเลือก trade-off ที่พวกเขายินดีที่จะยอมรับอย่างมีสติ
การถกเถียงสะท้อนความตึงเครียดที่กว้างขึ้นในการพัฒนาเว็บระหว่างความปรารถนาสำหรับโซลูชันที่เรียบง่ายและบำรุงรักษาได้กับความเป็นจริงของการสร้างแอปพลิเคชันที่ซับซ้อนและโต้ตอบได้บนแพลตฟอร์มที่ไม่ได้ถูกออกแบบมาสำหรับสิ่งเหล่านั้นในตอนแรก ขณะที่ชุมชนยังคงต่อสู้กับความท้าทายเหล่านี้ การมุ่งเน้นอาจกำลังเปลี่ยนจากการหาเครื่องมือที่สมบูรณ์แบบไปสู่การตัดสินใจที่รอบคอบมากขึ้นเกี่ยวกับการประนีประนอมที่ยอมรับได้
อ้างอิง: We Keep Reinventing CSS, but Styling Was Never the Problem
 |
|---|
| การแลกเปลี่ยนความคิดอย่างใคร่ครวญระหว่างมนุษย์และหุ่นยนต์เป็นสัญลักษณ์ของชุมชนนักพัฒนาเว็บในการแสวงหาความสมดุลระหว่างความซับซ้อนและความเรียบง่ายในโซลูชันการจัดรูปแบบ |