[gegtik]

classic SPA: (client request) -> (retrieve empty divs + js) -> (js kicks off) -> (API results used to fill initial page content) -> (further page interaction calls APIs to mutate client side page)

SSR: (client request) -> (server retrieves empty divs + js, API results used to fill initial page content) -> (fully rendered first page view + js delivered to client) -> (further page interaction calls APIs to mutate client side page)

[z3t4]

this sounds great, but isnt the point of a js web app that the data resides or are cached on the client !? Making it possible to use offline. And have real time push via websocket when online !? Server side rendering frameworks are as old as it gets.

[recursive]

The point of a js web app is that you can run it in a web browser. Hammers and nails are even older than server side rendering, yet somehow they still function perfectly.

[z3t4]

There are advantages to not coupling the client and the server. Like for example e-mail and IRC-chat. You can have a browser client, but also a native mobile app client, bot running against the same server API. Decoupled software almost always means more productivity.

Hammers and nails equivalent is cgi/perl/php/asp and they still do a fine job. You can use the screw machine to manually punch down screws, but then why not use the hammer and nails instead, as you do not see the advantage of the screw machine.

[agmcleod]

Yeah those would just be separate endpoints/requests. text/html vs application/json. Instead of serving a static html file that bootstraps your react app, you're serving a rendered component.

Not really any different from building say a PHP app that serves an API to a mobile app.

[z3t4]

If the user has JavaScript turned off, the whole point of a JavaScript app is lost. You could just render all the HTML on the server like a PHP app, witch would also make Reac pointless.