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

Our First Node.js App: Backbone on the Client and Server

nerds.airbnb.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Our First Node.js App: Backbone on the Client and Server

#61

Post by efnx »

frontendbeauty wrote: post #57
efnx wrote: post #56

Earlier quoted context omitted.

Not to mention SEO. The points outlined above in the top comment (* Caching of shared static HTML for fast-as-possible page loads. * Google indexing and searchability.* Backbone apps that feel more like a series of pages and less like a single-page app.) are all things that Rendr accomplishes that are already taken care of by not making a full blown client-side JS app. I think us developers are running into the same…

It sounds like you are really questioning the usefulness of client-side JS apps in general. Certainly not every app makes sense to be a "single-page app". But if you are creating a single-page app, then why not also allow it to render on the server? I like to think of Rendr as just another Backbone app, that happens to be able to serve HTML from the server as well.

Yes, I think I am too. I can see the need for a single page apps for really immersive applications like games or possibly for very small targeted applications like reading mail, or showing stats, but in the case of the latter you probably wouldn't run into ten seconds worth of loading scripts.

I think I'll understand when I run into the problem Rendr solves...

Re: Our First Node.js App: Backbone on the Client and Server

#62

Post by frontendbeauty »

ianstormtaylor wrote: post #59
frontendbeauty wrote: post #50

Earlier quoted context omitted.

Agreed, the underscore in the data-attribute isn't ideal. I initially tried to use camelCase, but alas, we often forget that DOM elements are case-insensitive: http://cl.ly/image/2c113k1h1L41

Why not stick to conventions and go with dashes? Underscores are out of place in Javascript and the DOM... If I'm going to be forced to use underscore_case in Rendr that's different than the rest of my codebase (or other codebases I don't control which are all camelCase in Javascript) it's going to feel more unclean from the start. Or you could say I'm not forced to use it, but now I'm using camelCase for variables a…

I'm open to that. Like I've said, there's definitely room for cleanup of the implementation. Either way, this isn't a detail that's exposed to the application developer.

Re: Our First Node.js App: Backbone on the Client and Server

#63

Post by spyder »

switz wrote: post #21

It's worth pointing out that DerbyJS already renders on the server and the client without any configuration. I implore you all to give it a shot. For an example, visit http://phishvids.com – try clicking around and then refreshing or even disabling javascript. [0] http://derbyjs.com

Nice, but it reinvents yet another templating which is hard to replace and seems to support only mongoDB :(

Re: Our First Node.js App: Backbone on the Client and Server

#65

Post by frontendbeauty »

ianstormtaylor wrote: post #60
dnajd wrote: post #55

I'm utterly confused. The main benefit of this approach is summed up in the paragraph: "Compare this with serving the full search results HTML from the server.... It feels 5x faster." But doesn't ruby on rails (and most other web stacks) already do server side rendering VERY well and are hugely supported by enormous communities. Javascript is useful for things like infinite scroll, interactive client side calendars o…

You're missing the part about how single-page, client-side apps are much more performant _once_ the page loads. Spike is trying to get the best of both worlds (hence "Holy Grail"). Server-side gives you fast page load times. Client-side gives you fast user interaction times.

Exactly.

Re: Our First Node.js App: Backbone on the Client and Server

#66

Post by dnajd »

ianstormtaylor wrote: post #60
dnajd wrote: post #55

I'm utterly confused. The main benefit of this approach is summed up in the paragraph: "Compare this with serving the full search results HTML from the server.... It feels 5x faster." But doesn't ruby on rails (and most other web stacks) already do server side rendering VERY well and are hugely supported by enormous communities. Javascript is useful for things like infinite scroll, interactive client side calendars o…

You're missing the part about how single-page, client-side apps are much more performant _once_ the page loads. Spike is trying to get the best of both worlds (hence "Holy Grail"). Server-side gives you fast page load times. Client-side gives you fast user interaction times.

That was the straw man I was thinking I saw in the post.

Why not use rails to load the page (no BYO framework involved) and then use javascript/backbone/etc on the client-side; as opposed to bringing the client-side technologies server-side to accomplish the same thing?

I'm thinking specifically of the search page example that was represented as a screenshot in this blog.

Re: Our First Node.js App: Backbone on the Client and Server

#67

Post by dnajd »

frontendbeauty wrote: post #57
efnx wrote: post #56

Earlier quoted context omitted.

Not to mention SEO. The points outlined above in the top comment (* Caching of shared static HTML for fast-as-possible page loads. * Google indexing and searchability.* Backbone apps that feel more like a series of pages and less like a single-page app.) are all things that Rendr accomplishes that are already taken care of by not making a full blown client-side JS app. I think us developers are running into the same…

It sounds like you are really questioning the usefulness of client-side JS apps in general. Certainly not every app makes sense to be a "single-page app". But if you are creating a single-page app, then why not also allow it to render on the server? I like to think of Rendr as just another Backbone app, that happens to be able to serve HTML from the server as well.

There is the straw man again. If you are creating a completely client side app and you find it's better to have some work done on the server side... why not use mature existing server side technology along with client side technologies. It's not a one or the other scenario.

Why work hard to move client-side technologies to the server? javascript is not so good that I want it on the server-side. And server-side lanaguages are not hard to learn or hard to find people that know how to use them.

Re: Our First Node.js App: Backbone on the Client and Server

#68

Post by fukyeah »

That's not the holy grail. I'll tell you what the holy grail is:

A web app that runs completely on CSS.

No need for stupid web servers, but since web servers are handy we'll build one with css.

And I scoff at HTML; but because of performance I made css compile to html too.

I'm working on a project that'll I'll be unveiling as my 'open source master piece'; It's just a little thing I call node.css. That's right, css bindings to C++. No more stupid C++ either.

Strap on some CSS build automation and what do you get? That's right, the holy grail. I'll call it CSS on Rails.

What's more, I've already done it and launched my current employers flagship product on it. Hope it doesn't screw the entire business over the long haul. Oh well, I can switch jobs if that happens and pretend I never posted this.

Post reply on HN