Păi jQuery nu a promis nimic altceva în afară de o uniformizare a API-urilor. Adică XMLHttpRequest era disponibil, dar în IE era într-un ActiveX:
if (window.XMLHttpRequest)
http = new XMLHttpRequest();
else
http = new ActiveXObject("Microsoft.XMLHTTP");
getElementById mergea OK dar în unele browsere, dar în IE era quirky șamd.
Da doar ca s-a descoperit ca este mai eficient sa ceri o resursa mai mica in loc sa refaci toata pagina, doar ca apoi intri in state management si asa ajungi la framework-uri
Corect. Single-Page Applications sunt foarte misto. Dar nici de o aplicatie clasica nu mi-e rusine cand fiecare pagina se incarca in 50 de milisecunde.
Din pacate SPA-urile dau deseori gresi. Cum e aplicatia de la Glovo si oricare nu stie ce sa faca daca un apel AJAX esuaza.
Dupa un anumit nivel trebuie sa te gandesti si la cost.
Uiti de faptul ca front-end-ul poate fi integral cache-uit (vezi Google Sheets/Documents/Devforum/Fb), doar prima incarcare iti incarca JS-ul de pe server, dupa iti ramane in browser.
Dupa daca nu ai internet iti scrie ca nu ai internet, iti poate afisa ceva si din datele locale, iti poate tine un draft ca daca dai submit cand nu ai internet sa nu pierzi datele.
Daca luam un milion de utilizatori care descarca clientul o data si dupa fac request-uri dupa JSON-uri vezi ca ai economii uriase. Practic trimiti doar JSON-urile in loc de tot XML-ul cu structura pentru design. Imaginile se pot descarca inteligent in functie de rezolutie, de pozitia la scroll. Nici nu trebuie sa folosesti JSON, poti folosi protocol buffers sau orice altceva.
Anumite lucruri se pot realiza doar cu SPA-uri, colaborarea in timp real de exemplu e un motiv foarte bun.
Autentificarea se poate decupla, token-ul se poate seta pe client care dupa se poate conecta la N servicii. Serverul poate verifica doar daca token-ul a fost semnat de server si sa creada tot ce scrie in el fara sa mai cheme un serviciu de autentificare, cu un cookie tot verifici cookie-ul in baza de date/sesiuni.
cu accent pe primul cuvanr
Da, stim, e in regula. Doar ca SPA-urile inseamna ca ai doua proiecte de gestionat: un API si un frontend.
Oricum ce ziceam e ca pentru unele lucruri nu ai nevoie de o arhitectura back/front separata. Si e mai ieftin ca numar de programatori.
Adevarat, si eu aveam problema asta cu Front End in React si Backend in Laravel.
Avea doua proiecte csre trebuia sa le administrez/dezvolt separat, mereu sa inregistrez ruta in react route pentru pagina de pe front end si dupa o ruta pentru api - faceam acelasi lucru de doua ori si devenise obositor ( mai erau si alte lucruri , cu verificarile front end si back end )
Dupa am descoperit InertiaJS si am renuntat la ideea de a avea front end si back end separat ca si proiecet. Se ocupa inertia de routing si erori si page props si de disponbilitatea rutelor si am totul sub acelasi proiect.
Nu cred ca nu e necesar ci ca e mai bine in aproape toate cazurile sa ai pe cineva dedicat pe domeniu.
Cineva care stie sa lucreze cu baza de date si domain modelul aplicatiei (un back-end) developer in 90% din cauzuri isi masoara front-end-ul cu rigla. Iar cuiva caruia ii place sa lucreze la design/front-end se uita ciudat la tine daca ii zici de domain model, Dto-uri, TDD, left join, right join, normalizare, controllere, servicii…
Sunt doua tipuri de gandire separate, am avut experienta sa lucrez cu MongoDB si front-end team si era vai si amar de baza de date. Aveam atatea date duplicate incat testam sa vedem care date sunt corecte.
Dupa am avut back-end pe front-end si in loc sa gandeasca cum o sa fie randata pagina a fortat totul cu calc…
E foarte rar ca la cineva de exemplu sa ii pese de UI/UX si dupa sa stea cu diagrame la domain model, se gandeste la entitati si abstractizarea lor, endpoint-uri si sa optimizeze query-urile de SQL. Daca taiem partea de endpoint tot nu se schimba asa multe, o sa ai model si controller-ul, doar ca e local.
Poti sa ai un backend developer la 30 euro pe ora si un frontend developer tot la 30 de euro pe ora sau poti sa ai un dezvoltator obisnuit la 45 de euro pe ora care face 90% din ce ai nevoie.
Sigur, in cazul ideal ai toti oamenii de care ai nevoie care stiu fix partea lor, dar cat de des firmele isi permit?
In anii 2000 isi faceau fetele site-uri pe Geocities si Hi5 despre Sailor Moon si Backstreet Boys si erau absolut ok. De ce acuma poti face o pagina doar daca ai 10 oameni?
Si mie imi place sa am un serviciu stabil si platit bine, dar sa fim seriosi. Multe servicii functioneaza perfect cu o interfata minimala care iti arata facturile intr-un <table> cu un buton de plata.
Ce zice @RedGuard este că nu este nevoie de framework-uri chiar la fiecare proiect (ceea ce, realist vorbind, este chiar foarte adevărat)
Ce înțelegeți majoritate este că @RedGuard zice că JS e bau bau și că nu trebuie folosit.
Ce mai ingrijoreaza mai mult e ca daca eu zic “JS trebuie ocolit” foarte multa lume se aprinde. Ceea ce ma face sa cred ca multa lume aici stie doar Javascript.
Daca mie imi zice cineva “PHP trebuie ocolit” eu zic: “Cool, ce vrei sa folosim?”. Pentru un dezvoltator tehnologia e doar o unealta. Oricand poti folosi altceva potrivit situatiei. Si cei care se supara tind sa cred ca nu pot folosi alta tehnologie. Ceea ce e trist.
Cu diferența că JS nu poate fi înlocuit cu altceva[1] - cel puțin nu în browser. 
excludem limbajele care compilează în JS (typescript, dart etc) și asm & co. ↩︎
Am mai mentionat, e vorba de $$.
Se face mult tracking, la Fb fiecare click, scroll pe care il faci e inregistrat pe server. Daca tii cursor-ul pe o poza iti masoara cat timp l-ai tinut acolo…
Chiar si site-urile simple, vezi de exemplu Medium au un sistem de subscribers, au tracking.
mhm, poate nu de atat de multi, dar totusi 
http://scjuc.ro/
am auzit odata ca multi ingineri pot fi developeri, dar putini developeri pot fi si ingineri si n-am repetat-o niciodata cu voce tare (ca si QA), desi as fi vrut uneori :))
Nu stiu de altii, dar eu am lucrat in mai multe limbaje de programare. Am scris si o gramada de HTML si CSS, mai scriu si astazi.
Nu stiu asta ce ma face. Eu ma consider un programator obisnuit, ba chiar mediocru. La o adica inteleg cum e codificat un jpg sau un fisier FLAC, am citit despre Radix Sort, am lucrat cu numere complexe, am facut niste joculete (adica am folosit concepte din geometrie). Nu mi se pare ca am facut ceva deosebit vreodata.
A man of culture. Uite cine are experiență 
Și coșmaruri. Nu uita de coșmaruri.
Eu am dat peste ceva cod vechi scris in NodeJS acum 8 ani de mine fara promises sau asnc/await.
Citesc codul de 2 ori si vad vreo 10 probleme, plus nu inteleg cum puteau oamenii sa se chinuie in asa hal cu callback-urile.
La fel si pe front-end, aveai XMLHttpRequest, dar e cu callback-uri, ceea ce inseamna ca e foarte dificil de legat bine.
Nu prea inteleg ce e asa de complicat. Trimiti o cerere catre un server si raspunsul il procesezi intr-o functie.
Am niste proiecte in vechiul Angular. Cam asa arata codul:
var promise = $AuthService.checkEmail($scope.credentials.email);
promise.then(function(responseDate)
{
if (responseDate.data.response == false)
{
$scope.canLogin = false;
$scope.canRegister = true;
$scope.checkPasswords();
}
else
{
$scope.canLogin = true;
$scope.canRegister = false;
$scope.errorMsg = false;
}
Adica tot o functie care proceseaza raspunsul. Pe de alta parte avem la servici niste proiecte in noul Angular. Acolo orice apel e cu await despre care am inteles ca dezactiveaza comportamentul asincron al apelului si executia se opreste pana vine raspunsul de la server. Ceea ce puteai face si cu XMLHttpRequest().
Nu aveai .then, adica au aparut ceva librarii precum Blackbird, deferred, dar nu inainte ca Angular sa existe. Angular 1.0 e nava spatiala pe langa ce aveai vanilla.
jQuery 1.5 a fost lansat in ~2011 cand au introdus jQuery.Deferred() | jQuery API Documentation
Pe node daca vroiai sa combini datele de la mai multe query-uri sql trebuia sa faci ori o tranzactie, ori
query1(query2(query3(altcevaasinc(facevacudatele())))) + cb-uri de error la fiecare.