เปิดตัว Tailwind CSS v4.0

 (tailwindcss.com)
1 คะแนน โดย GN⁺ 2025-01-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Tailwind CSS v4.0 เป็นรีลีสที่เขียนเฟรมเวิร์กขึ้นใหม่ทั้งหมดตั้งแต่ต้น โดยยกระดับประสิทธิภาพการบิลด์อย่างมาก และเปลี่ยนแนวทางการตั้งค่าและการปรับแต่งให้ยึด CSS เป็นศูนย์กลาง
  • จากเกณฑ์ของ Catalyst เวลาในการบิลด์ทั้งหมดเร็วขึ้น 3.78 เท่า จาก 378ms ใน v3.4 เหลือ 100ms ใน v4.0 และการบิลด์เพิ่มเฉพาะส่วนที่ไม่มี CSS ใหม่ดีขึ้น 182 เท่า จาก 35ms เหลือ 192µs
  • การติดตั้งเรียบง่ายขึ้นด้วย @import "tailwindcss" เพียงบรรทัดเดียวและค่าเริ่มต้นแบบไม่ต้องตั้งค่า และผู้ใช้ Vite สามารถใช้ @tailwindcss/vite แทน PostCSS ได้
  • v4.0 ใช้ประโยชน์จากฟีเจอร์ CSS สมัยใหม่ เช่น cascade layers, @property, color-mix(), logical properties พร้อมเพิ่มการตรวจจับคอนเทนต์อัตโนมัติและการจัดการ @import ในตัว
  • container queries, 3D transform, Gradient API ที่ขยายขึ้น, @starting-style, not-*, field-sizing, color-scheme, inert และอื่น ๆ ถูกนำมาเป็นฟีเจอร์หลัก ทำให้พึ่งพาปลั๊กอินแยกน้อยลง

เอนจินประสิทธิภาพสูงที่เขียนใหม่ทั้งหมดตั้งแต่ต้น

  • Tailwind CSS v4.0 เป็นเวอร์ชันที่ เขียนเฟรมเวิร์กใหม่ทั้งหมด โดยอาศัยประสบการณ์ด้านสถาปัตยกรรมที่สั่งสมมาหลายปี
  • จากเบนช์มาร์กภายในของโครงการ การรีบิลด์ทั้งหมดเร็วขึ้นมากกว่า 3.5 เท่า และการบิลด์เพิ่มเร็วขึ้นมากกว่า 8 เท่า
  • เวลาในการบิลด์ค่ามัธยฐานตามเกณฑ์ Catalyst มีดังนี้
    • บิลด์ทั้งหมด: v3.4 378ms → v4.0 100ms, ดีขึ้น 3.78 เท่า
    • รีบิลด์เพิ่มที่มี CSS ใหม่: 44ms → 5ms, ดีขึ้น 8.8 เท่า
    • รีบิลด์เพิ่มที่ไม่มี CSS ใหม่: 35ms → 192µs, ดีขึ้น 182 เท่า
  • การบิลด์เพิ่มที่ไม่จำเป็นต้องคอมไพล์ CSS ใหม่เร็วขึ้นเกิน 100 เท่า จนเสร็จได้ในระดับไมโครวินาที
    • ยิ่งทำงานกับโปรเจกต์นานขึ้น ก็ยิ่งมีโอกาสใช้คลาสเดิมซ้ำอย่าง flex, col-span-2, font-bold มากขึ้น จึงเจอสถานการณ์แบบนี้บ่อย

ใช้ประโยชน์จากแพลตฟอร์ม CSS สมัยใหม่

  • v4.0 ใช้ฟีเจอร์ของเว็บแพลตฟอร์มที่พัฒนาขึ้นหลัง Tailwind CSS v3.0 อย่างจริงจัง
  • ฟีเจอร์ CSS พื้นฐานสำคัญมีดังนี้
    • Native cascade layers: ควบคุมวิธีที่กฎสไตล์ต่าง ๆ โต้ตอบกันได้ละเอียดขึ้น
    • Registered custom properties: ทำให้เกิดแอนิเมชัน gradient ได้ และช่วยเพิ่มประสิทธิภาพอย่างมากในหน้าขนาดใหญ่
    • color-mix(): ปรับความทึบของค่าสีทุกแบบได้ รวมถึง CSS variables และ currentColor
    • Logical properties: ทำให้การรองรับ RTL ง่ายขึ้นและลดขนาด CSS ที่สร้างขึ้น
  • ฟีเจอร์เหล่านี้ยังช่วยให้การทำงานภายในของ Tailwind เรียบง่ายขึ้น ลดพื้นที่เสี่ยงต่อบั๊ก และดูแลรักษาได้ง่ายขึ้น

ทำให้การติดตั้งและการรวมเข้ากับขั้นตอนบิลด์ง่ายขึ้น

  • ขั้นตอนติดตั้งถูกจัดระเบียบใหม่เพื่อลดจำนวนสเต็ปและ boilerplate
    • npm i tailwindcss @tailwindcss/postcss
    • เพิ่ม @tailwindcss/postcss เข้าไปในปลั๊กอิน PostCSS
    • ใช้ @import "tailwindcss" ในไฟล์ CSS
  • ใน v4.0 สามารถนำ Tailwind มาใช้ได้ด้วย CSS เพียงบรรทัดเดียว แทนการใช้คำสั่ง @tailwind
  • มีแนวทางแบบไม่ต้องตั้งค่า ที่เริ่มต้นใช้งานได้ทันทีโดยไม่ต้องกำหนดค่าใด ๆ แม้แต่พาธของไฟล์เทมเพลต
  • มีการรวมกฎ @import ให้เองโดยไม่ต้องใช้ปลั๊กอินภายนอก และใช้ Lightning CSS ภายในสำหรับ vendor prefixing และการแปลงไวยากรณ์สมัยใหม่
  • ผู้ใช้ Vite สามารถเลือกใช้ @tailwindcss/vite แทน PostCSS ได้
    • Tailwind CSS v4.0 เร็วอยู่แล้วแม้ใช้เป็นปลั๊กอิน PostCSS แต่ถ้าใช้ปลั๊กอิน Vite จะได้ประสิทธิภาพที่ดียิ่งขึ้น

