An isomorphic app is basically a Single Page Application (think Angular / React / Ember application) with the special ability to be rendered server side. The interest vs a simple SPA is that on the first page load, instead of loading just javascript, and having to wait for XHR request and JavaScript rendering to draw the data, you get the page properly rendered in the first place. But when you navigate to go to a different page, you use javascript to repopulate the data. It's the best of both world for the users. But for the developers it usually means extra work.
It's not really esoteric... it just kind of has the wrong connotations, because it's used rigorously in mathematics, and here it just means "portable between different JavaScript runtimes," pretty much.
To me the word makes me imagine a web application that can parse its own rendered HTML and get back the application state. Which sounds kind of interesting...
It's not about runtimes. It's about environments. The difference between Node and Chrome isn't so much the runtime as that one is on the server (with arbitrary network and file I/O) and the other is a browser (with a DOM and Web APIs).
Isomorphic means that the same code can be used to "pre-render" an app on the server and to interactively run the app on the client, preferably without losing input state if the client-side execution is delayed (i.e. not throwing away the rendered content but attaching to it).
More generally it means that the code wraps any underlying APIs to make it behave similarly (but not necessarily identically) in node and the browser. Like isomorphic-fetch, which uses a polyfill (i.e. a fallback implementation in the absence of a native API) for the Fetch API in the browser or a node-based implementation in node.
The reason some people prefer the term isomorphic over universal is that isomorphic has no conflicting definition in the context of web apps. Universal on the other hand is extremely vague and ambiguous (ranging from "takes accessibility into account" to "works with different third party APIs" to "language independent").
The reason some people prefer the term universal over isomorphic is that isomorphic as a scientific term has unrelated meanings in mathematics, chemistry and other fields which can be domains for web apps.
Of course the real joke is that the definition is only about node and browsers, making no claim whatsoever about "all JS environments" or even "most". This is one of the reasons I personally don't like the term "universal": it implies a scope that simply isn't intended by most projects the term would be applied to. Something that only works in Edge and Node 5 might be "universal" but it isn't universal at all.
it just kind of has the wrong connotations, because it's used rigorously in mathematics
And the original use was in Philology[0]. Just because a word has two different meanings in two different contexts doesn't means it's wrong. I'm certainly glad the linguists didn't get up in arms when the mathematicians gave the 'wrong connotation' to isomorphism.
Well, I didn't mean to claim it's prescriptively wrong, just that to my mind, maybe because I've been around a lot of mathematicians and coded a lot of Haskell, the usage jumps out as kind of weird... and anecdotally, I've mostly heard "isomorphic JavaScript" used kind of ironically, with a wink bordering on a cringe.
By the way, for the broader point about language mutation, and prescriptivism vs descriptivism, I think there's a common stance against prescriptivism that also seems to rule out any negative opinion about language change—to which I say, hey, negative opinions are part of the whole mess too, even from a descriptivist standpoint. But this is a derail already; sorry.
Isomorphic means hybrid client/server view rendering.
SPAs are (relatively) slow to load. To improve perceived performance, the view requested is prerendered on the server with the ability to capture user input. The user sees a fully functioning site while the app bootstraps in the background.
Once the app is finished bootstrapping, the user inputs are replayed on the actual app.
This fixes the problem of poor perceived initial load times that come with SPAs. Once the app is bootstrapped everything is fast/snappy as one would expect with a SPA, incl no page refreshing between URIs.
Isomorphic React is already supported. Isomorphic Angular2 (ie Angular Universal) is in the works. I don't know about Ember but I'd assume they already support it.