3 ms·

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 serv

by 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...

by firasd 10y ago

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...