4 ms·

What do people mean when they keep saying "server side rendering" in this specific Javascript/Node.js context? I ask because I've seen quite a few people tout t

What do people mean when they keep saying "server side rendering" in this specific Javascript/Node.js context? I ask because I've seen quite a few people tout that term as a recent innovation. It was my understanding that "server side rendering" was the way the web worked since the beginning, with the server generating the markup that is provided to the browser to render the page. Nobody called it "server side rendering" until we had "client side rendering", where Javascript executed in the browser provided the markup instead of whatever program was running on the server. I'm not trying to lecture or be snarky here; I'm genuinely confused as to what people mean when they say "server side rendering" as a new thing. Like, is there something novel that I'm missing because the term is overloaded with a definition I don't know?

amasad 9y ago
It means you take your client side JavaScript code and render it on the server for performance and SEO. Previously you had to either duplicate the code in different languages or pick one or the other (either use angular or rails).
- steveklabnik 9y ago
  Not just that, but to accomplish it means that you need to provide the correct client-side APIs on the server side, so that your code renders the same in both places. Doing this nicely is a lot of work.
- mbrock 9y ago
  Running the same language on the client and the server also has some deeper implications. Like, it becomes easy to imagine an app that runs in a hybrid way with computations shared between the client and server, i.e., "offline mode". This is a pretty big deal, and it's one of the major benefits mostly ignored by the vocal critics of "single-page apps," as seen in the latest article on the HN front page.
  - gaius 9y ago
    If you need "offline mode" why not just write a native app? It will be far better in every way - looks, performance, battery drain, you name it.
    - sova 9y ago
      Make a native app for every independent platform?
      - gaius 9y ago
        Windows, Linux, OSX - there just aren't that many platforms these days, it's perfectly do-able. If your core logic is in ANSI C (or equivalent) and you just need a GUI for each platform, even easier.
        mahyarm 9y ago
        It's still 3 more platforms, which means 3 more developers, which leads to more $$$. Not everyone is VC backed with multi-millions.
        gaius 9y ago
        But one of these "offline" apps has to work in Firefox, IE and Safari, so really, it's no different
        squeaky-clean 9y ago
        As long as you stick to the APIs implemented in each browser, your code can be exactly identical. Realistically, you'll probably need to add some polyfills and edge case handling for IE, but it's much less than developing for different full-on platforms.
        moosingin3space 9y ago
        With the major exception that all evergreen browsers (most browsers in wide use today) quickly officially support new web standards, but Windows, OS X, and Linux are unlikely to ever officially support each others' native toolkits.
djur 9y ago
They're referring to the ability to execute the same code on the client and server and get the same output, which can provide a great deal of flexibility when optimizing for performance.
dasmoth 9y ago
Potentially a better term is "isomorphic", a label which is specifically applied to setups where you run the same rendering code client-side and server-side. That's still a comparatively new concept, at least as something that's actively supported by frameworks and reasonably straightforward to implement.
- tree_of_item 9y ago
  That's an awful term because it has nothing to do with the actual meaning of the word "isomorphic".
  - dasmoth 9y ago
    I'm inclined to agree, but it seems to have stuck, and is at least more specific than "server side rendering".
  - badosu 9y ago
    Well, unless you're talking about a homomorphism with an inverse the term seems pretty good for me: the same (iso) shape (morphos) between server-side and client-side.
