Ra mắt Tailwind CSS v4.0

 (tailwindcss.com)
1 điểm bởi GN⁺ 2025-01-24 | 1 bình luận | Chia sẻ qua WhatsApp
  • Tailwind CSS v4.0 là bản phát hành đã viết lại framework từ đầu, giúp tăng mạnh hiệu năng build và chuyển luồng cấu hình, tùy biến sang hướng lấy CSS làm trung tâm
  • Theo chuẩn Catalyst, build đầy đủ đã nhanh hơn 3,78 lần, từ 378ms ở v3.4 xuống 100ms ở v4.0; còn incremental build không có CSS mới được cải thiện 182 lần, từ 35ms xuống 192µs
  • Việc cài đặt được đơn giản hóa với một dòng @import "tailwindcss" và mặc định không cần cấu hình; người dùng Vite có thể dùng @tailwindcss/vite thay cho PostCSS
  • v4.0 tận dụng các tính năng CSS hiện đại như cascade layers, @property, color-mix(), logical properties, đồng thời bổ sung tự động phát hiện nội dung và xử lý @import tích hợp sẵn
  • Container query, 3D transform, API gradient mở rộng, @starting-style, not-*, field-sizing, color-scheme, inert... đã trở thành tính năng lõi, giúp giảm phụ thuộc vào plugin riêng

Cỗ máy hiệu năng cao được viết lại từ đầu

  • Tailwind CSS v4.0 là phiên bản được viết lại hoàn toàn từ đầu dựa trên nhiều năm kinh nghiệm về kiến trúc
  • Trong benchmark nội bộ của dự án, full rebuild nhanh hơn hơn 3,5 lần và incremental build nhanh hơn hơn 8 lần
  • Thời gian build trung vị theo chuẩn Catalyst như sau
    • Build đầy đủ: v3.4 378ms → v4.0 100ms, cải thiện 3,78 lần
    • Incremental rebuild có CSS mới: 44ms → 5ms, cải thiện 8,8 lần
    • Incremental rebuild không có CSS mới: 35ms → 192µs, cải thiện 182 lần
  • Những incremental build không cần biên dịch CSS mới nay nhanh hơn 100 lần, hoàn thành ở mức micro giây
    • Càng làm việc lâu trên một dự án, bạn càng thường tái sử dụng các class đã dùng như flex, col-span-2, font-bold, nên loại build này sẽ xuất hiện thường xuyên

Tận dụng nền tảng CSS hiện đại

  • v4.0 chủ động khai thác các khả năng của nền tảng web đã phát triển kể từ Tailwind CSS v3.0
  • Các tính năng CSS nền tảng chính gồm có
    • Native cascade layers: kiểm soát chi tiết hơn cách các quy tắc style khác nhau tương tác với nhau
    • Registered custom properties: cho phép animate gradient và cải thiện mạnh hiệu năng trên các trang lớn
    • color-mix(): có thể điều chỉnh độ mờ của mọi giá trị màu, bao gồm CSS variables và currentColor
    • Logical properties: đơn giản hóa hỗ trợ RTL và giảm kích thước CSS được tạo ra
  • Các tính năng này cũng giúp đơn giản hóa cách Tailwind được triển khai nội bộ, giảm bề mặt phát sinh lỗi và giúp bảo trì dễ hơn

Đơn giản hóa cài đặt và tích hợp build

  • Quy trình cài đặt được tinh gọn để giảm số bước và phần boilerplate
    • npm i tailwindcss @tailwindcss/postcss
    • Thêm @tailwindcss/postcss vào plugin PostCSS
    • Dùng @import "tailwindcss" trong file CSS
  • Trong v4.0, bạn có thể import và dùng Tailwind chỉ bằng một dòng CSS thay vì chỉ thị @tailwind
  • Bản v4.0 cung cấp luồng làm việc không cần cấu hình, có thể bắt đầu mà không cần bất kỳ thiết lập nào, kể cả đường dẫn file template
  • Không cần plugin bên ngoài riêng để bundle quy tắc @import; đồng thời Lightning CSS được dùng nội bộ cho vendor prefixing và chuyển đổi cú pháp hiện đại
  • Người dùng Vite có thể chọn @tailwindcss/vite thay cho PostCSS
    • Tailwind CSS v4.0 đã nhanh khi dùng dưới dạng plugin PostCSS, nhưng plugin Vite còn cho hiệu năng tốt hơn nữa

