Isomorphic JavaScript(isomorphic.net)
isomorphic.net
Isomorphic JavaScript
http://isomorphic.net/
13 comments
Sigh. I think I'm losing this fight. https://news.ycombinator.com/item?id=6714666
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.
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.
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.
My reply to the same nitpick (but other guy, you're not alone!): https://news.ycombinator.com/item?id=8238504
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.
> 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.
> 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.
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.
People love fancy/misused words, but eventually those wear out and lose to simpler, non-confusing words. Don't worry.
"Isomorphic Javascript" is a bad choice of word because coffeescript/typescript feels more "isomorphic" to Javascript than client/server js libraries.
"Isomorphic Javascript" is a bad choice of word because coffeescript/typescript feels more "isomorphic" to Javascript than client/server js libraries.
> coffeescript/typescript feels more "isomorphic" to Javascript than client/server js libraries.
What do you mean?
I use exactly the same shape (iso-morph) of JS business logic code in client and server and most libraries work out of the box in both environments (unless unable to, such as raw TCP/UDP connections from the browser).
What do you mean?
I use exactly the same shape (iso-morph) of JS business logic code in client and server and most libraries work out of the box in both environments (unless unable to, such as raw TCP/UDP connections from the browser).
Argh. I am not a formal maths person but I understand the term well enough to use it correctly in a sentence.
And, that word they keep using to describe JavaScript, I do not think it means what they think it means.
And, that word they keep using to describe JavaScript, I do not think it means what they think it means.
You're using the word "sentence" incorrectly. It actually means "way of thinking" or "opinion".
See what I did there? Word usage changes over time. Deal with it.
Also: isomorphic meant something before the math term came to be. Isos = equal. Morph = shape. Isomorphic = same shape. It's used as a math term because it's trying to convey "same underlying shape", not the other way around.
Ranting about "isomorphic JavaScript" is like ranting about "group of people" because group means "a set of elements with a binary operation satisfying closure, associativity, identity and invertibility".
See what I did there? Word usage changes over time. Deal with it.
Also: isomorphic meant something before the math term came to be. Isos = equal. Morph = shape. Isomorphic = same shape. It's used as a math term because it's trying to convey "same underlying shape", not the other way around.
Ranting about "isomorphic JavaScript" is like ranting about "group of people" because group means "a set of elements with a binary operation satisfying closure, associativity, identity and invertibility".
Group has a common interpretation that I don't think is at great odds with the mathematical definition. 'Isomorphic' as they use it needs this common interpretation established a little better than "the same code runs on client and server" as written in ad copy.
If you think that is my opinion, I think you are correct. I don't feel terribly isolated here, though. But I haven't begun to rant.
If you think that is my opinion, I think you are correct. I don't feel terribly isolated here, though. But I haven't begun to rant.
You can't stop the proliferation of buzzwords.
Ajax used to explicitly refer to the use of XMLHttpRequest to communicate with the web server without requiring a full page reload (incidentally, XMLHttpRequest doesn't require the use of XML). Eventually it went on to mean "interactive stuff on web pages" (probably because "Ajax libraries" like jQuery are as much about abstracting away the DOM as they are about abstracting away XHR).
HTML 5 used to refer to the HTML part of the Web Applications spec of WHAT WG. But WHAT WG dropped the version number (and the W3C has actually moved on to HTML 5.1 for the newer features) and most people say "HTML5" when they actually mean unrelated technologies like new browser APIs or "CSS3" (which isn't really a thing anymore because CSS was split into tiny modules, some of which are already at level 4 rather than 3).
The meaning of words changes. Especially when those words are used by groups outside of the (possibly much smaller) group that originally defined them. Resistance is futile. Deal with it.
Ajax used to explicitly refer to the use of XMLHttpRequest to communicate with the web server without requiring a full page reload (incidentally, XMLHttpRequest doesn't require the use of XML). Eventually it went on to mean "interactive stuff on web pages" (probably because "Ajax libraries" like jQuery are as much about abstracting away the DOM as they are about abstracting away XHR).
HTML 5 used to refer to the HTML part of the Web Applications spec of WHAT WG. But WHAT WG dropped the version number (and the W3C has actually moved on to HTML 5.1 for the newer features) and most people say "HTML5" when they actually mean unrelated technologies like new browser APIs or "CSS3" (which isn't really a thing anymore because CSS was split into tiny modules, some of which are already at level 4 rather than 3).
The meaning of words changes. Especially when those words are used by groups outside of the (possibly much smaller) group that originally defined them. Resistance is futile. Deal with it.
This probably won't help but it makes for a great quote when speaking about around this topic.
Unfortunately yes. Hopefully this is just a fad and people will grow out of it.
The word "Sigh" is not a complete sentence.
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.)
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.)
The point of punctuation is to convey where pauses and breaths should be taken when reading something (at least in this sort of context). If it makes sense to read it, then it is fine.
As an example, I could have left that comma out of the previous sentence. But having it there tells you how to read the sentence the way that I heard it in my head.
As an example, I could have left that comma out of the previous sentence. But having it there tells you how to read the sentence the way that I heard it in my head.
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
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.
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.
> 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.
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.
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.
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.
Such beauty: http://wtfjs.com
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).
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).
All languages are not equal, but "better" or "worse" depend on the opinion of the person asked much more than you're implying.
Not all opinions are equal.
True. Some are based on evidence.
But you still haven't shown any and the only thing mentioned in this thread is a collection of "WTFs" that range from obscure facts (which you will find in pretty much any language that has been around for a while) and novices being astonished that the language doesn't always do what they think it would do because they treat it like a different language they already know (IOW being lazy).
But you still haven't shown any and the only thing mentioned in this thread is a collection of "WTFs" that range from obscure facts (which you will find in pretty much any language that has been around for a while) and novices being astonished that the language doesn't always do what they think it would do because they treat it like a different language they already know (IOW being lazy).
[deleted]
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?
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.
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.
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.
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.
> 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.
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.
[deleted]
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.
React can run both on client and server as well! Would like to see it in the list.
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.
Not saying that doesn't work, in fact it works very well. It just means your server-side React code can't be async.
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.
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.
Isomorphic Javascript: for when you've decided that the 1993 Netscape engineers managed to produce the perfect language for programming computers.
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.
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.
-- 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) 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)
++ 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)
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.
> 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.
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
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
> 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.
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.
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
> 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
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.
In the context of JavaScript, it should be fairly obvious that the "client" is a web browser.
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
- - -
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 "hmm, maybe I'm missing something here"
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 me saying my interpretation was meaningless again
and then you finally tell me my interpretation was wrong. I think I know its wrong.
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
- - -
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 "hmm, maybe I'm missing something here"
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 me saying my interpretation was meaningless again
and then you finally tell me my interpretation was wrong. I think I know its wrong.
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
> Isomorphic apps can run both server side, and in the browser.
let me explain my issues with a couple questions:
"in what way?" and "oh, how so?"
let me explain my issues with a couple questions:
"in what way?" and "oh, how so?"
The learn more page links here: http://nerds.airbnb.com/isomorphic-javascript-future-web-app...
Isn't the greatest site though. Looks like it was started and then abandoned around March
Isn't the greatest site though. Looks like it was started and then abandoned around March
that is the start and end of my point. the site is poorly made, and other than being a collection of links, provides little else
make-and-forget-unless-it-becomes-popular
make-and-forget-unless-it-becomes-popular
But will isomorphism die now that Google is capable of indexing the content rendered by JavaScript apps on the browser?
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...
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...
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.
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?
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/
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."
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.
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.
A) code reuse === isomorphic javascript
B) http://tron.wikia.com/wiki/ISO === isomorphic javascript
C) trivial pursuit of a buzz word === isomorphic javascript
D) All of the above.
B) http://tron.wikia.com/wiki/ISO === isomorphic javascript
C) trivial pursuit of a buzz word === isomorphic javascript
D) All of the above.
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.
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.