
Isomorphic JavaScript - tilt
http://isomorphic.net/
======
quarterto
Sigh. I think I'm losing this fight.
[https://news.ycombinator.com/item?id=6714666](https://news.ycombinator.com/item?id=6714666)

~~~
kaoD
My reply to the same nitpick (but other guy, you're not alone!):
[https://news.ycombinator.com/item?id=8238504](https://news.ycombinator.com/item?id=8238504)

~~~
quarterto
I'll respond to you here.

> Just notice how function means something completely different in programming
> and math

Try telling Haskell that ;)

> The first thing I think when reading "isomorphic" is "same shape"

There are _actual, mathematical_ isomorphisms extant in Computer Science with
applications to programming. The Curry-Howard correspondence gives rise to
logic languages (Coq, Agda, Idris), where the programs _are_ proofs.

~~~
kaoD
> Try telling Haskell that ;)

That's funny because Haskell has monads, which was firstly a philosophical
term but has three different meanings in math and another one in music theory
(which is just math too).

You can argue Haskell's monads _are_ monads (in the category theory sense),
but I'd argue in Haskell they mean "a way to express types of sequential
computation" (they're _one specific case_ of monads).

You know what these have in common? They all allude to "mono", which is an
actual word in Greek. Just like iso and morph.

------
mateuszf
No mention of react.js. IMHO it is a perfectly good tool for generating views
both client and server side. More details:
[http://bensmithett.github.io/going-isomorphic-with-
react](http://bensmithett.github.io/going-isomorphic-with-react)

------
CmonDev
Kind of based on an assumption that using JavaScript at all is a good thing.
For me the idea is to avoid using it where possible. Can we stop the web
monopolisation/locking/despotism and drop specific languages from titles and
ideas? How about "Isomorphic Applications that give developers freedom and a
choice of language"?

~~~
pluma
Every language sucks. Every language is hated by at least one person (unless
it is entirely irrelevant and people who would hate it just ignore it). There
is no perfect language and there never will be.

If anything, JS is a better "lowest common denominator" than similar languages
because a) every browser already supports it (ask Microsoft (VBScript) or
Google (Dart) about the success of replacing JS in the browser) and b) it is a
compilation target for various other languages (including Haxe, Dart, Java,
Scala, OCaml, Haskell, Go, ClojureScript, LiveScript, Elm, various flavours of
Ruby and Python, as well as JVM and LLVM based cross-compilers) -- and thanks
to amd.js the generated code can be insanely optimized compared to hand-
written JS.

I'm not going to regurgitate the tired "JS is the new Assembly" meme, but with
the web still being the shared platform for all (smart) mobile and desktop
devices and JS being the only language consistently supported by and easiest
to deploy on all of them (via the browser), it certainly has earned its place.

With replacing JS in the browser (i.e. on most devices that have a browser)
having failed numerous times (even more if you include plugins like Java,
Shockwave, Flash, Gears and Silverlight), it makes sense to try to use JS on
the server instead of continuing to try to make the browser use server-side
languages.

But regardless of the language, calling for the use of one language (in one
flavour) for both the client and the server is _by definition_ a step towards
monopolisation. Unless you have a shared compilation target (like asm.js?) you
can't have "freedom and a choice of language" when developing isomorphic code.

~~~
frowaway001
> Every language sucks. Every language [bla]

Oh, another instance of "all languages are equal".

No they are not. Some are better, some are worse.

People who don't want to use JavaScript, try to avoid one of the worst
languages out there.

That's all.

~~~
pluma
I'm not saying all languages are equal. In fact, I have a pretty strong
opinion when it comes to PHP (and the majority of core developers involved in
it until Facebook decided to intervene).

I thought JS was ridiculous crap when I first encountered it in the nineties.
Then again, I still thought XHTML 2.0 was a brilliant idea well into the
noughties. It took me a journey through PHP, Java, ActionScript (both 2 and 3)
and Python (with a short visit to CoffeeScript) to rediscover it and fully
appreciate what modern JavaScript has become and what beauty lies therein.

I would love to hear a more detailed explanation of why you think JavaScript
is unsalvageably bad, but so far all I hear are baseless assertions.

