I for one haven't. Isomorphism as a word is used not just in Maths where it has a precise meaning, but in other subjective contexts as well. At a general enough level, it denotes some kind of structural similarity between two objects, not just a clear one-to-one mapping. Web development is not mathematics and so we can have different definitions for words, and this is unfortunately the best we have to convey this particular idea. ('universal', to my taste, is too broad and confusing)
It really didn't. Universal is flat out wrong unless you're using the exact same code on both server and client.
Isomorphic is 100% correct if you use the definition from biology, crystallography, sociology... etc etc. It's more technical of a term in one single field. In every other way it's a perfect description.
* Sociology: a similarity in the processes or structure.
* Crystallography: two structures closely similar in shape, formulation, and structure.
* Biology: a similarity of form or structure between organisms
All of these more closely describe a JavaScript application that lives on the client and server - because while they will be similar the likelihood of them having the complete same code (and therefore being universal is minimal.
Aside from being a set of instructions to complete some computational task, server-side code has very little similarity of process or structure to client-side code. "Isomorphic" is a bad description no matter what intellectual discipline you pull the word "isomorphic" from.
Taken from crystallography, the JavaScript here is like the oxygen in silicon dioxide and in water. Same material, same physical properties, completely different structure and function depending on where it is.
Form validation and DOM rendering are the only things that could look the same; literally everything else (data access, concurrency, remote requests, security, caching) will be different because the runtimes and the system architecture contexts are entirely different.
Clearly you have yet to work on something that isn't just form validation and DOM rendering.
Caching can easily be shared, @rill/loader works perfectly for my needs. For everything else you are more or less correct. However like i've mentioned Rill works perfectly fine as a standalone server side framework or a standalone browser framework.
Everything you mentioned is achievable with Rill. I have found two simple ways to Isolate server only code in Rill.
1) Have two Rill servers, one with shared code and one without. Where the shared code server interacts with the isolated secure api from the other server.
2) Have one server that calls itself through http(s) requests where the api bits of the server and everything else you mention is hidden behind a "if (!process.browser)" statement. With browserify and other build tools you can have it automatically parse out any server side code. This is my preferred approach because I get to bundle all of the important parts of my app together while still having granular control over where things run.
If there's "server only" code, then "isomorphic" is a terminologically incorrect characterization of the architectural style. The code on the server and the code on the client have different structures.
I use both but personally prefer Isomorphic because in most cases the code isn't actually universal, it has to be translated (shimmed, transpired, etc) between environments.
If there is one thing you can do to annoy programmers though is to use the wrong terminology :p.
It really is a very wrong use of "isomorphic", though:
First, "isomorphic" is a word that denotes a symmetric, relative relation between two separate things; Two things can be isomorphic to each other but one thing cannot be called "isomorphic" without specifying what other thing it is isomorphic to. That simply doesn't make sense.
Second, isomorphism is about those two things having the same conceptual structure, despite being different things. In math, this means that you can define a lossless two-way conversion between the things (you can start with an A, turn it into a B, and go back to an A, and you'll get the same A). In biology, the field the author took his definition from, isomorphic means that the things have a different ancestry but the same structure. This is literally the opposite of taking code and shimming or compiling it to allow it to run in multiple environments, as it would be taking a single common ancestor codebase and lossily changing its structure to allow it to run in multiple environments.
edit: Just realized you are the author. Now I feel silly for referring to you in the third person. In any case, I do want to say that despite any squabbling over terminology, you seem to be doing great work in putting out rill. Developing a full-blown application framework like this mostly on your own is no mean feat. My squabbling stands, though.
_Technically_, it would be more accurate to say that your client is isomorphic to your server. In that regard, the term 'isomorphic javascript' doesn't really make sense as there's nothing to compare it to.
However, everyone knows what you're talking about when you say 'isomorphic javascript', so the pedantry doesn't really matter.
Well indeed, and "isomorphic javascript" is really just dropping the heavily implied "application" at the end.
At it’s core Isomorphic JavaScript describes the relationship between the application that runs on the server and the one it serves to the client to run.
It's perfectly correct - because it's not describing the code it's describing the application(s) and the approach they take.
Sometimes I feel like I'm taking crazy pills because "universal" isn't and "isomorphic" is not only technically correct - it's absolutely accurate for the relationship between client and server side code.