It probably depends on what you're doing. Are you serving something that's pretty much a straightforward hypermedia document with minimal interaction enhanceme

It probably depends on what you're doing. Are you serving something that's pretty much a straightforward hypermedia document with minimal interaction enhancements? Pushing markup generation down the line to the client probably doesn't make a ton of sense, particularly for mobile. In this case "isomorphic" JS isn't going to gain you a lot, given that you don't have to do much on the client, but it does let you do most of the work on the back end, which is nice if JS is your language of choice (and I like it enough I have no quarrel with you, though you could probably do as well with any other language on the back end and a bit of progressive enhancement). If you're serving an app that isn't really a hypermedia document anymore... well, first you should ask yourself if your app really needs to not be a hypermedia document (and if so, maybe consider some of the tradeoffs between web/native to boot). But assuming you've made those thoughtful considerations, then yeah, the idea to send an initial payload of API call results along with any non-cached essential app code makes a lot of sense. There's an odd in between place that some apps get to where what you're managing is still a hypermedia document but it's got a lot of independent subsections that may have their own specialized interactions (Hi, Facebook!). If this is your app... well, first you should probably be asking yourself if you might improve experience by moving from the "everything and the kitchen sink" model into a few more targeted document endpoints. But assuming you've done that, having the ability to selectively generate document fragments on the server or the client is probably helpful. And that seems like a good use case for an isomorphic JS approach.