5 ms·

It’s worth nothing you can do server rendering to HTML with React, too.

mosselman 7y ago
It is, but I meant more in a 'traditional' way, so rendering with some templating engine whose abstractions aren't so far detached from HTML as they are with React. Mostly by mixing some dynamic parts into HTML rather than the other way around.
- danabramov 7y ago
  What kind of detachment are you referring to? React JSX has a few quirks but it maps pretty straightforwardly to DOM elements and HTML.
  - mosselman 7y ago
    A React application gets applied to a certain DOM element. Inside of that application are multiple layers of containing elements that handle things like routing or processing different events on existing DOM elements or triggered remote calls. If you add redux and something like redux-form you end up with sending each keyup event to the redux store and re-rendering your input fields from that store. So yes the JSX at the very bottom of your software tree is pretty much like HTML, but it takes a whole lot of engineering to get there and variables get pushed through many layers before they reach the final JSX in which they are rendered. Some of this has to do with how you implement your application, but in general getting from input to output takes more steps than it does with a server side rendering framework. This is fine when building something like a mobile application or an off-line-ready application like devdocs.io, but if you use a React application in front of some back-end you are just getting HTML in return for all your engineering efforts. If HTML with a few interactions is all you are after there is too much code and too many layers between the page that has your `<div id='myapp' />` and what you get after React is done rendering.
    - danabramov 7y ago
      Sure, I get that. What I'm saying is -- if you prefer to keep things simple and use server rendering, using server rendering alone with React (no routing, Redux, etc) is pretty much identical to using templates. You can treat React itself as a single-pass server template engine with component support. You don't have to bring all of this single-page app stuff into it. Hope that explains my point. You don't even have to run React on the client at all. I'm specifically talking about ReactDOMServer.renderToString() on the server and serving that HTML. Not "mounting into a <div>" client use case.
      - mosselman 7y ago
        Yes you are totally right. JSX in itself and the way you can nest React components, etc is very nice and could be great as a template engine. I should have said more clearly that I meant React et al. in the context of rendering everything on the client-side.
    - deleted 7y ago
      [deleted]
tannhaeuser 7y ago
> worth nothing (sic) Indeed. I mean who'd do that when there are plenty of server-side templating solutions that don't have to live by React's constraints (vdom/DOM diffing) only making things difficult? The only use case for React SSR seems quick first-page rendering and SEO.
- jjjmmm 7y ago
  what happens when you want some interactivity after the initial load? That's why you SSR React. If you used a serverside template then once the page loads, how do you deal with interactivity? jQuery? Plain JavaScript?
  - tannhaeuser 7y ago
    Yes why not? If you already decided your site is content-oriented by choosing server-side templating, then interactivity will be limited in scope and easily implemented using either vanilla js or jquery, or even basic HTML forms, links, and CSS menu tricks without js at all. In my experience, while I personally like React when it fits, I've seen too many projects that don't benefit from a MVw approach where React or Vue or another MVw framework seems like a decision by developers to pad their resume, or even by managers to win developers by giving them, like babies, something to play with and show off to their peer group when in reality the app is just a basic LOB application, like the old legacy app it replaces.

It is, but I meant more in a 'traditional' way, so rendering with some templating engine whose abstractions aren't so far detached from HTML as they are with React. Mostly by mixing some dynamic parts into HTML rather than the other way around.

danabramov 7y ago
What kind of detachment are you referring to? React JSX has a few quirks but it maps pretty straightforwardly to DOM elements and HTML.
- mosselman 7y ago
  A React application gets applied to a certain DOM element. Inside of that application are multiple layers of containing elements that handle things like routing or processing different events on existing DOM elements or triggered remote calls. If you add redux and something like redux-form you end up with sending each keyup event to the redux store and re-rendering your input fields from that store. So yes the JSX at the very bottom of your software tree is pretty much like HTML, but it takes a whole lot of engineering to get there and variables get pushed through many layers before they reach the final JSX in which they are rendered. Some of this has to do with how you implement your application, but in general getting from input to output takes more steps than it does with a server side rendering framework. This is fine when building something like a mobile application or an off-line-ready application like devdocs.io, but if you use a React application in front of some back-end you are just getting HTML in return for all your engineering efforts. If HTML with a few interactions is all you are after there is too much code and too many layers between the page that has your `<div id='myapp' />` and what you get after React is done rendering.
  - danabramov 7y ago
    Sure, I get that. What I'm saying is -- if you prefer to keep things simple and use server rendering, using server rendering alone with React (no routing, Redux, etc) is pretty much identical to using templates. You can treat React itself as a single-pass server template engine with component support. You don't have to bring all of this single-page app stuff into it. Hope that explains my point. You don't even have to run React on the client at all. I'm specifically talking about ReactDOMServer.renderToString() on the server and serving that HTML. Not "mounting into a <div>" client use case.
    - mosselman 7y ago
      Yes you are totally right. JSX in itself and the way you can nest React components, etc is very nice and could be great as a template engine. I should have said more clearly that I meant React et al. in the context of rendering everything on the client-side.
  - deleted 7y ago
    [deleted]

tannhaeuser 7y ago

> worth nothing (sic) Indeed. I mean who'd do that when there are plenty of server-side templating solutions that don't have to live by React's constraints (vdom/DOM diffing) only making things difficult? The only use case for React SSR seems quick first-page rendering and SEO.

jjjmmm 7y ago
what happens when you want some interactivity after the initial load? That's why you SSR React. If you used a serverside template then once the page loads, how do you deal with interactivity? jQuery? Plain JavaScript?
- tannhaeuser 7y ago
  Yes why not? If you already decided your site is content-oriented by choosing server-side templating, then interactivity will be limited in scope and easily implemented using either vanilla js or jquery, or even basic HTML forms, links, and CSS menu tricks without js at all. In my experience, while I personally like React when it fits, I've seen too many projects that don't benefit from a MVw approach where React or Vue or another MVw framework seems like a decision by developers to pad their resume, or even by managers to win developers by giving them, like babies, something to play with and show off to their peer group when in reality the app is just a basic LOB application, like the old legacy app it replaces.