I was lucky to be able to catch a preview presentation of this "Holy Grail" project at SpainJS, last summer. It's <i>very</i> 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 rendering of JavaScript models to a flat HTML page, this is a great project to keep a close watch on. In particular:<p>* Caching of shared static HTML for fast-as-possible page loads.<p>* Google indexing and searchability.<p>* Backbone apps that feel more like a series of pages and less like a single-page app.<p>... are all things that are addressed quite neatly by Rendr.
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.<p>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 would be better to go with dashes as that is HTML attribute standard. That was the only part that looked sloppy to me.<p>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.
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.<p>For an example, visit <a href="http://phishvids.com" rel="nofollow">http://phishvids.com</a> – try clicking around and then refreshing or even disabling javascript.<p>[0] <a href="http://derbyjs.com" rel="nofollow">http://derbyjs.com</a>
This is really interesting, although I'm still new enough to node and complex JS apps that I'm struggling to take it all in. That being said, could a hack-ish approximation of what Airbnb is doing be accomplished by rendering the first call of an app in phantom.js and pushing it out in the response stream?<p>Questions 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.<p>Great work guys, this is really pushing the boundaries of full stack app development with js.
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.
That's not the holy grail. I'll tell you what the holy grail is:<p>A web app that runs completely on CSS.<p>No need for stupid web servers, but since web servers are handy we'll build one with css.<p>And I scoff at HTML; but because of performance I made css compile to html too.<p>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.<p>Strap on some CSS build automation and what do you get? That's right, the holy grail. I'll call it CSS on Rails.<p>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.
I'd much, much rather move Django to the client than JS to the server. With CoffeeScript, this would be more tolerable, but even sacrificing Python, I love Django's architecture so much I don't want to give it up.
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."<p>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.<p>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?<p>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.<p>Not trying to troll, just thought I'd throw this perspective out there.
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#...
The span !important font-family css rule is overriding the gist monospace css though. Reading code snippets in proxima-nova is .. a little tricky.<p>That said, very interesting article.<p>I wonder.. Has anyone tried rendering a page, and then bootstraping your initial Backbone models pulling data from the HTML?
Great article, especially in coming up with a clean way to reaching the holy grail. I remember seeing in Spike's tech talk some months back that they initially chose DerbyJS, but it seems from the blog post that they went with Express instead. Curious to find out why.
Really hoping EmberJS gets this feature as well. It's possible now (with some fancy hacks), but I've read they plan to bake it into the framework (along with tight rails integration). Basically it just comes down to generating the initial view HTML on the server (by running the initial api call and render), then subsequent calls would be handled by the client.<p>Doesn'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.
I was just thinking about this today. The web devs I'm working with are talking about ditching Rails entirely in favor of in-browser template rendering by JS. With a backend also in JS, it seems to clearly be a winning development environment for new projects today. Just the diminished learning curve would be enough for me to look closely at this. This is coming from a very non-front end guy, though, so I might be a little starry-eyed.
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?<p>Thanks!
If they add in some generators, and throw in node-webkit support, this could end up like Microsoft Volta[1].<p>[1] <a href="http://www.liveside.net/2007/12/05/microsoft-releases-volta-tech-preview/" rel="nofollow">http://www.liveside.net/2007/12/05/microsoft-releases-volta-...</a>
I'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?
Looks great!<p>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.
Excellent stuff, thanks a lot for sharing. The Airbnb tech talks have been great, you guys are breaking some great ground and it's cool that you're so enthusiastic to share your discoveries.