În 2026, peisajul s-a schimbat — nu doar pentru că au apărut biblioteci noi, ci pentru că JavaScript a evoluat. Ca tech lead, nu mă mai interesează doar “ce funcții are”. Mă interesează dimensiunea bundle-ului, siguranța tipurilor, cât de ușor se face onboarding, costul de mentenanță pe termen lung și cum influențează un tool stilul de cod al echipei.

Așa mă gândesc eu azi la bibliotecile de utilitare.

Prima întrebare: chiar ai nevoie de una?

Înainte să aleg o bibliotecă, întreb mereu:

“Ce problemă rezolvăm pe care JavaScript-ul nativ nu o rezolvă deja?”

JavaScript-ul modern acoperă surprinzător de mult:

• Array.isArray, Array.prototype.toSorted, toReversed
• Object.groupBy
• structuredClone
• findLast, findLastIndex

Acum 10 ani, Lodash umplea goluri reale. Azi, multe din acele goluri au dispărut.

Regula mea de bază:

• Pornește cu API-urile native
• Adaugă o bibliotecă de utilitare doar când îmbunătățește clar lizibilitatea sau consistența

Notă de compatibilitate: unele API-uri “moderne” depind de țintele tale de runtime (browsere mai vechi, versiuni vechi de Node, webview-uri). Dacă nu te poți baza pe ele încă, ai nevoie fie de o strategie de polyfill (de ex. core-js), fie de o bibliotecă mică de helpers care nu îți umflă bundle-ul.

Cum arată “bine” în 2026

Când evaluez o bibliotecă de utilitare azi, optimizez pentru:

1. Design TypeScript-first

Nu “are types”, ci e gândită în jurul tipurilor. Asta influențează:

• Calitatea inferenței
• Ergonomia pentru developer
• Siguranța refactorizărilor

2. Tree-shaking și impact în bundle

Dacă import o funcție, vreau o funcție — nu jumătate de bibliotecă.

3. Claritatea API-ului

Face codul mai lizibil sau doar mai “șmecher”?

4. Costul de migrare

Dacă înlocuim ceva precum Lodash, fricțiunea contează.

Principalii “candidați”

1. Default-ul pragmatic

Dacă sunt într-o echipă care vrea un înlocuitor modern și safe pentru Lodash, tind spre un toolkit prietenos pentru migrare, orientat pe performanță.

De ce?

• Overhead cognitiv minim
• API familiar
• Adopție incrementală ușoară

Asta contează mai ales în echipe mari, unde nu toată lumea vrea să învețe o paradigmă nouă.

Biblioteci pe care le-aș pune pe shortlist aici: lodash-es (mai ales când deja “gândești în lodash”), sau toolkits mai noi precum es-toolkit (default-uri moderne, tree-shakeable).

2. Alegerea “puristului” TypeScript

Pentru echipe care îmbrățișează pattern-uri funcționale și țin mult la inferența tipurilor, există o direcție diferită: utilitare TS-native, prietenoase cu pipeline-uri.

Aceste biblioteci:

• Inferă tipuri prin transformări în lanț
• Încurajează compoziția (pipe, map, filter)
• Reduc bug-uri la runtime prin garanții la compile-time

Trade-off-ul e real:

• Curba de învățare e mai abruptă
• Mai puțină familiaritate pentru developerii care vin din Lodash

Ca lead, împing direcția asta doar dacă echipa e pregătită pentru ea.

Biblioteci pe care le-aș pune pe shortlist aici: remeda (TS-first), sau ecosisteme funcționale precum fp-ts (puternic, dar cu multe convenții).

3. “Modernistul” lightweight

Mai există și categoria de biblioteci axate pe:

• Amprentă mică
• Umplerea unor goluri practice (mai ales utilitare async)
• Apropiere de JS-ul nativ

Sunt excelente când:

• Nu vrei un “framework de utilitare”
• Ai nevoie doar de câțiva helpers făcuți bine

Biblioteci pe care le-aș pune pe shortlist aici: radash (mică, pragmatică) sau pachete foarte focusate, unde imporți strict ce folosești.

4. Opțiunea legacy

Lodash încă există — și încă e peste tot.

Într-un proiect greenfield, n-aș alege Lodash azi. Dar într-un codebase existent?

Nu l-aș scoate “din reflex”.

Motive să-l păstrezi:

• Stabilitate
• Familiaritatea echipei
• Costul de migrare depășește beneficiile

În schimb, prefer:

• Înlocuire graduală
• Native-first pentru cod nou
• Să nu extindem aria de utilizare

Ce recomand, de fapt, echipelor

Asta le spun în practică:

Pentru proiecte noi

• Începe cu JavaScript nativ
• Adaugă o bibliotecă mică și modernă când pattern-urile se repetă
• Evită dependențe “grele” prea devreme

Pentru codebase-uri existente, pline de Lodash

• Nu rescrie tot
• Introdu alternative moderne treptat
• Preferă API-urile native pentru cod nou

Pentru echipe foarte orientate pe tipuri

• Ia în calcul o bibliotecă funcțională TypeScript-first
• Dar aliniați convențiile devreme (asta e critic)

Un checklist rapid de decizie

• Dacă poți ținti runtime-uri moderne: mergi native-first, adaugă helpers doar unde repetarea doare.
• Dacă ai nevoie de familiaritate “drop-in”: alege un API în stil Lodash, care tree-shake-uie bine (lodash-es, es-toolkit).
• Dacă types + pipelines sunt preferința echipei: alege utilitare funcționale TS-first (remeda) și standardizează pattern-urile (pipe, naming, data-last vs data-first).
• Dacă azi ești blocat pe Lodash: nu-l scoate; îngheață-l și migrează oportunist.

Decizia reală nu e biblioteca

Cea mai mare greșeală pe care o văd nu e că lumea alege biblioteca “greșită”.

E asta:

Să lași biblioteca să-ți dicteze stilul de cod, în loc să pleci de la nevoile echipei.

O bibliotecă de utilitare ar trebui să:

• Reducă “zgomotul”
• Crească lizibilitatea
• Facă intenția evidentă

Dacă face opusul — chiar dacă e “modernă” sau “rapidă” — e alegerea greșită.

Concluzia mea

Dacă ar fi să rezum:

• JS nativ a înlocuit o bună parte din bibliotecile de utilitare
• Nu mai există un “cel mai bun” universal
• Alegerea corectă depinde de prioritățile echipei:
  • Familiaritate vs siguranța tipurilor
  • Simplitate vs compozabilitate

Și, cel mai important:

Cea mai bună bibliotecă de utilitare e cea pe care echipa aproape că nu o observă — pentru că totul se citește curat și funcționează.

Dacă alegi chiar acum, nu compara doar feature-uri. Uită-te la echipa ta, la codebase-ul tău și la costurile de mentenanță pe termen lung.

Acolo e, de fapt, răspunsul.