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?
Our First Node.js App: Backbone on the Client and Server
11–20 of 69 posts
Re: Our First Node.js App: Backbone on the Client and Server
#12Re: Our First Node.js App: Backbone on the Client and Server
#13Re: Our First Node.js App: Backbone on the Client and Server
#14Doesn't have to be 100% Node.js front to back (you can still write your APIs in another language), but Node provides that handy bridge to get the server side rendering of client code.
Re: Our First Node.js App: Backbone on the Client and Server
#15Random 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 would be better to go with dashes as that is HTML attribute standard. That was the only part that looked sloppy to me.
Another thought: Did you guys experiment with event-based logic for postRender instead of pre-defined method hooks? I find the pre-defined method approach hacky feeling.
Re: Our First Node.js App: Backbone on the Client and Server
#16I was lucky to be able to catch a preview presentation of this "Holy Grail" project at SpainJS, last summer. It's very interesting stuff. I think that one of the more important caveats to mention is that to the extent that your application is composed of rich interactions, visualizations and interactivity, and logged-in-user-only content, that stuff tends to remain on the client-side alone ... but for your basic rend…
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 curious.
Re: Our First Node.js App: Backbone on the Client and Server
#17I've been looking for resources on when to use rails vs when to use node.js. I've been programming in ruby/rails for 2 years and picked up node about 9 months ago. Any tips or resources to learn which tool to use depending on the problem?
Re: Our First Node.js App: Backbone on the Client and Server
#18I was lucky to be able to catch a preview presentation of this "Holy Grail" project at SpainJS, last summer. It's very interesting stuff. I think that one of the more important caveats to mention is that to the extent that your application is composed of rich interactions, visualizations and interactivity, and logged-in-user-only content, that stuff tends to remain on the client-side alone ... but for your basic rend…
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…
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 "publishing" applications will melt very quickly if Rails ever ends up serving dynamic requests. Instead, you cache everything, either on disk with Nginx, in Memcached, or in Varnish.
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.
It's only a small step from there to pushing down the updates to Backbone models for active users ... but one step at a time, right? No need to couple those things together.
ps. Kudos to you for reading the source. It's always enlightening: https://github.com/angular/angular.js/blob/master/src/ng/roo...
Re: Our First Node.js App: Backbone on the Client and Server
#19Questions about session state management are popping up in my head but maybe that's some of the secret sauce in the Rendr portion of Airbnb's app.
Great work guys, this is really pushing the boundaries of full stack app development with js.
Re: Our First Node.js App: Backbone on the Client and Server
#20I was lucky to be able to catch a preview presentation of this "Holy Grail" project at SpainJS, last summer. It's very interesting stuff. I think that one of the more important caveats to mention is that to the extent that your application is composed of rich interactions, visualizations and interactivity, and logged-in-user-only content, that stuff tends to remain on the client-side alone ... but for your basic rend…