De ce am ales Spring Boot și Vaadin, și nu altceva...

Mă întreabă lumea des, mai ales alți dezvoltatori: „de ce Vaadin, frate, în 2026, când toată lumea face React sau Next.js?" E o întrebare corectă și merită un răspuns serios, nu doar „pentru că așa știu eu". Am ales stack-ul ăsta după ce am trecut prin destule alternative, și motivele sunt practice, nu de fandom.

Ca să fiu direct: am ales să scap de bătaia de cap cu npm-urile. Cine a lucrat cu un proiect Node/React știe exact ce spun — node_modules cu mii de pachete, jumătate din ele întreținute de un singur om pe undeva prin lume, care poate abandona pachetul mâine sau poate publica un update care-ți strică tot build-ul peste noapte. La fiecare npm audit descoperi zeci de vulnerabilități în dependințe pe care nici nu știai că le ai, pentru că au venit „la pachet" cu altceva. Actualizezi o dependință, se rupe alta care depindea de versiunea veche. Peste asta pui și securitatea unui API REST expus public — CORS, tokenuri, validare dublată pe client și pe server — și te trezești că gestionezi un front întreg de probleme care n-au nicio legătură cu logica de business a clientului, ci doar cu faptul că ai ales un ecosistem instabil și fragmentat. Cu Spring și Vaadin, dependințele sunt puține, mature, publicate de organizații serioase (Spring, dezvoltat sub Broadcom/VMware, respectiv Vaadin Ltd.), și nu mă trezesc cu o gaură de securitate nouă în fiecare săptămână doar pentru că cineva a publicat un pachețel de trei linii de cod pe care jumătate din npm îl folosește ca dependință indirectă.

Contextul contează: nu construiesc rețele sociale

Primul lucru pe care trebuie să-l lămuresc: nu fac aplicații publice cu milioane de utilizatori și cerințe extreme de interactivitate vizuală. Fac aplicații de business pentru orice domeniu de activitate, sisteme de gestiune, formulare, fluxuri interne, administrare de date. E o categorie foarte diferită de un site de comerț electronic sau de o aplicație social media, și alegerea de tehnologie trebuie judecată în funcție de ce construiești, nu după ce e la modă.

Pentru genul ăsta de aplicații, ce contează cu adevărat e: cât de repede pot livra o funcționalitate corectă, cât de ușor o pot întreține peste 5-10 ani, și cât de puține lucruri pot să meargă prost fără supraveghere constantă. Din perspectiva asta, alegerea a fost aproape logică.

Un singur limbaj, o singură minte care ține totul în cap

Cu Vaadin, scriu tot — frontend și backend — în Java. Nu am un React separat care vorbește cu un backend Spring prin REST/JSON, cu două codebase-uri, două seturi de dependințe, două ecosisteme de build, și o groază de cod „de legătură" doar ca să transporte date dintr-o parte în alta.

Asta nu-i o preferință estetică, e o concluzie la care am ajuns după 25 de ani de programare. Am văzut haosul cu ochii mei: echipe mari, mulți programatori, păreri diferite despre cum „trebuie" făcut un lucru, și eterna vânătoare de vinovați când ceva pică în producție — „ba frontend-ul n-a trimis bine datele", „ba backend-ul a schimbat contractul fără să anunțe", „ba versiunea de librărie X nu mai e compatibilă cu Y". Am stat în destule discuții unde nimeni nu-și asuma clar responsabilitatea, pentru că fiecare parte a sistemului era în grija altcuiva, iar granița dintre ele era exact locul unde se ascundeau cele mai multe bug-uri.

De-atunci mi-am dat seama ce vreau cu adevărat: să livrez aplicații foarte stabile, fără bătăi de cap, fără cinci oameni cu cinci opinii diferite despre cum ar trebui scrisă o funcție. Îmi place ca aplicația să fie făcută de mâna mea, de la un capăt la altul, ca să știu exact ce se întâmplă în orice punct al ei — nu să depind de deciziile altcuiva, de un update pe care l-a făcut altă echipă fără să mă anunțe, sau de o presupunere greșită între „ce credea frontend-ul că primește" și „ce trimitea de fapt backend-ul". Fiecare linie suplimentară de cod „de legătură" între două sisteme separate e o linie în plus care poate avea bug, care trebuie testată, care trebuie întreținută peste ani — și, cel mai important, e o linie la granița dintre două responsabilități, exact locul unde lucrurile scapă printre degete. Eliminând stratul API/JSON dintre frontend și backend, elimin o clasă întreagă de probleme: desincronizare de contracte de date, versionare de API, breaking changes între frontend și backend care nu mai comunică bine după un update.

Stabilitate pe termen lung, nu goană după ultima modă