~~~
CmonDev
Such beauty: [http://wtfjs.com](http://wtfjs.com)

~~~
pluma
Oh, come on now. Most of these are edge cases of passing in invalid data into
functions that try to make sense of it, using discouraged functionality (e.g.
not using strict-mode or using obscure parts of the language that are only
supported for backwards-compatibility) and the rest shows just a complete lack
of understanding of the language.

One of the "WTFs" is `"true" == true` being false. Double-equals comparison
being discouraged aside, the only language in which I would expect that to be
true is PHP. Another is about `getElementById` -- that's not even about the
language, it's about the DOM (which has WTFs of its own right and still would
have them if you used a different language in the browser).

If you want a good laugh about JS, I recommend Destroy All Software's infamous
WAT talk (which also contains some Ruby).

------
phaer
Considering that code which runs client-side is untrusted ,your users could
easily change it, how does one deal with security in "isomorphic JavaScript"?
Is it just the rendering running on both sides with all business logic
remaining on the server?

If so, the main advantage would be that you could combine the responsiveness
and speed of a client-side app with the ability to serve static HTML for
clients without JavaScript like some search engine bots, right?

~~~
morgante
Right, with isomorphic JavaScript your server isn't trusted either. A good
paradigm for this is to have a completely separate API server, which is
secure, while the "frontend code" (which might run on either the server or
client) isn't trusted.

Also, the benefit of isomorphic JavaScript isn't chiefly for SEO (there are
other solutions to that problem, such as PhantomJS), it's in being able to
have fast initial pageloads even for rich JS apps.

~~~
progx
But isn't it a little fake?

e.g. form validation: In the examples i see, the client did not have any
validation code, it sends the raw data to the server, which validates and
respond to to the client. So the client did not use the same code.

~~~
morgante
> But isn't it a little fake?

What example are you looking at? I think you maybe don't understand how
isomorphic apps work...

Take form validation: 1) Your "frontend" code (which runs on both/either
client & server) does a quick sanity check, purely for responsiveness. 2) Your
API server does actual validation of code.

Of course, your API server isn't running the same code as the client—you can't
have the client talking directly to your database, for example. Rather, the
idea is that the "frontend" can be rendered on the server & client.

------
arianvanp
React can run both on client and server as well! Would like to see it in the
list.

~~~
pluma
To be fair, it works on the server by simply not executing the parts that are
meant to be executed after the components have been rendered (which is why
you're supposed to do AJAX requests, event listeners and other things in
`componentDidMount`).

Not saying that doesn't work, in fact it works very well. It just means your
server-side React code can't be async.

~~~
pluma
After watching more about Flux and React: I may have been wrong.

Flux seems to get away with React components being entirely synchronous by
offloading all the async parts into the interaction between dispatchers,
actions and stores. As the only thing React forces you to keep synchronous is
the component code leading up to the rendering, I guess you could just wait
for the stores to be ready and loaded before rendering the components.

The more you know.

------
al2o3cr
Isomorphic Javascript: for when you've decided that the 1993 Netscape
engineers managed to produce the perfect language for programming computers.

~~~
pluma
Ad hominem: for when you can't be bothered to come with an argument for why an
idea is flawed.

