Non è una questione di pagina singola / multipagina, è una questione di organizzazione del codice sorgente
Esagerare un po ': è come chiedere se si dovrebbe avere un solo file sorgente, poiché il risultato è solo un eseguibile.
Come presentare la pagina al cliente (1 pagina con js / 4 pagine con collegamenti) è un problema di presentazione, che non dovrebbe interferire con il modo in cui organizzi il codice.
Il modo in cui mantieni i tuoi file sorgente dovrebbe essere determinato dalla facilità con cui i programmatori possono leggere, estendere, eseguire il debug.
E il modo in cui soddisfi questi bisogni è determinato dalle attività effettive a portata di mano e non necessariamente dal fatto che tu li presenti all'utente in una singola pagina.
Quindi, senza parlare dei dettagli del progetto, penso, non è facile rispondere alla tua domanda.
Come guida generale su come, imho, i modelli HTML dovrebbero essere strutturati, vorrei suggerire quanto segue:
-
Il layout generale della pagina dovrebbe essere strutturato per fornire una sorta di ereditarietà, in modo che possa facilmente creare nuove pagine con la stessa intestazione, colonne, piè di pagina, ecc., dove devono essere riempiti solo segnaposti.
-
ogni "widget" utilizzato dalla pagina dovrebbe essere un'unità funzionale, non dipendente dal suo ambiente. ad esempio, se hai tag, dovresti cambiare solo una posizione nella tua fonte se vuoi che tutti i tuoi tag siano messi in minuscolo
A seconda del tuo stack tecnologico, questi vincoli potrebbero già implicare una certa struttura di file: in Jinja2 (motore di python templating), l'ereditarietà generale del layout di pagina richiede file separati, in Rails, il rendering dei widget verrebbe realizzato tramite "parziali" ", che sarebbero anche file separati.
In genere, preferisco i file piccoli, ma è più una preferenza. Prima di eseguire l'overengineering, inizia semplicemente (ovvero un file) e non esitare a dividere, non appena inizia a diventare disordinato.