Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Isomorphic JavaScript: The Future of Web Apps

nerds.airbnb.com

Post reply on HN
Print view View original

51–60 of 123 posts

Re: Isomorphic JavaScript: The Future of Web Apps

#51

Post by wrongc0ntinent »

williamcotton wrote: post #23
pak wrote: post #19

Earlier quoted context omitted.

Whoa old man quarterto, who said the word ever belonged to math people in the first place? I could argue that math people have a bad habit of squeezing English words into strange contexts that corrupt the original meaning. Take "manifold" for instance, or "curl", or even something as harmless as "mode". They all meant perfectly fine things until the math people claimed them as their own. According to M-W "isomorphic"…

He has a point. The system they are describing in the article isn't even isomorphic. If it WAS, it wouldn't depend on node. To clarify, if it was a true example of isomorphism it wouldn't be contingent on a single runtime environment or language. A better example of isomorphism in computing would be two modules of code that perform the same function and have the same abstract interface but that are written in DIFFERE…

I don't see why different languages would matter. It's a matter of abstracting things from one system and having that abstracted set function in a different one. edit: To clarify, yes, the set would remain intact and functional in both systems.

Re: Isomorphic JavaScript: The Future of Web Apps

#52

Post by frontendbeauty »

michaelwww wrote: post #36

I'm having a brain freeze here. How do you render a DOM on the server and then push it out to the client? Convert in memory DOM to a text/html representation before sending?

There are a few options. Easiest is to just render HTML strings on the server, not actual DOM. But, you can also use a DOM implementation if you want to, like jsdom or PhantomJS, and then capture the outerHTML of an element as an HTML string to serve. But, that is slower. React.js has a nice middleground approach; it has a fast pure-JavaScript DOM abstraction that can emit either DOM (browser) or HTML (server).

Re: Isomorphic JavaScript: The Future of Web Apps

#53

Post by wrongc0ntinent »

frontendbeauty wrote: post #34
quarterto wrote: post #9

You keep using that word. I do not think it means what you think it means. Using precisely defined mathematical words in contexts where they only make sense vaguely to a layperson ruins their original usage. Make up a new word. Repurpose a shitty English word. But leave our damn maths words alone. Old man quarterto shakes his fist at you! Get off my smooth, compact lawn!

(author here) Good point. TBH, I have no idea what "isomorphic" means in the mathematical sense. I was inspired to use "isomorphic" from a 2011 article by Nodejitsu [1]. It seemed like a fine way to describe this approach. I would gladly use a better would if I were to find one. [1] http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

Technically, you're correct, see the biology and chemistry use of the word. But seeing how you're dealing with a mathematically inclined audience, there will be disapproval. I think it's a very useful concept in general, the more it gets out into the world, the better.

Re: Isomorphic JavaScript: The Future of Web Apps

#54

Post by williamcotton »

wrongc0ntinent wrote: post #51
williamcotton wrote: post #23

Earlier quoted context omitted.

He has a point. The system they are describing in the article isn't even isomorphic. If it WAS, it wouldn't depend on node. To clarify, if it was a true example of isomorphism it wouldn't be contingent on a single runtime environment or language. A better example of isomorphism in computing would be two modules of code that perform the same function and have the same abstract interface but that are written in DIFFERE…

I don't see why different languages would matter. It's a matter of abstracting things from one system and having that abstracted set function in a different one. edit: To clarify, yes, the set would remain intact and functional in both systems.

I've been thinking about this for the last few hours... and regardless of the language used, I think I'm finding the point of confusion!

isomorphic: modules that have the same abstract interface and functionality but that are written in different languages and executed in different runtimes

monomorphic: modules that have the same abstract interface and functionality and that are written in the same language and have the same runtime

heteromorphic: modules that have the same abstract interface and functionality and that are written in the same language but run in different runtimes

homomorphic: modules that have the same abstract interface and functionality but that are written in different langauges that run on the same runtime

See, the thing is... languages are compiled to runtimes, right? But they are transpiled to other languages...

There surface area of this discussion is very interesting and seems to have some interesting properties, and if you don't mind the math pun, it is truly a complex issue!

As for how to actually name these different things, I don't think I really mind... maybe isomorphic and monomorphic swap in the above definition... I've been reading some latin and greek roots to try and give them good names, but I'd love some suggestions!

For example, a function written in Scala that functions the same as a function written in JRuby and compiled to the JVM would be an example of a "homomorphism".

And a function written in JavaScript that is compiled to run in both node and the web browser is an example of "heteromorphism".

A function written in JavaScript that is compiled to run in the Ruby runtime is an example of "isomorphism".

Monomorphic would just be sort of like an identity property.

Also, I have no idea what I'm going on about, so please help me fix the language!

Maybe isomorphic IS the correct term for what is going on in the article, who knows? :)

Re: Isomorphic JavaScript: The Future of Web Apps

#55

Post by wmf »

Breefield wrote: post #27

I'm curious to see how this shared rendering between client/server plays out for non JS based frameworks such as Django, Rails, etc. I've been feeling the burn myself—the desire to fully switch to handlebars templates in my Rails app. The expensive part would be building my API out more than I have, because I rely on associations in Rails view renders. However, gaining 1 template engine to rule front & back.

There's a different approach that performs all rendering server-side and sends snippets of HTML to the browser to be woven into the existing page. I suspect that would be more natural for non-JS frameworks.

Re: Isomorphic JavaScript: The Future of Web Apps

#56

Post by esamek »

Randgalt wrote: post #43

Wasn't this the idea with GWT so many years ago? In GWT's case, it was Java on both sides. I don't believe that it solves the problem and I don't believe Javascript on both sides will solve the problem. This is a classic "impedance mismatch" like O/R mapping. At the end of the day, there may be no good, i.e. simple, solution. It is inherently difficult and messy.

GWT is not Java on both sides. Its Java on the server, Javascript on the client. The Java client side code compiles to Javascript...the abstraction is way greater than what OP is presenting. (JS & JS)

GWT is/was a terrible amount of overhead baggage, but had some brilliant event systems and DOM tricks for its day.

Re: Isomorphic JavaScript: The Future of Web Apps

#58

Post by camus2 »

frontendbeauty wrote: post #30
danpeddle wrote: post #11

Earlier quoted context omitted.

If you are building a service or API, then you can do that in whatever language you like. The natural language for writing client side apps is JS (ok, the only language, for now).

Correct. If you're already writing a bunch of JavaScript for the client-side, then just think about this approach as migrating some of that client, UI logic to the server.

but who writes clientside logic before serverside logic ?

Re: Isomorphic JavaScript: The Future of Web Apps

#59

Post by michaelwww »

frontendbeauty wrote: post #52
michaelwww wrote: post #36

I'm having a brain freeze here. How do you render a DOM on the server and then push it out to the client? Convert in memory DOM to a text/html representation before sending?

There are a few options. Easiest is to just render HTML strings on the server, not actual DOM. But, you can also use a DOM implementation if you want to, like jsdom or PhantomJS, and then capture the outerHTML of an element as an HTML string to serve. But, that is slower. React.js has a nice middleground approach; it has a fast pure-JavaScript DOM abstraction that can emit either DOM (browser) or HTML (server).

> Easiest is to just render HTML strings on the server

That's old school way. Sometimes old ways are presented as new, which confuses me.

> then capture the outerHTML of an element as an HTML string to serve

That makes sense. Do the fancy building on the server and then convert it for transport

> React.js

That sounds interesting. You answered my question enough that I can do more research. Thanks.

Post reply on HN