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

31–40 of 123 posts

Re: Isomorphic JavaScript: The Future of Web Apps

#31

Post by frontendbeauty »

gmjoe wrote: post #17

This smells like over-engineering to me... In my experience, including rendering code both server-side and client-side is overkill. Just put all the rendering and templating code client-side, period. If you want your page to appear more quickly, then instead of loading content data with AJAX afterwards, just include JSON arrays of content directly within the HTML source itself, and use JavaScript to populate the page…

The approach you mention is much easier. However, it does make for slower perceived page load times, even when serializing JSON on the page, because the browser has to fetch, parse, and evaluate JS files before rendering the HTML into the document. This can take many hundreds of milliseconds, especially on mobile devices.

In my experience, server-side rendering has led to a much better UX.

Re: Isomorphic JavaScript: The Future of Web Apps

#32

Post by frontendbeauty »

avolcano wrote: post #5

My main concern - how does application state get handed off to the client-side code after the initial render? Sure, it's nice to have some pre-rendered templates, but at some point it needs to "transition" cleanly to the client.

(author here) We just bootstrap some JSON onto the page to transfer application state to the client. It's the same approach as the `express-state` (mentioned in a below comment). Same as any client-side app.

Re: Isomorphic JavaScript: The Future of Web Apps

#33

Post by [deleted] »

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…

[deleted]

Re: Isomorphic JavaScript: The Future of Web Apps

#34

Post by frontendbeauty »

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

Re: Isomorphic JavaScript: The Future of Web Apps

#35

Post by williamcotton »

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

How about "monomorphic", having or existing in only one form?

Re: Isomorphic JavaScript: The Future of Web Apps

#37

Post by williamcotton »

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?

You could use something like Phantom JS.

To iterate a point in the article, a number of client-heavy sites built on Angular and Ember have been rendering their content on the server-side to be presented to crawlers like the Googlebot for SEO purposes.

Re: Isomorphic JavaScript: The Future of Web Apps

#38

Post by williamcotton »

themanr wrote: post #10

A great thing about the web is that a multitude of server side languages can be used. While I don't ever want to have to write the same template twice, having everything converge on nothing but Javascript doesn't seem like a very inspiring future to me.

I whole heartedly agree and lately I've been getting worried that too many people in the web community are onboard with a node-centric view of the browser...

It may the same language, but the runtimes are completely different and have incredibly different use cases and environments. Not only that but I'd rather have a healthy ecosystem where the Unix runtime, .NET runtime, JVM runtime, and even interpretive runtimes that are built on top of those runtimes likes Ruby, Python and JavaScript are all considered equally!

That is closer in line to what the real definition of isomorphism is describing. :)

Re: Isomorphic JavaScript: The Future of Web Apps

#39

Post by sgdesign »

gmjoe wrote: post #17

This smells like over-engineering to me... In my experience, including rendering code both server-side and client-side is overkill. Just put all the rendering and templating code client-side, period. If you want your page to appear more quickly, then instead of loading content data with AJAX afterwards, just include JSON arrays of content directly within the HTML source itself, and use JavaScript to populate the page…

I think the idea is that the same bit of code would be running both on the server and/or the client, depending on what you need. So it wouldn't require any more work on the end developer's part.

Re: Isomorphic JavaScript: The Future of Web Apps

#40

Post by williamcotton »

There is a confusion between isomorphism and monomorphism when it is related to JavaScript as it runs in the web browser runtime compared to the node runtime.

I feel this tension is at the root of the CommonJS vs AMD discussions that have been taking place recently as well as issues related to npm, bower, and browserify.

Monomorphic code, while being very easily shared amongst different runtimes, still needs to aware of the mechanisms, strengths, and weaknesses of those runtimes!

Projects like browserify-cdn and sites built with on top of it like requirebin.org do a lot to bridge the gap but raise some interesting questions about wrappers like UMD.

I feel there is room for a better protocol for sharing code between the different environments.

I'm currently doing some research on the subject and plan on writing a spec and implementing some example interfaces.

BTW, projects like Bower head in the opposite direction and seem painfully unaware of their actual context...

I mean, installing a package manager to then install a package manager should raise some eyebrows, right?

Post reply on HN