Ciao, e benvenuto nella quinta puntata della settantottesima stagione. La volta scorsa, l'idratazione: ri-eseguire, far combaciare, adottare, la pagina pensata due volte. Oggi la puntata più onesta della stagione: cosa ti costa davvero quel raddoppio, e quali errori genera. È la disillusione più importante della stagione: il rendering lato server non è gratis, e l'idratazione è dove paghi. Il titolo lo dice: hai pagato due volte.
Costo uno: spedisci e fai girare le istruzioni comunque. La promessa seducente del rendering lato server è il primo sguardo veloce. Vero. Ma molti sentono: quindi non mi serve la scatola grossa di istruzioni. Falso. Per idratare, il client deve ri-eseguire i tuoi componenti, quindi devi spedire praticamente tutte le istruzioni dell'applicazione, scaricarle, analizzarle ed eseguirle, esattamente come nel rendering al tavolo puro. La scatola è grossa uguale, e chi guarda deve comunque ripercorrere tutta la ricetta per apparecchiare il servizio. Non hai evitato il lavoro del tavolo: ci hai aggiunto sopra il lavoro della cucina.
Costo due: l'interattività può arrivare perfino più tardi. Ecco la stilettata che sorprende. Il rendering del server deve avvenire per primo, e deve spedire più byte, l'HTML completo più i dati più le istruzioni, e solo dopo può girare l'idratazione: così il momento in cui la pagina diventa usabile può essere più tardi che nel rendering al tavolo puro, per una pagina pesante. Hai barattato un sembra finito più veloce con un funziona davvero forse più lento. Chi guarda vede il piatto prima ma aspetta più a lungo le posate. È la terra di mezzo della terza puntata, ora con un cartellino del prezzo.
Costo tre: l'errore di mancata combaciata. L'adozione ha bisogno che i due combacino. Quando non combaciano, quando il server ha cucinato qualcosa che il client non avrebbe cucinato, il metodo trova il piatto diverso da come se lo aspettava e deve arrangiarsi: nel caso peggiore butta via il lavoro del server e ricostruisce, proprio il lampo che volevamo evitare, oppure rattoppa e lascia una stortura sottile. E sono facili da causare per sbaglio: tutto ciò che è diverso tra server e browser, un orario reso come adesso, un valore a caso, qualcosa che legge la dimensione della finestra, contenuto che dipende dalla lingua o dal fuso di chi guarda, fa andare i due in disaccordo. La regola: durante quel primo rendering, server e client devono produrre la stessa cosa, cioè niente adesso, niente casualità, niente fatti che esistono solo nel browser, finché l'idratazione non è finita. Un'intera famiglia di errori del rendering lato server è questo: hai lasciato che le due cucine cucinassero diverso.
Costo quattro: il codice vive in due mondi. Più in sordina, il tuo codice dei componenti fa una doppia vita: gira sul server, dove non c'è la finestra né le funzioni del browser ma c'è vicinanza ai segreti e ai dati, e gira nel browser, dove non ci sono i segreti del server ma c'è pieno accesso alla pagina. Il codice che dà per scontato un mondo si rompe nell'altro. Scrivi per due ambienti insieme, e le cuciture tra loro sono una fonte costante di complessità.
E adesso il conto onesto, perché è questa la puntata. Cosa compra e cosa costa davvero il rendering lato server con l'idratazione. Compra: un primo sguardo veloce, completo e trovabile. Costa: tutte le istruzioni spedite e fatte girare comunque, un tempo all'interattività forse più tardi, una famiglia di errori di combaciata, un server che rende a ogni richiesta, e codice che deve funzionare in due mondi. Non è il tavolo ma meglio: è un baratto diverso. Paghi più lavoro totale, in cambio del primo sguardo che arriva presto. Per una pagina di contenuto a cui si dà un'occhiata, è un affare. Per un'applicazione pesante dietro un accesso, che nessuno deve trovare, può essere puro costo. Nessuno dei due è sbagliato; è sbagliato credere che sia gratis.
E il ritornello, reso concreto: è lo sposti il lavoro, e a volte lo paghi due volte, per intero. Il rendering avviene due volte, server e poi client; i dati viaggiano due volte, la prossima puntata; e i byte sul filo sono più grandi, non più piccoli. Tutto il resto della stagione è una collezione di tecniche per riprenderti il secondo pagamento: fare meno lavoro due volte.
Voglio lasciarti con l'onestà che ti risparmia le delusioni. Il rendering lato server non è gratis, e l'idratazione è dove paghi. Spedisci e fai girare le istruzioni comunque; l'interattività può arrivare perfino più tardi; nasce una famiglia di errori di combaciata; e il tuo codice deve vivere in due mondi. In cambio ottieni una cosa sola, ma preziosa quando serve: un primo sguardo veloce, completo e trovabile. Perciò non chiederti se usare il rendering lato server, chiediti se quel primo sguardo vale, per questa pagina, tutto ciò che costa. Quando la risposta è sì, paghi volentieri; quando è no, stai solo pagando due volte per niente.
Per oggi ci fermiamo qui. Abbiamo messo in fila i costi onesti dell'idratazione: le istruzioni spedite e fatte girare comunque; l'interattività che può arrivare più tardi; l'errore di mancata combaciata, con la regola di far produrre a server e client la stessa cosa; e il codice che vive in due mondi. E il conto: il rendering lato server compra un primo sguardo, e lo paga in lavoro doppio. Nella prossima puntata: la ricetta sotto il piatto. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.