3 ms·

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

by gegtik 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        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.

by gegtik 10y ago

z3t4 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.