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

111–120 of 123 posts

Re: Isomorphic JavaScript: The Future of Web Apps

#111

Post by pmelendez »

pak wrote: post #19
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!

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

>"According to M-W "isomorphic" has pre-existing definitions from medicine and chemistry"

That link doesn't say that those definitions were "pre-existing". They say the first use was on 1862 but failed in specifying in which context was used first.

Re: Isomorphic JavaScript: The Future of Web Apps

#112

Post by michaelwww »

hackerboos wrote: post #85
michaelwww wrote: post #49

Earlier quoted context omitted.

I understand node.js with V8 and also Phantom JS but how does a client browser view the DOM rendered on the server is what I'm asking. I'm guessing it gets rendered and serialized to JSON for transport, but I could be over-thinking it. Server side rendering is the same as it ever was, just with new tools.

>I understand node.js with V8 and also Phantom JS but how does a client browser view the DOM rendered on the server is what I'm asking. It's returned in the request as HTML if the USER_AGENT matches Googlebot just like it would in a normally non-SPA web app.

Then I don't understand the problem with SEO because we can feed the crawlers whatever HTML is relevant for search engines

Re: Isomorphic JavaScript: The Future of Web Apps

#113

Post by williamcotton »

michaelwww wrote: post #112
hackerboos wrote: post #85

Earlier quoted context omitted.

>I understand node.js with V8 and also Phantom JS but how does a client browser view the DOM rendered on the server is what I'm asking. It's returned in the request as HTML if the USER_AGENT matches Googlebot just like it would in a normally non-SPA web app.

Then I don't understand the problem with SEO because we can feed the crawlers whatever HTML is relevant for search engines

The issue is that frameworks like Angular and Ember generate markup AFTER the HTTP GET response has been returned.

If a crawler executes the web page without a full Javascript context it will miss out on the intended content.

Re: Isomorphic JavaScript: The Future of Web Apps

#114

Post by frontendbeauty »

bpizzi wrote: post #93
frontendbeauty wrote: post #34

Earlier quoted context omitted.

(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

Shall "multiplateform javascript [code]" be suitable here? Looks like this is all it's about: having a single js code generating the same results, with no dependance on the plateform.

I like "multiplatform" -- current winner :)

Re: Isomorphic JavaScript: The Future of Web Apps

#115

Post by frontendbeauty »

CmonDev wrote: post #95
frontendbeauty wrote: post #30

Earlier quoted context omitted.

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.

To have two problems instead of one?

There are already two problems, if you're building a rich client-side web app. Have you done this? If so, you would understand the problem.

Re: Isomorphic JavaScript: The Future of Web Apps

#116

Post by frontendbeauty »

JDDunn9 wrote: post #76

So then you couldn't use a CDN to load your JS files, which might kill your performance gains. How does this change loading partials? I disagree about the complexity. I've build Angular apps with a RESTful backend that couldn't be simpler. I also haven't noticed any performance issues. It's faster than traditional sites for me. SEO is a problem though.

Why couldn't you use a CDN for the JS files? We most certainly do.

Re: Isomorphic JavaScript: The Future of Web Apps

#117

Post by spikels »

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

There are only two hard things in Computer Science: cache invalidation and naming things.

A few ideas:

"End-to-End JavaScript" - popular but not exactly what you mean but close

"Run Anywhere JavaScript"

"Write Once JavaScript"

"Two Sided JavaScript" - server-side and browser-side

"Browse-N-Serve Javascript"

Re: Isomorphic JavaScript: The Future of Web Apps

#118

Post by sitkack »

lennel wrote: post #68
sitkack wrote: post #44

Earlier quoted context omitted.

Why not render the templates in PhantomJs and have a user account that can push the rendered template back into the server cache. No need to duplicate the work of writing two backends. Or hell, just use Rhino and generate the reified pages on the server. Also, you can't patent this now.

The soy templates have a java (tofu) backend already (several years old). The phantomjs idea is a shit idea and should go away. Phantom is fine and good for headless testing (hells we use it for quite a bit else) but seriously it is not a solution for a real load.

In my scenario an alternative (Rhino or PhantomJs) engine would generate a page once and then push that rendered page to the server. No real load would be sent to it. Single code path for all template rendering. Zero cross implementation bugs and the client still gets a fully reified page on first load.

Shit idea, lil harsh.

Re: Isomorphic JavaScript: The Future of Web Apps

#119

Post by peterhunt »

sitkack wrote: post #118
lennel wrote: post #68

Earlier quoted context omitted.

The soy templates have a java (tofu) backend already (several years old). The phantomjs idea is a shit idea and should go away. Phantom is fine and good for headless testing (hells we use it for quite a bit else) but seriously it is not a solution for a real load.

In my scenario an alternative (Rhino or PhantomJs) engine would generate a page once and then push that rendered page to the server. No real load would be sent to it. Single code path for all template rendering. Zero cross implementation bugs and the client still gets a fully reified page on first load. Shit idea, lil harsh.

Shit idea is a little harsh for sure, but the problem is when your page relies on dynamic data and you can't prerender it. It's just too expensive to boot up a DOM on the server.

Re: Isomorphic JavaScript: The Future of Web Apps

#120

Post by acjohnson55 »

CmonDev wrote: post #97
markc wrote: post #66

Earlier quoted context omitted.

Consider Clojure - an interesting language indeed, and the browser variant (ClojureScript) is gaining lots of interest.

Make it native across major browsers - that would be cool. At the moment it's just another transpiler.

I'm not sure anything's fundamentally wrong with transpilation.
Post reply on HN