การตรวจจับคอนเทนต์อัตโนมัติและ import ในตัว

  • การตั้งค่าอาร์เรย์ content ที่จำเป็นใน v3 ถูกแทนที่ด้วย heuristic การตรวจจับอัตโนมัติ ใน v4.0
  • รายการที่อยู่ใน .gitignore จะถูกละเว้นโดยอัตโนมัติ จึงไม่สแกน dependency หรือไฟล์ที่สร้างขึ้นซึ่งไม่ได้อยู่ภายใต้การจัดการเวอร์ชัน
    • ตัวอย่าง: /node_modules, /coverage, /.next, /build
  • นามสกุลไฟล์ไบนารีอย่างรูปภาพ วิดีโอ และ .zip ก็จะถูกละเว้นโดยอัตโนมัติเช่นกัน
  • เมื่อต้องการเพิ่มแหล่งข้อมูลที่ถูกยกเว้นโดยค่าเริ่มต้นอย่างชัดเจน สามารถใช้คำสั่ง @source ในไฟล์ CSS ได้
    • @source "../node_modules/@my-company/ui-lib";
    • @source ใช้ heuristic แบบเดียวกัน จึงยังคงตัดไฟล์ไบนารีออกโดยไม่ต้องระบุนามสกุลเพิ่มเติม
  • ก่อน v4.0 หากต้องการ inline ไฟล์ CSS อื่นผ่าน @import จำเป็นต้องใช้ปลั๊กอินแยกอย่าง postcss-import แต่ตอนนี้ไม่ต้องมีเครื่องมืออื่นแล้วด้วย การรองรับ import ในตัว
    • ระบบ import นี้ถูกสร้างมาเฉพาะสำหรับ Tailwind CSS และผสานเข้ากับเอนจินโดยตรงจึงทำงานได้เร็วกว่า

การตั้งค่าแบบ CSS-first และ theme variables

  • หนึ่งในการเปลี่ยนแปลงใหญ่ของ v4.0 คือการตั้งค่าโปรเจกต์โดยทำ ใน CSS โดยตรง แทน JavaScript
  • แทนที่จะใช้ไฟล์ tailwind.config.js สามารถปรับแต่งได้ด้วย @theme ภายในไฟล์ CSS ที่ import Tailwind
    • ตั้งค่า design tokens
    • นิยาม utility แบบกำหนดเอง
    • นิยาม variant แบบกำหนดเอง
  • design tokens ที่กำหนดใน @theme จะถูกเปิดเผยเป็น CSS variables โดยอัตโนมัติ
    • ตัวอย่าง: --font-display, --breakpoint-3xl, --color-avocado-500, --ease-fluid
  • CSS variables ที่สร้างขึ้นแบบนี้สามารถอ้างอิงใน runtime ด้วย CSS ปกติได้
    • นำ inline styles กลับมาใช้ซ้ำ
    • ส่งให้ไลบรารีอย่าง Motion เพื่อใช้ทำแอนิเมชัน

ค่า utility และ variant แบบไดนามิก

  • v4.0 ทำให้ utility และ variant หลายรายการรองรับค่าที่กำหนดเองเฉพาะจุดได้ง่ายขึ้นโดยไม่ต้องตั้งค่า
  • Grid สามารถใช้ขนาดที่ต้องการได้โดยไม่ต้องตั้งค่าเพิ่มเติม
    • ตัวอย่าง: grid grid-cols-15
  • custom boolean data attribute ก็สามารถ target ได้โดยไม่ต้องนิยามล่วงหน้า
    • ตัวอย่าง: data-current:opacity-100
  • spacing utilities อย่าง px-*, mt-*, w-*, h-* จะถูกคำนวณแบบไดนามิกจากตัวแปร spacing scale ตัวเดียว
    • ตัวอย่าง: --spacing: 0.25rem
    • w-17 จะถูกสร้างในรูปแบบ calc(var(--spacing) * 17)
  • เครื่องมืออัปเกรดที่เปิดตัวพร้อม v4.0 จะตรวจจับไวยากรณ์ค่ากำหนดเองที่ไม่จำเป็นแล้วทำให้เรียบง่ายลงให้อัตโนมัติเป็นส่วนใหญ่

พาเลตสีและ container queries

  • พาเลตสีเริ่มต้นทั้งหมดถูกอัปเกรดจาก rgb เป็น oklch
    • ทำให้ใช้ gamut ที่กว้างขึ้นนอกข้อจำกัดของ sRGB และได้สีที่สดขึ้น
    • เนื่องจากพยายามรักษาสมดุลระหว่างสีให้ใกล้กับ v3 การอัปเกรดโปรเจกต์เดิมจึงไม่ควรรู้สึกเหมือนเป็น breaking change
  • การรองรับ container queries ถูกนำเข้าเป็นฟีเจอร์หลักใน v4.0 ทำให้ไม่ต้องใช้ปลั๊กอิน @tailwindcss/container-queries
  • มี variant ใหม่ @max-* สำหรับใช้ max-width container queries
  • สามารถซ้อน @min-* และ @max-* เพื่อกำหนดช่วงของ container query ได้เหมือนกับ breakpoint variants ทั่วไป

ขยาย 3D transform และ Gradient API

  • v4.0 เพิ่ม API สำหรับ 3D transform
    • rotate-x-*
    • rotate-y-*
    • scale-z-*
    • translate-z-*
  • ความสามารถด้าน gradient ก็ถูกขยายเช่นกัน ทำให้สร้างเอฟเฟกต์ที่หลากหลายขึ้นได้โดยไม่ต้องเขียน CSS เอง
  • linear gradient สามารถรับค่ามุมได้โดยตรง
    • ตัวอย่าง: bg-linear-45
    • เดิม bg-gradient-* ถูกเปลี่ยนชื่อเป็น bg-linear-*
  • โหมดการไล่สีของ gradient ควบคุมได้ผ่าน modifier
    • bg-linear-to-r/srgb
    • bg-linear-to-r/oklch
    • ค่าปริยายของการไล่สีใน v4.0 คือ OKLAB และยังใช้ modifier สำหรับ color space อื่นได้
  • มี utility ใหม่ bg-conic-*, bg-radial-* สำหรับสร้าง conic และ radial gradient
    • ใช้งานร่วมกับ from-*, via-*, to-* เดิมได้
    • รวมถึงรองรับค่ากำหนดเองสำหรับการควบคุมรายละเอียด เช่น วิธี interpolation ของสีและตำแหน่ง gradient

