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.
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.
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.
> 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).
[1] https://medium.com/@firasd/quick-start-tutorial-universal-re...