Tự động phát hiện nội dung và import tích hợp

  • Thiết lập mảng content từng cần ở v3 nay được thay bằng heuristic tự động phát hiện trong v4.0
  • Các mục có trong .gitignore sẽ tự động bị bỏ qua để không quét dependency hoặc các file sinh ra nhưng không được quản lý phiên bản
    • Ví dụ: /node_modules, /coverage, /.next, /build
  • Các phần mở rộng nhị phân như ảnh, video, .zip cũng tự động bị bỏ qua
  • Khi cần chủ động thêm các nguồn vốn mặc định bị loại trừ, bạn có thể dùng chỉ thị @source ngay trong file CSS
    • @source "../node_modules/@my-company/ui-lib";
    • @source cũng dùng cùng heuristic nên các loại file nhị phân vẫn bị loại trừ mà không cần khai báo phần mở rộng riêng
  • Trước v4.0, muốn inline file CSS khác bằng @import thì cần plugin riêng như postcss-import, nhưng giờ đã có hỗ trợ import tích hợp sẵn, không cần thêm công cụ khác
    • Hệ thống import được xây riêng cho Tailwind CSS và tích hợp chặt với engine nên chạy nhanh hơn

Cấu hình CSS-first và theme variables

  • Một thay đổi lớn của v4.0 là cấu hình dự án được thực hiện trực tiếp trong CSS thay vì bằng JavaScript
  • Thay vì file tailwind.config.js, bạn có thể dùng @theme trong file CSS import Tailwind để tùy biến
    • Thiết lập design token
    • Định nghĩa utility tùy chỉnh
    • Định nghĩa variant tùy chỉnh
  • Các design token định nghĩa trong @theme mặc định sẽ được xuất ra dưới dạng CSS variables
    • Ví dụ: --font-display, --breakpoint-3xl, --color-avocado-500, --ease-fluid
  • Các CSS variables được tạo ra như vậy có thể được tham chiếu trong CSS thông thường ở runtime
    • Tái sử dụng trong inline style
    • Truyền vào các thư viện như Motion để xử lý animation

Giá trị utility động và variant

  • v4.0 đơn giản hóa để nhiều utility và variant có thể nhận các giá trị tùy ý mà không cần thiết lập trước
  • Grid có thể dùng kích thước mong muốn mà không cần cấu hình riêng
    • Ví dụ: grid grid-cols-15
  • Các boolean data attribute tùy chỉnh cũng có thể được target mà không cần định nghĩa trước
    • Ví dụ: data-current:opacity-100
  • Các utility spacing như px-*, mt-*, w-*, h-* được suy ra động từ một biến spacing scale duy nhất
    • Ví dụ: --spacing: 0.25rem
    • w-17 sẽ được tạo dưới dạng calc(var(--spacing) * 17)
  • Công cụ nâng cấp đi kèm v4.0 cũng sẽ tự động đơn giản hóa trong hầu hết trường hợp khi phát hiện cú pháp giá trị tùy ý không còn cần thiết

Bảng màu và container query

  • Toàn bộ bảng màu mặc định đã được nâng cấp từ rgb sang oklch
    • Vượt qua giới hạn của không gian màu sRGB để tận dụng gamut rộng hơn, giúp màu sắc rực rỡ hơn
    • Vì vẫn cố giữ cân bằng giữa các màu như ở v3, nên khi nâng cấp dự án cũ sẽ không có cảm giác như một breaking change
  • Hỗ trợ container query đã trở thành tính năng lõi trong v4.0, nên không còn cần plugin @tailwindcss/container-queries
  • Variant @max-* mới cho phép dùng max-width container query
  • Có thể xếp chồng @min-* và @max-* để định nghĩa phạm vi container query giống như với các breakpoint variant thông thường

3D transform và API gradient mở rộng

  • v4.0 bổ sung API cho 3D transform
    • rotate-x-*
    • rotate-y-*
    • scale-z-*
    • translate-z-*
  • Tính năng gradient cũng được mở rộng để tạo đa dạng hiệu ứng hơn mà không cần CSS tùy chỉnh
  • Linear gradient có thể nhận góc làm giá trị
    • Ví dụ: bg-linear-45
    • bg-gradient-* trước đây đã được đổi tên thành bg-linear-*
  • Chế độ nội suy màu của gradient có thể được điều khiển bằng modifier
    • bg-linear-to-r/srgb
    • bg-linear-to-r/oklch
    • Mặc định nội suy trong v4.0 là OKLAB, và bạn cũng có thể dùng modifier cho các không gian màu khác
  • Các utility bg-conic-*, bg-radial-* mới cho phép tạo conic gradient và radial gradient
    • Hoạt động cùng với from-*, via-*, to-* hiện có
    • Bao gồm hỗ trợ giá trị tùy ý để điều khiển chi tiết như cách nội suy màu và vị trí gradient

