Tailwind CSS v4.0 जारी

 (tailwindcss.com)
1 पॉइंट द्वारा GN⁺ 2025-01-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Tailwind CSS v4.0 एक ऐसा रिलीज़ है जिसमें framework को शुरू से फिर से लिखा गया है, जिससे build performance में बड़ा सुधार हुआ है और configuration व customization का flow CSS-केंद्रित हो गया है
  • Catalyst के आधार पर full build v3.4 के 378ms से v4.0 के 100ms तक 3.78x तेज़ हुआ, और बिना नए CSS वाले incremental build 35ms से 192µs तक 182x बेहतर हुए
  • इंस्टॉलेशन @import "tailwindcss" की एक लाइन और zero-configuration defaults के साथ सरल हो गया है, और Vite उपयोगकर्ता PostCSS की जगह @tailwindcss/vite इस्तेमाल कर सकते हैं
  • v4.0 में cascade layers, @property, color-mix(), logical properties जैसे modern CSS features का उपयोग किया गया है, और content auto-detection व built-in @import handling जोड़ी गई है
  • container queries, 3D transform, विस्तारित gradient API, @starting-style, not-*, field-sizing, color-scheme, inert आदि अब core features का हिस्सा हैं, जिससे अलग plugins पर निर्भरता घटती है

शुरू से फिर से लिखा गया high-performance engine

  • Tailwind CSS v4.0 framework का वह संस्करण है जिसे कई वर्षों के architecture अनुभव के आधार पर शुरू से फिर से लिखा गया है
  • अपने project benchmarks में full rebuild 3.5x से अधिक और incremental build 8x से अधिक तेज़ हुए हैं
  • Catalyst के आधार पर median build time इस प्रकार है
    • Full build: v3.4 378ms → v4.0 100ms, 3.78x सुधार
    • नए CSS के साथ incremental rebuild: 44ms → 5ms, 8.8x सुधार
    • बिना नए CSS के incremental rebuild: 35ms → 192µs, 182x सुधार
  • जिन incremental builds में नया CSS compile करने की ज़रूरत नहीं होती, वे 100x से अधिक तेज़ होकर microsecond स्तर पर पूरे होते हैं
    • किसी project पर लंबे समय तक काम करने पर flex, col-span-2, font-bold जैसी पहले से इस्तेमाल की गई classes दोबारा उपयोग होने की संभावना बढ़ती है, इसलिए ऐसे build अक्सर मिलते हैं

modern CSS platform का उपयोग

  • v4.0, Tailwind CSS v3.0 के बाद विकसित हुई web platform capabilities का सक्रिय रूप से उपयोग करता है
  • आधार बनने वाले मुख्य CSS features इस प्रकार हैं
    • Native cascade layers: अलग-अलग style rules के आपसी interaction को और बारीकी से नियंत्रित करते हैं
    • Registered custom properties: gradient animation को संभव बनाते हैं और बड़े pages पर performance में बड़ा सुधार करते हैं
    • color-mix(): CSS variables और currentColor सहित सभी color values की opacity समायोजित कर सकता है
    • Logical properties: RTL support को सरल बनाते हैं और generated CSS का आकार घटाते हैं
  • ये features Tailwind के internal implementation को भी सरल बनाते हैं, जिससे bugs की surface area कम होती है और maintenance आसान होता है

इंस्टॉलेशन और build integration का सरलीकरण

  • इंस्टॉलेशन flow को steps और boilerplate कम करने के हिसाब से व्यवस्थित किया गया है
    • npm i tailwindcss @tailwindcss/postcss
    • PostCSS plugin में @tailwindcss/postcss जोड़ें
    • CSS file में @import "tailwindcss" इस्तेमाल करें
  • v4.0 में @tailwind directive की जगह Tailwind को CSS की एक लाइन से import करके इस्तेमाल किया जा सकता है
  • यह template file paths सहित किसी भी configuration के बिना शुरू करने वाला zero-configuration flow देता है
  • अलग external plugin के बिना @import rules को bundle किया जाता है, और vendor prefixing व modern syntax transforms के लिए अंदरूनी रूप से Lightning CSS का उपयोग होता है
  • Vite उपयोगकर्ता PostCSS की जगह @tailwindcss/vite चुन सकते हैं
    • Tailwind CSS v4.0 PostCSS plugin के रूप में भी तेज़ है, लेकिन Vite plugin के साथ और बेहतर performance मिल सकती है