variant และ utility ใหม่

  • variant ใหม่ starting รองรับ CSS @starting-style
    • ทำให้สร้าง transition ของพร็อพเพอร์ตีได้ตอนที่องค์ประกอบแสดงขึ้นครั้งแรก
    • สามารถทำแอนิเมชันให้กับองค์ประกอบที่ปรากฏบนหน้าได้โดยไม่ต้องใช้ JavaScript
    • การรองรับของเบราว์เซอร์อาจยังไม่เพียงพอสำหรับหลายทีมในตอนนี้ แต่กำลังเข้าใกล้จุดนั้น
  • variant ใหม่ not-* รองรับ CSS pseudo-class :not()
    • ตัวอย่าง: not-hover:opacity-75
    • ยังสามารถปฏิเสธ media query และ @supports query ได้ด้วย
  • v4.0 ยังเพิ่ม utility และ variant ต่อไปนี้
    • inset-shadow-*, inset-ring-*: ซ้อน box shadow ได้สูงสุด 4 เลเยอร์ในองค์ประกอบเดียว
    • field-sizing: รองรับการปรับขนาด textarea อัตโนมัติโดยไม่ต้องใช้ JavaScript
    • color-scheme: ช่วยลบ scrollbar สีสว่างใน dark mode
    • font-stretch: ปรับ variable font ที่รองรับหลายความกว้าง
    • inert: สไตล์องค์ประกอบที่ไม่โต้ตอบซึ่งถูกระบุด้วยพร็อพเพอร์ตี inert
    • nth-*: รองรับการจัดสไตล์ตระกูล nth
    • in-*: ทำงานคล้าย group-* โดยไม่ต้องมีคลาส group
    • :popover-open: ใช้ target popover ที่เปิดอยู่ได้ผ่าน variant open เดิม
    • descendant variant: ใช้จัดสไตล์องค์ประกอบลูกทั้งหมด

