Se usi i WebForm di ASP.NET, ci sono in effetti un paio di aspetti che allargheranno il tuo HTML. Possono essere mitigati in una certa misura, alcuni più facilmente di altri, e sono stati apportati miglioramenti in particolare in .NET 4.0.

• Come dici tu, c'è l'elemento __VIEWSTATE nascosto che WebForms usa per mantenere l'illusione di stato. Questa opzione è attivata per impostazione predefinita e, se non la si tocca, può facilmente aggiungere un sacco di peso non necessario a una pagina con molti controlli. Se in realtà non lo stai utilizzando, puoi disattivarlo su una pagina o su un controllo con EnableViewState="False" .
• Se utilizzi i controlli Web Form più potenti, puoi fare uno sviluppo piuttosto rapido, ma puoi anche generare un sacco di HTML generato che non è realmente sotto il tuo controllo e potrebbe essere molto più grande del necessario per il sottoinsieme di funzionalità di cui hai bisogno. Nei miei giorni di Web Form, ho scoperto che molti sviluppatori (me compreso) evitavano i controlli più potenti perché sembrava sempre che ti avessero fatto risparmiare tempo all'inizio, ma alla fine ti sono costati più tempo dopo, come hai combattuto con per ottenere il risultato preciso di cui avevi bisogno.
• Se architetti le tue pagine in modo facile da gestire, con pagine master, pagine e vari controlli utente, scoprirai che la manipolazione dei nomi degli ID di Web Form (per garantire univocità) porterà ad alcuni ID piuttosto lunghi su elementi HTML, cose come id="ctl00_AGSMasthead_imgSkipContent" . Questo è stato migliorato in .NET 4.0 - puoi usare la nuova proprietà ClientIDMode="Static" per dire a Web Forms che non ha bisogno di manipolare l'ID, manterrai l'unicità da solo.
• Poiché Web Form utilizza l'ID di un controllo per fare riferimento a quel controllo nel codice lato server e come ID dell'elemento nell'HTML reso, spesso porta a te avere un sacco di Elementi HTML con ID che non vengono mai utilizzati lato client da CSS o JavaScript e sono solo uno spazio sprecato. A proposito, questo è uno dei miei difetti di Web Form. Fai qualcosa come <asp:Label Id="lblName" Runat="Server"/> in modo da poter popolare un'etichetta nel code-behind, e viene pubblicata come <span id="lblName"> - o in passato, più probabilmente, qualcosa come <span id="ctl00_ucHeader_lblName"> . Quindi non necessario, personalmente vorrei che invece dell'attributo Runat="Server" , avessero progettato qualcosa sulla falsariga di ServerID="lblName" che entrambi identificavano un controllo come lato server e assegnato un ID lato server che era separato dall'ID lato client (se presente).

In definitiva, è possibile aggirare la maggior parte di ciò in una certa misura, ma se si utilizza Web Forms nel modo in cui è progettato per essere utilizzato, sarà ottenuto un po 'di peso aggiunto all'HTML servi che non è strettamente necessario.

Tuttavia, penso che la differenza di peso tra una pagina Web Form e una pagina prodotta da qualche altra piattaforma e framework sia probabilmente inferiore alla differenza tra una pagina mal codificata e una ben codificata che faccia buon uso della semantica pulita markup, riduce al minimo tag e attributi non necessari, utilizza JavaScript discreto e pulito, ecc.

ASP.NET come hai indicato usa il ViewState. Prima di tutto spiegherò brevemente lo scopo del ViewState e il motivo per cui è lì.

Che cos'è il ViewState

In breve, lo scopo di ViewState è di preservare il valore dei campi del modulo tra i postback. Da quella dichiarazione, puoi dedurre che più campi hai, più grande sarà il tuo ViewState.

Oltre a preservare il valore dei campi modulo tra i postback, puoi anche archiviare dati arbitrari all'interno di ViewState, utilizzando ViewState[key] = value .

Tuttavia, è possibile disabilitare ViewState, a livello di pagina o livello di elemento in cui non è appropriato utilizzarlo. Questo può anche risparmiare spazio nel ViewState.

Come

Il ViewState è memorizzato come elemento del modulo nascosto che viene pubblicato sul server quando si invia la pagina. Il seguente diagramma mostra i punti chiave nell'elaborazione di ViewState:

asp.net viewstate http://i.msdn.microsoft.com/dynimg/IC152667.gif

I punti chiave qui sono LoadViewState e SaveViewState . LoadViewState carica i dati inviati al server, dove SaveViewState lo serializza per la memorizzazione nel ViewState dopo che gli eventi della pagina sono stati elaborati.

vantaggi

Il vantaggio principale dell'utilizzo di ViewState è la persistenza dei dati tra i carichi di pagina. Ad esempio, quando la pagina viene caricata per la prima volta, i campi possono essere compilati con i risultati, ad esempio, di una query di database con esecuzione prolungata. Carichi successivi possono utilizzare i valori nel ViewState per salvare la riesecuzione di tale query.

Relazione con ASP.NET MVC

ViewState non è affatto pertinente per ASP.NET MVC ed è un componente di Web Form di ASP.NET.

Equivalente in PHP?

Non esiste un equivalente in PHP. Potresti implementare manualmente la funzionalità se lo desideri, serializzando ad esempio il tuo modello e ricaricandolo su POST.

Devi usare ViewState

No, non lo fai. Se la disattivi, la dimensione dell'output della pagina diminuirà, ma dovrai anche tenere conto del sovraccarico dovuto al ricaricamento dei dati.

TL; DR e alla domanda

La differenza tra la dimensione delle pagine PHP e l'HTML generato delle pagine ASP.NET sarà drammatica? . La risposta è dipende da ciò che stai emettendo. Se stai realizzando moduli di grandi dimensioni e in particolare se stai facendo uso di controlli come Asp: DataTable allora sì, il tuo output potrebbe essere notevolmente più grande. Ho visto ViewState crescere oltre 1mb. È necessario tenere a mente che su ogni invio, l'intero ViewState deve essere caricato sul server web. Se stai producendo moduli piccoli e semplici, la differenza di dimensioni sarà trascurabile. YMMV a seconda di cosa si sta facendo esattamente.

L'altra cosa da tenere a mente è che in PHP hai molto più controllo sul markup generato rispetto a quello che fai con WebForms.