എല്ലാവരും Tailwind CSS v4-നെ ചൊല്ലി തർക്കിക്കുന്ന യഥാർത്ഥ കാരണം
Tailwind CSS v4 സംബന്ധിച്ച തർക്കങ്ങൾ എല്ലായിടത്തുമുണ്ട്. മിക്ക ആളുകളും തെറ്റായ കാര്യങ്ങളെക്കുറിച്ചാണ് വാദിക്കുന്നത്.
യഥാർത്ഥ ചോദ്യം utility classes വേണോ അതോ inline styles വേണോ എന്നതല്ല. നിങ്ങളുടെ സ്റ്റൈലിംഗ് എവിടെയാണ് ഇരിക്കുന്നത് എന്നും അത് കൈകാര്യം ചെയ്യുമ്പോൾ ഉണ്ടാകുന്ന മാനസിക അധ്വാനം ആർക്കാണ് എന്നതുമാണ് പ്രധാനം.
Tailwind v4 കോൺഫിഗറേഷനെ നിങ്ങളുടെ CSS ഫയലിലേക്ക് മാറ്റുന്നു. ഒരു JavaScript കോൺഫിഗ് ഫയലിന് പകരം നിങ്ങൾ @theme ഉപയോഗിക്കുന്നു. ഇത് വർക്ക്ഫ്ലോ കൂടുതൽ ലളിതമാക്കുന്നു.
എന്നാൽ ഈ തർക്കത്തിന്റെ കാരണം ഇതല്ല. v4 രണ്ട് വ്യത്യസ്ത രീതികളെ (patterns) കൂടുതൽ എളുപ്പത്തിൽ ഉപയോഗിക്കാൻ സഹായിക്കുന്നു എന്നതാണ് തർക്കത്തിന് കാരണമാകുന്നത്.
Pattern 1: നിങ്ങളുടെ കംപോണന്റുകളിൽ (components) utility classes ഉപയോഗിക്കുക. നിങ്ങൾ HTML അല്ലെങ്കിൽ JSX-ൽ നേരിട്ട് ക്ലാസുകൾ എഴുതുന്നു. ഇത് ഒരു എലമെന്റ് എങ്ങനെയിരിക്കുന്നു എന്ന് കൃത്യമായി മനസ്സിലാക്കാൻ സഹായിക്കുന്നു.
Pattern 2: @apply രീതി. നിങ്ങൾ ഒരു CSS ഫയലിൽ .alert അല്ലെങ്കിൽ .alert--error പോലുള്ള semantic ക്ലാസുകൾ നിർമ്മിക്കുന്നു. ഇത് ഒരു എലമെന്റ് എന്താണെന്ന് വ്യക്തമാക്കുന്നു.
രണ്ട് രീതികളും ഫലപ്രദമാണ്. അവയിൽ ഒന്നും തെറ്റല്ല. അവ വ്യത്യസ്തമായ തത്വങ്ങളാണ് (philosophies) പിന്തുടരുന്നത്.
Group A 'co-location'-ൽ വിശ്വസിക്കുന്നു. എല്ലാം ഒരിടത്ത് തന്നെ ഇരിക്കുന്നു. Group B 'semantic names'-ൽ വിശ്വസിക്കുന്നു. കാര്യത്തിന്റെ ഉദ്ദേശ്യം വ്യക്തമാക്കുന്ന പേരുകളാണ് അവർ ആഗ്രഹിക്കുന്നത്.
ഒരു ഡിസൈനർ എറർ കളർ (error color) ചുവപ്പിൽ നിന്ന് ഓറഞ്ചിലേക്ക് മാറ്റുമ്പോൾ, Group A കോഡ് ഫയലുകളിലൂടെ തിരയുന്നു. എന്നാൽ Group B ഒരു CSS ഫയലിലെ ഒരു വരി മാത്രം മാറ്റിയാൽ മതിയാകും.
Tailwind v4 @apply ഉപയോഗിക്കുന്നത് കൂടുതൽ സ്വാഭാവികമാക്കുന്നു. ഇത് തർക്കങ്ങൾ വർദ്ധിപ്പിക്കുന്നു.
നിങ്ങളുടെ ടീമിന്റെ വലുപ്പത്തിനനുസരിച്ച് എങ്ങനെ തിരഞ്ഞെടുക്കാം എന്ന് താഴെ നൽകുന്നു:
ചെറിയ ടീമുകൾ: utility classes ഉപയോഗിക്കുക. ക്ലാസുകൾക്ക് പേര് നൽകാൻ സമയം ചെലവഴിക്കേണ്ടതില്ല. എല്ലാവരും ഒരേ ഫയലുകളിൽ ജോലി ചെയ്യുമ്പോൾ വേഗത്തിൽ മുന്നോട്ട് പോകാൻ സാധിക്കും.
കംപോണന്റ് ലൈബ്രറികൾ (Component libraries): @apply അല്ലെങ്കിൽ CSS variables ഉപയോഗിക്കുക. നിങ്ങളുടെ ഇന്റേണൽ ഡിസൈൻ ടോക്കണുകളെക്കുറിച്ച് (design tokens) ഉപയോക്താക്കൾ അറിയേണ്ടതില്ല.
വലിയ കമ്പനികൾ: ഒരു ഹൈബ്രിഡ് മോഡൽ (hybrid model) ഉപയോഗിക്കുക. സെമാന്റിക് ക്ലാസുകൾ കൈകാര്യം ചെയ്യാൻ ഒരു ഡിസൈൻ സിസ്റ്റം ടീമിനെ ഏൽപ്പിക്കുക. വേഗത്തിലുള്ള ലേഔട്ടുകൾക്കായി ആപ്ലിക്കേഷൻ ഡെവലപ്പർമാരെ യൂട്ടിലിറ്റികൾ ഉപയോഗിക്കാൻ അനുവദിക്കുക.
നീളമുള്ള ക്ലാസ് സ്ട്രിംഗുകൾ (class strings) വായിക്കുന്നത് ഒഴിവാക്കാൻ വേണ്ടി മാത്രം @apply ഉപയോഗിക്കരുത്. അത് ഒരു തന്ത്രമല്ല, മറിച്ച് ഒളിച്ചോട്ടമാണ്.
കടുത്ത വിമർശകർ പലപ്പോഴും ഫ്രെയിംവർക്കിനെക്കാൾ ഉപരിയായി അവരുടെ ടൂളുകളോടാണ് പോരാടുന്നത്. നിങ്ങളുടെ എഡിറ്ററിൽ IntelliSense ഇല്ലെങ്കിലോ അല്ലെങ്കിൽ നിങ്ങളുടെ ടീമിന് ഒരു ഡിസൈൻ ടോക്കൺ സിസ്റ്റം ഇല്ലെങ്കിലോ, വർക്ക്ഫ്ലോ തകരാറിലായതായി നിങ്ങൾക്ക് തോന്നും.
ഫ്രെയിംവർക്കിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് നിങ്ങളുടെ വർക്ക്ഫ്ലോ ശരിയാക്കുക.
Tailwind v4 മികച്ചൊരു റിലീസാണ്. CSS-first കോൺഫിഗറേഷൻ കൂടുതൽ മെച്ചപ്പെട്ടതാണ്. ടീമുകൾ വ്യക്തമായ തീരുമാനങ്ങൾ എടുക്കേണ്ടതുണ്ട് എന്നതിന്റെ സൂചന മാത്രമാണ് ഈ തർക്കം.
ഒരു തീരുമാനം എടുക്കുക. അത് രേഖപ്പെടുത്തുക. മുന്നോട്ട് പോവുക.
നിങ്ങളുടെ ടീമിന്റെ രീതി എന്താണ്? നിങ്ങൾ utility classes ആണോ അതോ @apply ആണോ ഉപയോഗിക്കുന്നത്?
ഉറവിടം: https://dev.to/enjoy_kumawat/the-real-reason-everyones-fighting-about-tailwind-css-v4-4o0g