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

41–50 of 69 posts

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

#41

Post by JPKab »

fourstar wrote: post #7
mmahemoff wrote: post #6

Fantastic. This kind of thing, and Meteor, is really what Node is made for. Till recently, Node web frameworks mostly been "let's do RoR or Sinatra, but look it's in JS! #Neat". Sure, there's some benefit in terms of developer skill set and avoiding schizophrenic context-switching; but still, the great promise of SSJS is running the same actual code on both sides.

To be honest, Meteor is nice and a very ambitious project but the fact that you are writing an application with it means you are probably wedded to it. That's why I've been using Express for my middleware, npm modules as needed, and mongoose as my db wrapper (or if I want to switch it out for redis, I can do so easily). Not sure how easily I can port my "meteor app" to a different framework that comes along.

I've been playing with Meteor lately, and I can certainly see some element of lock in when using it. That scares me naturally. However, the positives are: 1) Speed: It is insane how little work has to be done to stand something up that is decent and funtional 2) Packages: Not a long list, but the ones that exist are ridiculously easy to implement.

Seriously, the sheer amount of work that you end up NOT doing almost makes it feel like cheating. I can completely understand why people don't like it. I fully intend to build something in Derby soon, and to examine Rendr. But I'm wanting to build an enterprise focused metadata management app, and Meteor seems to me to be the right way to go, because at the end of the day I just want to get something built that provides a capability.

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

#42

Post by Hupo »

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…

>But you know when the data is changing -- when an article has been updated and republished ... or when you've done another load of the government dataset that's powering your visualization. Waiting for a user request to come in and then caching your response to that (while hoping that the thundering herd doesn't knock you over first) is backwards, right?

>I think it would be fun to play around with a Node-based framework that is based around this inverted publishing model, instead of the usual serving one. The default would be to bake out static resources when data changes, and you'd want to automatically track all of the data flows and dependencies within the application. So when your user submits a change, or your cron picks up new data from the FEC, or when your editor hits "publish", all of the bits that need to be updated get generated right then.

You mean most things don't already do this? I've been working on a personal blog engine with this as one of the core ideas (basically all static assets and pages are compiled on edit), and I thought it was a pretty obvious way to go about it. Looks like I'm indeed not the only one to think of it, but how "new" you present the idea as is a bit surprising to me.

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

#43

Post by enoughalready »

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!

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

#45

Post by lnanek2 »

This sort of integration has been happening more and more with the data format as well for me. After around the third mobile client for a server I'm tired of native data models and just want the closest thing to the server's (and the DB's in the case on Mongo) JSON. I don't need it repeated in SQL DML, JSON, Java, Objective-C, C#...

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

#46

Post by btown »

fourstar wrote: post #7
mmahemoff wrote: post #6

Fantastic. This kind of thing, and Meteor, is really what Node is made for. Till recently, Node web frameworks mostly been "let's do RoR or Sinatra, but look it's in JS! #Neat". Sure, there's some benefit in terms of developer skill set and avoiding schizophrenic context-switching; but still, the great promise of SSJS is running the same actual code on both sides.

To be honest, Meteor is nice and a very ambitious project but the fact that you are writing an application with it means you are probably wedded to it. That's why I've been using Express for my middleware, npm modules as needed, and mongoose as my db wrapper (or if I want to switch it out for redis, I can do so easily). Not sure how easily I can port my "meteor app" to a different framework that comes along.

Agreed. You can still get a lot of the code-reuse benefits without lock-in by using tools like Browserify and Socket.io. With Browserify (or any of the other CommonJS packagers), I can use the same lib directory for both my client and server code, and all my utilities/templates/validators/algorithms/NPM modules work on both. One of the most awesome things about Socket.io that's not really emphasized in the docs is that the API for client and server is almost exactly the same, so you can change your mind almost on a whim whether you want a certain RPC to work on the client or the server.

To me, it's a lot easier to "grok" exactly what's going on when you're using a simple middleware layer and a simple socket framework, than when you're using a full-stack solution like Meteor.

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

#47

Post by rapind »

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…

"But you know when the data is changing -- when an article has been updated and republished ... or when you've done another load of the government dataset that's powering your visualization. Waiting for a user request to come in and then caching your response to that (while hoping that the thundering herd doesn't knock you over first) is backwards, right?"

I'm not trying to pick a fight or anything, but it sounds like you're arguing against lazy loading?

Eager caching is very situational, and not something you want to do unless you can reasonably anticipate the thundering herd or have very few items or have unlimited resources to generate and store a complete cache.

I'm probably misunderstanding though.

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

#48

Post by bkirkbri »

Hupo wrote: post #42
jashkenas wrote: post #18

Earlier quoted context omitted.

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…

>But you know when the data is changing -- when an article has been updated and republished ... or when you've done another load of the government dataset that's powering your visualization. Waiting for a user request to come in and then caching your response to that (while hoping that the thundering herd doesn't knock you over first) is backwards, right? >I think it would be fun to play around with a Node-based fram…

For simple problem domains (Blog, Mom and Pop store website, etc) it's trivial to pre-generate content. For larger content systems you can run into a more complicated dependency tree. Then you have the choice between keeping the dependency logic accurate vs regenerating the entire content set on any change.

It also turns out that content sets that change infrequently, but also unpredictably are a pain to cache. You can cache them for a short time (as long as stale content can be tolerated), but then you lose cache effectiveness. Or you can cache it forever with some sort of generation/versioned cache, but that doesn't interface with named, public resources very well. Telling your visitors and Google that it's yourdomain.com/v12345/pricing not yourdomain.com/v12344/pricing doesn't really fly.

I definitely concur with your surprise about it being novel though. I think that for many situations it's just easier to run extra boxes to handle the increased load of generating dynamic content on the fly over and over again. It's good for SuperMicro and AWS. It's not so good for the planet.

I'm very excited to see Jeremy's approach to addressing the problem.

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

#50

Post by frontendbeauty »

ludwigvan wrote: post #31
ianstormtaylor wrote: post #15

This is exactly what I've been waiting for. I can't wait til this is open-sourced! Was just thinking about trying out Angular because Backbone just wasn't cutting it, but this is going to make me hold out. Random piece of feedback: it's weird to use data-model_id (instead of data-model-id). I assume you're trying to match some pre-existing naming convention (but JS tends towards camelCase anyways...), but I think it…

> 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

Post reply on HN