TanStack അതിന്റെ ലൈബ്രറികളിൽ React Server Components (RSC) ഉപയോഗിക്കുന്നത് ഔദ്യോഗികമായി നിർത്തലാക്കി. സങ്കീർണ്ണത വർദ്ധിക്കുന്നത്, ഫ്ലെക്സിബിലിറ്റി കുറയുന്നത്, മിതമായ പെർഫോമൻസ് നേട്ടങ്ങൾ, ഡെവലപ്‌മെന്റ് വേഗത കുറയുന്നത് എന്നിവയാണ് ഇതിന് കാരണമായ നിർണ്ണായക ഘടകങ്ങൾ. React അടിസ്ഥാനമാക്കിയുള്ള ടൂളുകൾ നിർമ്മിക്കുന്നവർക്ക് ഈ മാറ്റം വളരെ പ്രധാനമാണ്, കാരണം TanStack-ന്റെ ലൈബ്രറികൾ വ്യാപകമായി ഉപയോഗിക്കപ്പെടുന്നവയാണ് കൂടാതെ ഇവ പലപ്പോഴും ഇക്കോസിസ്റ്റത്തിന് പ്രായോഗിക മാനദണ്ഡങ്ങൾ നിശ്ചയിക്കാറുമുണ്ട്.

എന്തുകൊണ്ടാണ് RSC ആകർഷകമായി തോന്നിയത്

ഡാറ്റാ ഫെച്ചിംഗ് (data-fetching), റെൻഡറിംഗ് (rendering) ജോലികൾ സെർവറിലേക്ക് മാറ്റുന്നതിനും, ക്ലയന്റ് ബണ്ടിലുകളുടെ (client bundles) വലിപ്പം കുറയ്ക്കാനും, പേജുകൾ വേഗത്തിൽ ലോഡ് ചെയ്യാനും സഹായിക്കുന്ന ഒരു മാർഗമായാണ് React Server Components അവതരിപ്പിക്കപ്പെട്ടത്. തങ്ങളുടെ data-grid, query ലൈബ്രറികളുടെ യൂസർ എക്സ്പീരിയൻസ് മെച്ചപ്പെടുത്താമെന്ന പ്രതീക്ഷയിൽ TanStack ടീം ഈ രീതി പരീക്ഷിച്ചു നോക്കി.

എന്താണ് അവരെ ഇതിൽ നിന്ന് പിന്തിരിപ്പിച്ചത്

  • Complexity – RSC കോഡ് ഡീബഗ് (debug) ചെയ്യുന്നത് പുതിയൊരു മാനസിക മാതൃക (mental model) ആവശ്യപ്പെടുന്നു. സെർവർ സൈഡ് റെൻഡറിംഗ് (server-side rendering) പ്രശ്നങ്ങൾ കണ്ടെത്തുന്നതിനായി ടീമിന് അവരുടെ കഴിവിനേക്കാൾ കൂടുതൽ സമയം ചെലവഴിക്കേണ്ടി വന്നു.
  • Flexibility – പല തേർഡ് പാർട്ടി (third-party) ലൈബ്രറികളും പൂർണ്ണമായും ക്ലയന്റ് എൻവയോൺമെന്റിലാണ് പ്രവർത്തിക്കുന്നത്. RSC-യുടെ സെർവർ-ഒൺലി (server-only) രീതി, ആ ഡിപെൻഡൻസികളെ (dependencies) മാറ്റം വരുത്താതെ തന്നെ ഉപയോഗിക്കുന്നത് പ്രയാസകരമാക്കി.
  • Performance – വേഗതയിലുണ്ടായ മാറ്റങ്ങൾ വളരെ കുറവായിരുന്നു. സെർവറും ക്ലയന്റും തമ്മിലുള്ള ഏകോപനം നടത്തുന്നതിനായുള്ള അധിക അധ്വാനം (overhead), ലഭിച്ച നേട്ടങ്ങളേക്കാൾ കൂടുതലായിരുന്നു.
  • Velocity – ലളിതമായ ക്ലയന്റ്-ഒൺലി (client-only) രീതികൾ ഉപയോഗിക്കുന്നത് ടീമിന് വേഗത്തിൽ അപ്‌ഡേറ്റുകൾ പുറത്തിറക്കാൻ സഹായിക്കുന്നു. എന്നാൽ RSC ഉപയോഗിക്കുമ്പോൾ, ഓരോ മാറ്റവും സെർവറിലും ക്ലയന്റിലും പരിശോധിക്കേണ്ടി വരുന്നത് റിലീസ് സൈക്കിളിനെ സാവധാനത്തിലാക്കി.

