7 ms·

Isomorphic JavaScript

36 points by tilt 12y ago

poseid 12y ago
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 12y ago
  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 12y ago
    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/
kennu 12y ago
But will isomorphism die now that Google is capable of indexing the content rendered by JavaScript apps on the browser?
- markuskobler 12y ago
  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-isomorphic-spa https://speakerdeck.com/markuskobler/react-the-importance-of...
- xtrumanx 12y ago
  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.
- morgante 12y ago
  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.
phaer 12y ago
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?
- sim0n 12y ago
  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.
- morgante 12y ago
  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 12y ago
    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 12y ago
      > 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 12y ago
React can run both on client and server as well! Would like to see it in the list.
- pluma 12y ago
  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 12y ago
    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.
mateuszf 12y ago
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
quarterto 12y ago
Sigh. I think I'm losing this fight. https://news.ycombinator.com/item?id=6714666 https://news.ycombinator.com/item?id=6714666
- markuskobler 12y ago
  This probably won't help but it makes for a great quote when speaking about around this topic.
- kaoD 12y ago
  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 12y ago
    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 12y ago
      > 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.
- emotionalcode 12y ago
  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.
CmonDev 12y ago
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 12y ago
  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 12y ago
    > 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.
RubyPinch 12y ago
-- 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 12y ago
  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 12y ago
    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
bceagle 12y ago
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.
steego 12y ago
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?
al2o3cr 12y ago
Isomorphic Javascript: for when you've decided that the 1993 Netscape engineers managed to produce the perfect language for programming computers.
- pluma 12y ago
  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.
knappador 12y ago
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."
ChaoticGood 12y ago
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.

36 points by tilt 12y ago

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 12y ago
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 12y ago
  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/

kennu 12y ago

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

markuskobler 12y ago
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-isomorphic-spa https://speakerdeck.com/markuskobler/react-the-importance-of...
xtrumanx 12y ago
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.
morgante 12y ago
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.

phaer 12y ago

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?

sim0n 12y ago
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.
morgante 12y ago
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 12y ago
  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 12y ago
    > 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 12y ago

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

pluma 12y ago
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 12y ago
  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.

mateuszf 12y ago

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

quarterto 12y ago

Sigh. I think I'm losing this fight. https://news.ycombinator.com/item?id=6714666 https://news.ycombinator.com/item?id=6714666

markuskobler 12y ago
This probably won't help but it makes for a great quote when speaking about around this topic.
kaoD 12y ago
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 12y ago
  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 12y ago
    > 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.
emotionalcode 12y ago
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.

CmonDev 12y ago

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 12y ago
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 12y ago
  > 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.

RubyPinch 12y ago

-- 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 12y ago
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 12y ago
  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

bceagle 12y ago

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.

steego 12y ago

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?

al2o3cr 12y ago

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

pluma 12y ago
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.

knappador 12y ago

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."

ChaoticGood 12y ago

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.