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

71–80 of 123 posts

Re: Isomorphic JavaScript: The Future of Web Apps

#71

Post by gsg »

siegecraft wrote: post #12
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!

I just assumed it meant the opposite of polymorphic, but no it's not even related to that..

It is related, really.

Polymorphic: many shaped. Monomorphic: single shaped. Isomorphic: same shaped.

Re: Isomorphic JavaScript: The Future of Web Apps

#72

Post by mindcrime »

Now, the Web has matured into a fully-featured application platform, and fast JavaScript runtimes and HTML5 standards have enabled developers to create the rich apps that before were only possible on native platforms.

Eh, saying "matured into" implies that the current state is somehow better or more desirable than the previous state, and somewhat implies that this was the expected / desired goal state. I reject all of those implications. I posit that it would be more correct to say that "the Web has been mangled, bent, distorted, twisted and hacked into a fully-featured application platform..."

A Web browser should be good at browsing, trying to make it into an application runtime is a "separation of concerns" violation of the first magnitude. It might work, but let's not pretend there aren't other choices, or forget to continue researching alternative approaches to delivering applications over the Internet.

Re: Isomorphic JavaScript: The Future of Web Apps

#73

Post by akbar501 »

AirBnB's Rendr library is not a JavaScript, and only JavaScript solution. It is however a library that allows you to mostly unite your web rendering layers on the web client and application server.

Look at the first diagram in the article and you'll notice that the author shows 3 environments:

1. Client (obviously the browser is JS) 2. Application Server (the server-side rendering environment = what he says can now change to JS thanks to Rendr) 3. API Server (use whatever you want here - JS, Java, Ruby, Python...)

And, in production you will no doubt need a "static" server as well (for rendering privacy, tos, etc. pages). Plus all of the other production systems (like a queue, stream processing, and so on) that are not JavaScript environments.

If you check out his example code you'll see that he actually sets up example 04 (https://github.com/airbnb/rendr/blob/master/examples/04_entr...) with a subapp for a static page.

Also, if you look at the react-moment branch in the isomorphic tutorial repo (https://github.com/spikebrehm/isomorphic-tutorial/blob/react...) you'll see that he's proxying a dummy API server to a route on the application server.

Re: Isomorphic JavaScript: The Future of Web Apps

#74

Post by icebraining »

frontendbeauty wrote: post #28
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.

(OP here) Probably your best bet is to create a small Node web service that takes a template name and data and returns HTML. Then your (Rails, Python, PHP) app can call out to that in the request cycle. Instagram.com does something similar; it's a Django app.

Seems to me that the approach with best separation of concerns would be to redirect the initials requests directly to node, which would then call the Python/Ruby/etc API to get the data to render the template. After that, the browser JS could call the API directly, and so the latter would never have to know about templates at all.

Re: Isomorphic JavaScript: The Future of Web Apps

#76

Post by JDDunn9 »

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.

Re: Isomorphic JavaScript: The Future of Web Apps

#77

Post by babby »

hippich wrote: post #67

Funny thing, had related talk today with my co-worker... Anyway, so problem currently is that client devices are slow and HTTP requests are expensive/slow. If these were not issues - I guess rendering on a client would be just fine? If above is correct, I do not see good reason for smallish websites/apps/whateverucallit fallback on server rendering, as it looks like every single year mobile devices getting faster and…

> 3 second to get HTML

No server should take more than 100ms-500ms on a sufficiently cached page to process and to begin transferring, in non-edge cases. The only thing that could take that long is a shitty datacenter/vps, and as such, transfer speed/latency limits will encumber all types of requests.

In the end, you still have to transfer data from databases, so ignoring that, client-side template rendering seems like a non-issue to me. Surely it's never the latency issue unless you're serving at ~100+ requests per second, which translates to many millions of requests a day, and I don't believe 99% of websites are doing this.

Re: Isomorphic JavaScript: The Future of Web Apps

#78

Post by btilly »

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

I like relocatable JavaScript.

Re: Isomorphic JavaScript: The Future of Web Apps

#79

Post by spion »

lucasjans wrote: post #60

Conspicuously absent from the author's article was Angular. What is it about Angular that doesn't lend itself to this dual purpose frontend and backend infrastructure?

Lots of potential hidden state as well as the need to support the entire DOM API server-side. For example, directives may add hidden state to the DOM and assume full availability of DOM API (even jQuery). The server will have to support all that

Also, you'll have to re-do the entire rendering on the client, then swap the server-generated DOM with the client-generated DOM. Its probably possible - but is it worth the effort?

Post reply on HN