Utility First, Component Second

• ใน CSS มักมีความเข้าใจกันว่าแนวทางแบบ utility-first อย่าง tailwindcss คือการแขวนคลาสจำนวนมากไว้ใน HTML

• แต่นั่นเป็นเพียงรูปลักษณ์ภายนอกเท่านั้น แก่นสำคัญของ utility-first คือปัญหาเรื่องจังหวะเวลาในการประกอบคอมโพเนนต์

• วิธีที่เคยได้รับความนิยมในช่วงแรกของ CSS ก่อให้เกิดฝันร้ายในการบำรุงรักษา

• กระแส OOCSS พยายามแก้ปัญหาด้วยการประกอบคอมโพเนนต์ แม้ความสามารถในการนำกลับมาใช้ซ้ำจะสูงขึ้น แต่ก็ต้องเจอกับปัญหาความยากในการกำหนดขอบเขตของคอมโพเนนต์

• คอมโพเนนต์มีไว้เพื่อการนำกลับมาใช้ซ้ำ แต่ปัญหาคือเราไม่อาจรู้ล่วงหน้าได้ว่าอะไรจะถูกนำกลับมาใช้ซ้ำในอนาคต

• กระแส Atomic CSS พยายามแก้ปัญหาด้วยการกำหนดหนึ่งคลาสต่อหนึ่งพร็อพเพอร์ตี ทำให้ความเร็วในการพัฒนาเริ่มต้นเพิ่มขึ้น แต่ปัญหาเรื่องการบำรุงรักษาก็กลับมาอีกครั้ง

• แหล่งความจริงเดียว (Single Source of Truth) แตกสลายได้ง่ายเกินไป — ต้องพึ่งการค้นหาและแทนที่ทั้งระบบ (การพึ่งเทมเพลตภายนอกทั้งยุ่งยากและมีข้อจำกัด)

• utility-first ต่างจาก atomic ตรงที่ยอมรับคอมโพเนนต์ และต่างจาก OOCSS ตรงที่เริ่มต้นจาก utility โดยสามารถค่อยประกอบคอมโพเนนต์เมื่อมีความจำเป็นจริง

• มันเปลี่ยนคำถามจาก “จะทำอะไรให้เป็นคอมโพเนนต์” ไปเป็น “จะสร้างมันเมื่อไร”

• กล่าวคือ utility-first ควรถูกมองว่าเป็นการสังเคราะห์ ต่อยอด และพัฒนาจากทั้งสองแนวคิด

• ดังนั้นในแนวทาง utility-first คอมโพเนนต์จึงควรถูกเน้นมากกว่านี้ ไม่ใช่แค่ “เราอนุญาตให้มีคอมโพเนนต์” แต่ควรเป็น “เราเลื่อนการสร้างคอมโพเนนต์ออกไปจนถึงจุดที่จำเป็นจริง เพื่อเพิ่มการนำกลับมาใช้ซ้ำให้สูงสุด”

[nemorize]

อ่านได้ดีมากครับ

[mytory]

ขอบคุณครับ :)