There is no fight. You will be able to recognize when the word fits and when it does not, if you took the time to understand it's precise meaning.
Anyone who wants to use words with the wrong intention (such as, sounding intelligent) will eventually realize they are only confusing themselves. It's having a spaghetti mind that occasionally voids itself. Pedantry aims to deconstruct spaghetti mind and carefully compose conceptual clarity.
You either drop a word like you know what it means in a sentence, or you continue to study to ensure you understand it. That's not a fight, it's something an individual must resolve within themselves.
Congratulations, you've just discovered one major problem in prescriptivist linguistics: it just doesn't work.
Words change their meaning over time. Words with pretty clear and unambiguous definitions get re-purposed (often initially as a metaphor) or used in fuzzier and more ambiguous ways. This can happen as an import from one cultural context into another (where one use of that word develops entirely differently because there is no or only a small overlap between the population that originally used the word and the one that adopted it) or it can happen as a linear evolution in the same cultural context over time (see the euphemism treadmill).
Just as it is impossible to dictate one permanent definition across all cultures sharing (some variety of) the same language, it is also impossible to dictate the same across different sub-cultural jargons, even closely related ones (or even a single one, even if it involves only one person over time).
Isomorphic JS is a thing and its definition is unrelated to the definition of isomorphism in mathematics, computer science or anywhere else. And there's nothing you can do about it.
Just be happy that the term is relatively unlikely to collide with CS isomorphism because the context will generally make it clear which definition is being used. Other words weren't as lucky and lost their "original" meaning entirely.
Prescriptivism in linguistics is dead because linguists learned that it is futile and it's better to observe the actual meaning of words and how it changes than to insist that everybody is wrong about every word they use unless they follow a narrow set of rules derived from Latin (which, by virtue of being a dead language, is less likely to change a lot).
If you enjoy battling conflicting definitions, ponder the use of "transparency" in CS and politics some day.
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"?
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.
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?
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.
Exactly. The client and server share the bulk of the same code so the server is able to generate the initial response to a request and then the client can continue where the server left of by binding to DOM events, etc and handling further client-use of the app.
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.
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.
"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) 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)
The client in this case isn't a personal machine, it's the browser. Isomorphic apps can run both server side, and in the browser. Not that difficult of a concept
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.
No, since one of the bigger benefits of isomorphism is having fast initial page loads.
The standard SPA experience of having to wait for JS to download and execute before the page appears is terrible for large classes of apps (ex. media), and isomorphic JavaScript solves that while preserving the benefits of SPAs.
There's more to isomorphism than SEO; one code base that allows for both the initial html to be delivered without needing to run js and responsiveness of a client-side app is my favorite feature of isomorphic javascript apps.
nice - I was tracking this in the context of my book on Backbone 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?
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?
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."
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.
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?
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/). 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.
[+] [-] quarterto|11 years ago|reply
[+] [-] emotionalcode|11 years ago|reply
Anyone who wants to use words with the wrong intention (such as, sounding intelligent) will eventually realize they are only confusing themselves. It's having a spaghetti mind that occasionally voids itself. Pedantry aims to deconstruct spaghetti mind and carefully compose conceptual clarity.
You either drop a word like you know what it means in a sentence, or you continue to study to ensure you understand it. That's not a fight, it's something an individual must resolve within themselves.
[+] [-] pluma|11 years ago|reply
Words change their meaning over time. Words with pretty clear and unambiguous definitions get re-purposed (often initially as a metaphor) or used in fuzzier and more ambiguous ways. This can happen as an import from one cultural context into another (where one use of that word develops entirely differently because there is no or only a small overlap between the population that originally used the word and the one that adopted it) or it can happen as a linear evolution in the same cultural context over time (see the euphemism treadmill).
Just as it is impossible to dictate one permanent definition across all cultures sharing (some variety of) the same language, it is also impossible to dictate the same across different sub-cultural jargons, even closely related ones (or even a single one, even if it involves only one person over time).
Isomorphic JS is a thing and its definition is unrelated to the definition of isomorphism in mathematics, computer science or anywhere else. And there's nothing you can do about it.
Just be happy that the term is relatively unlikely to collide with CS isomorphism because the context will generally make it clear which definition is being used. Other words weren't as lucky and lost their "original" meaning entirely.
Prescriptivism in linguistics is dead because linguists learned that it is futile and it's better to observe the actual meaning of words and how it changes than to insist that everybody is wrong about every word they use unless they follow a narrow set of rules derived from Latin (which, by virtue of being a dead language, is less likely to change a lot).
If you enjoy battling conflicting definitions, ponder the use of "transparency" in CS and politics some day.
[+] [-] kaoD|11 years ago|reply
[+] [-] zefei|11 years ago|reply
"Isomorphic Javascript" is a bad choice of word because coffeescript/typescript feels more "isomorphic" to Javascript than client/server js libraries.
[+] [-] spacemanmatt|11 years ago|reply
And, that word they keep using to describe JavaScript, I do not think it means what they think it means.
[+] [-] markuskobler|11 years ago|reply
[+] [-] spion|11 years ago|reply
[+] [-] WorldWideWayne|11 years ago|reply
Using this word as a complete sentence where it only make sense vaguely to an internet person ruins its original usage.
(It's like starting with "This." It's stupid, you sound stupid and you should stop doing it, especially when you're being pedantic about words.)
[+] [-] mateuszf|11 years ago|reply
[+] [-] CmonDev|11 years ago|reply
[+] [-] pluma|11 years ago|reply
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.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] phaer|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] sim0n|11 years ago|reply
[+] [-] arianvanp|11 years ago|reply
[+] [-] pluma|11 years ago|reply
Not saying that doesn't work, in fact it works very well. It just means your server-side React code can't be async.
[+] [-] al2o3cr|11 years ago|reply
[+] [-] pluma|11 years ago|reply
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|11 years ago|reply
++ 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) 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|11 years ago|reply
> 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.
[+] [-] sehr|11 years ago|reply
[+] [-] kennu|11 years ago|reply
[+] [-] markuskobler|11 years ago|reply
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...
[+] [-] morgante|11 years ago|reply
The standard SPA experience of having to wait for JS to download and execute before the page appears is terrible for large classes of apps (ex. media), and isomorphic JavaScript solves that while preserving the benefits of SPAs.
[+] [-] xtrumanx|11 years ago|reply
[+] [-] poseid|11 years ago|reply
[+] [-] phaer|11 years ago|reply
[+] [-] knappador|11 years ago|reply
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|11 years ago|reply
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|11 years ago|reply
B) http://tron.wikia.com/wiki/ISO === isomorphic javascript
C) trivial pursuit of a buzz word === isomorphic javascript
D) All of the above.
[+] [-] steego|11 years ago|reply
[+] [-] bceagle|11 years ago|reply
First, as far as adoption, some of the other comments mention React, but Ember is also moving toward Isomorphic JS (see 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.