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