ഇതിന്റെ ആഘാതം

TanStack പോലുള്ള ഒരു പ്രമുഖ ടൂൾകിറ്റ് RSC-യിൽ നിന്ന് പിന്മാറുന്നുവെങ്കിൽ, മറ്റ് പ്രോജക്റ്റുകളും ഇതിനെക്കുറിച്ചുള്ള അമിത പ്രതീക്ഷകൾ പുനർചിന്തനം ചെയ്തേക്കാം. പുതിയ ഫീച്ചറുകൾ ഡെവലപ്പർമാരുടെ ഉൽപ്പാദനക്ഷമതയെയും ദീർഘകാല പരിപാലനത്തെയും (maintenance) ബാധിക്കുന്ന ചില മറഞ്ഞിരിക്കുന്ന ചിലവുകൾ ഉണ്ടാക്കിയേക്കാം എന്ന വലിയൊരു വെല്ലുവിളിയാണ് ഈ തീരുമാനം ഉയർത്തുന്നത്. വേഗത്തിലുള്ള മാറ്റങ്ങൾക്കും ലൈബ്രറികളുടെ വിപുലമായ പൊരുത്തപ്പെടലിനും (compatibility) മുൻഗണന നൽകുന്ന കമ്പനികളും ഇതേ പാത പിന്തുടർന്നേക്കാം.

മറ്റൊരു വശം

ചില ഡെവലപ്പർമാർ ഇപ്പോഴും പ്രത്യേക സാഹചര്യങ്ങളിൽ RSC-യുടെ മൂല്യം കാണുന്നുണ്ട്—പ്രത്യേകിച്ച് സെർവർ സൈഡ് ഡാറ്റാ പ്രോസസ്സിംഗിലൂടെ പേലോഡ് സൈസ് (payload size) ഗണ്യമായി കുറയ്ക്കാൻ കഴിയുന്ന ഇടങ്ങളിൽ. ഈ രീതി ഭാവിയിൽ പരിഷ്കരിക്കപ്പെട്ടേക്കാം, TanStack ചൂണ്ടിക്കാണിച്ച പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ പുതിയ ടൂളുകൾ വന്നേക്കാം. നിലവിൽ ഇതിനെക്കുറിച്ച് വ്യത്യസ്ത അഭിപ്രായങ്ങളാണ് ഉള്ളത്.

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

  • Tooling updates – ഡീബഗ്ഗിംഗിലും ഇന്റഗ്രേഷൻ സപ്പോർട്ടിലുമുള്ള പുരോഗതി സങ്കീർണ്ണത കുറയ്ക്കാൻ സഹായിച്ചേക്കാം.
  • Community feedback – കൂടുതൽ ടീമുകൾ പെർഫോമൻസ് ഡാറ്റ പങ്കുവെക്കുമ്പോൾ, ഇതിന്റെ ഗുണദോഷങ്ങളെക്കുറിച്ചുള്ള വിലയിരുത്തലുകൾ മാറാൻ സാധ്യതയുണ്ട്.
  • Alternative patterns – ഇൻക്രിമെന്റൽ സെർവർ റെൻഡറിംഗ് (incremental server rendering) രീതികളോ ഹൈബ്രിഡ് സമീപനങ്ങളോ ഒരു മധ്യമാർഗ്ഗമായി വന്നേക്കാം.

Takeaway: പുതിയ സാങ്കേതികവിദ്യകൾ എപ്പോഴും മികച്ചതാകണമെന്നില്ല എന്ന് TanStack-ന്റെ ഈ തീരുമാനം നമ്മെ ഓർമ്മിപ്പിക്കുന്നു; പുതിയ രീതികൾ സ്വീകരിക്കുന്നതിന് മുമ്പ്, അവ നൽകുന്ന നേട്ടങ്ങളെക്കാൾ അവ നിങ്ങളുടെ ജോലിരീതിയിൽ ഉണ്ടാക്കുന്ന യഥാർത്ഥ ചിലവുകളെക്കുറിച്ച് ഡെവലപ്പർമാർ ചിന്തിക്കേണ്ടതുണ്ട്.

Source: https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com