FWIW, the "1993 Netscape engineers" were mostly Brendan Eich, and JS today has
not only improved a lot since 1993 (see ES 6 and 7 -- btw, some popular
languages don't even _have_ a spec), but is amongst the most widely deployed
languages in the world, with the entire weight of Mozilla, Google and
Microsoft behind it.

By your logic C is just a language developed by one guy at a 1970s telephone
company.

------
RubyPinch
\-- jesus that is horrible

++ jesus that site is horrible

"Isomorphic JavaScript apps are JavaScript applications that can run both
client-side and server-side."

like bash, wget (edit: yes I know these arn't javascript, missing the point by
roughly 462 miles), etc? hmm, maybe I'm missing something here, oh look, a
[learn
more]([http://isomorphic.net/javascript](http://isomorphic.net/javascript))
link, which says...

"Isomorphic JavaScript. JavaScript applications that can run both client-side
and server-side." and a little meaningless venn diagram

...

so I need to go down to "Why isoblah", follow the link to a random article
about the latest tech craze

"At the end of the day, we really want a hybrid of the new and old approaches:
we want to serve fully-formed HTML from the server for performance and SEO,
but we want the speed and flexibility of client-side application logic."

oh, so, "HTML pre-rendering"? or, "like twitter for the past # months"?

\- - -

making a website to introduce people to a new concept, doesn't work if its
aimed at people who are already knowledgeable about said concept.

not like this matters, this website seems more... "lets drop a copy of
bootstrap and knock something together quickly and we might be able to
capitalize on this craze", judging by the lack of any actual content (no blog,
no jobs listing, links for both, the blog of the copyright holder has a blog
consisting of "hello world", and who's portfolio consists of 20 broken
websites, all of which look exactly the same)

~~~
morgante
Actually, it's your comment that's horrible.

> like bash, wget, etc

What? In what world is bash a JavaScript application that can run both client-
side and server-side?

The tagline is direct and obvious. What part of running both client-side and
server-side don't you understand?

And yes, it does look like a bit of an MVP, but that's no reason to rip into
their efforts.

~~~
RubyPinch
hint: I was referring to the client/server part with those examples

if it must be in JS to satisfy the entire sentence, vtop, any node.js
application, etc

> The tagline is direct and obvious. What part of running both client-side and
> server-side don't you understand?

going by the examples I gave, the fact that it doesn't clear up any ambiguity
one might have over that tag line

my first reading, it seemed like it was talking about any program, written in
JS, that could be run on either server or client, which is obviously
meaningless. so I decided to look further, something the site itself didn't
clear up

it doesn't mention implementation approaches, effects it would have, (well, it
mentions the effects (all 2 of them), giving no actual reason for any of it)

what it could of said, "The same application runs on both server and client,
along-side one another. By sending pre-rendered HTML, it greatly speeds up
initial page load and allows for more accessibility"

like, that takes no effort, and that no-effort wasn't made in the creation of
this site

at this point I'm literally re-typing my previous comment so there isn't much
point in continuing.

\- - -

I have zero problem with the approach itself, sending HTML is great, per-
rendering is great. I have a problem with the site. its only as good as a list
of libraries, nothing more

~~~
morgante
> if it must be in JS to satisfy the entire sentence, vtop, any node.js
> application, etc

What? "Any node.js application" most definitely _won 't_ successfully run
client-side. Similarly, "bash" most definitely won't run client-side.
Additionally, most client-side frameworks don't effortlessly work in a DOMless
environment.

> that could be run on either server or client, which is obviously meaningless

How is that meaningless? That's literally the _entirety_ of what's important
about isomorphic apps: the same codebase can be run client-side and server-
side.

~~~
RubyPinch
I'm not typing for personal gratification, I've explained this

> Similarly, "bash" most definitely won't run client-side

what is a terminal, what is linux, what is windows even. you know "client-
side" can refer to multiple things, yes? browser, computer, etc

> that could be run on either server or client, which is obviously meaningless

I've mentioned this in relation to my examples given, 3 times now, stop
intentionally making this difficult

I can run program A on my computer, I can run program A on a server. this has
no value to mention, as such it is a meaningless personal comprehension of the
tagline.

if you want me to explain that a 4th time, I'll be glad to

\- - -

you must realize the world exists in /and out/ of the browser, javascript
exists outside of the browser and server, Atom comes to mind

~~~
morgante
So, I'm pretty sure you're just being intentionally stupid.

In the context of JavaScript, it should be fairly obvious that the "client" is
a web browser.

~~~
RubyPinch
the fact that you couldn't understand me 3 times in a row, should easily prove
the fact that misunderstandings / poor explanations can be given

and it wasn't fairly obvious, I work software, not web-dev. using a browser as
an application host is something I know of, but I do not spend any time
thinking about.

as I said, atom jumps to mind

that being said, I knew that my interpretation was wrong (I actually had to
explain that my initial view was wrong, 4 times, to you, my god) so I looked
for more information

which is the meat of my complaint, it doesn't provide information

\- - -

[https://news.ycombinator.com/item?id=8415448](https://news.ycombinator.com/item?id=8415448)

\- - -

all you have been doing is telling me that my interpretation, which I
considered incorrect, is incorrect. I don't know what you are trying to
achieve with that

[https://news.ycombinator.com/item?id=8415363](https://news.ycombinator.com/item?id=8415363)
"hmm, maybe I'm missing something here"

[https://news.ycombinator.com/item?id=8415420](https://news.ycombinator.com/item?id=8415420)
me saying my interpretation was meaningless, and also very specific use of the
word "either"

[https://news.ycombinator.com/item?id=8415472](https://news.ycombinator.com/item?id=8415472)
me saying my interpretation was meaningless again

and then you finally tell me my interpretation was wrong. I think I know its
wrong.

------
kennu
But will isomorphism die now that Google is capable of indexing the content
rendered by JavaScript apps on the browser?

~~~
markuskobler
Google's ability to indexing content is only part of the story. Google cant
link to your content if its not deep link friendly and will rank it poorly if
you content loads slowly. Both of which SPA are often bad at delivering.

I demoed how big the performance difference can be at Manning's recent powered
by JavaScript conference [https://speakerdeck.com/markuskobler/react-the-
importance-of...](https://speakerdeck.com/markuskobler/react-the-importance-
of-isomorphic-spa)

------
poseid
nice - I was tracking this in the context of my book on Backbone
[http://pipefishbook.com/references](http://pipefishbook.com/references) , but
isomorphic JavaScript has potential to address programmable devices via the
web too, e.g. what if your lamp would speak JavaScript?

~~~
phaer
Why should it? There's not too much a lamp can do besides being switched on
and off and maybe changing the brightness and/or color. I guess a REST
interface, it not a simpler protocol, would be more than sufficient to control
it. Why bother with the power you need to run a JS VM?

~~~
poseid
true, a RESTful API would be enough for state changes. but javascript would
help working with events (e.g. for prototyping interactions). this goes a bit
in the direction of building robots, e.g where Cylonjs is a nice example
[http://cylonjs.com/documentation/guides/what_is_cylon/](http://cylonjs.com/documentation/guides/what_is_cylon/)

------
knappador
We should stop saying "isomorphic" because the explanation relies on two
orthogonal concepts that ensure that "isomorphic" will only ever be applied to
Javascript. That seems possibly self-serving if not only misleading.

The diagram after "learn more" is not one but two concepts. A common backend
API for clients and servers is one wholly independent concept. People can do
this with any collection of languages and libraries written for clients on all
kinds of platforms. It has nothing to do with using the same code on the
client and server.

The other concept in the diagram, using client code both in the web
application server and on the client because they both use the same run-time
is also not particular to javascript, but is anyone holding their breath for
Java applets stuffed into mobile Safari? We could do it, but it requires
standardization that JS even doesn't ever seem to achieve in practice (where's
asm.js on Windows?).

Now, we live in a world with LLVM and nearly every language has some
Javascript compiler. Let's write the application server code in Haskell beyond
a narrow interface that expects to work with JSON and other abstractions that
will "just work" with local storage -or- with a file pulled out of
/data/data/my.package.org/files/ (Android). I can't call my Haskell-based
implementation of these ideas "isomorphic" because the client and server code
is not really in the same language as it has been "transpiled" to javascript
for web clients. It's heterogeneous in some senses that the "isomorphic"
solution is not.

However, the difference between these two implementations boils down only to
which pieces get stubbed and wrapped up in simpler API's. If you go with
Haskell and "transpile" to javascript, then the web client has a Javascript
stub while mobile clients will have Java and Objective C stubs to talk to
respective platforms through narrow API's. The reverse for Javascript
everywhere requires web-views for native mobile clients but "just works" on
browsers, like our Haskell "transpiled" solution does. There's probably no
difference in amount of work to get hello world working in these solutions on
all platforms. I can screw with Phonegap just as much as I can screw with LLVM
for Android.

Now, does it make sense to say "isomorphic Haskell?" Nobody knows what that
means. They will look up "isomorphic" and find it totally outside the lexicon
of CS, just like "hyrbid API." While it _feels_ cool to say, "Oh, gee it's a
new concept then," the concepts aren't new. Java was supposed to be a run-
anywhere program. Separating API servers from application servers and clients
has been around likewise for a long time. Think about the history of any
legacy system where many clients start hitting a legacy database. There's your
fancy "hybrid" API server, but resulting from accretion of ugly years and not
cool enough for hipster coding.

In the end, what I'm trying to say is that none of this stuff is particularly
new and we should stop wrapping it up in pretentious sounding labels. I don't
like to see "isomorphic" because it sounds like Quorra is going to crash
through my computer screen on a light cycle and breath strong AI into my
microwave's controller board. People who are looking for the appropriate
direction may be roped in and then think they are awesome and that everyone
else is jealous. This has all the makings of an annoying cult in the long run
^__^;

Let's look in the lexicon of old computer stuff for a COTS label, such as
"shared" or "common" to indicate that two non-identical things use the same
thing. There is no need to say "hybrid" API. It's a common API server used by
clients and application servers. If you understand the concept, the words are
interchangeable. Now, for the idea of portable code, well, how about that.
Portable is portable.

Our non-pretentious, hypothetical engineer conversation using regular
engineering words:

 _" Where does the mobile client get it's data from?" "The same server" "The
application server?" "No, both the application server and clients use one
backend server. It's a common backend architecture" "So it cuts out a round-
trip time for the web client cold loads?" "Yeah, and I'm sure you can see
where it saves us time authenticating clients and so on" "How do you make sure
all the clients treat the data the same?" "There's some common code in all the
clients for unpacking the models from the backend and initializing
controllers. The views of course are really client-specific, but we just run a
stub in between each view and the portable sections of the client." "But what
about web?" "Because the controller and model code are really only dealing
with mostly raw data, they're very portable and we just transpile them with
Haste." "That all sounds a lot like this 'isomorphic' thing I've been hearing
about, but I thought it sounded really pretentious and deliberately esoteric,
so I've been avoiding it."_

~~~
bceagle
I agree that the term Isomorphic isn't necessarily the best, but I do think it
makes sense to have some sort of label that people recognize for the same code
that runs in multiple places. Enough people have a sense of what 'Isomorphic
JavaScript' means now that the term is likely here to stay until you or
someone else starts marketing a different term.

Getting past the terminology, you make a good point about how non-JavaScript
languages could technically be seen in the same "isomorphic" light. In my
mind, the more valuable thing the higher level concept of writing code once
that can be effectively and efficiently used at any layer of your stack.

The reason why I like to do this with JavaScript is that I can do it more
effectively and efficiently than what I have seen in other languages.

------
ChaoticGood
A) code reuse === isomorphic javascript

B) [http://tron.wikia.com/wiki/ISO](http://tron.wikia.com/wiki/ISO) ===
isomorphic javascript

C) trivial pursuit of a buzz word === isomorphic javascript

D) All of the above.

------
steego
Am I the only one who excitedly clicked on the link thinking it was some sort
of library that parsed JavaScript in an isomorphic data structure that could
be symbolically evaluated?

------
bceagle
It is unfortunately that this site doesn't do Isomorphic JavaScript justice
because it is actually a very powerful concept and is being more widely
adopted than indicated.

First, as far as adoption, some of the other comments mention React, but Ember
is also moving toward Isomorphic JS (see
[http://tomdale.net/](http://tomdale.net/)). I have been working on something
similar for AngularJS.

As far as the benefits or why you would care, there are a few things to keep
in mind:

1\. Some commenters mention why bother since Google now indexes content
rendered by client side JavaScript. My answer to this in short is that there
is a big difference between a search engine indexing content and a search
engine ranking a site highly. For at least the near future we have no idea how
much search engines actually are able to capture and it would be difficult for
search engines to rank client side web apps and server side websites evenly
(i.e. due to the massive history and trust with server side rendered
websites). This may change over time, but it does not change overnight.

2\. SEO is a benefit of Isomorphic JavaScript, but it is not IMHO the primary
benefit. The primary benefit comes from being able to create ultra DRY code
with one technology, one overarching framework and one way of thinking. There
is a lot of power in using the same code in one file at all layers of your
stack. To me, Isomorphic JavaScript not only includes the browser client code
and the web server code, but also the API, mobile, batch and all other
potential containers. There is so much potential power there when you get rid
of all the context switching that usually goes on through your stack.

I think a valid criticism of Isomorphic JavaScript is that in order to
implement it the right way it needs to be customized to your environment
(which takes time) and ends up creating certain levels of abstraction that can
seem like "magic" to newbies. Most of the frameworks that try to implement
Isomorphic JavaScript today either aren't complete (i.e. you can't use it for
every layer of the stack or you can't adapt it to your environment) and/or it
is too complex and confusing for many devs to grok.