Ecosistemul JavaScript se reinventează constant. Uneltele și practicile „standard" din React s-au schimbat de multe ori — de la componente de clasă la hooks, de la Create React App la Vite sau Next.js — și un proiect scris acum 6-7 ani, deși încă rulează, ajunge greu de întreținut cu unelte moderne. Iar cazul AngularJS (versiunea 1.x, folosită masiv până prin 2016-2018) e și mai clar: a fost declarat oficial ieșit din suport, iar migrarea la Angular modern (2+) nu e un simplu update, e practic o rescriere completă, pentru că sunt două framework-uri diferite care doar au un nume asemănător. Pentru mine, care întrețin aplicații pentru clienți mici pe termen de 5, 10, poate 15 ani, instabilitatea asta e un cost ascuns uriaș — nu azi, ci peste 4 ani, când clientul vrea o modificare mică și eu descopăr că tot ecosistemul frontend de atunci a devenit arheologie.

Spring Boot are un istoric foarte diferit: versiuni cu suport lung, compatibilitate ascendentă gândită serios, un ecosistem care evoluează, dar nu se reinventează din temelii la fiecare release major. Java, ca limbaj, e notoriu pentru stabilitate — codul scris acum 10 ani, cu ceva mentenanță normală, încă rulează și încă are sens. Pentru un solo developer care nu-și permite să rescrie aplicații la fiecare schimbare de trend, asta cântărește enorm.

Mai puțină suprafață de atac, mai puține lucruri de securizat

Fără un API REST public expus separat, am mult mai puțină suprafață de atac. Nu expun endpoint-uri JSON pe care oricine le poate testa cu Postman, nu gestionez separat autentificare pe frontend și autorizare pe backend, nu mă lupt cu CORS, cu tokenuri JWT care expiră greșit, cu validare dublată (o dată pe client, o dată pe server, ca să nu am găuri). Vaadin gestionează comunicarea client-server printr-un canal controlat, iar logica de business rămâne strict pe server — clientul nu vede niciodată direct structura datelor sau regulile de validare.

Pentru clienți care lucrează cu date sensibile — dosare medicale, acte notariale — asta nu-i un detaliu tehnic oarecare, e chiar diferența dintre „ușor de securizat corect de o singură persoană" și „ai nevoie de o echipă de securitate dedicată ca să faci lucrurile bine".

Siguranță la compilare, nu la producție

Java e un limbaj tipizat static, verificat la compilare. Multe categorii de erori care în JavaScript/TypeScript apar în producție — sau, în cel mai bun caz, sunt prinse de teste pe care cineva trebuie să le scrie și să le mențină — la mine sunt prinse înainte să apuc să dau deploy. Nu am o echipă de QA. Nu am un tester dedicat care verifică fiecare modificare. Și, ca să fiu sincer, nici nu-mi doresc așa ceva. Experiența m-a învățat că, de multe ori, cu cât bagi mai mulți oameni într-un proiect, cu atât aplicația devine mai instabilă și apar bug-uri de nici nu mai știi de unde — pentru că fiecare om mai adaugă un strat de presupuneri, de comunicare imperfectă, de „am crezut că se ocupă altul de asta". Munca cu oamenii e, de departe, cea mai grea parte din tot ce înseamnă un proiect software, iar vorba bătrânilor spune exact ce trebuie: prea mulți bucătari strică ciorba. La mine, lanțul de responsabilitate e scurt cât se poate — eu scriu, eu verific, eu răspund — și tocmai asta ține numărul de bug-uri jos. Compilatorul e, în bună parte, prima mea linie de apărare împotriva bug-urilor stupide, iar asta contează enorm când ești singurul om responsabil de zeci de aplicații în producție.

Ecosistem matur pentru exact ce am nevoie

Spring are, practic, o soluție testată-n luptă pentru orice problemă de business obișnuită: securitate (Spring Security), acces la baze de date (Spring Data), integrări, task-uri programate, email, mesagerie. Nu reinventez roata, nu caut o bibliotecă nouă și nesigură de pe npm cu 40 de descărcări pe săptămână și un singur întreținător care poate abandona proiectul mâine. Ecosistemul Spring e construit pentru exact tipul de aplicații enterprise/business pe care le fac — nu trebuie să „adaptez" un instrument gândit pentru altceva.

Vaadin e potrivit special pentru ce construiesc eu

Aplicațiile mele sunt, în esență, formulare, tabele, fluxuri de aprobare, panouri de administrare — genul de interfață unde utilizatorul introduce și vede date structurate, nu unde ai nevoie de animații complexe sau interacțiuni vizuale spectaculoase. Exact pentru genul ăsta de aplicații, modelul de componente al lui Vaadin e mai rapid de dezvoltat decât să construiești manual fiecare tabel, fiecare formular, fiecare validare, într-un framework frontend generic. Componentele vin gata făcute, accesibile, consistente vizual, și integrate direct cu logica de business din Java — fără să scriu cod JavaScript de fiecare dată când am nevoie de un dropdown care se comportă cum trebuie.

Nu sunt doar convingerile mele — o confirmă și marii jucători

