La semplicità di utilizzo è uno dei punti di forza di JQuery, ma come abbiamo detto ciò comporta spesso la perdita del controllo dell'architettura dell'applicazione che rischia di trasformarsi in un connubio inscindibile e ingestibile di codice e presentazione mescolate.
Questo problema viene affrontato con estrema efficacia da AngularJS, il framework creato da Google per lo sviluppo di applicazioni Web.
AngularJS sfrutta a fondo il paradigma Model View Controller (MVC): a differenza di JQuery, l'interfaccia utente (la vista) è totalmente separata dal modello (l'oggetto che contiene i dati da rappresentare) e anche dalla business logic (la logica applicativa, implementata attraverso servizi) mentre il Controller fa da "collante" tra tutti questi elementi gestendo l'input dell'utente e modificando il modello dei dati, tramite la logica di business, che comporta l'aggiornamento dinamico della vista HTML.
I problemi legati all'architettura dell'applicazione che si riscontrano con JQuery vengono così a scomparire con AngularJS, che consente di suddividere tutti i componenti dell'applicazione (viste, controller, servizi, ecc.) in moduli separati; tramite poi l'uso estremizzato del data binding e lo sfruttamento della dependency injection, il framework consente di rendere la quasi totalità del codice testabile usando i framework di Unit/Integration Testing più diffusi.
Queste possibilità non sono però fornite a "costo zero": la curva di apprendimento di AngularJS è altalenante. Alcune funzionalità anche complesse si possono ottenere facilmente su progetti piccoli, ma al crescere della complessità è necessario che l'intero team di sviluppo che lavora al progetto sia dotato delle conoscenze necessarie per implementare ciò che serve, seguendo precisi dettami che consentano di integrare gli elementi dell'applicazione con l'infrastruttura fornita da AngularJS, pena la rinuncia ai vantaggi che il framework è in grado di garantire.
L'obiettivo che React si pone è del tutto identico a quello di AngularJS: slegare lo sviluppatore dalla necessità di gestire direttamente il DOM.
Tuttavia React si concentra sulla parte visuale dell'applicazione suddividendola in blocchi (componenti) che contengono il proprio stato e la propria logica di gestione, mentre la comunicazione con il server o la strutturazione dei moduli sono demandati a librerie esterne. AngularJS invece, oltre alla gestione dell'UI, include anche servizi per la gestione degli aspetti architetturali dell'applicazione, la comunicazione tramite AJAX e il consumo di servizi REST.
AngularJS è una soluzione più completa, a discapito di una complessità maggiore di apprendimento e uso, laddove React si presenta più focalizzato e accessibile all'apprendimento, con la possibilità di ricorrere a librerie note (es. anche la stessa JQuery) per le parti che non sono strettamente legate all'interfaccia utente.
La contestazione maggiore che viene mossa a React da parte degli sviluppatori AngularJS è quella di mescolare logica di gestione degli eventi alla presentazione, riducendo quindi la separazione delle responsabilità degli elementi del progetto. Questo approccio viene giustificato da React con il criterio della “Separation of Concerns” a discapito della “Separation of Responsibility”: in termini pratici, con React si tende a isolare codice e lo stato dei componenti in base al loro ambito di utilizzo, rendendoli il più possibile autonomi e riutilizzabili in un medesimo contesto, piuttosto che estremizzare la separazione della parte di presentazione e del codice che la governa.
In un certo senso, i componenti React possono essere visti come i “building block” che si ottengono in AngularJS tramite le direttive, che includono allo stesso tempo sia presentazione (markup) che codice, ma grazie alla sintassi JSX che vedremo, scrivere il markup dei componenti React è un'operazione molto più semplice.