content auto-detection और built-in import

  • v3 में ज़रूरी content array configuration को v4.0 की auto-detection heuristics ने replace कर दिया है
  • .gitignore में मौजूद items अपने-आप ignore हो जाते हैं, इसलिए dependencies या version control में न होने वाली generated files scan नहीं होतीं
    • उदाहरण: /node_modules, /coverage, /.next, /build
  • images, videos, .zip जैसी binary extensions भी अपने-आप ignore हो जाती हैं
  • जब default रूप से exclude होने वाले source को स्पष्ट रूप से जोड़ना हो, तब CSS file के भीतर @source directive इस्तेमाल किया जा सकता है
    • @source "../node_modules/@my-company/ui-lib";
    • @source भी वही heuristics इस्तेमाल करता है, इसलिए binary file types बिना अलग extension बताए ही exclude हो जाते हैं
  • v4.0 से पहले दूसरे CSS files को @import से inline करने के लिए postcss-import जैसे अलग plugin की ज़रूरत होती थी, लेकिन अब built-in import support के कारण किसी दूसरे tool की ज़रूरत नहीं है
    • import system Tailwind CSS के लिए खास तौर पर बनाया गया है और engine के साथ काफ़ी tightly integrated है, इसलिए यह और तेज़ काम करता है

CSS-first configuration और theme variables

  • v4.0 के बड़े बदलावों में से एक यह है कि project configuration अब JavaScript के बजाय सीधे CSS में की जाती है
  • tailwind.config.js file की जगह Tailwind import करने वाली CSS file में @theme का उपयोग करके customization किया जा सकता है
    • design tokens configure करना
    • custom utilities define करना
    • custom variants define करना
  • @theme में define किए गए design tokens default रूप से CSS variables के रूप में expose होते हैं
    • उदाहरण: --font-display, --breakpoint-3xl, --color-avocado-500, --ease-fluid
  • इन generated CSS variables को runtime में सामान्य CSS की तरह refer किया जा सकता है
    • inline styles का reuse
    • animation के लिए Motion जैसी libraries को pass करना

dynamic utility values और variants

  • v4.0 कई utilities और variants को इस तरह सरल बनाता है कि वे बिना configuration के specific arbitrary values स्वीकार कर सकें
  • grid में बिना अलग configuration के मनचाहा size इस्तेमाल किया जा सकता है
    • उदाहरण: grid grid-cols-15
  • custom boolean data attributes को भी पहले से define किए बिना target किया जा सकता है
    • उदाहरण: data-current:opacity-100
  • px-*, mt-*, w-*, h-* जैसी spacing utilities एक single spacing scale variable से dynamically derive होती हैं
    • उदाहरण: --spacing: 0.25rem
    • w-17 calc(var(--spacing) * 17) के रूप में generate होता है
  • v4.0 के साथ आए upgrade tool को जब अनावश्यक arbitrary value syntax मिलती है, तो वह ज़्यादातर मामलों में उसे अपने-आप सरल कर देता है

color palette और container queries

  • default color palette को पूरी तरह rgb से oklch में upgrade किया गया है
    • इससे sRGB color space की सीमाओं से आगे बढ़कर wider gamut का उपयोग होता है और colors अधिक vivid दिखते हैं
    • v3 के साथ colors के संतुलन को बनाए रखने की कोशिश की गई है, इसलिए मौजूदा projects को upgrade करते समय इसे breaking change जैसा महसूस नहीं होना चाहिए
  • container query support अब v4.0 में core का हिस्सा है, इसलिए @tailwindcss/container-queries plugin की ज़रूरत नहीं रहती
  • नया @max-* variant max-width container queries के लिए इस्तेमाल किया जा सकता है
  • सामान्य breakpoint variants की तरह @min-* और @max-* को stack करके container query range define की जा सकती है

3D transform और gradient API का विस्तार

  • v4.0 में 3D transform के लिए API जोड़ी गई है
    • rotate-x-*
    • rotate-y-*
    • scale-z-*
    • translate-z-*
  • gradient features को भी विस्तारित किया गया है ताकि custom CSS के बिना अधिक विविध effects बनाए जा सकें
  • linear gradient अब angle को value के रूप में ले सकता है
    • उदाहरण: bg-linear-45
    • पहले का bg-gradient-* अब bg-linear-* नाम से है
  • gradient color interpolation mode को modifier से नियंत्रित किया जा सकता है
    • bg-linear-to-r/srgb
    • bg-linear-to-r/oklch
    • v4.0 में default interpolation OKLAB है, और दूसरे color space modifiers भी इस्तेमाल किए जा सकते हैं
  • नई bg-conic-*, bg-radial-* utilities से conic और radial gradients बनाए जा सकते हैं
    • ये मौजूदा from-*, via-*, to-* के साथ काम करती हैं
    • इनमें color interpolation settings modifiers और gradient position जैसे detailed control के लिए arbitrary values support भी शामिल है

