Our First Node.js App: Backbone on the Client and Server • Hacker News Board

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

#51

Post by frontendbeauty » Wed, Jan 30, 2013, 6:33 PM UTC

enoughalready wrote: post #43

Hey guys, looks pretty good. I'm interested in the decision to move to server side templating. You mention that the loading of js, then making an ajax call, then rendering the page, was slower than just serving up html. Did you guys try bootstrapping json data server side? That way you could avoid making an ajax request on load. Do you have any perf numbers to share? Thanks!

Author here. So, yes, bootstrapping the JSON on initial pageload would be a lot faster than waiting for the Backbone.Router to fetch it (for the Rails + Backbone approach). But therein lies the problem I was talking about: to bootstrap the data for a particular URL, but to also have the client-side request the proper data for that URL in response to a pushState event, you end up needing to duplicate the mappings from app URLs to API resources on the client- and server-sides, and you need to be able to access the same API on both sides as well.

We avoid this with Rendr by defining routes, controllers, models, etc in a way that can be run on both sides.

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

#52

Post by mcgwiz » Wed, Jan 30, 2013, 6:41 PM UTC

Looks great!

I'd just like to note that those working on Backbone single-page apps hosted by an ASP.NET site can also achieve this idiomatically, with the use of the Nustache view engine and controller actions that can do HTTP content negotiation.

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

#53

Post by frontendbeauty » Wed, Jan 30, 2013, 7:08 PM UTC

gdonelli wrote: post #49

I was excited until I saw coffee script code

While the library (Rendr) is written in CoffeeScript, you would of course be able to write your application code in JavaScript, or anything that compiles down to it.

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

#54

Post by 2mur » Wed, Jan 30, 2013, 7:18 PM UTC

minikomi wrote: post #3

The span !important font-family css rule is overriding the gist monospace css though. Reading code snippets in proxima-nova is .. a little tricky. That said, very interesting article. I wonder.. Has anyone tried rendering a page, and then bootstraping your initial Backbone models pulling data from the HTML?

Here is an article about that:

http://lostechies.com/derickbailey/2011/09/26/seo-and-access...

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

#55

Post by dnajd » Wed, Jan 30, 2013, 7:41 PM UTC

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 or making browser based games; but a web search is absolutely simple in ROR and doesn't need backbone or javascript at all.

Don't get me wrong, I love javascript and backbone / angular. But why push logic to the client side for a search page and then try to pull client-side technologies back to the server side in an effort to resolve performance problems that are already solved by existing technology?

In the words of Carl Sagan "why not skip a step". Unless you just love javascript so much that you're willing to recreate rails on the server side with it. That would be a sensible reason to do it.

Not trying to troll, just thought I'd throw this perspective out there.

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

#56

Post by efnx » Wed, Jan 30, 2013, 7:48 PM UTC

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…

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 issues or pitfalls that we ran into during the rise of flash, where we move everything to the client because we can. The problems that Rendr is solving seems to be the same problems caused by giving too much responsibility to JS.

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

#57

Post by frontendbeauty » Wed, Jan 30, 2013, 8:39 PM UTC

efnx wrote: post #56

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…

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.

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

#58

Post by [deleted] » Wed, Jan 30, 2013, 8:53 PM UTC

jashkenas wrote: post #18

ianstormtaylor wrote: post #16

Earlier quoted context omitted.

Jashkenas, do you have any plans to venture into this area? I was just talking today about how I am tempted to try some of the other libraries that are going this direction. But that whenever I look at their code I'm envious of how clean Backbone is. Seriously the biggest turn-off to Angular is reading the code and seeing that people aren't as nit-picky, pseudo-OCD, whatever you want to call it as you are. Just curio…

I've got no immediate plans to play around with any Backbone-on-the-client-and-server stuff ... the next web app library in the works is only semi-related: The basic idea is that for many public-facing websites (think NYTimes, natch, or Airbnb's search result listings, for example), the usual Rails convention of "Hey, here comes a request, let me generate a page just for you", is fairly inappropriate. Lots of "publis…

[deleted]

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

#59

Post by ianstormtaylor » Wed, Jan 30, 2013, 9:15 PM UTC

frontendbeauty wrote: post #50

ludwigvan wrote: post #31

Earlier quoted context omitted.

> Random piece of feedback: it's weird to use data-model_id (instead of data-model-id) I have thought about this one too in my own applications, and I seem to switch back and forth. The good thing about using underscore is that the variable name can match on both sides of the expression: var model_id = $foo.data('model_id'); vs var model_id = $foo.data('model-id'); Mixing camelCase with dash seems a bit weird for me,…

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 and underscore_case for data attributes... so the two don't match, so why have the non-standard underscore_case at all.

(This would be an example of one of the things that makes libraries feel cludgy, and one of the reasons I love how consistent Backbone is, like I was talking about further up the thread with Jashkenas.)

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

#60

Post by ianstormtaylor » Wed, Jan 30, 2013, 9:18 PM UTC

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.