We should stop saying "isomorphic" because the explanation relies on two orthogonal concepts that ensure that "isomorphic" will only ever be applied to Javascri

We should stop saying "isomorphic" because the explanation relies on two orthogonal concepts that ensure that "isomorphic" will only ever be applied to Javascript. That seems possibly self-serving if not only misleading. The diagram after "learn more" is not one but two concepts. A common backend API for clients and servers is one wholly independent concept. People can do this with any collection of languages and libraries written for clients on all kinds of platforms. It has nothing to do with using the same code on the client and server. The other concept in the diagram, using client code both in the web application server and on the client because they both use the same run-time is also not particular to javascript, but is anyone holding their breath for Java applets stuffed into mobile Safari? We could do it, but it requires standardization that JS even doesn't ever seem to achieve in practice (where's asm.js on Windows?). Now, we live in a world with LLVM and nearly every language has some Javascript compiler. Let's write the application server code in Haskell beyond a narrow interface that expects to work with JSON and other abstractions that will "just work" with local storage -or- with a file pulled out of /data/data/my.package.org/files/ (Android). I can't call my Haskell-based implementation of these ideas "isomorphic" because the client and server code is not really in the same language as it has been "transpiled" to javascript for web clients. It's heterogeneous in some senses that the "isomorphic" solution is not. However, the difference between these two implementations boils down only to which pieces get stubbed and wrapped up in simpler API's. If you go with Haskell and "transpile" to javascript, then the web client has a Javascript stub while mobile clients will have Java and Objective C stubs to talk to respective platforms through narrow API's. The reverse for Javascript everywhere requires web-views for native mobile clients but "just works" on browsers, like our Haskell "transpiled" solution does. There's probably no difference in amount of work to get hello world working in these solutions on all platforms. I can screw with Phonegap just as much as I can screw with LLVM for Android. Now, does it make sense to say "isomorphic Haskell?" Nobody knows what that means. They will look up "isomorphic" and find it totally outside the lexicon of CS, just like "hyrbid API." While it feels cool to say, "Oh, gee it's a new concept then," the concepts aren't new. Java was supposed to be a run-anywhere program. Separating API servers from application servers and clients has been around likewise for a long time. Think about the history of any legacy system where many clients start hitting a legacy database. There's your fancy "hybrid" API server, but resulting from accretion of ugly years and not cool enough for hipster coding. In the end, what I'm trying to say is that none of this stuff is particularly new and we should stop wrapping it up in pretentious sounding labels. I don't like to see "isomorphic" because it sounds like Quorra is going to crash through my computer screen on a light cycle and breath strong AI into my microwave's controller board. People who are looking for the appropriate direction may be roped in and then think they are awesome and that everyone else is jealous. This has all the makings of an annoying cult in the long run ^__^; Let's look in the lexicon of old computer stuff for a COTS label, such as "shared" or "common" to indicate that two non-identical things use the same thing. There is no need to say "hybrid" API. It's a common API server used by clients and application servers. If you understand the concept, the words are interchangeable. Now, for the idea of portable code, well, how about that. Portable is portable. Our non-pretentious, hypothetical engineer conversation using regular engineering words: "Where does the mobile client get it's data from?" "The same server" "The application server?" "No, both the application server and clients use one backend server. It's a common backend architecture" "So it cuts out a round-trip time for the web client cold loads?" "Yeah, and I'm sure you can see where it saves us time authenticating clients and so on" "How do you make sure all the clients treat the data the same?" "There's some common code in all the clients for unpacking the models from the backend and initializing controllers. The views of course are really client-specific, but we just run a stub in between each view and the portable sections of the client." "But what about web?" "Because the controller and model code are really only dealing with mostly raw data, they're very portable and we just transpile them with Haste." "That all sounds a lot like this 'isomorphic' thing I've been hearing about, but I thought it sounded really pretentious and deliberately esoteric, so I've been avoiding it."