नए variants और utilities

  • नया starting variant CSS @starting-style को support करता है
    • element पहली बार दिखाई देने पर property transition बनाई जा सकती है
    • page पर दिखाई देने वाले elements को बिना JavaScript animate किया जा सकता है
    • browser support अभी हर टीम के लिए पर्याप्त न हो, लेकिन यह काफ़ी नज़दीक है
  • नया not-* variant CSS :not() pseudo-class को support करता है
    • उदाहरण: not-hover:opacity-75
    • media query और @supports query को भी negate किया जा सकता है
  • v4.0 में ये utilities और variants भी जोड़े गए हैं
    • inset-shadow-*, inset-ring-*: एक single element पर अधिकतम 4 box shadow layers stack की जा सकती हैं
    • field-sizing: बिना JavaScript textarea auto-resize support करता है
    • color-scheme: dark mode में हल्के scrollbar हटाए जा सकते हैं
    • font-stretch: विभिन्न widths को support करने वाले variable fonts को adjust करता है
    • inert: inert attribute वाले non-interactive elements को style करता है
    • nth-*: nth series styling को support करता है
    • in-*: group class के बिना group-* जैसा काम करता है
    • :popover-open: मौजूदा open variant के साथ खुले popover को भी target करता है
    • descendant variant: सभी child elements को style करता है

शुरुआत और upgrade path

  • नए projects में installation docs का पालन करके Tailwind CSS v4.0 इस्तेमाल किया जा सकता है
  • browser में सीधे प्रयोग करने के लिए Tailwind Play का उपयोग किया जा सकता है
  • मौजूदा projects के लिए upgrade guide और automatic upgrade tool उपलब्ध हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-24
