First let’s get out our dictionary and see what we’ve got for the scientific and mathematical granddaddy of our present-day vernacular:
- a: being of identical or similar form, shape, or structure
- b: having sporophytic and gametophytic generations alike in size and shape
2) related by an isomorphism
Clearly 1(b) is not applicable because as much as we wish it were so, computer systems are not biological. This leaves us with the possible definitions:
- “being of identical or similar form, shape, or structure”
- “related by an isomorphism”
Now you might think that the first definition is the de-facto since it is “running the same code on the client and the server”, but in fact many libraries have some distinct similarities when running in the different environments. It is for this reason that we should prefer the latter definition of “related by an isomorphism”.
And at this point your eyes glaze over and tell me to go back to my PhD program in discrete math. I don’t actually have a PhD in Mathematics (embarrassing!), but I can still give you a little more context into what exactly an “isomorphism” is. Crossing the boundaries of math and programming is the problem of “screen to world coordinates” and vice versa. In a 3D game, there are all sorts of
(x, y, z) coordinates that need to be mapped onto your 2D screen which has
(x, y) coordinates. These two coordinate systems are isomorphic via the
screen-to-world(x, y) and
world-to-screen(x, y, z) functions, which together make up the “isomorphism” that relates them.
In this context, the isomorphism needed for an isomorphic library is related to the semantics of the code itself. You see, these semantics are similar (but not exactly the same) when running either on the client or the server. In many cases they may be exactly the same, but they need not be. The isomorphism is the thing that mucks around with the code to make the two use-cases sane. Take for example, one of the first isomorphic libraries that I wrote: director. Director is a routing library that works for client-side routing and server side routing (both HTTP(S) and CLI).
Yet the semantics of these routing functions are very different. Routing to a
POST event in a client-side page makes little to no sense. Nonetheless, I refer to director as an isomorphic library, because there is an isomorphism that relates the two of them. This isomorphism is namely the client-side build script, which takes exactly the methods we need from the larger HTTP(S) / CLI implementation and packages them up into the browser-version.
Simple right? I thought so when I decided to repurpose our friend complex math terminology for complex programming terminology. At least it’s better than a new TLA or FLA because those don’t MEAN enough yet. I hope this has been somewhat educational and I’m looking forward to seeing more isomorphic libraries come out!