การเริ่มต้นและเส้นทางอัปเกรด

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-24
ความคิดเห็นบน Hacker News

  • ครั้งหนึ่งเคยวิจารณ์ข้อบกพร่องหลายอย่างของ Tailwind และความไม่เข้ากันกับแนวทางเว็บ “บริสุทธิ์” สมัยใหม่อย่างรุนแรง แต่ ความก้าวหน้าครั้งใหญ่ใน v4 นั้นน่ายินดีมาก
    การที่สามารถเข้าถึงธีมของ Tailwind ได้ในรูปแบบตัวแปร CSS แบบเนทีฟ และในเอกสารยังมีตัวอย่างคอมโพเนนต์ปุ่มที่เขียนด้วยตัวแปรเนทีฟในสไตล์ชีตภายนอก ถือเป็นการเปลี่ยนแปลงครั้งใหญ่มาก
    การที่สามารถ ตั้งค่าด้วย CSS ล้วน ๆ ได้ก็ดีเยี่ยม และตอนนี้ Tailwind ให้ความรู้สึกเหมือนยูทิลิตีที่เพิ่มเข้าไปในโปรเจกต์ใดก็ได้ มากกว่าจะเป็นเฟรมเวิร์กแบบ JavaScript ที่ “แพร่กระจาย” จนกลืนสถาปัตยกรรมที่สมเหตุสมผล
    ไม่ว่าคำวิจารณ์ในช่วงหลายปีที่ผ่านมาจะได้ผล หรือพวกเขาจะได้ข้อสรุปที่ดีด้วยตัวเองก็ตาม ข้อถกเถียงจำนวนมากระหว่างฝ่ายสนับสนุนและคัดค้าน Tailwind ตอนนี้ดูจะเกี่ยวข้องน้อยลงแล้ว และนั่นเป็นเรื่องดีมาก ตอนนี้จึงโฟกัสกับการสร้างผลิตภัณฑ์ได้

    • ในแง่การใช้งานจริงก็ยังคงวิจารณ์อยู่ แต่ก็น่าประหลาดใจที่ Tailwind เข้ากับ เวิร์กโฟลว์ที่สร้างโดย AI ได้ดี
      เพราะสามารถแสดงอะไรก็ได้อย่างเป็นระบบ จึงทำงานได้ดีจริง ๆ และมีบางอย่างที่มีประโยชน์มากอยู่ในนั้น
    • ยากที่จะเห็นด้วยว่าข้อถกเถียงฝ่ายสนับสนุน/คัดค้าน Tailwind ไม่เกี่ยวข้องอีกต่อไป และในฐานะดีไซเนอร์/ดีไซน์เอนจิเนียร์ มีปัญหาอยู่สองอย่าง
      อย่างแรก วิศวกร JavaScript/Tailwind เข้ามาครอบงำการถกเถียงด้านดีไซน์ไปแล้ว แทนที่จะโฟกัสกับ “utility-first”, “การลบโค้ดที่ไม่ได้ใช้”, “CSS ที่ type-safe” ควรโฟกัสกับระบบดีไซน์มากกว่า เช่น ในงานไทโปกราฟีจะใช้ Perfect Fifth หรือ Perfect Fourth
      อย่างที่สอง Tailwind ทำให้การมีส่วนร่วมในกระบวนการผลิตจริงเป็นเรื่องยาก การตัดสินใจด้านดีไซน์ถูกฝังอยู่ในนิพจน์คอมโพเนนต์ React ที่อ่านยากอย่าง flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)]
      สำหรับวิศวกร JavaScript อาจเข้าใจได้ แต่สำหรับดีไซน์ที่เป็นระบบ มันกลายเป็นกำแพง แทนที่จะใช้ CSS แสดงความสัมพันธ์ทางคณิตศาสตร์ที่แม่นยำ กลับกลายเป็นการใช้ inline style ที่สะดวกกว่า
    • อยากได้แค่ พาเลตสี ของ Tailwind CSS

  • CSS ใช้ง่ายกว่าเดิมมาก และเบราว์เซอร์ส่วนใหญ่ตอนนี้ก็ทำงานสอดคล้องกันแล้ว
    ไม่มีขั้นตอน build และไม่ทำให้มาร์กอัปเลอะเทอะด้วยโค้ดที่มากเกินไป จึงคุ้มค่าที่จะเรียนรู้
    จะเขียนแอตทริบิวต์ style ลงใน HTML โดยตรงก็ได้ ซึ่งเมื่อก่อนหลีกเลี่ยงกันเพื่อแยก concerns ออกจากกัน แต่ก็สงสัยว่าทำไมถึงอยากนำแนวทางคล้าย ๆ กันกลับมาใช้อีก หรือแค่ต้องการลดตัวอักษรลงไม่กี่ตัวกันแน่
    แอตทริบิวต์ style ดูจะเข้าใจง่ายกว่าด้วยซ้ำ เพราะไม่ต้องแปลงโค้ดในหัว เลยยังไม่ค่อยเห็นเสน่ห์ของมัน

    • มีหลายอย่างที่ทำด้วยแอตทริบิวต์ style ไม่ได้ เช่น pseudo-class :hover, :focus, pseudo-element ::before, ::after, media query, keyframe และ animation
      ประสบการณ์นักพัฒนาในโปรเจกต์ใหญ่ก็ไม่ดีนัก
      ในทางกลับกัน @scope ซึ่งกำลังจะกลายเป็นมาตรฐาน เป็นฟีเจอร์เสริมที่ดีสำหรับการวางสไตล์ไว้ใกล้กับจุดใช้งาน: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • ทุกวันนี้ Tailwind มักใช้ร่วมกับ ระบบ abstraction ของคอมโพเนนต์ ซึ่งทำหน้าที่เป็นชั้น abstraction แทน CSS class
      abstraction ของคอมโพเนนต์ช่วยแยกความหมายกับสไตล์ออกจากกันได้แน่นขึ้น ในทั้งสองกรณีต้องหา abstraction อย่าง “hero” เหมือนกัน แต่ในโลกของคอมโพเนนต์ ไม่ได้ abstraction แค่สไตล์ แต่รวมถึงชื่อแท็ก HTML ด้วย
      ไม่ว่าจะทางไหน “รายละเอียดด้านสไตล์” ก็ถูกแยกออกจาก “คอนเทนต์” ซึ่งเป็นไฟล์ซอร์สของหน้าอยู่แล้ว เพื่อ separation of concerns หรือการแยกคอนเทนต์กับการนำเสนอให้ดียิ่งขึ้น การยอมรับขั้นตอน build ก็เป็นสิ่งที่ทำได้
    • เสน่ห์คือไม่ต้องตั้งชื่อ CSS class, อ่านง่ายเพราะอยู่ข้าง ๆ HTML และรูปแบบการตั้งชื่อถูกทำให้เป็นมาตรฐาน ใช้กฎเดียวกันทุกที่
      ยังลดความจำเป็นในการดูแลไฟล์แยก และการลบคอมโพเนนต์ที่ไม่ได้ใช้ออกไปด้วย
      สามารถใช้ media query ที่แท็ก style ทำไม่ได้ และไม่มีความเสี่ยงที่จะไปแก้ class ที่ใช้ในที่อื่นโดยไม่ตั้งใจ global scope ของ CSS มีข้อดี แต่ก็อันตราย
    • นี่เป็นผลจากการที่เรายอมรับการผูกติดกับ React อย่างแน่นแฟ้นจนเกินไป
      สไตล์ถูกมองว่าเป็นของคอมโพเนนต์ ไม่ใช่ของระบบดีไซน์ ใน ecosystem วิศวกรรมที่ให้ JavaScript มาก่อน ยังต้องการ บริษัทที่ขับเคลื่อนด้วยดีไซน์ ซึ่งเข้าใจพลังของ CSS สมัยใหม่และดีไซน์ที่เป็นระบบมากกว่านี้
    • เมื่อดูจำนวนไฟล์ที่ต้องจัดการในโปรเจกต์ใหญ่ Tailwind ก็ดูน่าสนใจทีเดียว
      แนวทาง .css ปกติทำให้เกิดชื่อแปลก ๆ การซ้ำซ้อน และความเป็นไปได้ที่จะชนกัน css modules ก็เป็นตัวเลือกหนึ่ง แต่จำนวนไฟล์ต่อคอมโพเนนต์/หน้าจะเพิ่มขึ้นเป็นสองเท่าโดยแทบจะเป็นเช่นนั้นจริง ๆ
      sass หรือ less ให้ความรู้สึกเหมือนเอาปัญหาของ css modules กับ .css ปกติมารวมกัน
      ไม่ได้ชอบหรือเกลียด Tailwind โดยเนื้อแท้ และตอนแรกก็เกลียดมาก แต่ในโปรเจกต์ที่มีคอมโพเนนต์และหน้ารวมกัน มากกว่า 200 ไฟล์ ก็รู้สึกได้ถึงคุณค่าของมัน

  • ปฏิกิริยาแรกต่อ Tailwind คือ “น่ารำคาญ” รู้สึกเหมือนว่าทั้งที่รู้ CSS อยู่แล้ว แต่ตอนนี้ต้องมาเรียน CSS ใหม่อีกครั้ง
    คล้ายกับสถานการณ์ที่พ่อแม่พยายามช่วยลูกทำการบ้านคณิตศาสตร์ แต่แนวทางที่สอนในโรงเรียนต่างจากสมัยก่อนอย่างสิ้นเชิง วิธีแก้โจทย์ของตัวเองยังถูกต้องอยู่ แต่ไม่ถูกยอมรับ และลูกก็หงุดหงิดเพราะต้องปรับสองระบบให้ตรงกัน
    เข้าใจบรรยากาศที่ว่าในทีมมันทำงานได้ดีและขยายได้ดี ก็เลยต้องใช้ไป และเคยมีประสบการณ์แบบนั้นมาแล้ว
    ถึงอย่างนั้นก็ยังชอบ สไตล์ชีตธรรมดา ที่กำหนดเป้าหมายด้วยคลาสหรือแท็กมากกว่า โดยเฉพาะตอนนี้ที่ CSS รองรับ nested selector แล้วก็ยิ่งเป็นแบบนั้น
    ปัญหาเรื่องการจัดการสไตล์ชีตมีอยู่จริง และชอบแนวทางแบบ Remix/React Router ที่กำหนดและใช้ไฟล์ CSS ในระดับ route ถ้าแค่นั้นไม่พอ หรือสไตล์แบบไดนามิกซับซ้อนเกินไปสำหรับไฟล์ .css ก็ยังใช้ style={{...}} ได้เสมอ
    CSS ทรงพลัง ยืดหยุ่น และขยายได้ จึงรู้สึกว่า Tailwind เป็นข้อจำกัดมากกว่าการปรับปรุง ไม่ค่อยเข้าใจว่าทำไมยังได้รับความนิยมต่อเนื่อง แต่คิดว่าอีก 3–4 ปี ทุกคนก็คงย้ายไปใช้อย่างอื่นกันอีก

    • ตอนแรกก็รู้สึกอึดอัดเหมือนต้องเรียน CSS ใหม่ และเมื่อก่อนก็เคยยืนยันแบบเดียวกัน
      แต่พอได้มีส่วนร่วมในโปรเจกต์โอเพนซอร์สที่ใช้ Tailwind ก็เริ่มคุ้นเคย และตอนนี้รู้สึกต่างออกไป
      โดยพื้นฐานแล้ว Tailwind ใกล้เคียงกับ ชวเลข ของ style={{…}} สิ่งที่ถ้าเขียนในไฟล์ .css หรือ style object ต้องใช้หลายบรรทัด ยูทิลิตีเดียวจบได้ในราว 15 ตัวอักษร
      เวลาที่ใช้ค้นหาอะไรอย่าง “visual text replacement css” หรือเปิด CSS cheat sheet กับบทความ CSS-Tricks เมื่อ 8 ปีก่อนลดลงมาก แทนที่จะทำแบบนั้น ก็ดูเอกสาร Tailwind อยู่เสมอและหาคลาสยูทิลิตีที่ทำสิ่งที่ต้องการได้เร็ว
      หลายอย่างเข้าไปอยู่ในแคชในหัวได้มากจนน่าประหลาดใจ และรู้สึกว่าดีกว่าการพยายามจำ CSS ทั้งหมดที่จำเป็นสำหรับงาน layout มาก
    • คิดว่าเป็นเพราะตอนนี้ทั้งคอมโพเนนต์อยู่ใน ไฟล์เดียว
      ไม่ต้องไปแตะ CSS แยกต่างหาก และสไตล์ก็อยู่บนองค์ประกอบที่ถูกใช้สไตล์นั้นทันที จึงไม่ต้องเทียบไปเทียบมา
      จริง ๆ ใช้แค่แอตทริบิวต์ css ก็ทำได้ แต่ปัญหาคือทุกคนถูกสอนมาว่านั่นเป็นวิธีที่ผิด และรายการสตริงที่มียูทิลิตีหลายตัวก็ใช้ง่ายกว่าการใช้ CSS object ล้วน ๆ ด้วย
    • ข้อจำกัดช่วยลดความซับซ้อนที่เป็นไปได้ และนั่นคือเหตุผลที่ Tailwind ชนะ
      มันเป็น wrapper แบบโมดูลาร์ที่ประกอบกันได้และเป็นมาตรฐาน วางอยู่บนระบบขนาดใหญ่และซับซ้อน จึงถือเป็นความก้าวหน้าครั้งใหญ่
    • กำลังเรียนคณิตศาสตร์กับลูกอยู่ และมันไม่ได้ต่างจากที่ผมเคยเรียน ยังแก้ได้เร็วเหมือนเดิม
      ในทางกลับกัน บนโซเชียลมีเดียมีโพสต์ที่เอาการคูณกับการหารมาปนกันแล้วบอกว่าคำตอบมีเพียงคำตอบเดียว Tailwind ไม่ได้แย่ถึงขนาดนั้น แต่ในฐานะคนแก่ มันดูใกล้ทิศทางนั้นมากกว่า

  • ชอบ Tailwind ใช้มันใน 3 โปรเจกต์ตลอด 4 ปีที่ผ่านมา รู้สึกว่าใช้งานเป็นธรรมชาติ เอกสารดี และเรียบง่าย
    ไม่คิดถึงยุค emotion กับ styled-components ที่ต้องตั้งชื่อให้ div ทุกตัวที่มีสไตล์ในโปรเจกต์
    ใน Tailwind คอนเทนเนอร์ก็เป็นแค่ div กับคลาสไม่กี่ตัวเท่านั้น การถกเถียงเรื่องการตั้งชื่อ ลดลง และสมองกับเวลารีวิวที่เสียไปกับการตั้งชื่อลดลง

    • เห็นปัญหาเรื่องต้องคิดชื่อให้ styled div ทุกตัวอยู่บ่อย ๆ แล้วก็แปลกใจนิดหน่อย
      แทบไม่เคยคิดเกิน 1 วินาทีเพื่อจะตั้งชื่ออะไรสักอย่างเลย สำหรับบางคนมันเป็นจุดที่ติดขัดจริง ๆ หรือ? อยากรู้ว่ามันทำให้ชะงักจนไปต่อไม่ได้จริงหรือไม่
    • ถ้าบอกว่า “คลาสไม่กี่ตัว” แปลว่าคงได้ทำงานกับ product owner ที่ดีมาก
      คนที่ผมเจอมักจะกำหนดรายละเอียดทุกอย่างเท่าที่จะเป็นไปได้แบบไม่มีที่สิ้นสุด ปฏิบัติกับเว็บฟอร์มเหมือนเป็นรายการรีโนเวตบ้านส่วนตัวทาง HGTV
      ตอนลองใช้ Tailwind ครั้งหนึ่ง จำนวนคลาสมากกว่ามาร์กอัปเป็นหลักหนึ่ง และไม่นานก็อ่านยาก
    • เคยใช้ในหลายโปรเจกต์แต่ไม่ชอบ ในโปรเจกต์ใหญ่ ๆ มันเลอะเทอะเร็วมาก และรู้สึกเหมือนเป็น Bootstrap ตัวใหม่
      ตอนนี้พอใจกับ workflow แบบ CSS-in-JS เป็นการเขียน CSS แบบเดิมโดยมี LLM ช่วย แสดงรูปให้ LLM ดูแล้วขอคอมโพเนนต์ ก็ได้ออกมาทันทีพร้อมชื่อที่เหมาะสม
    • ถ้าเลือกได้ นี่เป็นหนึ่งในเหตุผลหลักที่เลี่ยง React
      การทำสไตล์ใน React ไม่ค่อยดี และถึงใช้ Tailwind ก็เป็นแค่ตัวเลือกที่แย่น้อยลงเท่านั้น
      ถ้าใช้ frontend framework กับขั้นตอน build แล้ว Svelte กับ Astro ก็ดีตามแต่กรณีใช้งาน สามารถทำสไตล์ด้วย CSS ธรรมดาได้ และถ้าคงคอมโพเนนต์ให้เล็ก ก็แทบไม่ต้องใช้ชื่อคลาส
      ใช้ element selector แล้วให้ framework จัด scope ของสไตล์ตอน build ก็พอ

  • เคยลองใช้ Tailwind กับไซต์ของตัวเองและค่อนข้างชอบ แต่อาจไม่ใช่ด้วยเหตุผลที่มักพูดกัน
    คุณค่าที่แท้จริงของ Tailwind คือการที่สามารถอ่าน สไตล์ทั้งหมดที่มีผลต่อองค์ประกอบหนึ่งได้ในที่เดียว
    ชื่อคลาสอาจยาวได้ แต่การอ่านบรรทัดยาว ๆ หนึ่งบรรทัดเร็วกว่าการต้องเปิด browser developer tools ทุกครั้ง หรือเลื่อนขึ้นลงไปมาระหว่างสไตล์ชีตหนึ่งไฟล์หรือมากกว่านั้นมาก
    ภายหลังกลับมาที่โค้ดนั้นก็แก้ได้อย่างมั่นใจโดยไม่ต้องกังวลว่าจะไปเปลี่ยนองค์ประกอบอื่น
    ธรรมชาติแบบ cascading ของ CSS ยังมีประโยชน์อยู่ แต่โดยปกติแล้วอยากจำกัดสไตล์ไว้กับองค์ประกอบเดียว ส่วนที่เหลือก็กลับไปใช้ CSS แต่ CSS ที่เขียนจริง ๆ มีน้อยมาก ส่วนใหญ่ก็แค่อยากจัดระยะห่างให้พอดี

    • คิดว่านั่นแหละคือเหตุผลที่ Tailwind ดีและสะดวก
      ชอบตรงที่ “จะทำ X ยังไง?” ไม่ได้กลายเป็นงานค้นคว้า 30 นาที แต่จบด้วยการค้นเอกสารอย่างรวดเร็ว
    • เครื่องมือที่แสดงสไตล์ทั้งหมดที่ใช้กับองค์ประกอบก็มีใน IDE เช่นกัน เช่น “Show Applied Styles for Tag” ของ Intellij หรือใน Chrome developer tools ก็แสดงให้อ่านได้ดี
      ชิ้นส่วน Tailwind ในโพสต์ HN นี้ดูค่อนข้างน่ากลัวเมื่อเทียบกับสิ่งนั้น
    • เห็นด้วยในระดับหนึ่ง แต่ปัญหาเดียวกันยังคงอยู่
      ถ้าเพิ่ม text-xl ให้ div แล้วข้างในมี div กับ span ซ้อนอยู่ ทั้งหมดจะสืบทอด text-xl ดังนั้นถ้าจะดูว่าอะไรทำให้เกิด text-xl ในองค์ประกอบที่ซ้อนอยู่ สุดท้ายก็ยังต้องไล่ย้อนขึ้นไปตาม ลำดับชั้นขององค์ประกอบ
      ถึงอย่างนั้น โดยรวมก็ง่ายขึ้นเล็กน้อย

  • วลีอย่าง “เวลาบิลด์สั้นลง”, “ไม่มี directive @tailwind อีกต่อไป”, “ไม่มีการตั้งค่าด้วย JavaScript”, “ออกแบบมาเพื่อเว็บสมัยใหม่” ฟังดูเหมือนว่า
    ตอนนี้ CSS ทำทุกอย่างที่เราเคยทำเองได้แล้ว แต่เราก็ยังแสร้งกันต่อไปว่าเรายังจำเป็นอยู่

    • ถ้าจะเกลียด อย่างน้อยก็ควรพยายามทำความเข้าใจว่ามันคืออะไร และทำไมคนถึงใช้มัน
    • จุดขายของ Tailwind ตั้งแต่แรกคือ “แทบจะเป็น CSS แบบ inline แต่ยุ่งยากน้อยกว่าแอตทริบิวต์ style และปรับให้เหมาะสมได้ง่ายกว่ามาก”
    • สงสัยว่าเมื่อก่อนมีอะไรที่ CSS ปกติทำไม่ได้จนต้องใช้ Tailwind
      Tailwind ก็แทบจะแมปกับ CSS แบบ 1:1 ไม่ใช่หรือ?
    • สงสัยว่ารับสารแบบนั้นจริง ๆ หรือเปล่า
      เข้าใจได้ว่าไม่ชอบ Tailwind แต่คิดว่าควรพูดว่าชอบหรือไม่ชอบอะไรใน Tailwind มากกว่าจะตั้งหุ่นฟางขึ้นมาโจมตี
      การดูถูกโปรเจกต์โอเพนซอร์สของคนอื่นและคนที่ใช้มันอย่างเป็นประโยชน์ก็ไม่ดีเหมือนกัน

  • อยากถามคนที่รู้ CSS ดี ๆ ผมไม่ค่อยรู้
    กำลังอัปโปรเจกต์ Phoenix ส่วนตัวเป็น 1.7 และเห็นว่า Phoenix ตอนนี้ใช้ Tailwind เป็นค่าเริ่มต้น เลยคิดว่าจะลองใช้แทน Bootstrap
    จนถึงตอนนี้เวอร์ชัน Bootstrap ดู “พอใช้ได้” แต่เวอร์ชัน Tailwind ดูเละเทะมาก
    วิธีที่ง่ายที่สุดในการได้ค่าเริ่มต้นที่ดูดี โดยไม่ต้องพยายามเป็นดีไซเนอร์คืออะไร? หรือควรแค่ติดตั้ง Bootstrap กลับไปแล้วจบ?

    • ถ้าเป็นกรณีนั้น ผมจะติดตั้ง Bootstrap กลับไป
      Tailwind ให้เครื่องมือเมื่อคุณอยากควบคุมดีไซน์ แต่สุดท้ายคุณก็ต้อง ควบคุมดีไซน์เอง
      ถ้าแค่อยากให้ดูดีและกลิ่นอายแบบ Bootstrap ก็รับได้ Bootstrap นั่นแหละเหมาะกว่า
      ตามทฤษฎีมีโปรเจกต์ที่นำ Bootstrap มาสร้างใหม่บน Tailwind ซึ่งน่าจะให้จุดเริ่มต้นแบบ Bootstrap พร้อมพลังของ Tailwind ได้ แต่ในทางปฏิบัติผมยังไม่เห็นอะไรที่ทำงานได้ดีกว่าการใช้ Bootstrap ตรง ๆ
    • สำหรับจุดประสงค์นั้นผมใช้ DaisyUI มีเว็บเดโมตัวอย่างอยู่ที่นี่: https://nwk-landing-kit.netlify.app
      เอกสาร DaisyUI อยู่ที่นี่: https://daisyui.com
    • ถ้ากำลังมองหาคอมโพเนนต์แบบ Bootstrap ลองใช้ฟรีได้ที่ https://flowbite.com/
      Tailwind ก็มีคอมโพเนนต์แบบเสียเงินด้วย แค่คัดลอกแล้ววางก็ใช้ได้ ข้อดีคือพอคุ้นแล้วคุณสามารถค่อย ๆ แก้คอมโพเนนต์ของ Flowbite ได้
    • ขึ้นอยู่กับว่าใครเป็นคนจ่ายเงิน
      ถ้ามีความมั่นคงในงานและอยากลองจับนู่นนี่ ก็เล่นกับ Tailwind ได้ คนที่ตามกระแสไวและเสียงดังส่วนใหญ่ดูเหมือนจะชอบ Tailwind
      แต่ถ้าเป็นโปรเจกต์ของตัวเอง ใช้เงินตัวเอง หรือมีเดดไลน์ ก็ควรใช้ Bootstrap ที่รู้อยู่แล้ว และโฟกัสกับการทำงานให้เสร็จมากกว่ามาสู้สงครามยืดเยื้อกับ UI
    • Tailwind กับ Bootstrap เหมือนเทียบแอปเปิลกับพายแอปเปิลมากกว่า
      Tailwind ให้ชุดคลาสที่ต้องนำมาซ้อนกันเพื่อสร้างคอมโพเนนต์
      ถ้าใช้ซอร์สของ UI component ร่วมด้วยก็น่าจะง่ายขึ้น เมื่อก่อนเคยใช้ TailwindUI แต่เป็นแบบเสียเงิน และคิดว่าน่าจะมีทางเลือกฟรีดี ๆ อยู่เหมือนกัน

  • บทสนทนาเรื่อง “Tailwind หรือไม่ Tailwind” มีแพตเทิร์นชัดเจน มันเกิดซ้ำทุกครั้งที่มีการพูดถึง Tailwind
    มีคนที่ไม่เคยใช้จริงจังเกิน 30 นาที แค่ลองนิดหน่อยหรืออ่านเอกสารผ่าน ๆ คนกลุ่มนี้ไม่ชอบ Tailwind และชอบอะไรอย่าง “CSS ล้วน” มากกว่า
    ในทางกลับกัน มีคนที่เคยใช้ในโปรเจกต์จริง ภายในทีมที่มีมากกว่าหนึ่งคน คนกลุ่มนี้เข้าใจคุณค่า ยอมรับ trade-off และชอบมัน
    ผมเห็นคนย้ายจากกลุ่มแรกไปกลุ่มที่สองเยอะ แต่แทบไม่เคยเห็นคนจากกลุ่มที่สองกลับไปกลุ่มแรก
    นั่นแหละคือเหตุผลที่ Tailwind ประสบความสำเร็จ มันอาจไม่สวยในสายตานักบริสุทธิ์นิยม แต่ในสายตาคนสร้างของและนักปฏิบัตินิยม มันยอดเยี่ยมจริง ๆ

    • ผมคิดว่าตัวเองไม่ค่อยเข้ากับทั้งสองกลุ่มนั้น
      ไม่ได้ต่อต้าน Tailwind แต่เหตุผลที่ยังไม่ได้ลองใช้คือยังไม่เห็นชัดว่ามันเป็นแนวทางที่ดีกว่าทางเลือกอื่นอย่าง Web Components หรือ React Styled Components อย่างไร
      ปัญหาใหญ่ที่สุดคือ Tailwind ทำให้ HTML รกไปด้วย utility class จำนวนมาก จนอ่านและดูแลรักษายาก
      ผมรู้ว่ามันดีกว่าไฟล์ CSS global ขนาดมหึมาและ CSS แบบคลาสสิกที่อิงชื่อแท็ก แต่ก็มีวิธีใช้ CSS ที่ scope อยู่กับคอมโพเนนต์ โดยไม่ทำให้ namespace ส่วนกลางปนเปื้อนอยู่แล้ว เช่น Web Components และ Styled Components
      ทั้งสองแบบผูกสไตล์ไว้กับคอมโพเนนต์ หรือโดยทั่วไปก็คือชุดของแท็ก HTML เฉพาะ ทำให้ดูได้ง่ายว่าสไตล์ไหนถูกใช้ที่ไหน
      ไม่ต้องมีชื่อคลาส global และลดความกังวลเรื่องผลข้างเคียงหรือการชนกันโดยไม่ตั้งใจ เมื่อลบคอมโพเนนต์ สไตล์ที่เกี่ยวข้องก็ถูกลบไปด้วย จึงไม่ต้องกังวลว่าจะมี CSS ที่ไม่ได้ใช้หลงเหลืออยู่ ด้วย shadow DOM ก็ไม่มีความเสี่ยงที่สไตล์ของคอมโพเนนต์หนึ่งจะไปกระทบอีกคอมโพเนนต์โดยไม่ตั้งใจ
      ผมให้ความสำคัญกับการรักษา HTML ให้สั้นและอ่านง่าย โดยไม่ผสมสไตล์เพื่อการแสดงผลเข้าไปในมาร์กอัปโดยตรง ถ้าสไตล์ทั้งหมดอยู่ในแอตทริบิวต์ class แบบ Tailwind ก็จะเกิดลิสต์คลาสยาว ๆ ในบรรทัดเดียว และถ้าต้องใส่ชื่อคลาสจริงร่วมด้วย HTML ก็จะรก
      มองแวบเดียวก็ยากที่จะรู้ว่ามีสไตล์อะไรถูกใช้ และจัด indentation ให้ดี ๆ ก็ยากด้วย มันทำให้นึกถึงหลายเหตุผลที่เราเคยเลิกใช้แอตทริบิวต์ style แบบ inline ใน HTML
      ไม่ได้เกลียด Tailwind แต่ในแง่ความอ่านง่าย การดูแลรักษา และการแยกความรับผิดชอบ ยังไม่เห็นข้อได้เปรียบที่ชัดเจนเหนือ Web Components หรือ Styled Components และยังมีข้อกังวลใหญ่ ๆ ที่ยังไม่ได้คำตอบ
      อ่านเอกสารแล้วแต่ยังไม่เคยใช้ และยังเข้าใจยากว่าทำไมถึงควรเลือก Tailwind แทนทางเลือกอื่น การที่มีคลาสจำนวนมหาศาลอยู่กลาง HTML ธรรมดา ทำให้สำหรับผมแล้วทั้งสองอย่างอ่านยาก

  • ยอมรับว่ามีคนที่ใช้ Tailwind ได้อย่างมีประโยชน์และทำงานได้มีประสิทธิภาพ แต่ตอนนี้ Tailwind อยู่แทบทุกที่ จึงเห็น หน้าตาที่ดูสะอาดแต่พบได้ทั่วไป โผล่อยู่หลายแห่ง

    • นี่เป็นการสับสนระหว่าง Tailwind กับ TailwindUI/shadcn
      โดยทั่วไป Tailwind ไม่ได้มีอิทธิพลต่อสไตล์มากกว่า CSS ปกติเท่าไรนัก มีข้อยกเว้นอยู่บ้าง เช่น เงาที่ค่อนข้างถูกทำให้เป็นมาตรฐานมากขึ้น และพาเลตสี indigo ที่ช่วงหลังส่งอิทธิพลออกไปภายนอกด้วย
    • Tailwind ให้ค่าเริ่มต้นที่สมเหตุสมผล แต่ไม่ได้ส่งผลต่อดีไซน์มากนัก
      แค่ผู้คนมักออกแบบไซต์ไปในแนวทางหนึ่งเท่านั้น โดยเฉพาะเมื่อใช้ร่วมกับ ShadCn
    • กลับรู้สึกเหมือนเป็นเรื่องดีด้วยซ้ำ ตัวเลือกของ Tailwind ถูกออกแบบมาดีและใช้งานได้ดี
      มองคล้ายกับที่ Inter ถูกใช้เป็นฟอนต์เว็บไซต์เหมือน Helvetica ยุคใหม่ ถ้ามีคนจำนวนมากใช้และมันดูดี ก็ไม่เห็นเหตุผลว่าทำไมถึงไม่ควรใช้
    • เมื่อก่อนก็เคยได้ยินคำพูดแบบนี้กับ Bootstrap แต่ไซต์ Bootstrap ที่ผมทำไม่ได้ดูเหมือนกันเลย
      Bootstrap มี utility class จำนวนมากมาตั้งแต่นานก่อน Tailwind และช่วยประหยัดเวลาได้มาก โดยไม่ได้บังคับหน้าตาเฉพาะแบบใดแบบหนึ่ง
      แค่เรียกใช้เฉพาะคลาสที่ต้องการก็พอ แน่นอนว่าถ้าไม่ได้ดาวน์โหลดไฟล์ซอร์ส Sass มาก็เป็นอีกเรื่องหนึ่ง แต่นั่นคงเป็นการเลือกที่โง่เขลา
    • ความเห็นของผมต่อปัญหานี้คือ UI framework ที่ดี หรือก็คือการผสมผสานระหว่าง Tailwind กับคอมโพเนนต์ ยังมีอยู่น้อย
      ดังนั้นโปรเจกต์ส่วนใหญ่จึงใช้เฟรมเวิร์กเพียงไม่กี่ตัว ถ้ามีโปรเจกต์ UI คุณภาพดีเพิ่มอีกสัก 4–5 ตัว โดยเฉพาะที่มีทิศทางสไตล์แตกต่างกันมากขึ้น ความหลากหลายก็น่าจะเพิ่มขึ้น
      ดีไซน์ก็เหมือนงานสร้างสรรค์หลายอย่าง ที่คนจำนวนน้อยอย่างน่าประหลาดเป็นผู้กำหนดกระแส
      อยากให้คนรู้เรื่องนี้มากขึ้น คิดว่าอาจมีคนมีพรสวรรค์ที่ไม่ลงมือทำเพราะคิดว่า “ต่อให้ฉันทำ ก็ไม่มีใครฟัง”
      แต่ถ้าคนเหล่านั้นบางส่วนลองลงมือ ผมเชื่อว่าอาจเปิดทางให้ UI ใหม่ ๆ กับส่วนใหญ่ของเว็บได้

  • Tailwind เป็นหลักฐานที่แสดงให้เห็น ข้อดีของ inline style นั่นคือวิธีสไตลิงบางสิ่งโดยไม่ต้องตั้งชื่อ ความเป็นสากลของสตริง และข้อจำกัดของสตริง
    ผมตั้งตารอสิ่งที่จะตามมาหลังจากนี้ และระหว่างนั้นก็คงจะใช้ Tailwind ไปแบบไม่ค่อยเต็มใจ