Hacker News की राय

  • एक समय Tailwind की कई कमियों और सच में आधुनिक “pure” web तरीकों के साथ इसकी असंगति की कड़ी आलोचना की थी, लेकिन v4 की बड़ी प्रगति देखकर बहुत खुशी है
    Tailwind theme को native CSS variables के रूप में access कर पाना, और docs में external stylesheet में native variables से लिखे button component का उदाहरण तक होना, बहुत बड़ा बदलाव है
    सिर्फ CSS से configuration कर पाना भी शानदार है, और अब Tailwind ऐसा JavaScript-स्टाइल “viral” framework नहीं लगता जो समझदार architecture को निगल जाता है, बल्कि ऐसी utility लगता है जिसे किसी भी project में जोड़ा जा सकता है
    पिछले कुछ सालों की आलोचना का असर हुआ हो या वे खुद अच्छे निष्कर्ष पर पहुंचे हों, Tailwind के पक्ष-विपक्ष की बहसों का बड़ा हिस्सा अब कम प्रासंगिक दिखता है, और यह बहुत अच्छी बात है। अब product बनाने पर ध्यान दे सकते हैं

    • असल इस्तेमाल के लिहाज़ से मैं अब भी आलोचनात्मक हूं, लेकिन Tailwind का AI-generated workflow के साथ अच्छी तरह फिट होना चौंकाने वाला है
      किसी भी चीज़ को व्यवस्थित ढंग से व्यक्त किया जा सकता है, इसलिए यह सच में अच्छी तरह काम करता है, और इसमें बेहद उपयोगी कुछ है
    • इस बात से सहमत होना मुश्किल है कि Tailwind के पक्ष-विपक्ष की बहस अब relevant नहीं रही, और designer/design engineer के तौर पर दो समस्याएं हैं
      पहली, JavaScript/Tailwind engineers ने design discussions पर कब्ज़ा कर लिया है। “utility-first”, “unused code हटाना”, “type-safe CSS” के बजाय design system पर ज़्यादा ध्यान होता है, जैसे typography में Perfect Fifth इस्तेमाल करें या Perfect Fourth
      दूसरी, Tailwind असली production process में भाग लेना मुश्किल बना देता है। Design decisions flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)] जैसे मुश्किल React component expressions के अंदर दब जाते हैं
      JavaScript engineer के लिए यह समझ में आ सकता है, लेकिन systematic design के लिए यह बाधा बनता है। CSS में सटीक mathematical relationships व्यक्त करने के बजाय, यह ज़्यादा सुविधाजनक inline styles इस्तेमाल करने जैसा है
    • मुझे Tailwind CSS का सिर्फ color palette चाहिए

  • CSS अब पहले की तुलना में बहुत आसान हो गया है, और ज़्यादातर browsers भी अब consistently behave करते हैं
    build step की जरूरत नहीं, और markup को excessive code से clutter नहीं करता, इसलिए इसे सीखना worth it है
    HTML में सीधे style attribute भी लिख सकते हैं, जिसे पहले separation of concerns के लिए avoid किया जाता था। लेकिन समझ नहीं आता कि वैसा ही तरीका फिर से क्यों लाना चाहते हैं। लगता है बस कुछ characters कम करने के लिए है
    style attribute तो दिमाग में code को translate करने की जरूरत भी नहीं पड़ती, इसलिए उल्टे ज़्यादा intuitive लगता है। इसकी appeal ठीक से समझ नहीं आती

    • style attribute से काफी चीज़ें नहीं हो सकतीं। उदाहरण के लिए pseudo-classes :hover, :focus, pseudo-elements ::before, ::after, media queries, keyframes और animations
      बड़े projects में developer experience भी अच्छा नहीं होता
      वहीं जल्द standard बनने वाला @scope, styles को पास में रखने के लिए अच्छा addition है: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • आजकल Tailwind अक्सर ऐसे component abstraction system के साथ इस्तेमाल होता है जो CSS classes के बजाय abstraction layer की तरह काम करता है
      Component abstraction meaning और style को ज़्यादा मजबूती से अलग करता है। दोनों cases में “hero” abstraction ढूंढना पड़ता है, लेकिन component world में style के साथ-साथ HTML tag name तक abstract हो जाता है
      किसी भी तरह, “style details” page source file यानी “content” से अलग रहते हैं। separation of concerns, यानी content और presentation के बेहतर separation के लिए build step स्वीकार किया जा सकता है
    • इसकी appeal यह है कि CSS class names रखने की जरूरत नहीं होती, HTML के साथ-साथ होने से पढ़ना आसान होता है, और naming का तरीका standardized है इसलिए हर जगह वही rules चलते हैं
      अलग file manage करने और unused components हटाने की जरूरत भी कम हो जाती है
      style tag से जो media queries नहीं हो पाती थीं, वे इस्तेमाल कर सकते हैं, और कहीं और इस्तेमाल हो रही classes को गलती से बदल देने का risk भी नहीं होता। CSS का global scope फायदा भी है, लेकिन जोखिम भरा है
    • यह React के साथ मजबूत coupling को बहुत स्वाभाविक मान लेने का नतीजा है
      माना जाता है कि styles design system के नहीं, components के होते हैं। JavaScript-first engineering ecosystem को ऐसी और design-led companies चाहिए जो modern CSS और systematic design की ताकत समझती हों
    • बड़े projects में संभालनी पड़ने वाली files की संख्या देखें तो Tailwind काफी आकर्षक लगता है
      सामान्य .css approach में अजीब names, duplication और collisions की संभावना बनती है। css modules भी एक विकल्प है, लेकिन प्रति component/page files की संख्या व्यावहारिक रूप से दोगुनी हो जाती है
      sass या less, css modules और सामान्य .css की समस्याओं को एक साथ मिला देने जैसा लगता है
      Tailwind को मूल रूप से न तो पसंद करता हूं न नापसंद; शुरुआत में बहुत नापसंद था, लेकिन components और pages से बने 200 से अधिक files वाले project में इसकी value महसूस होती है

  • Tailwind पर मेरी पहली प्रतिक्रिया “झंझट है” थी। CSS मुझे पहले से आती है, लेकिन अब ऐसा लगा जैसे CSS फिर से सीखनी पड़ेगी
    यह वैसा ही लगता है जैसे कोई पैरेंट बच्चे के गणित के होमवर्क में मदद करने की कोशिश करे, लेकिन स्कूल में सिखाया जाने वाला तरीका पुराने तरीके से पूरी तरह अलग हो गया हो; आपका हल अभी भी सही है, पर स्वीकार नहीं किया जाता, और बच्चा दो सिस्टम मिलाने में चिढ़ जाता है
    मैं समझता हूं कि टीम में यह अच्छी तरह काम करता है और scale भी अच्छे से होता है, इसलिए बस इसे इस्तेमाल करना चाहिए—यह माहौल मैंने भी अनुभव किया है
    फिर भी मुझे अब भी classes या tags को target करने वाली साधारण stylesheet ज्यादा पसंद है। खासकर अब जब CSS nested selectors support करता है, तो और भी
    Stylesheet management की समस्या है, और Remix/React Router की तरह route level पर CSS files define और apply करने का तरीका मुझे पसंद है। अगर वह काफी न हो, या dynamic styles .css file में बहुत जटिल हो जाएं, तो style={{...}} भी हमेशा एक विकल्प है
    CSS शक्तिशाली, flexible और scalable है, इसलिए Tailwind सुधार नहीं बल्कि restriction जैसा लगता है। यह लगातार लोकप्रिय क्यों है, यह मुझे ठीक से समझ नहीं आता, लेकिन मुझे लगता है 3–4 साल बाद सब किसी और चीज़ पर चले गए होंगे

    • शुरुआत में CSS फिर से सीखने जैसा महसूस होना परेशान करने वाला था, और पहले मैं भी यही तर्क देता था
      लेकिन Tailwind इस्तेमाल करने वाले open source project में contribute करते-करते इसकी आदत हो गई, और अब मेरी राय अलग है
      Tailwind मूल रूप से style={{…}} की shorthand जैसा है। जिस चीज़ के लिए .css file या style object में कई lines लगतीं, वह एक utility में करीब 15 characters में खत्म हो जाती है
      “visual text replacement css” जैसी चीज़ें search करने या CSS cheatsheet और 8 साल पुराने CSS-Tricks article खंगालने में लगने वाला समय काफी कम हो गया। इसके बजाय मैं हमेशा Tailwind docs देखता हूं और जो काम चाहिए उसके लिए utility class जल्दी ढूंढ लेता हूं
      हैरानी की बात है कि इसका बहुत बड़ा हिस्सा दिमाग के cache में आ जाता है, और layout काम के लिए जरूरी सारी CSS याद करने की कोशिश से यह कहीं बेहतर लगता है
    • मुझे लगता है कारण यह है कि अब पूरा component एक ही file में आ जाता है
      अलग से CSS छूने की जरूरत नहीं होती, और style उसी element के ठीक ऊपर होता है जिस पर वह लागू हो रहा है, इसलिए दोनों को compare करने की जरूरत नहीं पड़ती
      css property से भी यह संभव है, लेकिन समस्या यह है कि सबको सिखाया गया है कि वह गलत तरीका है, और कई utilities वाली string list इस्तेमाल करना pure CSS object से आसान भी है
    • Restrictions संभावित complexity घटाते हैं, और इसी वजह से Tailwind जीतता है
      यह एक विशाल और जटिल system के ऊपर रखा गया composable और standardized modular wrapper है, इसलिए यह बड़ी प्रगति है
    • मैं अपने बच्चे के साथ गणित सीख रहा हूं, और यह मेरे सीखे हुए से अलग नहीं है; मैं अब भी जल्दी solve कर सकता हूं
      दूसरी ओर social media पर ऐसे posts हैं जो multiplication और division को मिला देते हैं और कहते हैं कि सही जवाब सिर्फ एक है। Tailwind उतना बुरा नहीं है, लेकिन बूढ़े व्यक्ति के नजरिए से यह उसी दिशा के ज्यादा करीब दिखता है

  • मुझे Tailwind पसंद है। पिछले 4 सालों में 3 projects में इस्तेमाल किया है, और यह intuitive, अच्छी documentation वाला और simple लगा
    मुझे emotion और styled-components वाले वे दिन याद नहीं आते जब project के हर styled div को नाम देना पड़ता था
    Tailwind में container बस एक div और कुछ classes होता है। Naming debates घटती हैं, और नाम रखने में लगने वाली दिमागी ऊर्जा और review time कम होता है

    • हर styled div के लिए नाम सोचने की समस्या बार-बार दिखती है, लेकिन यह मुझे थोड़ा अजीब लगता है
      किसी चीज़ का नाम रखने में मैंने शायद ही कभी 1 second से ज्यादा सोचा हो। क्या सच में कुछ लोगों के लिए यही bottleneck बनता है? सचमुच जानना चाहता हूं कि क्या वे वहीं पर इतने अटक जाते हैं
    • अगर “कुछ classes” कह रहे हैं, तो लगता है आप किसी बहुत अच्छे product owner के साथ काम करते हैं
      जिन लोगों को मैंने देखा है, वे हर संभव detail अंतहीन रूप से specify करते रहते थे। web form को अपने personal HGTV renovation की तरह treat करते हैं
      जब मैंने Tailwind एक बार इस्तेमाल किया, तो classes markup से एक digit order ज्यादा हो गईं, और वह जल्दी ही पढ़ने में मुश्किल हो गया
    • कई projects में इस्तेमाल किया, लेकिन पसंद नहीं आया। बड़े projects में यह जल्दी messy हो जाता है, और नए Bootstrap जैसा लगता है
      अभी मैं CSS-in-JS workflow से संतुष्ट हूं। यह LLM की मदद से पुराने तरीके वाली CSS लिखने जैसा है। LLM को image दिखाकर component मांगें, तो proper names के साथ तुरंत मिल जाता है
    • अगर मेरे पास choice हो, तो React से बचने का यह एक मुख्य कारण है
      React में styling अच्छी नहीं है, और Tailwind इस्तेमाल करें तो भी वह बस थोड़ा कम खराब विकल्प है
      अगर frontend framework और build step इस्तेमाल कर रहे हैं, तो use case के हिसाब से Svelte और Astro अच्छे हैं। साधारण CSS से styling कर सकते हैं, और components छोटे रखें तो class names लगभग इस्तेमाल करने की जरूरत नहीं पड़ती
      Element selectors इस्तेमाल करें और framework को build time पर styles scope करने दें

  • मैंने अपनी site पर Tailwind इस्तेमाल किया और मुझे काफी पसंद आया, हालांकि शायद आमतौर पर बताए जाने वाले कारणों से थोड़ा अलग
    Tailwind की असली value यह है कि किसी element को प्रभावित करने वाले सभी styles एक जगह पढ़े जा सकते हैं
    Class names लंबे हो सकते हैं, लेकिन हर बार browser developer tools खोलने या एक से ज्यादा stylesheets में ऊपर-नीचे जाने के मुकाबले एक लंबी line पढ़ना कहीं तेज है
    बाद में उस code पर लौटने पर भी आप यह चिंता किए बिना confident होकर बदलाव कर सकते हैं कि कहीं किसी दूसरे element को बदल न दें
    CSS का cascading स्वभाव अब भी useful है, लेकिन आमतौर पर मैं style को सिर्फ एक element तक सीमित रखना चाहता हूं। बाकी के लिए CSS पर लौटता हूं, लेकिन असल में लिखी जाने वाली CSS बहुत कम होती है। अक्सर बस spacing ठीक करनी होती है

    • मुझे लगता है यही बात Tailwind को अच्छा और सुविधाजनक बनाती है
      “X कैसे करूं?” का जवाब 30 मिनट की research task नहीं, बल्कि quick docs search में मिल जाता है—यह भी अच्छा लगता है
    • किसी element पर apply हुए सभी styles दिखाने वाले tools IDE में भी हैं। उदाहरण के लिए Intellij का “Show Applied Styles for Tag” या Chrome developer tools भी इसे readable तरीके से दिखाते हैं
      उसके मुकाबले इस HN post में दिखे Tailwind snippets काफी डरावने लगते हैं
    • कुछ हद तक सहमत हूं, लेकिन वही समस्या बची रहती है
      अगर div में text-xl जोड़ते हैं और उसके अंदर nested div और span हैं, तो वे सभी text-xl inherit करेंगे, इसलिए nested elements में यह देखने के लिए कि text-xl किससे आ रहा है, आखिरकार element hierarchy में ऊपर जाना ही पड़ेगा
      फिर भी कुल मिलाकर यह थोड़ा आसान जरूर है

  • “build time में कमी”, “अब @tailwind directives नहीं”, “JavaScript configuration नहीं”, “modern web के लिए designed” जैसे वाक्य ऐसे सुनाई देते हैं
    CSS अब वह सब कर सकता है जो हम खुद करते थे, फिर भी चलो यह दिखावा जारी रखें कि हमारी अभी भी जरूरत है

    • अगर नापसंद करना है, तो कम-से-कम यह समझने की कोशिश तो करनी चाहिए कि यह है क्या और लोग इसे क्यों इस्तेमाल करते हैं
    • Tailwind का selling point शुरुआत से यही था: “लगभग inline CSS, लेकिन style attribute से कम झंझट वाला और optimize करना कहीं आसान”
    • मुझे जानना है कि पहले ऐसा क्या था जो plain CSS से नहीं हो पाता था और जिसके लिए Tailwind की जरूरत पड़ती थी
      Tailwind तो लगभग CSS से 1:1 mapping जैसा ही नहीं है?
    • सच में इसे ऐसे ही समझा गया था क्या, ऐसा लगता है
      Tailwind पसंद न होना समझ में आता है, लेकिन strawman बनाकर हमला करने के बजाय यह कहना बेहतर होगा कि Tailwind की कौन-सी बात पसंद नहीं है
      दूसरे लोगों के open source project और उसे उपयोगी मानकर इस्तेमाल करने वालों को नीचा दिखाना भी अच्छा नहीं है

  • CSS अच्छी तरह जानने वालों से पूछना चाहता हूँ। मुझे ज्यादा नहीं पता
    मैं अपना personal Phoenix project 1.7 पर upgrade कर रहा हूँ, और Phoenix अब default रूप से Tailwind इस्तेमाल करता है, इसलिए Bootstrap की जगह इसे आजमाने की सोची
    अभी तक Bootstrap version “ठीक-ठाक” दिखता था, लेकिन Tailwind version बिखरा हुआ लग रहा है
    designer बने बिना अच्छे दिखने वाले defaults पाने का सबसे आसान तरीका क्या है? या फिर बस Bootstrap दोबारा install करके बात खत्म कर दूँ?

    • उस case में मैं Bootstrap दोबारा install करूँगा
      Tailwind आपको design control करना हो तो tools देता है, लेकिन आखिर में design को खुद control करना पड़ता है
      अगर बस अच्छा दिखना और Bootstrap जैसा feel भी ठीक है, तो Bootstrap ही सही है
      theory में Tailwind के ऊपर Bootstrap को reimplement करने वाले projects हैं, जो Bootstrap जैसा starting point और Tailwind की ताकत दोनों दे सकते हैं, लेकिन practical में मैंने ऐसा कुछ नहीं देखा जो सीधे Bootstrap इस्तेमाल करने से बेहतर काम करता हो
    • उस purpose के लिए मैं DaisyUI इस्तेमाल करता हूँ। example demo site यहाँ है: https://nwk-landing-kit.netlify.app
      DaisyUI docs यहाँ हैं: https://daisyui.com
    • अगर Bootstrap जैसे components ढूँढ रहे हैं, तो free में https://flowbite.com/ आजमाने लायक है
      Tailwind में paid components भी हैं, जिन्हें बस copy-paste करना होता है। इसकी अच्छी बात यह है कि familiar होने पर आप Flowbite components को धीरे-धीरे tweak कर सकते हैं
    • यह इस पर depend करता है कि पैसे कौन दे रहा है
      अगर job stability है और अलग-अलग चीज़ें छेड़ना चाहते हैं, तो Tailwind से खेल सकते हैं। trend-sensitive और loud लोग आम तौर पर Tailwind पसंद करते दिखते हैं
      लेकिन अगर यह अपना project है, खुद की funding है, या deadline है, तो जिसे पहले से जानते हैं उस Bootstrap को इस्तेमाल करना और UI पर थकाऊ लड़ाई लड़ने के बजाय काम पूरा करने पर focus करना बेहतर है
    • Tailwind और Bootstrap की तुलना apples और apple pie जैसी है
      Tailwind वे classes देता है जिन्हें जोड़कर components बनाने होते हैं
      UI component source साथ में इस्तेमाल करें तो आसान होगा। मैंने पहले TailwindUI इस्तेमाल किया था, लेकिन वह paid था; अच्छे free alternatives भी होंगे

  • “Tailwind या नहीं” वाली बातचीत में एक साफ pattern है। Tailwind का जिक्र होते ही यह दोहराता है
    कुछ लोग ऐसे हैं जिन्होंने इसे 30 मिनट से ज्यादा ढंग से इस्तेमाल नहीं किया, बस थोड़ी देर try किया या docs सरसरी तौर पर देखे। ये लोग Tailwind को नापसंद करते हैं और “pure CSS” जैसी चीज़ों को prefer करते हैं
    दूसरी तरफ वे लोग हैं जिन्होंने इसे real projects में, एक से ज्यादा लोगों वाली teams में इस्तेमाल किया है। ये लोग value समझते हैं, trade-offs accept करते हैं, और इसे पसंद करते हैं
    मैंने कई लोगों को पहले group से दूसरे group में जाते देखा है, लेकिन दूसरे से पहले में लौटते हुए बहुत कम देखा है
    इसलिए Tailwind सफल हुआ है। purists की नजर में यह सुंदर न लगे, लेकिन builders और pragmatists की नजर में यह वाकई शानदार है

    • मुझे लगता है कि मैं उन दोनों groups में ठीक से fit नहीं होता
      मैं Tailwind के खिलाफ नहीं हूँ, लेकिन अभी तक इसे न आजमाने की वजह यह है कि Web Components या React Styled Components जैसे दूसरे options की तुलना में यह बेहतर approach क्यों है, यह साफ नहीं दिखता
      सबसे बड़ी समस्या यह है कि Tailwind HTML को ढेर सारी utility classes से भरकर पढ़ने और maintain करने में मुश्किल बना देता है
      मैं समझता हूँ कि यह बड़े global CSS file और classic tag-name-based CSS से बेहतर है, लेकिन component-scoped CSS को global namespace दूषित किए बिना इस्तेमाल करने के तरीके पहले से मौजूद हैं। Web Components और Styled Components इसके उदाहरण हैं
      दोनों styles को सीधे component, या और सामान्य रूप से कहें तो specific HTML tag groups से बाँध देते हैं, इसलिए कौन-सा style कहाँ लागू हो रहा है यह देखना आसान होता है
      global class names की जरूरत नहीं होती, और unwanted side effects या conflicts की चिंता भी कम होती है। component हटाएँ तो related styles भी साथ हट जाते हैं, इसलिए unused CSS बचा रह जाने की चिंता नहीं रहती। shadow DOM की वजह से एक component के styles का दूसरे component पर अनजाने में असर पड़ने का risk भी नहीं रहता
      मैं presentation styles को markup में सीधे मिलाए बिना HTML को छोटा और readable बनाए रखने को important मानता हूँ। Tailwind की तरह जब सारे styles class attribute में चले जाते हैं, तो एक line में classes की लंबी list बन जाती है, और अगर actual class names भी साथ लिखने हों तो HTML messy हो जाता है
      कौन-से styles apply हो रहे हैं, यह एक नजर में समझना मुश्किल होता है, और ठीक से indentation करना भी कठिन। यह मुझे HTML के inline style attribute से दूर जाने की पुरानी कई वजहें याद दिलाता है
      मैं Tailwind से नफरत नहीं करता, लेकिन readability, maintainability और separation of concerns के लिहाज से Web Components या Styled Components की तुलना में इसका स्पष्ट advantage नहीं दिखता, और मेरी unresolved concerns काफी बड़ी हैं
      docs पढ़े हैं लेकिन इस्तेमाल नहीं किया, और यह समझना मुश्किल है कि दूसरे options के बजाय Tailwind क्यों चुनूँ। plain HTML के बीच बहुत ज्यादा classes होना मेरे लिए दोनों को पढ़ना मुश्किल बना देता है

  • यह मानता हूँ कि कुछ लोग Tailwind को उपयोगी तरीके से इस्तेमाल करते हैं और productive हैं, लेकिन अब Tailwind हर जगह है, इसलिए साफ-सुथरा लेकिन आम-सा look जगह-जगह दिखता है

    • यह Tailwind को TailwindUI/shadcn वगैरह से गड़बड़ाने जैसा है
      आम तौर पर Tailwind, सामान्य CSS की तुलना में style पर ज़्यादा बड़ा असर नहीं डालता। कुछ exceptions हैं। shadows जैसी चीज़ें थोड़ी ज़्यादा standardized हैं, और indigo color palette ने हाल में बाहर भी कुछ असर डाला है
    • Tailwind समझदारी वाले defaults देता है, लेकिन design पर बड़ा असर नहीं डालता
      बस लोग sites को किसी खास तरीके से design करने की ओर झुकते हैं। खासकर ShadCn के साथ इस्तेमाल करते समय ऐसा होता है
    • बल्कि यह अच्छी बात जैसी लगती है। Tailwind के options अच्छे से design किए गए हैं और ठीक काम करते हैं
      इसे कुछ वैसा ही देखता हूँ जैसे websites के font के तौर पर Inter नए Helvetica की तरह इस्तेमाल हो रहा है। अगर बहुत लोग इस्तेमाल कर रहे हैं और यह अच्छा दिखता है, तो इसे न इस्तेमाल करने की कोई खास वजह नहीं लगती
    • पहले Bootstrap को लेकर भी ऐसी बातें सुनी थीं, लेकिन मैंने जो Bootstrap sites बनाई थीं वे एक-दूसरे जैसी नहीं दिखती थीं
      Bootstrap, Tailwind से बहुत पहले से कई utility classes देता था, जिससे काफी समय बचता था, और वह कोई खास look थोपता नहीं था
      बस अपनी ज़रूरत की classes import करनी होती थीं। हाँ, अगर आपने Sass source files download नहीं की थीं तो बात अलग है, लेकिन वह मूर्खतापूर्ण विकल्प होता
    • इस समस्या पर मेरी राय यह है कि अच्छे UI frameworks, यानी Tailwind और components का combination, अभी भी दुर्लभ है
      इसलिए ज़्यादातर projects बहुत कम frameworks का इस्तेमाल करते हैं। अगर 4–5 और high-quality UI projects आएँ, खासकर जिनकी style direction ज़्यादा अलग हो, तो diversity बढ़ेगी
      design भी कई creative कामों की तरह है, जहाँ हैरानी की बात है कि बहुत कम लोग trend तय करते हैं
      काश ज़्यादा लोगों को यह पता होता। लगता है कि कुछ talented लोग “मैं बनाऊँ भी तो कोई सुनेगा नहीं” सोचकर बनाते ही नहीं होंगे
      लेकिन अगर उनमें से कुछ लोग कोशिश करें, तो वे web के बड़े हिस्से के लिए नई UI possibilities खोल सकते हैं

  • Tailwind inline styles के फायदे दिखाने वाला प्रमाण है: यानी किसी चीज़ को नाम दिए बिना style करने का तरीका, strings की सार्वभौमिकता, और strings की सीमाएँ
    आगे क्या आएगा, इसका इंतज़ार है, और तब तक अनिच्छा से Tailwind इस्तेमाल करूँगा