Tehnologii
JavaScript: ce păstrăm, ce curățăm și ce rescriem
Limbajul care rulează în orice browser — dar decizia reală se ia la nivel de framework, nu de limbaj.
Un site de opt ani are, aproape întotdeauna, un strat de JavaScript pe care nimeni nu-l mai atinge: două biblioteci abandonate, un jQuery rămas pentru trei linii de cod și un fișier pe care furnizorul anterior l-a numit provizoriu.
Asta e forma în care ne întâlnim cel mai des cu limbajul în firme reale — nu ca alegere pentru un proiect nou, ci ca moștenire care încetinește orice modificare și face imposibil de estimat orice cerere ulterioară.
Pe pagina asta vorbim despre două lucruri: ce facem cu codul acela și de ce codul nou îl scriem cu verificare de tipuri. Alegerea de framework — React, Vue sau Angular — e o decizie separată, cu paginile ei pe site.
Hai să vorbim despre proiectul tău
Scrie-ne pe WhatsApp sau trimite un email — vorbești direct cu un programator.
office@northdan.com · +40 752 070 247
Ce primești
Un inventar înainte de prima modificare
Aflați ce biblioteci rulează azi în paginile voastre, care nu mai primesc corecții de securitate și ce se întâmplă concret dacă sunt scoase.
Curățare în pași care se pot opri
Se scoate întâi ce nu e folosit, apoi ce apare într-un singur loc, iar componentele centrale rămân la final — fiecare pas livrat separat.
Cod nou scris cu plasă de siguranță
Tot ce adăugăm pornește în TypeScript, deci nepotrivirile de date se opresc la compilare și nu ajung în ecranul unui client.
Ce facem, concret, cu JavaScript
Trei tipuri de lucrare. Curățarea unui front-end moștenit: inventarul bibliotecilor care rulează azi și ordinea în care se scot. Scoaterea jQuery-ului dintr-un site vechi, unde a rămas pentru funcții pe care browserele le fac acum nativ. Și construirea de cod nou, care la noi începe cu verificare de tipuri.
Ordinea contează mai mult decât uneltele. Se scoate întâi ce nu e folosit deloc, apoi ce e folosit într-un singur loc, și abia la final se ating componentele centrale. Un audit care nu produce această ordine e o listă, nu un plan de lucru.
Ce livrăm înainte de prima modificare
Nu revendicăm niciun produs public pe JavaScript ca atare — ar fi o etichetă, nu o dovadă. Livrăm în schimb, înainte de a atinge codul, un audit: ce biblioteci rulează azi, care nu mai primesc corecții de securitate și ce se întâmplă dacă sunt scoase.
Auditul e un document, nu o ședință, și rămâne al vostru chiar dacă lucrarea o face altcineva. E și singurul mod onest de a da o estimare: fără el, orice cifră e ghicită.
Compromisurile reale ale limbajului
JavaScript permite prea multe. Aceleași libertăți care fac un prototip rapid transformă un proiect de câțiva ani într-un teren unde nimeni nu mai știe ce date circulă printr-o funcție. Nu e o critică teoretică: e chiar motivul pentru care codul nou îl scriem cu verificare de tipuri.
Costul de după lansare vine din arborele de dependențe: fiecare bibliotecă adăugată e o promisiune de întreținere făcută în locul altcuiva. Efortul unei modernizări urmează numărul de pagini atinse.
Când NU scriem JavaScript simplu
Pentru orice proiect nou care va trăi mai mult de câteva luni, alegem TypeScript. Condiția o formulăm invers: JavaScript simplu rămâne rezonabil pentru un script de o pagină, un prototip aruncabil sau o intervenție punctuală într-un cod existent care nu are verificări.
Nu recomandăm conversia integrală a unui proiect vechi ca lucrare de sine stătătoare. Verificările se activează fișier cu fișier, pe măsură ce lucrați oricum la acele zone — altfel plătiți o migrare care nu schimbă nimic pentru utilizatorul final.
Ce se degradează, de fapt, și cine repară
Limbajul nu se degradează. Standardul evoluează anual, dar prin adăugiri, iar codul scris corect acum zece ani rulează și azi în orice browser. Ce se degradează e arborele de biblioteci din jurul lui — acolo apar avertismentele de securitate și acolo se blochează actualizările.
De aceea măsura de continuitate pe care o recomandăm nu e o rescriere, ci reducerea numărului de dependențe. Cu mai puține biblioteci, orice programator din piața locală — cea mai largă dintre toate — poate prelua front-end-ul fără să învețe întâi un ecosistem întreg.
Întrebări frecvente
Când scriem JavaScript simplu și când trecem pe TypeScript?
Cod nou care va trăi mai mult de câteva luni îl scriem în TypeScript, fără excepții. JavaScript simplu rămâne potrivit pentru un script de o pagină, un prototip aruncabil sau o intervenție mică într-un cod fără verificări.
Găsim ușor pe cineva să preia un front-end JavaScript vechi?
Oameni se găsesc — e cea mai largă piață de programatori din România. Dificultatea e alta: nimeni nu vrea să preia un proiect cu treizeci de dependențe abandonate și fără teste. Reducerea numărului de biblioteci înainte de predare schimbă mai mult decât orice document de predare.
De ce depinde costul unei modernizări de front-end?
De câte pagini ating modificările și de cât de amestecat e codul vechi cu cel nou. O bibliotecă folosită într-un singur loc se scoate într-o zi; aceeași bibliotecă răspândită în patruzeci de fișiere e altă lucrare. Ce înseamnă asta în bani am explicat separat, pe pagina de costuri.
Site-ul nostru are mult JavaScript vechi — se poate curăța?
Da, și de regulă fără să oprim site-ul nicio zi. Începem cu auditul, scoatem întâi ce nu mai e folosit, apoi ce apare într-un singur loc, iar componentele centrale rămân la final. Fiecare pas e livrat separat, deci procesul se poate opri oricând.
Pagini similare
Resurse conexe
Hai să vorbim despre proiectul tău
Scrie-ne pe WhatsApp sau trimite un email — vorbești direct cu un programator.
office@northdan.com · +40 752 070 247