[biocomputation]

"Isomorphic" Javascript? If there exists an isomorphism between the code on the client and the code on the server, then someone should be able to write a proof.

Otherwise, using the same language on the client and the server does not constitute an isomorphism.

Kthxbai!

[mikemikemike]

The JS community switched from the term "isomorphic" to "universal" around a year ago. Seems not everyone is on the same page yet.

[jasim]

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)

[abritinthebay]

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.

[empthought]

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.

[abritinthebay]

Clearly you've never written an isomorphic app because your first paragraph is just outright wrong.

[empthought]

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.

[piercey4]

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.

[piercey4]

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.

[clhodapp]

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.

[abritinthebay]

> It really is a very wrong use of "isomorphic", though

It's really not.

> Two things can be isomorphic to each other but one thing cannot called "isomorphic" without specifying what other thing it is isomorphic to.

Good thing we're talking about the relationship of client and server code then so we're not doing that then isn't it?

> isomorphism is about those two things having the same conceptual structure, despite being different things.

Yup, still perfectly on topic here with Client vs Server...

> In math...

Ah well, there's your problem. It's nothing to do with the mathematical definition of the term.

[madeofpalk]

_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.

[abritinthebay]

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.

[abritinthebay]

THANK YOU.

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.

[efnx]

Yeah, the author maintains a very loose definition of isomorphism.

[piercey4]

Yeah it's not a perfect word to describe what's going on. I think the loose definition I posted at the beginning of the article works well though.

[abritinthebay]

You don't understand isomorphism outside of a very very very narrow usage of the term. Especially how it is applied here.

kthxbai!

[empthought]

> In the first place, singularities-events correspond to heterogeneous series which are organized into a system which is neither stable nor unstable, but rather 'metastable', endowed with a potential energy wherein the differences between series are distributed... In the second place, singularities possess a process of auto-unification, always mobile and displaced to the extent that a paradoxical element traverses the series and makes them resonate, enveloping the corresponding singular points in a single aleatory point and all the emissions, all dice throws, in a single cast.

-- Deleuze, as quoted in Sokal and Bricmont's "Fashionable Nonsense."

Misusing technical terms in order to fake a veneer of intellectual respectability should be called out every time.