apparentlymart 9y ago
In this context, I think it usually means that the same rendering paths are available on both the client _and_ the server, whereas formerly it was often the case that the server was responsible for the bulk of the rendering and the client just made minor adjustments to the DOM in response to events. I agree that it's a bit of a misnomer, but I can see why people would call it that given the path we took to get here: first we rendered almost everything on the server, and then it became popular to render everything on the client, but now we're finding that a compromise is best, and that compromise is easiest to achieve when you have similar technology on both sides. ("We" in the above is intended to represent some vague idea of the web development community at large, not any particular individuals or groups.)
alayek 9y ago
I was confused with this initially as well. What I came to understand, was that "server-side rendering" refers to whole application lifecycle steps: - The server generates initial HTML markup, based on the request. - The browser can parse & render the already generated HTML (instead of waiting for the client-side JS to load first, then have it create / modify the DOM). - From that point onward, all changes in UI happen through client-side rendering. You could do this with Django template / JSP pages / Jade templates as well. Just write your templates, and some jQuery sprinkled here and there, to dictate how user interaction should change the page. But that's not all there is to it. We slowly took away SSR, with client side JS frameworks, like Backbone, Angular 1, Ember etc. Applications started to have client side routes, even with ugly hashbangs in the URLs. It was easier to write entire application logic of your UI in a client-side framework with two-way data bindings; than writing the server side in a template language, and put in some JS here & there to handle interactions. Especially, if your application was big enough. But this started having problems with SEO, and initial load times. Say, your app has a homepage URL, of the form https://company.tld/ https://company.tld/, and a products URL, of the form https://company.tld/products https://company.tld/products. If a user goes to homepage, and clicks on the "products" link in the navbar, the page content of /products route would load in the client side, via the framework. But, if a user directly hits the /products URL from their browser (can be from history and omnibox prompt), the browser would first load the home page with assets, then the client side JS would take over, and route the user to the /products URI endpoint. New server-side rendering paradigm gives you best of both worlds - get to maintain a single codebase to render your page (be it server or client), while give the initial fast loading, so that your page is interactive quite fast. This is not easy to do. One big challenge for most server side rendering solution is that, after initial render, the JS in the page would try to re-render the page; thereby creating an impression of a "flash". Yes, if you're using a framework like React or Vue, which uses VDOM, this won't happen in most cases, because of how a virtual DOM based renderer works. But there are still cases, where you might need to explicitly do something to prevent the re-render. There are other challenges too. For instance, having the page server-rendered, and hydrating the state. In the search of maintaining a single unifying codebase for both server and client (isomorphic rendering), we often do things that cannot work on server. For instance, chunk splitting your front-end bundle based on routes. Or CSS media queries. To sum it all up, "server-side rendering" isn't just about initially rendering the page on server. It's so much more than that. It's mostly about how we can maintain a single codebase (now that we have JS on server too), and run on two different platforms.

amasad 9y ago

It means you take your client side JavaScript code and render it on the server for performance and SEO. Previously you had to either duplicate the code in different languages or pick one or the other (either use angular or rails).

steveklabnik 9y ago
Not just that, but to accomplish it means that you need to provide the correct client-side APIs on the server side, so that your code renders the same in both places. Doing this nicely is a lot of work.
mbrock 9y ago
Running the same language on the client and the server also has some deeper implications. Like, it becomes easy to imagine an app that runs in a hybrid way with computations shared between the client and server, i.e., "offline mode". This is a pretty big deal, and it's one of the major benefits mostly ignored by the vocal critics of "single-page apps," as seen in the latest article on the HN front page.
- gaius 9y ago
  If you need "offline mode" why not just write a native app? It will be far better in every way - looks, performance, battery drain, you name it.
  - sova 9y ago
    Make a native app for every independent platform?
    - gaius 9y ago
      Windows, Linux, OSX - there just aren't that many platforms these days, it's perfectly do-able. If your core logic is in ANSI C (or equivalent) and you just need a GUI for each platform, even easier.
      - mahyarm 9y ago
        It's still 3 more platforms, which means 3 more developers, which leads to more $$$. Not everyone is VC backed with multi-millions.
        gaius 9y ago
        But one of these "offline" apps has to work in Firefox, IE and Safari, so really, it's no different
        squeaky-clean 9y ago
        As long as you stick to the APIs implemented in each browser, your code can be exactly identical. Realistically, you'll probably need to add some polyfills and edge case handling for IE, but it's much less than developing for different full-on platforms.
        moosingin3space 9y ago
        With the major exception that all evergreen browsers (most browsers in wide use today) quickly officially support new web standards, but Windows, OS X, and Linux are unlikely to ever officially support each others' native toolkits.

