Isomorphic JavaScript: The Future of Web Apps

Using precisely defined mathematical words in contexts where they only make sense vaguely to a layperson ruins their original usage. Make up a new word. Repurpose a shitty English word. But leave our damn maths words alone.

Old man quarterto shakes his fist at you! Get off my smooth, compact lawn!

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 :)

In my experience, including rendering code both server-side and client-side is overkill. Just put all the rendering and templating code client-side, period.

If you want your page to appear more quickly, then instead of loading content data with AJAX afterwards, just include JSON arrays of content directly within the HTML source itself, and use JavaScript to populate the page instantly, even as it loads.

(Obviously SEO is a different case, but there are tools built for that specifically.)

It seems like CoffeeScript did this rather successfully, and with source maps, the debugging story is getting better too. Any reasons why this might not be a more compelling future than the "JS everywhere" vision?

This is a classic "impedance mismatch" like O/R mapping. At the end of the day, there may be no good, i.e. simple, solution. It is inherently difficult and messy.

I've been feeling the burn myself—the desire to fully switch to handlebars templates in my Rails app. The expensive part would be building my API out more than I have, because I rely on associations in Rails view renders. However, gaining 1 template engine to rule front & back.

Eh, saying "matured into" implies that the current state is somehow better or more desirable than the previous state, and somewhat implies that this was the expected / desired goal state. I reject all of those implications. I posit that it would be more correct to say that "the Web has been mangled, bent, distorted, twisted and hacked into a fully-featured application platform..."

A Web browser should be good at browsing, trying to make it into an application runtime is a "separation of concerns" violation of the first magnitude. It might work, but let's not pretend there aren't other choices, or forget to continue researching alternative approaches to delivering applications over the Internet.

Look at the first diagram in the article and you'll notice that the author shows 3 environments:

1. Client (obviously the browser is JS) 2. Application Server (the server-side rendering environment = what he says can now change to JS thanks to Rendr) 3. API Server (use whatever you want here - JS, Java, Ruby, Python...)

And, in production you will no doubt need a "static" server as well (for rendering privacy, tos, etc. pages). Plus all of the other production systems (like a queue, stream processing, and so on) that are not JavaScript environments.

If you check out his example code you'll see that he actually sets up example 04 (https://github.com/airbnb/rendr/blob/master/examples/04_entr...) with a subapp for a static page.

Also, if you look at the react-moment branch in the isomorphic tutorial repo (https://github.com/spikebrehm/isomorphic-tutorial/blob/react...) you'll see that he's proxying a dummy API server to a route on the application server.

Anyway, so problem currently is that client devices are slow and HTTP requests are expensive/slow. If these were not issues - I guess rendering on a client would be just fine?

If above is correct, I do not see good reason for smallish websites/apps/whateverucallit fallback on server rendering, as it looks like every single year mobile devices getting faster and faster. And we have SPDY on a way to mainstream.

Do I want to wait 3 seconds to get HTML or wait 100ms to get bootstrap code and see pieces rendering as data comes in? Probably doesn't matter, since it will take roughly same 3 seconds to render it on client side.

Ultimately, perceived responsiveness of webapp depends a lot on particular implementation. If you wait for all data required for page to render - yes, it will be slow. If you render pieces of page as data comes in - user sees that something going on and this is good enough. Why it should matter where data will be converted to presentation, on server or on a client? It is still waiting. And if client is not happy with it? Buy beefier hardware!

I feel this tension is at the root of the CommonJS vs AMD discussions that have been taking place recently as well as issues related to npm, bower, and browserify.

Monomorphic code, while being very easily shared amongst different runtimes, still needs to aware of the mechanisms, strengths, and weaknesses of those runtimes!

Projects like browserify-cdn and sites built with on top of it like requirebin.org do a lot to bridge the gap but raise some interesting questions about wrappers like UMD.

I feel there is room for a better protocol for sharing code between the different environments.

I'm currently doing some research on the subject and plan on writing a spec and implementing some example interfaces.

BTW, projects like Bower head in the opposite direction and seem painfully unaware of their actual context...

I mean, installing a package manager to then install a package manager should raise some eyebrows, right?

Edit - A couple of unofficial but useful links:

http://wiki.beyondunreal.com/Introduction_to_replication

http://wiki.beyondunreal.com/Legacy:Replication_De-Obfuscati...

It's not javascript on the server but that's fine. I actually used the Jwt (java version) with Jruby and Groovy, which is translated from their C++ codebase.

I disagree about the complexity. I've build Angular apps with a RESTful backend that couldn't be simpler. I also haven't noticed any performance issues. It's faster than traditional sites for me. SEO is a problem though.

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.