7 ms·

Having the same language allows to share some code between frontend and backend. This can be used to prerender your SPA on the server, for example, or to share

Having the same language allows to share some code between frontend and backend. This can be used to prerender your SPA on the server, for example, or to share some logic with the client to enable offline usage.

lloeki 8y ago
Being able to share code is really not that great because you don't share that much code between front and back in reality. Being able to share the paradigms, structure, mindset and tooling (like linters, formatters, code generators, packagers, whatever..) is what's awesome. You remove a whole lot of context switches and cognitive dissonance, smoothing the train of thought which greatly eases the expression of ideas. Source: used quite a bunch of golang + gopherjs, ruby + opal, js + node
- jonny_eh 8y ago
  > you don't share that much code between front and back in reality Good luck rendering React server-side in Go or Ruby.
  - repsilat 8y ago
    I've never looked into server-side react, can you explain a bit about the requirements? Does the server keep a lot of session data around to maintain a shadow DOM for each connected client? How far is it in practice on the continuum between a fancy templating language and a full app framework? Does anyone put server-side React on server-side Redux? Whatever the case, if people write clients in react to talk to Ruby backends, can't they do the same to get "server-side react clients" that run in front of their backend app? Or does that go against the programming model somehow? Would it enforce too much of a barrier between "the view" and the model than is traditional these days?
    - acemarke 8y ago
      While I haven't done SSR myself, my understanding of the general process is that it's about rendering that first initial page that's sent to the browser. This is most beneficial for speed of initial load and SEO purposes. An SSR React app that uses Redux would probably create a unique Redux store instance for each new client, dispatch just enough actions to fill in whatever data is needed for the initial render, and then serialize the Redux store state to the host HTML page so that it can be used to re-hydrate the Redux store on the client. For more info, see the "React Server Rendering" [0] section of my React/Redux links list, and the "Server Rendering" recipe [1] in the Redux docs. [0] https://github.com/markerikson/react-redux-links/blob/master/react-server-rendering.md https://github.com/markerikson/react-redux-links/blob/master... [1] https://redux.js.org/recipes/server-rendering https://redux.js.org/recipes/server-rendering
  - lloeki 8y ago
    Turns out not every application needs, let alone require React.
- repsilat 8y ago
  Depends a great deal on what the application is, I think. If you're doing heavy lifting (or anything a bit complicated) in the client and then need to make similar functionality available to APIs offline it's a godsend. My current hobby project is a kind of REPL/programming language that does all of its compute in the client, and being able to hit a button and export a "serverless" microservice is lovely side-effect of being able to run JS on the server. It isn't exactly "the backend" to my application, more "a headless client exposed to the net," though, I guess. (As someone new to JS, the frigging Node ".mjs" fiasco almost derailed the whole thing, though... What were they thinking?) Edit: oh, and "optimistic rendering" is also a big win -- if you can show the result of an action before it has persisted (or preview it before the user has done it) shared code can also come in handy. Though perhaps we're too scared of network round-trip times.
  - Scarbutt 8y ago
    fiasco? isn't '.mjs' still the path forward for them?
    - repsilat 8y ago
      Maybe it is for them, but `node -r esm` is what I'm going to do for now. I'll probably start webpacking the backend soon instead, but I'm sure as hell not going to rename every single file in my codebase.
- kybernetikos 8y ago
  I'm working with a system that lets you develop code in the client, then gradually move it further back in the stack as needed. It's incredibly useful for testing.
- davedx 8y ago
  It depends. I was working on a websockets based game using node.js on the backend and React, redux & canvas on the front end. As my game grew, more and more code went into the /shared/ folder. It's extremely useful to be able to mirror the game logic that's run on the server for security in the front end for convenience and performance (avoid waiting for round trips for everything). For example, I had a standard RPG style combat system. Being able to share all of the code that does calculations for combat allows you to put those calculations into the UI as much as you want. I think standard CRUD web apps are different because there's much more asymmetry in the responsibilities of the back end and front end.

lloeki 8y ago

Being able to share code is really not that great because you don't share that much code between front and back in reality. Being able to share the paradigms, structure, mindset and tooling (like linters, formatters, code generators, packagers, whatever..) is what's awesome. You remove a whole lot of context switches and cognitive dissonance, smoothing the train of thought which greatly eases the expression of ideas. Source: used quite a bunch of golang + gopherjs, ruby + opal, js + node

jonny_eh 8y ago
> you don't share that much code between front and back in reality Good luck rendering React server-side in Go or Ruby.
- repsilat 8y ago
  I've never looked into server-side react, can you explain a bit about the requirements? Does the server keep a lot of session data around to maintain a shadow DOM for each connected client? How far is it in practice on the continuum between a fancy templating language and a full app framework? Does anyone put server-side React on server-side Redux? Whatever the case, if people write clients in react to talk to Ruby backends, can't they do the same to get "server-side react clients" that run in front of their backend app? Or does that go against the programming model somehow? Would it enforce too much of a barrier between "the view" and the model than is traditional these days?
  - acemarke 8y ago
    While I haven't done SSR myself, my understanding of the general process is that it's about rendering that first initial page that's sent to the browser. This is most beneficial for speed of initial load and SEO purposes. An SSR React app that uses Redux would probably create a unique Redux store instance for each new client, dispatch just enough actions to fill in whatever data is needed for the initial render, and then serialize the Redux store state to the host HTML page so that it can be used to re-hydrate the Redux store on the client. For more info, see the "React Server Rendering" [0] section of my React/Redux links list, and the "Server Rendering" recipe [1] in the Redux docs. [0] https://github.com/markerikson/react-redux-links/blob/master/react-server-rendering.md https://github.com/markerikson/react-redux-links/blob/master... [1] https://redux.js.org/recipes/server-rendering https://redux.js.org/recipes/server-rendering
- lloeki 8y ago
  Turns out not every application needs, let alone require React.
repsilat 8y ago
Depends a great deal on what the application is, I think. If you're doing heavy lifting (or anything a bit complicated) in the client and then need to make similar functionality available to APIs offline it's a godsend. My current hobby project is a kind of REPL/programming language that does all of its compute in the client, and being able to hit a button and export a "serverless" microservice is lovely side-effect of being able to run JS on the server. It isn't exactly "the backend" to my application, more "a headless client exposed to the net," though, I guess. (As someone new to JS, the frigging Node ".mjs" fiasco almost derailed the whole thing, though... What were they thinking?) Edit: oh, and "optimistic rendering" is also a big win -- if you can show the result of an action before it has persisted (or preview it before the user has done it) shared code can also come in handy. Though perhaps we're too scared of network round-trip times.
- Scarbutt 8y ago
  fiasco? isn't '.mjs' still the path forward for them?
  - repsilat 8y ago
    Maybe it is for them, but `node -r esm` is what I'm going to do for now. I'll probably start webpacking the backend soon instead, but I'm sure as hell not going to rename every single file in my codebase.
kybernetikos 8y ago
I'm working with a system that lets you develop code in the client, then gradually move it further back in the stack as needed. It's incredibly useful for testing.
davedx 8y ago
It depends. I was working on a websockets based game using node.js on the backend and React, redux & canvas on the front end. As my game grew, more and more code went into the /shared/ folder. It's extremely useful to be able to mirror the game logic that's run on the server for security in the front end for convenience and performance (avoid waiting for round trips for everything). For example, I had a standard RPG style combat system. Being able to share all of the code that does calculations for combat allows you to put those calculations into the UI as much as you want. I think standard CRUD web apps are different because there's much more asymmetry in the responsibilities of the back end and front end.