Btw, does "Isomorphic Javascript" rub anyone the wrong way or am I the only one.
It seems like someone watched a Haskell tutorial and copied a smart sounding word and just appended it to Javascript. This used to be called "code reuse". But that doesn't sound as cool anymore.
Hear hear! It's even the wrong word. Isomorphic means "same shape", which that means that the "shape" of the code is the same between client and server on these apps.
Huh? What's the "shape" of code?
It's not actually the "shape" that's the same, it's the HTML that it produces. It would be more accurate to call this Isohtml or Isoproduce or Isooutput apps.
People say Isomorphic when they don't know what they are saying, and want to sound smart in greek. Idiots.
The code itself is the shape of the code, to an appoximation. Isomorphic applications run the same code (or big swathes thereof) on the client and the server, so that the common core exists only in one place.
> It's not actually the "shape" that's the same, it's the HTML that it produces. It would be more accurate to call this Isohtml or Isoproduce or Isooutput apps.
A port of an application would satisfy that criteria, but would not fall under the moniker of isomorphic. If you have a better term to qualify applications with extensive to almost complete code-sharing between the client and the server, feel free to try and popularise it, but so far your demonstrations have been sorely lacking.
> People say Isomorphic when they don't know what they are saying, and want to sound smart in greek. Idiots.
Unfortunately, no one has yet come up with a better word to capture the idea for a shared codebase client- and server-side. I'm really hoping it happens soon, because the abusage of the term drives me insane, too.
It's more than just sharing code. It's all about your routes. In an isomorphic web framework: You write a single description of a route handler as a function from JSON to VDOM. That handler will load different dependencies on the client/server to create DOM/HTML. This is where the isomorphism thing comes from: the HTML generated on the server, once loaded by the clients HTML parser, will be equivalent to the DOM that would have been generated on the client. You could of course do this normally but you'd be responsible for maintaining a server operating on HTML in coordination with a client operating on DOM. An isomorphic web framework unifies these two worlds.
An isomorphic framework itself is effectively a proof (in the mathematical sense) of the statement: client-side rendering and server-side rendering are isomorphic.
That still seems like an overly pseudo-mathy way of describing that you render some data structure (possibly just a string, in the case of Rendr), and then the framework produces either HTML or DOM operations. Regardless, to my knowledge, it's not necessarily the case that isomorphic frameworks produce VDOM, rather than HTML on both sides. If I'm reading their site right, Meteor only seems to have gained VDOM-like functionality with the release of Blaze less than a year ago.
Totally agree on VDOM, it's an implementation detail.
I also agree that isomorphic is an intimidating and esoteric term. There are examples however, like the word function, which are "overly psuedo-mathy" in exactly the same way. The mapping between rendering technologies is basically an isomorphism. Each category has objects (html OR dom) and a we can map them with the html parser (html => dom). Each category has morphisms (json => html OR json => dom) and we can map them between by loading the client modules ((json => html) => (json => dom)). Finally, for some json input (J), a renderer (R) and a function (F) that performs those mappings, the framework ensures that: F(R(J)) === F(R)(J). That's not exactly an isomorphism but it's VERY similar.
Its an old concept. It describes the same code running on both the client and the server. Its been called isomorphism for at lest 20 years, when it was first used in networked video games.
I feel your pain, but you're wrong. There are lots of languages that compile to JavaScript, so there's an even-more-plausible future where you can continue writing in your favorite server-side language.
Code reuse intuitively has a much smaller scope, you can use a function on both sides it's code reuse, you can use your templates on both sides it might be (pretty advanced) code reuse. The idea behind "isomorphic" applications is that almost all of the application runs on either side of the network, it's closer to multiplatform or portable computer applications where there's a low-level substrate papering over differences and everything above that is identical.
> It seems like someone watched a Haskell tutorial and copied a smart sounding word and just appended it to Javascript.
It's not completely nonsensical though, isomorphic objects are identical on the properties used to define the morphism. The idea behind "isomorphic javascript" is that you're running (more or less) identical applications on the client and the server.
Yes, but without an obviously better coinage it may be entrenched (especially given ~adrusi's testimony it's been used for at least 20 years in the context of networked gaming).
Any proposals?
In 10 seconds the best alternative I've come up with is "Clerverable", as in "CLient-or-sERVER-ABLE". HEY DON'T SNICKER ALL IDEAS ARE OK IN THE BRAINSTORMING PHASE. And this term 100% solves the problem of people sounding pretentiously-smart when they say it.
It seems like someone watched a Haskell tutorial and copied a smart sounding word and just appended it to Javascript. This used to be called "code reuse". But that doesn't sound as cool anymore.