4 ms·

"the possibility of client/server code sharing" I have yet to see a good example where this was worth even considering. Model validation seems to be the only r

"the possibility of client/server code sharing" I have yet to see a good example where this was worth even considering. Model validation seems to be the only real use case and there are so many potential non-JS based clients that you'll likely need a more general solution for that problem anyway. And even for JS based clients, usually the big pain is the UI logic for showing users the errors and helping them correct it, stuff you won't use on the server side.

golergka 10y ago
I had one example of client/server sharing with C#. It was ASP.NET on the server and Unity3d client: all the data model objects were shared and serialization in both direction was a breeze.
- maxxxxx 10y ago
  In client/server settings with a .NET frontend and a .NET WPF client you can get a lot of code sharing. But in typical web apps with javascript frontend and a a Javascript server I don't think there will ever be much sharing.
firasd 10y ago
It's useful for views, I've done it with React. But yes more for demo apps than in production, at some point things break down because you can't write both server-side and client-side code handling for every UI state.
- kaoD 10y ago
  > you can't write both server-side and client-side code handling for every UI state I'm interested, what do you mean? Can you give an example? As far as I can tell, whatever you serve to the client is also available server-side. You render it there, send it down the pipe as static HTML and hydrate it client-side seamlessly. Except for specific cases where client's local storage has a significant amount of data, of course, but that seems more like the exception than the norm.
  - firasd 10y ago
    Like if you have an error saying "no results for this book title", you'd have logic that sends JSON and checks that, and on the server side you'd need logic that checks the POST request and checks that (and there'd be subtle differences in the variable format between the JSON & regular HTML POST data), and then maybe the way the UI element would be displayed in JS vs in the server-side HTML is also different. I think if you try to be very fastidious about making everything work without JS you will have two code paths for many things.
    - kaoD 10y ago
      Not sure I agree with the example at all. Maybe I didn't understand? > you'd have logic that sends JSON and checks that, and on the server side you'd need logic that checks the POST request and checks that Sending != receiving. That's not duplicate code, it's just different functionality. > (and there'd be subtle differences in the variable format between the JSON & regular HTML POST data) I don't see why. > and then maybe the way the UI element would be displayed in JS vs in the server-side HTML is also different. Why would you do that? Inconsistent UI is bad. I'd expect the same UI whether I got the page via URL or via AJAX. What JS code sharing gives you is the same server-side and client-side rendering. E.g. you can send fully rendered HTML or just JSON depending on the Accept header, saving on data and full-page refreshes but still having SEO (and not having to wait for client-side to render). You can also share the same model in both environments (like having the same Book class, which you'd have to code twice in JS and whatever server-side language you use).
      - firasd 10y ago
        Trust me, although I've written a tutorial about this[1], it's not that straightforward to do for a live site :) To put it another way, making the same app work with and without JS isn't made much easier even if you use React server-side rendering. But if you make something like that I'd be happy to check it out (contact info in profile.) [1] https://medium.com/@firasd/quick-start-tutorial-universal-react-with-server-side-rendering-76fe5363d6e https://medium.com/@firasd/quick-start-tutorial-universal-re...
sciolistse 10y ago
We share model validation, internationalisation functions / string parsing and formatting values (language strings, datetime formats, currencies, etc), access rules, configuration settings, views and constants at least.. I've also had a few situations where we've moved client side code to the server, and not having to rewrite from scratch is nice. None of these are huge issues to solve with a separate language on the server. But for our projects it's been a time saver.
oever 10y ago
Doing operation transform (OP) on ODF in WebODF uses JS code that can run in the client in peer to peer mode or on the server.
Can_Not 10y ago
You can make nodejs front facing, use the same code for views on server and client, and still defer your real backend (any language, probably APIs only) behind nodejs.

golergka 10y ago

I had one example of client/server sharing with C#. It was ASP.NET on the server and Unity3d client: all the data model objects were shared and serialization in both direction was a breeze.

maxxxxx 10y ago
In client/server settings with a .NET frontend and a .NET WPF client you can get a lot of code sharing. But in typical web apps with javascript frontend and a a Javascript server I don't think there will ever be much sharing.

firasd 10y ago

It's useful for views, I've done it with React. But yes more for demo apps than in production, at some point things break down because you can't write both server-side and client-side code handling for every UI state.

kaoD 10y ago
> you can't write both server-side and client-side code handling for every UI state I'm interested, what do you mean? Can you give an example? As far as I can tell, whatever you serve to the client is also available server-side. You render it there, send it down the pipe as static HTML and hydrate it client-side seamlessly. Except for specific cases where client's local storage has a significant amount of data, of course, but that seems more like the exception than the norm.
- firasd 10y ago
  Like if you have an error saying "no results for this book title", you'd have logic that sends JSON and checks that, and on the server side you'd need logic that checks the POST request and checks that (and there'd be subtle differences in the variable format between the JSON & regular HTML POST data), and then maybe the way the UI element would be displayed in JS vs in the server-side HTML is also different. I think if you try to be very fastidious about making everything work without JS you will have two code paths for many things.
  - kaoD 10y ago
    Not sure I agree with the example at all. Maybe I didn't understand? > you'd have logic that sends JSON and checks that, and on the server side you'd need logic that checks the POST request and checks that Sending != receiving. That's not duplicate code, it's just different functionality. > (and there'd be subtle differences in the variable format between the JSON & regular HTML POST data) I don't see why. > and then maybe the way the UI element would be displayed in JS vs in the server-side HTML is also different. Why would you do that? Inconsistent UI is bad. I'd expect the same UI whether I got the page via URL or via AJAX. What JS code sharing gives you is the same server-side and client-side rendering. E.g. you can send fully rendered HTML or just JSON depending on the Accept header, saving on data and full-page refreshes but still having SEO (and not having to wait for client-side to render). You can also share the same model in both environments (like having the same Book class, which you'd have to code twice in JS and whatever server-side language you use).
    - firasd 10y ago
      Trust me, although I've written a tutorial about this[1], it's not that straightforward to do for a live site :) To put it another way, making the same app work with and without JS isn't made much easier even if you use React server-side rendering. But if you make something like that I'd be happy to check it out (contact info in profile.) [1] https://medium.com/@firasd/quick-start-tutorial-universal-react-with-server-side-rendering-76fe5363d6e https://medium.com/@firasd/quick-start-tutorial-universal-re...

sciolistse 10y ago

We share model validation, internationalisation functions / string parsing and formatting values (language strings, datetime formats, currencies, etc), access rules, configuration settings, views and constants at least.. I've also had a few situations where we've moved client side code to the server, and not having to rewrite from scratch is nice. None of these are huge issues to solve with a separate language on the server. But for our projects it's been a time saver.

oever 10y ago

Doing operation transform (OP) on ODF in WebODF uses JS code that can run in the client in peer to peer mode or on the server.

Can_Not 10y ago

You can make nodejs front facing, use the same code for views on server and client, and still defer your real backend (any language, probably APIs only) behind nodejs.