Isomorphic JavaScript

by tilt • 12 years ago

36 61 12 years ago

poseid2• 12 years ago

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?

phaer2• 12 years 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?

poseid2• 12 years 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/

kennu• 12 years ago

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

markuskobler2• 12 years 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...

xtrumanx• 12 years 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.

morgante6• 12 years 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.

phaer2• 12 years 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• 12 years 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.

morgante6• 12 years 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• 12 years 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.

arianvanp• 12 years ago

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

pluma10• 12 years 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.

pluma10• 12 years 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• 12 years 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

quarterto2• 12 years ago

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

markuskobler2• 12 years ago

This probably won't help but it makes for a great quote when speaking about around this topic.

kaoD4• 12 years ago

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

quarterto2• 12 years 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.

emotionalcode• 12 years 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.

spion• 12 years ago

Unfortunately yes. Hopefully this is just a fad and people will grow out of it.

zefei• 12 years ago

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.

kaoD4• 12 years ago

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

spacemanmatt2• 12 years ago

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.

kaoD4• 12 years ago

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

pluma10• 12 years ago

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.

WorldWideWayne• 12 years ago

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

tcfunk• 12 years ago

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.

CmonDev2• 12 years 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"?

pluma10• 12 years 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.

frowaway0013• 12 years 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.

RubyPinch6• 12 years 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) 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)

morgante6• 12 years 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.

RubyPinch6• 12 years 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

sehr2• 12 years ago

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

RubyPinch6• 12 years ago

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

bceagle2• 12 years 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/). 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• 12 years 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• 12 years ago

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

pluma10• 12 years 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• 12 years 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."

bceagle2• 12 years ago

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

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

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

ChaoticGood• 12 years ago

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.

Isomorphic JavaScript

Related Stories