djur 9y ago

They're referring to the ability to execute the same code on the client and server and get the same output, which can provide a great deal of flexibility when optimizing for performance.

dasmoth 9y ago

Potentially a better term is "isomorphic", a label which is specifically applied to setups where you run the same rendering code client-side and server-side. That's still a comparatively new concept, at least as something that's actively supported by frameworks and reasonably straightforward to implement.

tree_of_item 9y ago
That's an awful term because it has nothing to do with the actual meaning of the word "isomorphic".
- dasmoth 9y ago
  I'm inclined to agree, but it seems to have stuck, and is at least more specific than "server side rendering".
- badosu 9y ago
  Well, unless you're talking about a homomorphism with an inverse the term seems pretty good for me: the same (iso) shape (morphos) between server-side and client-side.

apparentlymart 9y ago

In this context, I think it usually means that the same rendering paths are available on both the client _and_ the server, whereas formerly it was often the case that the server was responsible for the bulk of the rendering and the client just made minor adjustments to the DOM in response to events. I agree that it's a bit of a misnomer, but I can see why people would call it that given the path we took to get here: first we rendered almost everything on the server, and then it became popular to render everything on the client, but now we're finding that a compromise is best, and that compromise is easiest to achieve when you have similar technology on both sides. ("We" in the above is intended to represent some vague idea of the web development community at large, not any particular individuals or groups.)

alayek 9y ago

I was confused with this initially as well. What I came to understand, was that "server-side rendering" refers to whole application lifecycle steps: - The server generates initial HTML markup, based on the request. - The browser can parse & render the already generated HTML (instead of waiting for the client-side JS to load first, then have it create / modify the DOM). - From that point onward, all changes in UI happen through client-side rendering. You could do this with Django template / JSP pages / Jade templates as well. Just write your templates, and some jQuery sprinkled here and there, to dictate how user interaction should change the page. But that's not all there is to it. We slowly took away SSR, with client side JS frameworks, like Backbone, Angular 1, Ember etc. Applications started to have client side routes, even with ugly hashbangs in the URLs. It was easier to write entire application logic of your UI in a client-side framework with two-way data bindings; than writing the server side in a template language, and put in some JS here & there to handle interactions. Especially, if your application was big enough. But this started having problems with SEO, and initial load times. Say, your app has a homepage URL, of the form https://company.tld/ https://company.tld/, and a products URL, of the form https://company.tld/products https://company.tld/products. If a user goes to homepage, and clicks on the "products" link in the navbar, the page content of /products route would load in the client side, via the framework. But, if a user directly hits the /products URL from their browser (can be from history and omnibox prompt), the browser would first load the home page with assets, then the client side JS would take over, and route the user to the /products URI endpoint. New server-side rendering paradigm gives you best of both worlds - get to maintain a single codebase to render your page (be it server or client), while give the initial fast loading, so that your page is interactive quite fast. This is not easy to do. One big challenge for most server side rendering solution is that, after initial render, the JS in the page would try to re-render the page; thereby creating an impression of a "flash". Yes, if you're using a framework like React or Vue, which uses VDOM, this won't happen in most cases, because of how a virtual DOM based renderer works. But there are still cases, where you might need to explicitly do something to prevent the re-render. There are other challenges too. For instance, having the page server-rendered, and hydrating the state. In the search of maintaining a single unifying codebase for both server and client (isomorphic rendering), we often do things that cannot work on server. For instance, chunk splitting your front-end bundle based on routes. Or CSS media queries. To sum it all up, "server-side rendering" isn't just about initially rendering the page on server. It's so much more than that. It's mostly about how we can maintain a single codebase (now that we have JS on server too), and run on two different platforms.