Isomorphic JavaScript: The Future of Web Apps

I can't disagree more. From thefreedictionary.com:

  (Mathematics) A one-to-one correspondence between the elements of two sets such 
  that the result of an operation on elements of one set corresponds to the result
  of the analogous operation on their images in the other set.

This seems exactly like what the author is describing. Colloquial English does not have an objective standard -- it is a constantly evolving language. I certainly agree with this term's usage unless a better one is suggested.

At the Meteor meetup last week, David Greenspan outlined an interesting approach to how Meteor UI separates the "template-parsing" logic from the "rendering" logic with an intermediate representation (in Javascript) of the steps you need to take to produce that HTML. Check out the video (relevant slide is at 16:47, but the entire talk is awesome):

http://www.meteor.com/blog/2013/11/06/david-greenspan-at-dev...

The cool thing is, other template languages (like Handlebars, Jade, etc.) can compile to this intermediate representation, which then gets rendered on any updates.

If the front-end community could agree on a protocol for how to represent these steps in, say, JSON, then we could be on our way to a world where you could use any rendering engine with any template library, on the client or the server.

That is, if the community could agree on a representation :)

Consider Clojure - an interesting language indeed, and the browser variant (ClojureScript) is gaining lots of interest.

The soy templates have a java (tofu) backend already (several years old).

The phantomjs idea is a shit idea and should go away. Phantom is fine and good for headless testing (hells we use it for quite a bit else) but seriously it is not a solution for a real load.

"She's an iso" http://www.youtube.com/watch?v=y8nXRQQ0bjA

Mostly Django user attempting to ask from outside the Node/server-side js community for an explanation of why we're invoking "isomorphic" here: As far as what's going on, are we just saying that the js for rendering the page is equally capable of talking to the API and doing the DOM work while running on the server as it is when downloaded, interpreted, JIT'd etc before fetching the actual request content? Does this mostly eliminate an extra RTT to the API if the js/web application server experience relatively zero RTT due to network/physical proximity to the API server? Does this incidentally make SEO possible while having fat clients and server-side initialization all in one setting and with mostly one code base?

Assuming I'm on track, working backwards towards understanding the implementation as it relates to "isomorphic", if a program's output state is a valid input state to initialize the program (we're talking fat, stateful MVC clients after all) state, then all that's needed to re-create the entire execution state of the current program is to copy itself into the output in such a way that it will be run upon receipt (we link js files in the page). I'm going to take a wild guess that the output state of the client doesn't have the necessary template tags etc used when a cold page is rendered, server or client-side, so the server has to serialize some of the state and pump it into the copy of the program to make it as if the client we're sending is the client that rendered the page, keeping the client's internal representation consistent with the state of the page.

If this is true, we're taking a program that cannot be initialized from it's own output and modifying it to be a program that achieves the same effect. JS is modifying JS, and is therefore said to be "isomorphic?" It still sounds like a glorified way to describe a serialized execution state, one that happens to involve a program in a language outputting a valid program in the same language, but the purpose is to achieve the effect, as far as the developer is concerned, that the output is a valid input, albeit with an intermediate technique to make the abstraction hold water.

If I'm on track, then I have to say it's rather as if we have a fat client, output of one render, serialized client state (because the DOM is not sufficient to re-create the program state or else our client js has to initialize from one format that's programmer friendly and one that's program-friendly), and necessarily a third-leg responsible for injecting the client js and serialized state as js into the output.

Standing to see the mauve dusk of my life against the impending rain of spears and arrows, I must ask if we can not simply call the js necessary to achieve the equivalent state of running everything client side a "continuation" and call the entire technique "client continuation programming?" with it implicitly understood that creating the continuation involves a third piece of program? I'm prepared to die. I just want to know.