Alegerea framework-ului e o componenta de inginerie la fiecare inceput de proiect. Eu prefer React fiindca testarea cu react-testing-library e relativ buna. Ai multe solutii, suport bun pentru monorepo-uri cu nx sau turborepo. E destul de rapid pentru aproape orice, ai librarii de baza foarte bune, react query, react table, react hook form de exemplu. Ai multe librarii de UI mature.
La companii mari trebuie ales intre Angular, React, cateodata Vue si pe proiecte legacy am vazut Ember. Mai exista raritati precum Elm, utilizat de echipe mai speciale. In multe locuri ai micro frontend-uri legate cu un app shell care leaga mai multe framework-uri/aplicatii vechi/noi impreuna.
Am utilizat cam un an Angular, era foarte greu sa scrii teste functionale, mi-a facut multe probleme Rx.JS, e greu sa faci debugging, te bati cu change detection-ul, nu imi place structura de clase la componente fiindca nu sunt clase adevarate ci doar boilerplate inutil, nu poti face de exemplu property testing ca in Java/.NET. Documentatia era horror, stateam zile cu 2-3 colegi sa inteleg ce face ceva. TypeScript-ul e complicat cu clase.
In corporatie am vazut si Vaadin (Java) pentru aplicatii web, Kotlin pe front-end…
Solutiile hibride care apar sunt putin nisate si eu n-as avea incredere in edge rendering. Nu e deloc ieftin sa iti setezi propriul edge rendering daca se intampla ceva cu cloudflare/aws.
Vaadin am vazut ca iti da posibilitatea sa scrii in Java si Typescript
Exista si https://hilla.dev care daca te uiti e frumusel de simplu. Foloseste tot componente de Vaadin si iti expune fiecare endpoint (cu type-uri) din Spring in front-end cu generator de cod.
UI-ul e o combinatie de lit-html si vaadin, dar ai putea foarte usor introduce orice in loc de lit-html pe front-end.
Vaadin e probabil utilizat ca sa ai ‘server-side views’, adica server-side rendering.
Pe JS/TS ceva similar ar fi https://blitzjs.com si https://redwoodjs.com.
arata dragut 
mai ales partea de java 
apar si frameworkurile astea mai ceva decat srl-urile lui dascalu. n-ai timp sa inveti unul, ca deja e invechit/neutilizat 
Eu sunt foarte curios și abia aștept să testez Astro și Qwik. Mi se pare că – mai ales pentru proiecte mai mici unde n-ai nevoie de funcționalități mega avansate caracteristice web apps – astea două framework-uri înțeleg că web-ul e prin definiție HTML și CSS, iar JS-ul este un progressive enhancement și ar trebui folosit doar când și unde ai nevoie de el.
M-a deranjat dintotdeauna ideea să construiești o aplicație întreagă cu un mare single point of failure axat pe prezența sau absența JS-ului din browser. Probabil m-a influențat prea mult Jeremy Keith în https://resilientwebdesign.com/ și numeroși alți oameni care văd în soluțiile pure SPA o problemă principială înainte de toate, care anulează complet aspecte cum ar fi SEO sau accesibilitatea și bagă pe gâtul browserului sute sau mii de kb de date de care n-are nevoie (imediată). Probabil dacă React & co n-ar fi suportat SSR sau SSG ar fi fost și mai grav.
Deci nu cred că e un lucru rău c-au apărut alte framework-uri. Fiecare proiect are caracteristici unice și va deveni un skill din ce în ce mai căutat acum (pentru oamenii cu experiență): să poți alege framework-ul ideal pentru fiecare context de proiect în care e nevoie să-l folosești.
Eu inca n-am gasit un proiect care plateste bine pentru pagini statice generate cu JS.
Am evitat ecommerce cat am putut, probabil devforum insusi e un exemplu bun de aplicatie care ar profita de pe urma unui framework cat mai progresiv cu JS-ul.
Problema cu aceste framework-uri e ca o pagina statica se poate crea de exemplu cu figma si exporta in html/css. Se adauga doar animatiile la scroll/breakpoint-urile.
Probleme sunt mai mult cu aplicatiile, unde orice framework care nu are mult suport are un dezavantaj.
La aplicatii nici nu prea conteaza asa mult framework-ul, ai de facut domain modelul (de refacut ca se tot schimba), ai de setat totul ca sa fie usor de intretinut, ai de scris teste, trebuie sa adaugi feature-urile cat mai rapid)
Tot ce este content-heavy: bloguri, pagini de prezentare, forumuri, pagini cu documentație, chiar și magazine online, etc. ar beneficia major de pe urma unui framework care generează HTML-uri statice. Dacă ai nevoie de SEO (și cine n-are outside FAANG?) te ajută mult scorul de Lighthouse cât mai bun, mai nou. Și cum ziceam, ăsta e doar unul din argumente.
Da, dar cu ce coding standards? Ziceam mai devreme de accesibilitate, SEO, etc. Ca să nu mai vorbim de validitate, optimizare a DOM-ului și CSS-ului, folosirea SCSS pentru extensibilitate și mentenanță ușoară, eventual chiar cu un framework de CSS gen Tailwind (deși nici alea nu-mi plac prea tare), etc. Varianta no-code sau „export from Ț” (unde Ț variază de la Photoshop în 201X până la Figma în 202X) n-o să meargă niciodată decât dacă n-ai nevoie de standarde și n-ai pretenții prea mari de Lighthouse scores și mentenanță ușoară. Pentru aplcații serioase și ceva mai complexe decât una comparabilă cu un site făcut în Wix n-ai de ales decât să codeze cineva. Deci nu cred că ține apă argumentul ăsta, dar probabil depinde ce pretenții ai. Eu fac tot posibilul să am cât mai puține bube raportate de tool-uri de validare cum sunt astea strânse de mine aici: Auditorul de site-uri - Viorel Mocanu
Aici sunt de acord cu tine, framework-ul e mai puțin relevant. Sunt unele mai flexibile decât altele (React vs Angular) și unele mai optimizate decât altele (Vue, Svelte, Astro, Qwik, etc) dar până la urmă important e să livrezi ce trebuie și să fie totul stabil, contează mai puțin în ce e scris, atâta timp cât are comunitate care să te ajute fie pasiv cu articole și răspunsuri pe StackOverflow fie activ să dai de cap problemelor.
Faza e ca daca luam orice framework de acum 1-2 ani si niste principii de common sense, adica nu pui 1Mb de JS pe front-end si ai corect setat bundlerul o sa ai de descarcat ceva acceptabil de 100-300kb JS in cel mai rau caz pentru un site de prezentare, plus AdSense, tracking si toate cele.
Cand Lighthouse se plange problema cea mai mare pe care poti sa o ai e cu imaginile/SVG-urile/video-urile si in cel mai rau caz gif-urile. Imaginile trebuie servite la cea mai mica marime posibila si nu la prima incarcare. Aici o sa fiu avocatul diavolului si o sa zic ca JS ajuta cu skeleton loadere, cu preincarea datelor in JSON si in cazul NextJS cu optimizarea automata a imaginilor trimise clientului de la server. Iti trebuie si un CDN ca sa nu iti puna cookie-urile pe imagini.
Daca chiar vrei sa ai un site instant/rapid, faci pre-fetching si cand apesi un buton incarci din local tot text content-ul si raman doar imaginile, care se pot incarca progresiv cum faci scroll. Mai mult, ai nevoie de optimistic UI, doar cele mai simple lucruri merg instant in viata reala.
Poti sa ai cel mai bun framework de JS, cum ai pus o imagine care nu e optimizata de server ai distrus tot avantajul dat de Astro/Qwik/Remix… O sa ai cu 0.5ms mai mult timp de incarcare din cauza a 500kb de JS.
am dat de acest lucru
Sper ca voi nu ati uitat ca paginile pot fi scrise direct in HTML unde Javascript-ul poate ocupa si 0 KB.
Atunci backend-ul trebuie sa randeze raspunsul dupa un template si ajungem inapoi la PHP si Ruby on Rails.
Și nu mai avem nevoie de FE engineers
sau jsf unde ai ssr inclus 
Am avut vreodata nevoie?
Inapoi? Asta e singura metoda sigura de a face lucrurile corect. Toata treaba asta de a genera paginile via Javascript e doar un gimmick care a generat o gramada de probleme de-a lungul anilor (si a dus la aparitia a gramada de solutii de care nimeni nu avea nevoie).
Internetul la inceput era o cerere pentru o resursa (de genul /index.html) si raspunsul continand acea resursa (codul HTML). Si nu s-a schimbat nimic de atunci. In continuare ceri unui server o resursa si ea poate fi un text simplu. Un fisier care deja exista pe acel server.
Nu stiu de ce am impresia ca unii din voi vor fi socati sa auda ca nu ai nevoie de 100 de bibilioteci Javascript ca sa trimiti niste text in format HTML.
Virtual scroll-ul e un motiv foarte bun, ce permite afisarea mult mai multor date, autocomplete, filtre, date in timp real.
Infinite scroll-ul, in special pe mobile.
Editoarele de text precum cel de pe forum.
In trecut paginile erau formulare, nu puteai sa faci scroll la pisici sau reddit până ti se descarca bateria.
Interfata XMLHttpRequest era disponibila din anii 2000 si din 2006 general implementata in mai toate browser-ele.
Pe partea de Javascript puteai manipula DOM-ul cu document.getElementById(); si document.createElement(); in 2006 foarte bine.
Cu vreo 2 - 3 oameni capabili si o arhitectura ierarhica sanatoasa puteai face pagini din PHP care apoi sa fie modificate via Javascript foarte bine inca dinainte de 2010 fara jQuery sau Angular/Vue/React.
Pe vremea aceea nu exista diferenta asta de backend developer/frontend developer, asa ca de HTML/CSS/Javascript se ocupa… programatorul. Acelas om care se ocupa de baza de date, de logica aplicatiei, de performanta, de mentenanta, de documentatie, etc.
Inseamna ca esti ca o cafea 3 in 1.