Aș putea să vă spun că am dreptate doar pe baza experienței mele, dar prefer să pun pe masă fapte verificabile, nu impresii personale. Iar faptele arată clar că alegerea asta nu-i un moft de-al meu, izolat undeva într-un colț de țară — e o alegere confirmată, la scară mult mai mare, de unele dintre cele mai mari corporații din lume.

Pe partea de Spring Boot, exemplul cel mai clar e chiar Netflix, care a anunțat oficial, pe blogul lor tehnic, că din 2018 a trecut la Spring Boot ca framework Java de bază pentru întreaga lor infrastructură. Vorbim despre unul dintre cele mai mari sisteme distribuite din lume, care servește sute de milioane de utilizatori simultan — nu un proiect de nișă, ci coloana vertebrală a unei companii care nu-și permite absolut deloc instabilitate.

Pe partea de Vaadin, lista de companii care au ales exact aceeași filozofie e la fel de convingătoare. Kemira, gigant global din industria chimică, a folosit Vaadin pentru a construi KemConnect, o platformă complexă de colectare și analiză a datelor de clienți din surse multiple, după ce s-a lovit de limitările sistemelor vechi fragmentate. CSS AG, un furnizor important de soluții ERP, a ales Vaadin exact pentru că nu mai putea susține pe termen lung vechea aplicație desktop și avea nevoie de o alternativă modernă, stabilă, în browser — practic aceeași problemă de longevitate despre care vorbeam mai devreme. Iar pe partea instituțională, Lotteri- og stiftelsestilsynet, autoritatea norvegiană care supraveghează toate loteriile private și de stat din Norvegia și raportează direct Ministerului Culturii, a construit tot pe Vaadin — o instituție de stat nu-și permite să rămână, peste câțiva ani, cu o aplicație pe care nimeni n-o mai poate întreține.

Și, ca să nu rămână la nivel de câteva exemple izolate, chiar compania Vaadin declară public că tehnologia lor e folosită de peste 40% dintre companiile din Fortune 100 — nu-i o cifră inventată de mine, ci una asumată oficial de producătorul tehnologiei. La toate astea se adaugă un detaliu simplu, dar grăitor: Vaadin, sub forma lui inițială, există din anul 2000 — cu mult înaintea AngularJS (2009), React (2013) sau Vue.js (2014). E, pur și simplu, un instrument mai bătrân și mai testat în foc decât toate framework-urile „moderne" cu care e comparat azi.

Concluzie: nu e despre ce-i „cool", e despre ce pot să susțin singur, ani de zile

Aș putea folosi React cu un backend separat, aș putea folosi Node pe tot stack-ul, aș putea încerca low-code. Dar niciuna dintre variantele astea nu rezolvă problema mea reală: sunt un singur om care trebuie să livreze rapid, să securizeze corect, și să întrețină pe termen lung, fără o echipă în spate. Iar faptul că exact aceleași motive m-au condus spre alegerea pe care o fac și Netflix, Kemira, CSS AG sau o autoritate de stat norvegiană — companii și instituții care n-au niciun interes să-și riște reputația pe o tehnologie fragilă — îmi confirmă că nu-i vorba de o părere personală, ci de o logică validă la orice scară, de la un singur developer până la corporații globale. Spring Boot și Vaadin sunt exact alegerea cea mai bună pentru stabilitate supremă — nu cea mai „trendy", ci cea care nu te lasă de izbeliște. În fond, unui client nu-i trebuie un meniu care arată superb pentru că-i făcut în React sau Angular, dacă tot el mă sună disperat că nu i s-a încărcat pagina sau că meniul „a luat-o razna" după un update de dependințe pe care nimeni nu l-a mai testat. Clientului îi trebuie o aplicație care merge, punct — nu drame de framework la fiecare câteva luni. Sunt alegerea care-mi permite să dorm liniștit știind că aplicația unui client va merge la fel de bine peste 5 ani, cu un efort de întreținere pe care-l pot duce singur, fără să reconstruiesc tot ecosistemul de fiecare dată când cineva din altă parte a lumii decide că framework-ul preferat de anul trecut nu mai e „la modă".

Și ca să fie clar de unde vine toată convingerea asta: n-am ajuns aici din lipsă de experiență cu alternativele. Am lucrat mult timp și cu React, și cu Angular, și cu Node.js, și cu alte framework-uri — știu exact ce oferă și exact unde dor. Dar nu-mi place să-mi bat joc de afacerea unui om. Un client care mi-a dat banii lui pe o aplicație nu trebuie să mă sune peste trei luni pentru că „nu merge aia" sau „s-a stricat ailaltă" — și, de cele mai multe ori, când se întâmplă asta la alte proiecte, nu-i vina programatorului, e vina unui ecosistem cu prea multe piese mobile, prea multe dependințe fragile și prea multe locuri unde ceva se poate rupe fără avertisment. Eu nu vreau să fiu sunat așa, și nici clientul nu merită să treacă prin asta. De-aia soluțiile pe care le livrez trebuie să fie beton — nu pentru că sunt încăpățânat cu tehnologia, ci pentru că am văzut, cu mâinile mele, ce înseamnă alternativa.