Entrambe le soluzioni sono valide, semplicemente non si applicano agli stessi casi d'uso.
a) manipola il DOM tramite JavaScript: questo porta a una prima pagina più pesante, ma dopo userai meno larghezza di banda, perché recupererai solo ciò di cui hai bisogno e non ricostruirai e invierai tutto. E nei casi in cui non hai bisogno di recuperare nulla, sarà molto veloce (pre-validazione di un modulo per esempio).
b) Questo è il vecchio modo tradizionale di fare applicazioni web. È ancora valido un modo valido per fare siti web, diamo solo un'occhiata al motivo per cui la maggior parte delle persone sta cambiando la propria strada.
Fare roba lato client consente un rendering più veloce quando l'utente fa un input. Riduce anche le risorse necessarie al server. E infine, recuperando i dati solo su un servizio web, fornisci qualcosa che potrebbe essere riusabile da altri sistemi. Ecco perché queste soluzioni stanno diventando sempre più popolari.
Ha un costo, non tutto può essere fatto sul client (validazione / sicurezza) e spesso hai bisogno di gestire diverse tecnologie e interfacce più numerose.
Vorrei solo aggiungere che non devi fare tutto con una soluzione o un'altra, puoi mescolare entrambi gli approcci, su alcuni eventi che manipolano il DOM, su qualche altro ricaricando la pagina.
EDIT: Poiché la larghezza di banda sembra essere una preoccupazione molto strong, è possibile perdere parte della reattività dell'utente caricando il codice JS solo quando necessario con la soluzione a. Vedi questo esempio di caricamento lazy in JS Probabilmente il design più efficiente se consideri principalmente / solo che aspetto.