Variant và utility mới

  • Variant starting mới hỗ trợ CSS @starting-style
    • Có thể tạo transition thuộc tính khi phần tử xuất hiện lần đầu
    • Có thể animate các phần tử xuất hiện trên trang mà không cần JavaScript
    • Mức hỗ trợ trình duyệt có thể vẫn chưa đủ với đa số team, nhưng đang đến rất gần
  • Variant not-* mới hỗ trợ pseudo-class CSS :not()
    • Ví dụ: not-hover:opacity-75
    • Cũng có thể phủ định media query và @supports query
  • v4.0 cũng bổ sung các utility và variant sau
    • inset-shadow-*, inset-ring-*: có thể xếp tối đa 4 lớp box shadow trên một phần tử
    • field-sizing: hỗ trợ tự động thay đổi kích thước textarea mà không cần JavaScript
    • color-scheme: có thể loại bỏ scrollbar sáng trong dark mode
    • font-stretch: điều chỉnh variable font hỗ trợ nhiều độ rộng khác nhau
    • inert: style cho các phần tử không tương tác được đánh dấu bằng thuộc tính inert
    • nth-*: hỗ trợ style theo họ nth
    • in-*: hoạt động tương tự group-* mà không cần class group
    • :popover-open: variant open hiện có cũng target được popover đang mở
    • descendant variant: style cho mọi phần tử con

