Ne întoarcem la începuturi? Oare faptul că server-side rendering ar pune mai puțină presiune pe terminalul clientului este specificat în articol? Sau că ar determina costuri mai mari pentru servere?
Depinde foarte mult ce vrei sa faci cu aplicatia aia si peste ce librarie vrei sa implementezi SSR, daca nu ai ceva deja implementat intr-un framework sau nu incepi tu de la 0 proiectul iti urez bafta, eu am implementat peste un proiect deja scris in React care consuma 2 api-uri unul REST si unul graphql, iti zic sincer ca nu m-am mai enervat atat de mult de FFFFF mult timp.
In primul rand niciodata n-a zis nimeni ca trebuie sa folosesti altceva decat o pagina statica pentru un site de prezentare. Problema e ca editorul site-ului static va fi dinamic sau tot apare ceva element dinamic pe pagina statica (comentarii/evaluari/feedback/pret), aceste lucruri iti cer randare pe client:
Ca sa te deosebesti sau sa tii pasul cu concurenta trebuie sa ai o interfata in timp real, altfel cred ca putem fi de acord si ca forumul acesta folosea phpbb in loc de Discourse daca nu conta. Practic nu numai argumentele tehnice conteaza ci si ce ofera utilizatorului solutia aleasa.
Dupa cum zice si foobaz256 randarea interfetei se poate realiza si combinat, o parte pe server, o parte pe client, ceea ce e cea mai buna solutie in opinia mea. Problema e ca acest lucru implica ca solutia sa se realizeze in acelasi limbaj de programare si pe front-end si pe back-end ca sa nu ai deaface cu cod pe server si cod pe client cand vine vorba de randare. (isomorphic rendering)
Putem iesi din acest pattern si mai bine: Ce se intampla cand HTML nu mai este destul ? Oare tot iti permiti sa randezi inainte un site 3d in VR pe server in loc sa trimiti doar texturile si modelele ? (teoretic ai putea trimite imagini 360/video 360 in loc de continut randat de client, dar e scump de randat pe server si calitatea nu e aceeasi ca la randare nativa)
Inca o problema pentru SSR: Ce faci cand pentru a randa pe server un view ai deaface cu multe resurse care se incarca asincron (de exemplu ai date in baze de date din mai multe locatii) ? Nu mai bine incarci pe client resursele asincron decat sa astepti dupa fiecare resursa pe server si cand toate s-au incarcat sa raspunzi clientului ?