Views are not controllers. Views are more akin to presenters, or viewmodels. You are right that what is traditionally considered a "view" in the rails parlance is a template to backbone.
I think we all know that by now. Backbone doesn't subscribe to neither MVC or MVP. It takes what it needs and does away with the rest. Either you like that or you don't, but that doesn't make it wrong.
I originally came very close to doing just that ... but decided to call the Backbone.View a "View" because it's usually tied very concretely to a specific DOM element. From the perspective of your application, as you're working with the object, it feels like a view.
One of my co-workers comes from a strong server side MVC background; dealing with Backbone has confused him greatly as to the terminology and separation of concerns.
The break-through explanation I gave him is that Backbone views are DOM elements that are code-backed and adhere to OOP principles. They have constructors, properties, methods, etc. Ultimately, though, they are DOM elements. They can derive their content from templates, but they're still just code-backed DOM elements.
They sometimes behave as smart elements.. and sometimes they behave as controllers. Sometimes, depending on necessity, views get rendered and added to the DOM without templates at all (thus the nicety of tagName and attributes). Sometimes views necessitate a template because the result of the view is less dynamic, or merely appends more dynamic views and places them within placeholders in the template.
Point being.. They're not called controllers because they aren't controllers. They can behave as controllers, but... they're still not strictly controllers. The templates aren't called views because, although the UI is a result of the templates, they aren't always the sole source of the UI.
Backbone indeed lacks clear naming conventions if we are to stuff it in to an existing paradigm, but I have no need to do that - and I don't think you should try it either.
Yeah, I've started learning Django this week, and one of the first confusing questions I asked myself is "why are there so many templates?". Then I realized a template in Django is like a normal view in Rails or other frameworks.
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.
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.
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.
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...
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.