Bắt đầu và lộ trình nâng cấp

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-01-24
Ý kiến trên Hacker News

  • Từng có thời tôi chỉ trích mạnh mẽ nhiều khiếm khuyết của Tailwind và việc nó thực sự không tương thích với cách làm web “thuần” hiện đại, nhưng bước tiến lớn của v4 là điều rất đáng mừng
    Việc có thể truy cập theme của Tailwind dưới dạng biến CSS native, và trong tài liệu thậm chí có ví dụ component nút được viết bằng biến native trong stylesheet bên ngoài, là một thay đổi rất lớn
    Việc có thể cấu hình chỉ bằng CSS cũng rất tuyệt, và giờ Tailwind không còn giống một framework kiểu JavaScript có tính “lan truyền” nuốt chửng kiến trúc hợp lý nữa, mà giống một tiện ích có thể thêm vào bất kỳ dự án nào
    Dù những lời chỉ trích vài năm qua đã có tác dụng, hay họ tự đi đến kết luận đúng, thì phần lớn tranh luận ủng hộ/phản đối Tailwind giờ có vẻ đã bớt liên quan, và đó là một điều rất tốt. Giờ có thể tập trung vào việc xây sản phẩm

    • Về mặt sử dụng thực tế thì tôi vẫn còn phê phán, nhưng thật đáng ngạc nhiên là Tailwind rất hợp với quy trình làm việc do AI tạo sinh
      Vì có thể biểu đạt mọi thứ một cách có hệ thống nên nó hoạt động rất tốt, và trong đó có một điều gì đó cực kỳ hữu ích
    • Tôi khó đồng ý rằng tranh luận ủng hộ/phản đối Tailwind không còn liên quan nữa; với tư cách designer/kỹ sư thiết kế, tôi thấy có hai vấn đề
      Thứ nhất, các kỹ sư JavaScript/Tailwind đã chiếm lĩnh các cuộc thảo luận về thiết kế. Họ tập trung vào “utility-first”, “loại bỏ code không dùng”, “CSS an toàn kiểu” hơn là hệ thống thiết kế, chẳng hạn trong typography nên dùng Perfect Fifth hay Perfect Fourth
      Thứ hai, Tailwind khiến việc tham gia vào quy trình sản xuất thực tế trở nên khó khăn. Các quyết định thiết kế bị chôn trong những biểu thức component React khó hiểu như flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)]
      Với kỹ sư JavaScript thì có thể hiểu được, nhưng với thiết kế có hệ thống thì đó là rào cản. Thay vì biểu đạt các quan hệ toán học chính xác bằng CSS, về cơ bản là dùng inline style tiện hơn
    • Tôi chỉ muốn có bảng màu của Tailwind CSS

  • CSS đã dễ dùng hơn trước rất nhiều, và hầu hết trình duyệt giờ cũng hoạt động nhất quán
    Nó đáng để học vì không cần bước build và không làm markup rối tung bằng quá nhiều code
    Cũng có thể viết trực tiếp thuộc tính style trong HTML, điều mà trước đây người ta tránh để tách biệt các mối quan tâm. Nhưng tôi thắc mắc tại sao lại muốn đưa một cách tương tự trở lại. Có phải chỉ để giảm vài ký tự không
    Thuộc tính style thậm chí còn trực quan hơn vì không cần phải chuyển đổi code trong đầu. Tôi không hiểu sức hấp dẫn của nó

    • Có khá nhiều thứ không thể làm bằng thuộc tính style. Ví dụ như pseudo-class :hover, :focus, pseudo-element ::before, ::after, media query, keyframe và animation
      Trải nghiệm lập trình viên trong dự án lớn cũng không tốt
      Ngược lại, @scope sắp trở thành tiêu chuẩn là một bổ sung tốt để đặt style gần nơi sử dụng: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • Tailwind ngày nay thường được dùng cùng với hệ thống trừu tượng hóa component, đóng vai trò như một tầng trừu tượng thay cho class CSS
      Trừu tượng hóa component giúp tách ý nghĩa và style mạnh hơn. Trong cả hai trường hợp đều phải tìm abstraction “hero”, nhưng trong thế giới component, không chỉ style mà cả tên thẻ HTML cũng được trừu tượng hóa
      Dù theo cách nào, “chi tiết style” cũng được tách khỏi “nội dung” là file source của trang. Có thể chấp nhận bước build để tách biệt mối quan tâm tốt hơn, tức tách nội dung và trình bày tốt hơn
    • Sức hấp dẫn nằm ở chỗ không cần đặt tên class CSS, dễ đọc vì nằm cạnh HTML, và cách đặt tên được chuẩn hóa nên dùng cùng một quy tắc ở mọi nơi
      Cũng giảm nhu cầu quản lý file riêng và xóa các component không dùng
      Có thể dùng media query, điều mà thẻ style không làm được, và không có nguy cơ sửa nhầm class đang được dùng ở nơi khác. Phạm vi toàn cục của CSS có ưu điểm nhưng cũng nguy hiểm
    • Đây là kết quả của việc coi sự gắn kết chặt với React là quá hiển nhiên
      Style được xem là thuộc về component chứ không phải hệ thống thiết kế. Hệ sinh thái kỹ thuật ưu tiên JavaScript cần thêm nhiều công ty dẫn dắt bởi thiết kế hiểu sức mạnh của CSS hiện đại và thiết kế có hệ thống
    • Nếu nhìn vào số lượng file phải xử lý trong dự án lớn, Tailwind trông khá hấp dẫn
      Cách .css thông thường tạo ra tên gọi kỳ lạ, trùng lặp và khả năng xung đột. css modules cũng là một lựa chọn, nhưng số file trên mỗi component/trang trên thực tế gần như tăng gấp đôi
      sass hay less có cảm giác như trộn lẫn các vấn đề của css modules và .css thông thường
      Tôi không thực chất thích hay ghét Tailwind; ban đầu tôi rất ghét nó, nhưng trong một dự án gồm component và trang với hơn 200 file, tôi thấy được giá trị của nó

  • Phản ứng đầu tiên với Tailwind là “phiền phức”. Tôi đã biết CSS rồi, giờ lại có cảm giác phải học lại CSS
    Trông giống tình huống phụ huynh cố giúp con làm bài tập toán, nhưng cách dạy ở trường đã hoàn toàn khác ngày xưa; cách giải của mình vẫn đúng nhưng không được chấp nhận, còn đứa trẻ thì bực bội vì phải khớp hai hệ thống với nhau
    Tôi hiểu bầu không khí kiểu “trong team nó chạy tốt và mở rộng tốt nên cứ dùng thôi”, và cũng đã trải nghiệm rồi
    Nhưng tôi vẫn thích stylesheet bình thường nhắm vào class hoặc tag hơn. Đặc biệt là giờ CSS đã hỗ trợ selector lồng nhau thì càng vậy
    Vấn đề quản lý stylesheet thì có, và tôi thích cách định nghĩa rồi áp dụng file CSS ở cấp route như Remix/React Router. Nếu như thế vẫn chưa đủ, hoặc style động trở nên quá phức tạp trong file .css, thì style={{...}} luôn là một lựa chọn
    CSS mạnh mẽ, linh hoạt và có thể mở rộng, nên Tailwind với tôi giống một sự giới hạn hơn là cải tiến. Tôi không rõ vì sao nó vẫn phổ biến, nhưng tôi nghĩ 3–4 năm nữa mọi người lại chuyển sang thứ khác

    • Ban đầu cảm giác phải học lại CSS rất khó chịu, và trước đây tôi cũng từng lập luận như vậy
      Nhưng khi đóng góp cho một dự án mã nguồn mở dùng Tailwind, tôi dần quen với nó, và giờ cảm nhận đã khác
      Về bản chất, Tailwind khá gần với một cách viết tắt của style={{…}}. Những thứ cần nhiều dòng trong file .css hoặc object style thì một utility có thể giải quyết trong khoảng 15 ký tự
      Thời gian tìm những thứ như “visual text replacement css”, tra cheat sheet CSS hay lục lại bài CSS-Tricks từ 8 năm trước giảm đi rất nhiều. Thay vào đó, tôi luôn xem tài liệu Tailwind và nhanh chóng tìm utility class làm đúng việc mình muốn
      Nhiều thứ đáng ngạc nhiên đã nằm trong “cache” trong đầu, và cảm giác tốt hơn nhiều so với việc cố ghi nhớ mọi CSS cần cho công việc layout
    • Tôi nghĩ là vì giờ toàn bộ component nằm trong một file
      Không cần đụng riêng đến CSS, style nằm ngay trên phần tử được áp dụng nên không cần đối chiếu qua lại
      Chỉ dùng thuộc tính css cũng làm được, nhưng vấn đề là ai cũng đã được dạy rằng đó là cách làm sai, và danh sách chuỗi chứa nhiều utility cũng dễ dùng hơn object CSS thuần
    • Giới hạn làm giảm độ phức tạp có thể có, và vì thế Tailwind thắng
      Nó là một lớp bọc module hóa, có thể tổ hợp và được chuẩn hóa đặt lên trên một hệ thống khổng lồ, phức tạp, nên đó là một bước tiến lớn
    • Tôi đang học toán cùng con, và nó không khác với những gì tôi đã học; tôi vẫn có thể giải nhanh
      Trong khi đó trên mạng xã hội có những bài trộn lẫn phép nhân và phép chia rồi bảo chỉ có một đáp án đúng. Tailwind không tệ đến mức đó, nhưng với góc nhìn của người già, nó có vẻ gần hướng đó hơn

  • Tôi thích Tailwind. Trong 4 năm qua tôi đã dùng nó ở 3 dự án, và nó trực quan, tài liệu tốt, đơn giản
    Tôi không nhớ thời emotion và styled-components, khi phải đặt tên cho mọi div có style trong dự án
    Trong Tailwind, container chỉ là div với vài class. Tranh luận đặt tên ít đi, bớt tốn chất xám và thời gian review cho việc đặt tên

    • Tôi thường thấy vấn đề phải nghĩ tên cho từng styled div, nhưng hơi thấy lạ
      Tôi gần như chưa từng phải nghĩ quá 1 giây để đặt tên cho thứ gì đó. Với một số người, đây thật sự là điểm bị kẹt sao? Tôi tò mò liệu họ có thực sự bị tê liệt ở chỗ đó không
    • Nếu gọi là “vài class” thì có vẻ bạn đang làm việc với một product owner rất tốt
      Những người tôi từng gặp thường chỉ định vô tận mọi chi tiết có thể. Họ đối xử với form web như dự án cải tạo HGTV cá nhân của mình
      Lần tôi thử dùng Tailwind, số class nhiều hơn markup ít nhất cả một bậc, và rất nhanh trở nên khó đọc
    • Tôi đã dùng thử trong nhiều dự án nhưng không thích. Ở dự án lớn, nó nhanh chóng bừa bộn và có cảm giác như Bootstrap mới
      Hiện tôi hài lòng với workflow CSS-in-JS. Đó là cách viết CSS kiểu cũ với sự trợ giúp của LLM. Cho LLM xem ảnh và yêu cầu component thì nó xuất ra ngay, kèm cả tên phù hợp
    • Nếu có thể chọn, đây là một trong những lý do chính khiến tôi tránh React
      Styling trong React không hay, và dù dùng Tailwind thì cũng chỉ là lựa chọn đỡ tệ hơn
      Nếu dùng framework frontend và bước build, tùy mục đích thì Svelte và Astro rất tốt. Có thể style bằng CSS bình thường, và nếu giữ component nhỏ thì hầu như không cần dùng tên class
      Chỉ cần dùng selector phần tử và để framework scope style tại thời điểm build

  • Tôi đã thử dùng Tailwind cho site của mình và khá thích, nhưng có thể vì lý do hơi khác những gì thường được nói
    Giá trị thật sự của Tailwind là có thể đọc mọi style ảnh hưởng đến một phần tử ở cùng một chỗ
    Tên class có thể dài, nhưng đọc một dòng dài vẫn nhanh hơn nhiều so với việc lần nào cũng mở devtools của trình duyệt hoặc nhảy lên xuống qua một hay nhiều stylesheet
    Khi quay lại đoạn code đó sau này, tôi có thể tự tin sửa mà không lo vô tình thay đổi phần tử khác
    Tính cascading của CSS vẫn hữu ích, nhưng thường thì tôi chỉ muốn giới hạn style cho một phần tử. Phần còn lại quay về CSS, nhưng CSS tôi thực sự viết rất ít. Phần lớn chỉ là muốn căn chỉnh khoảng cách

    • Tôi nghĩ chính điểm đó là lý do Tailwind tốt và tiện
      Tôi cũng thích việc “làm X thế nào?” không còn là một cuộc điều tra 30 phút, mà chỉ là tìm nhanh trong tài liệu
    • Công cụ hiển thị mọi style áp dụng lên phần tử cũng có trong IDE. Ví dụ “Show Applied Styles for Tag” của Intellij hoặc Chrome DevTools cũng hiển thị khá dễ đọc
      So với vậy, các đoạn Tailwind trong bài HN này trông khá đáng sợ
    • Tôi đồng ý ở một mức nào đó, nhưng vẫn còn cùng vấn đề
      Nếu thêm text-xl vào một div và bên trong có div cùng span lồng nhau, tất cả sẽ kế thừa text-xl; vì vậy để xem điều gì gây ra text-xl ở phần tử lồng nhau, cuối cùng vẫn phải lần ngược lên cây phần tử
      Dù vậy, nhìn chung thì vẫn dễ hơn một chút

  • Những cụm như “rút ngắn thời gian build”, “không còn chỉ thị @tailwind nữa”, “không cần cấu hình JavaScript”, “được thiết kế cho web hiện đại” nghe như thế này
    CSS giờ đã có thể tự làm hết những gì trước đây chúng ta làm thủ công, nhưng ta vẫn cứ giả vờ rằng mình còn cần thiết

    • Nếu đã ghét thì ít nhất cũng nên cố hiểu nó là gì và vì sao người ta dùng nó
    • Điểm bán hàng của Tailwind ngay từ đầu là “gần như CSS inline, nhưng đỡ phiền hơn thuộc tính style và dễ tối ưu hơn nhiều”
    • Tôi tự hỏi trước đây có thứ gì mà CSS thường không làm được nên mới cần Tailwind
      Tailwind chẳng phải gần như ánh xạ 1:1 với CSS sao?
    • Tôi không chắc có thật sự nên hiểu như vậy không
      Không thích Tailwind thì tôi hiểu, nhưng thay vì dựng người rơm để công kích, tốt hơn là nói rõ bạn không thích điểm nào của Tailwind
      Hạ thấp dự án mã nguồn mở của người khác và những người đang dùng nó hữu ích cũng không hay

  • Muốn hỏi những người hiểu rõ CSS. Tôi thì không rành
    Tôi đang nâng một dự án Phoenix cá nhân lên 1.7, và vì Phoenix giờ mặc định dùng Tailwind nên tôi định thử dùng thay Bootstrap
    Từ trước đến nay phiên bản Bootstrap trông “cũng ổn”, còn phiên bản Tailwind thì trông như một mớ hỗn độn
    Cách dễ nhất để có các giá trị mặc định trông ổn mà không cần cố làm designer là gì? Hay cứ cài lại Bootstrap cho xong?

    • Trường hợp đó thì tôi sẽ cài lại Bootstrap
      Tailwind cho bạn công cụ khi muốn kiểm soát thiết kế, nhưng cuối cùng bạn vẫn phải tự kiểm soát thiết kế
      Nếu chỉ cần trông đẹp và có cảm giác kiểu Bootstrap là được thì Bootstrap là đúng
      Về lý thuyết có các dự án tái triển khai Bootstrap trên Tailwind, có thể cho bạn điểm xuất phát kiểu Bootstrap cùng sức mạnh của Tailwind, nhưng thực tế tôi chưa thấy cái nào hoạt động tốt hơn việc cứ dùng Bootstrap
    • Với mục đích đó tôi dùng DaisyUI. Trang demo ví dụ ở đây: https://nwk-landing-kit.netlify.app
      Tài liệu DaisyUI ở đây: https://daisyui.com
    • Nếu đang tìm các component kiểu Bootstrap thì có thể thử bản miễn phí ở https://flowbite.com/
      Tailwind cũng có component trả phí, và chỉ cần sao chép rồi dán là dùng được. Khi quen rồi, điểm hay là bạn có thể chỉnh dần các component của Flowbite
    • Còn tùy ai trả tiền
      Nếu công việc ổn định và muốn vọc vạch đủ thứ thì cứ chơi với Tailwind. Những người hay chạy theo xu hướng và nói lớn tiếng nhìn chung có vẻ thích Tailwind
      Nhưng nếu là dự án của chính bạn, tự bỏ vốn, hoặc có deadline, thì tốt hơn là dùng Bootstrap bạn đã biết và tập trung hoàn thành việc, thay vì sa vào cuộc chiến tiêu hao với UI
    • Tailwind và Bootstrap giống so sánh táo với bánh táo hơn
      Tailwind cung cấp các class để bạn chồng lên nhau nhằm tạo component
      Nếu dùng kèm mã nguồn UI component thì sẽ dễ hơn. Trước đây tôi từng dùng TailwindUI nhưng nó trả phí, chắc cũng có lựa chọn miễn phí tốt

  • Trong cuộc trò chuyện “Tailwind hay không Tailwind” có một mô thức rất rõ. Nó lặp lại mỗi khi Tailwind được nhắc đến
    Có những người chưa từng dùng nghiêm túc quá 30 phút, chỉ thử qua loa hoặc lướt tài liệu. Họ ghét Tailwind và thích những thứ như “CSS thuần”
    Ngược lại có những người đã dùng trong dự án thực tế, trong đội ngũ có hơn một người. Họ hiểu giá trị, chấp nhận đánh đổi, và thích nó
    Tôi đã thấy nhiều người chuyển từ nhóm thứ nhất sang nhóm thứ hai, nhưng hầu như không thấy ai từ nhóm thứ hai quay lại nhóm thứ nhất
    Đó là lý do Tailwind thành công. Trong mắt người theo chủ nghĩa thuần túy nó có thể không đẹp, nhưng trong mắt người xây dựng sản phẩm và người thực dụng thì nó thật sự tuyệt vời

    • Tôi nghĩ mình không thật sự thuộc nhóm nào trong hai nhóm đó
      Tôi không phản đối Tailwind, nhưng lý do tôi chưa dùng là vì chưa thấy rõ tại sao nó là cách tiếp cận tốt hơn những lựa chọn khác như Web Components hay React Styled Components
      Vấn đề lớn nhất là Tailwind làm HTML rối lên với vô số utility class, khiến khó đọc và khó bảo trì
      Tôi hiểu nó tốt hơn một file CSS toàn cục khổng lồ và CSS cổ điển dựa trên tên thẻ, nhưng đã có cách dùng CSS được scope theo component mà không làm ô nhiễm namespace toàn cục. Web Components và Styled Components là ví dụ
      Cả hai đều gắn style trực tiếp với component, hoặc nói chung hơn là với một nhóm thẻ HTML cụ thể, nên dễ thấy style nào áp dụng ở đâu
      Cũng không cần tên class toàn cục, giảm lo về tác dụng phụ hay xung đột không mong muốn. Khi xóa component thì style liên quan cũng bị xóa theo, nên không phải lo CSS không dùng đến còn sót lại. Nhờ shadow DOM, cũng không có nguy cơ style của một component vô tình ảnh hưởng đến component khác
      Tôi coi trọng việc giữ HTML ngắn gọn và dễ đọc bằng cách không trộn trực tiếp style trình bày vào markup. Khi mọi style đều nằm trong thuộc tính class như Tailwind, một dòng sẽ có danh sách class dài, và nếu còn phải dùng cả tên class thật thì HTML trở nên lộn xộn
      Khó nắm bắt ngay style nào đang được áp dụng, và cũng khó thụt lề cho tử tế. Nó làm tôi nhớ đến nhiều lý do vì sao trước đây chúng ta rời bỏ thuộc tính style inline trong HTML
      Tôi không ghét Tailwind, nhưng về khả năng đọc, khả năng bảo trì và tách biệt mối quan tâm, tôi chưa thấy lợi thế rõ ràng so với Web Components hay Styled Components, và vẫn còn nhiều lo ngại chưa được giải đáp
      Tôi đã đọc tài liệu nhưng chưa dùng thử, và khó hiểu vì sao nên chọn Tailwind thay vì các lựa chọn khác. Việc có quá nhiều class ngay giữa HTML bình thường khiến với tôi cả hai đều khó đọc

  • Tôi thừa nhận có những người dùng Tailwind một cách hữu ích và làm việc rất hiệu quả, nhưng giờ Tailwind xuất hiện ở khắp nơi nên đâu đâu cũng thấy vẻ ngoài gọn gàng nhưng phổ biến

    • Đây là sự nhầm lẫn giữa Tailwind và TailwindUI/shadcn
      Nhìn chung, Tailwind không ảnh hưởng đến style nhiều hơn CSS thông thường. Có một vài ngoại lệ. Những thứ như shadow được chuẩn hóa hơn một chút, và bảng màu indigo gần đây cũng phần nào ảnh hưởng ra bên ngoài
    • Tailwind đưa ra các giá trị mặc định hợp lý, nhưng không ảnh hưởng lớn đến thiết kế
      Chỉ là mọi người có xu hướng thiết kế site theo một cách nhất định. Đặc biệt là khi dùng cùng ShadCn
    • Ngược lại, tôi thấy đây có vẻ là điều tốt. Các lựa chọn của Tailwind được thiết kế tốt và hoạt động hiệu quả
      Tôi nhìn nhận nó giống như việc Inter được dùng làm phông chữ website như một Helvetica mới. Nếu nhiều người dùng và trông đẹp thì có lý do gì để cố tránh dùng nó đâu
    • Trước đây tôi cũng từng nghe người ta nói như vậy về Bootstrap, nhưng các site Bootstrap tôi làm không hề giống nhau
      Từ rất lâu trước Tailwind, Bootstrap đã cung cấp nhiều utility class hơn hẳn, giúp tiết kiệm rất nhiều thời gian và không ép buộc một ngoại hình cụ thể
      Chỉ cần nạp những class mình muốn là được. Tất nhiên, nếu bạn không tải các file nguồn Sass xuống thì lại là chuyện khác, nhưng đó hẳn sẽ là một lựa chọn ngớ ngẩn
    • Suy nghĩ của tôi về vấn đề này là các UI framework tốt, tức là sự kết hợp giữa Tailwind và component, vẫn còn hiếm
      Vì vậy đa số dự án dùng một số rất ít framework. Nếu có thêm 4–5 dự án UI chất lượng cao nữa, đặc biệt là với hướng style khác biệt hơn, thì sự đa dạng sẽ tăng lên
      Thiết kế, cũng như nhiều công việc sáng tạo khác, dường như có một số lượng người ít đến đáng ngạc nhiên quyết định xu hướng
      Tôi mong nhiều người biết điều này hơn. Có lẽ có những người tài năng không làm vì nghĩ rằng “dù mình có làm thì cũng chẳng ai nghe”
      Nhưng nếu một phần trong số họ thử sức, tôi nghĩ họ có thể mở ra những UI mới cho một phần lớn của web

  • Tailwind là bằng chứng cho thấy ưu điểm của inline style, tức là cách style một thứ gì đó mà không cần đặt tên, tính phổ quát của chuỗi, và cả giới hạn của chuỗi
    Tôi mong chờ thứ sẽ đến tiếp theo, và cho đến lúc đó thì sẽ miễn cưỡng dùng Tailwind