Tailwind CSS เคยโดนด่าหนักจนแทบเลิกใช้ แล้วทำไมกลับกลายเป็นมาตรฐานใหม่ของวงการเว็บ?
หากเปรียบ Tailwind CSS เป็นเมนูอาหารในยุคแรกเริ่ม มันคงเหมือนอาหารหน้าตาประหลาดที่พนักงานเสิร์ฟเชียร์นักหนาว่า "อร่อยนะ ลองสิ" แต่พอนักพัฒนาเว็บหลายคนตักเข้าปากคำแรก กลับรู้สึกอยากจะคายทิ้ง. ในช่วงปีแรกๆ ที่เปิดตัว Tailwind CSS ไม่ได้ได้รับการต้อนรับที่อบอุ่นนัก ตรงกันข้าม มันโดนวิพากษ์วิจารณ์อย่างหนักหน่วง โดนแซะ โดนบูลลี่ และถูกมองว่าเป็น "ตัวตลก" ของวงการ Web Development คำถามคือ ทำไมเครื่องมือที่ปัจจุบันคนรักกันทั่วบ้านทั่วเมือง ถึงเคยโดนเกลียดขนาดนั้น? และมันพลิกเกมกลับมาได้อย่างไร?
นักพัฒนาเว็บในยุคนั้นถูกปลูกฝังมากับหลักการ Separation of Concerns นั่นคือ HTML ทำหน้าที่จัดโครงสร้างเนื้อหา และ CSS แยกไปอยู่อีกไฟล์เพื่อจัดการความสวยงาม แต่ Tailwind กลับทำลายกฎนั้นทิ้ง แล้วบอกให้ทุกคน "ยัดทุกอย่างลงไปใน HTML" ซึ่งนำมาสู่เสียงด่าทอในหลายประเด็น
นี่คือข้อหาแรกและหนักหน่วงที่สุด การเอาคลาสยิบย่อย - Utility classes ไปใส่ใน HTML ทำให้โค้ดดูรกตาและอ่านยากมาก หลายคนบ่นว่ามันบังคับให้นักพัฒนาต้อง "กวาดสายตาอ่านแนวนอน" ยาวเป็นหางว่าว แทนที่จะอ่าน CSS เป็นบรรทัดแนวตั้งที่อ่านง่ายกว่า
ตัวอย่างสุดคลาสสิก: เคยมีคนหยิบยกโค้ดหน้า Admin Dashboard ของ Netlify มาแฉว่า แค่การทำ Checkbox เล็กๆ ตัวเดียว ต้องยัด Tailwind Class ต่อกันยาวถึง 71 คลาส! สิ่งนี้ทำให้การรีวิวโค้ด กลายเป็นฝันร้าย เพราะเต็มไปด้วย String ยาวเหยียดที่ดูไม่ออกว่าคืออะไร
ในช่วงปี 2011-2015 ที่ Bootstrap ครองตลาดด้วยสไตล์สำเร็จรูป พอ Tailwind เข้ามาพร้อมแนวคิดที่ต้องประกอบร่างเองทีละคลาส เช่น w-16 h-16 bg-black text-white p-2 คนจึงด่าว่ามันถอยหลังลงคลอง และแทบไม่ต่างอะไรกับการเขียน style="..." แทรกใน HTML แบบคนยุค 90s ซึ่งเป็นสิ่งที่วงการพยายามหนีมาตลอด
การเรียนรู้ชื่อคลาสของ Tailwind ในช่วงแรกทำให้หลายคนหงุดหงิด เพราะบางทีก็ตั้งชื่อไม่ตรงไปตรงมา เช่น:
justify-* ตรงกับคุณสมบัติ justify-contentalign-* กลับไปตรงกับ align-content แทนที่จะเป็น align-items ที่คนใช้บ่อยกว่า ความไม่สม่ำเสมอนี้ทำให้คนเพิ่งเริ่มใช้ต้องเปิด Document สลับไปมาจนเสียเวลาใน CSS ดั้งเดิม คุณสามารถจัดกลุ่ม หรือที่เรียกว่า Chain Selectors เพื่อให้เขียนโค้ดครั้งเดียวได้ เช่น .btn:hover, .btn:focus { ... } แต่ใน Tailwind ยุคแรก คุณต้องพิมพ์ hover:bg-blue-500 focus:bg-blue-500 ซ้ำ ๆ ลงไปในทุกๆ คลาส ทำให้โค้ดบวมและบำรุงรักษายาก
เมื่อต้องเขียนเงื่อนไขคลาสแบบ Dynamic เช่น ปุ่ม Active หรือ Disabled ร่วมกับไลบรารีอย่าง classnames ใน React โค้ดจะยิ่งพันกันยุ่งเหยิง เพราะแต่ละเงื่อนไขต้องพ่วงมากับคลาสอีกเป็นสิบ ๆ ตัว
เมื่อมีบั๊กในหน้าเว็บ การหาต้นตอใน Browser DevTools กลายเป็นเรื่องปวดหัว เพราะไม่มีชื่อคลาสแบบ Semantic เช่น .nav-bar-wrapper ให้ค้นหาอีกต่อไป มีแต่ทะเลของคลาส div ที่หน้าตาเหมือนกันหมด และยังทดลองปรับ CSS ทีละหลาย ๆ ก้อนพร้อมกันใน DevTools ได้ยากอีกด้วย
แม้จะโดนด่าสารพัด แต่ Tailwind CSS ก็ไม่ยอมแพ้ ทีมพัฒนาได้รับฟังข้อเสนอแนะและอัปเดตแก้ไขจุดอ่อนอย่างต่อเนื่อง ประกอบกับทิศทางของวงการเว็บที่เปลี่ยนไป ทำให้ข้อเสียในอดีตถูกกลบด้วยข้อดีที่ทรงพลัง:
ข้อด้อยเรื่อง "HTML สกปรก" ถูกปัดตกไปเมื่อโลกก้าวเข้าสู่ยุคของ React, Vue และ Next.js เพราะปัจจุบันเราไม่ได้เขียนหน้า HTML ยาว ๆ อีกต่อไป แต่เราแยกมันเป็น Component เล็ก ๆ เช่น <Button/> ทำให้คลาสที่ยาวเป็นหางว่าวถูกเขียนแค่ที่เดียวและนำไป Re-use ได้ทั่วทั้งโปรเจกต์
นี่คือไพ่ตายที่อุดปากนักวิจารณ์เรื่อง "ไฟล์บวม" และ "ฟีเจอร์ไม่ครบ" ในอดีต Tailwind เคยไม่มี Pseudo-elements อย่าง ::before, ::after เพราะถ้าสร้างคลาสรอไว้ทั้งหมดไฟล์ CSS จะใหญ่ทะลุฟ้า แต่เมื่อมีระบบ JIT Engine มันจะคอยจับตาดูว่าเราพิมพ์คลาสอะไรลงไปบ้าง และ "สร้าง CSS เฉพาะตัวที่ใช้จริงๆ เท่านั้น"
ผลลัพธ์: ไฟล์ CSS ที่พร้อมขึ้น Production เล็กจิ๋วระดับกิโลไบต์ บางเว็บไม่ถึง 10KB ด้วยซ้ำ โหลดเร็วกว่าการเขียน CSS เองแบบดั้งเดิม
สิ่งที่ทำให้นักพัฒนาวัยเก๋าหลายคนยอมกลืนน้ำลายตัวเองแล้วหันมาใช้ Tailwind คือการแก้ปัญหา CSS Hell อย่างเด็ดขาด
.card-inner-box-left ดีไหมการเดินทางของ Tailwind CSS เป็นเครื่องพิสูจน์ชั้นดีว่า "บางครั้งนวัตกรรมใหม่ ก็ต้องแลกมากับการพังทลายกฎเกณฑ์เดิม ๆ"
จริงอยู่ที่มันอาจจะทำให้หน้าตาของ HTML ดูไม่สวยงาม และมี Learning Curve ในช่วงแรก แต่เมื่อแลกกับความเร็วในการพัฒนาที่เพิ่มขึ้น การบำรุงรักษาโค้ดที่ง่ายขึ้น และ Performance ที่ยอดเยี่ยมในตอนจบ จึงไม่น่าแปลกใจเลยว่าทำไมคนที่เคยบูลลี่ Tailwind ในวันนั้น ถึงกลายมาเป็นแฟนตัวยงในวันนี้.