Unimorphic Isoversal JavaScript What?

First, credit where due. Thanks, David!

OK what’s up with this crazy post title? I’m calling bullshit on both recent terms people have tried to rally behind to describe the trend of using the same JS code in both client and server: isomorphic and universal.

Come on! Why are we trying to coin some kind of ridiculous new term for something that’s been around for a long, long time?

I know why. It’s because we have this foolish notion that a marketing buzzword will somehow bring some legitimacy to whatever we’re interested in. We’re not content to just describe the thing we’re doing, we need some sexy label for it. If we give it a name, the masses of community will surely come and rally around it!

And recruiters are absolutely drooling, just itching to get in on the hype bandwagon by dribbling these nonsense terms all over any job postings they can get their little fingers on.

What is it!?

In short, the technique we’re talking about is reusing JS code in both the server (Node) and the browser. Awhile back, someone gave this the name “isomorphic”, which is just plainly a misuse of the precisely defined mathematic term.

More recently, others have tried to re-label it “universal”. Bah. That’s not an abuse of the meaning of the word per se, but it’s also trite and meaningless, and it misses the main point.

It’s important to note: we’re not talking about server-side JS. Did you know that there was techincally server-side JS before there was even browser JS!? Yeah, really. The original experimental embedding of JS was actually in a Netscape server, around the same time it was also landing in a Netscape browser.

This is about more than just the fact that JS can run outside a browser. Of course, JS can run just about anywhere! But that’s why “universal” misses the mark — because of course it can! Duh. “Universal” is a non sequitur. Asserting that JS is universal is as useful in 2015 as saying, “the color red is not the color blue”, which is to say: not useful at all.

No, the thing we’re talking about here is the ability to write a piece of JS code in an environment-agnostic enough way that the exact same code can run in more than one environment. THAT is super important.

An old idea is new again

I said this idea has been around a long time. But you probably don’t believe me. Node’s only gotten really widespread popular in the last 3-4 years, so it can’t be much older than that. Right?

Except, it is. I’m sure I wasn’t the first to talk about these ideas, but I can at least cite my own blog post on the topic: What exactly is the “middle-end”? from mid 2010 where I formulated my own take. And actually, I’d been working on that idea since mid-2009 (pre-Node!).

That’s right, the name I gave this idea back then was “middle-end”. What comes between the front-end and the back-end? The middle-end, of course!

In short, my term middle-end actually refers to the set of logic that generally represents the top ~10% of the server and the bottom ~10% of the browser, and everything in between. Specifically, what I was calling for back then — I’m still calling for it, though not many have ever listened to me — was defining these bits of the application architecture in JS and sharing that code between client and server; aka, DRY.

Common examples of middle-end bits: templating, URL routing, (stateless) data validation, data formatting, etc. These are all tasks that modern SPAs need to do in both the client and on the server. Writing one version of that code in some non-JS on the server, and then writing it again in JS for the browser, has always been a sub-optimal idea.

So at its heart, middle-end was about embracing writing the code just once, and then sharing this code on both sides of the wire.

Note: If you think my term is bullshit, that’s fine and fair, too. Maybe it is. Probably.

I had an employer around that time that hired me and paid me for about 6 months to develop these ideas (for both OSS and commercial purposes). Abruptly one day, they ended the iniative because, and this is a near exact quote, “this idea is at least 24 months ahead of the industry”.

Yeah. They were right in that sense. Or maybe it was 36-48 months ahead.

But anyway, now in these last couple of years, all of a sudden everyone seems to be like, “Oh, cool, let’s write this JS code and use it in both places. Yeah!”

Don’t get me wrong. I’m not bitter. I was ahead of the curve. Others were, too, before me. I’m just happy that now much smarter people than me are finally clued in and this stuff is getting the attention it deserves!

For example, I love the recent stuff that Ember has been up to with FastBoot. I read that post last year and was like, “Finally! Yes! Someone gets it!” I hope they keep up the great work.

Isomorphic?

So let’s get back to the point of this post: calling bullshit on bullshit terms.

What does isomorphic mean? Well, we could talk about it in mathematic terms, or sociology, or biology.

The general notion of isomorphism is that you have two things which are similar in structure but not the same.

In all those usages, isomorphism is differentiated from equality in this way: two values are equal if they’re exactly identical in all ways, but they are isomorphic if they are represented differently but still have a 1-to-1, bi-directional mapping relationship.

In other words, two things A and B would be isomorphic if you could map (convert) from A to B and then go back to A with the inverse mapping.

So, is it appropriate to call two absolutely identical things isomorphic? Eh, maybe in some sense. But I say no. I am no mathematician, sociologist, or biologist. But those definitions speak to the idea that isomorphism is importantly different than strict equality.

Turning our attention back to this bullshit “isomorphic JS”: having two copies of the exact same JS code running in two respectively different environments just doesn’t fit the notion of isomorphism. Sorry.

By the way, what would isomorphic JS be if there were such a thing? Well, it could be that you have one set of JS code that is converted to another set of JS code, and that (importantly) you could convert from the latter back to the former if you wanted.

Here’s a silly example:

// A:
function foo(x,y) {
    return x * y;
}

// B:
function foo(y,x) {
    return y * x;
}

These two functions are not identical. They produce the same outcome. They have a similar structure. And you could define a conversion mapping where either could be used to get the other. That’s isomorphic JS. But two copies of A are not isomorphic. Not by the way I read and understand it, anyway.

Another way of thinking about isomorphic JS: if you had a set of non-JS code (say: python or PHP) that is automatically converted to the equivalent JS so that both pieces of code can run in their respective environments (python/PHP on server, JS in browser). As long as the generated JS could be mapped back to the original python/PHP, then it’d be isomorphic code.

Isomorphic sounds great. It has all the hallmarks of a great buzzword. It’ll look awesome on your resume. I’m sure job offers will just roll in. But it’s also inaccurate.

Universal

I kinda already addressed why universal is a bad term for the important idea at hand. Universal misses out on explaining the shared nature of the identical code. Universal just implies that you can run JS in all kinds of different environments.

There’s lots of places you can run JS: robots, refrigerators, lightbulbs, drones, etc. But you don’t really share the exact same code in all those places, at least not commonly.

So, yeah, JS is universal. Great. But that still doesn’t capture the important notion. It just rings hollow.

So… what then?

What should we call it!? middle-end is bullshit (right?), isomorphic is bullshit, and universal is most definitely bullshit.

Some now say we shouldn’t call it anything except just “JavaScript”. That’s cheating. And also, it has the same shortcoming as universal, which is that it misses the important point.

I’ve already used the label I prefer a bunch of times in this blog post, and I bet you didn’t object so far: shared.

Shared JS. Sharing your JS across environments is a powerful technique. You could call it other things, like “environment-agnostic”, but that’s a mouthful and it’ll never show up on a resume.

Don’t like shared? OK. What about “hybrid”, or “adaptive”, or “reusable”?

Oh, you hate all those, too? My, my, that bikeshed of your’s is awfully green. Have you considered a different…

Nevermind. What do I care what you call it?