Creating single page applications with RoR

Question 1

Your simple approach is essentially exactly what angular or backbone are doing, so yes you can build a single page app this way. However, your simple example would not be considered a single page app in my opinion. I would consider it simply a single page. A single page application has routes (multiple "pages" with different urls). To accomplish this, you would use javascript's window.location to manipulate the url when you change partials. You would have to handle nested routes and the case when the user goes directly to a subpage (like /contact) in their browser.

There are a lot of tricky edge cases to handle and it would probably be pretty time consuming to implement this on your own, so why not use a framework that was designed exactly for this? Rails is an awesome web development framework, but it is not designed for single page apps. Rails was designed to render html pages server side and a large portion of its code does just that. Building a single page app in rails means carrying a lot of dead weight. All you really need server side for a single page app is a JSON API and a static file server (like NGINX).

Moving the task of rendering dynamic html from the server side to the browser means a lot more javascript code. Its really easy to make a mess using plain jQuery. jQuery is a library, not a framework, meaning jQuery does not provide you with any structure, or code reuse patterns to keep things organized. Angular and Backbone are MVC frameworks, like Rails, but for the browser. They provide you code organization that is crucial for a well structured, testable, maintainable application. In purely jQuery applications, you often see code that handles the data model mixed in directly with DOM manipulation (the view). In an MVC framework, this would be considered sinful.

So really the question of whether you should use a front-end framework in building a single page app is the same question as should you use a back-end framework for building a traditional application. Should you use Rails or just plain Ruby? Sure, you could use just plain Ruby, just like you could use just plain jQuery, but why would you? No need to reinvent the wheel.

Question 2

You can get the illusion of a single page app with things like Tubolinks and its better cousin WiseLinks but it can be a real mess on both the client and server as you need lots of routes or route parameters so the server can render the right partials for the particular state the client is in. It becomes messy fast, sending back html and javascript to update the clients DOM properly and do transitions. I highly recommend avoiding it altogether.

It is generally better to keep your server just an API and use a client framework. The server becomes SO much simpler and that is always a good thing, plus you can also support native mobile apps too if needed.

I have had a lot of success with Ember despite an initial learning curve, it has very good abstractions including route/url state management, object property binding and observing, computed properties and handlebars templates and components. I also had Oauth2 authentication up and working in minutes. API authentication is something you will need to nail.

I didn't start out with Ember, but I was writing a very ambitious app in Backbone/Marionette and had quite a lot of difficulty composing my app trying to implement reusable components and managing application state. API authentication was not simple either and required a lot of complex custom code. I realised exactly the abstractions I needed and noticed Ember had pretty much nailed it proper and Backbone/Marionette was nowhere near what I needed, not to say it isn't useful for certain type of apps but I personally haven't looked back. I was able to get quick wins (i.e. a huge productivity increase) with Ember plus have a more powerful framework so I changed. The total code size is a lot smaller with Ember because the code I need to write is far less. Its food for thought when someone says framework ABC is larger than XYZ. Who cares when your app code is 3 times larger, harder to write and does less. Tiny frameworks are good if your app is small, or if its large and you have the time to implement or cobble together your own framework on top of it and think you can do a better job than those working on a more fully featured framework with more experience than you :) Just use the right tool for the job and remember your framework will likely be smaller than the images on the page so put it in perspective when concerning framework size.

All the web frameworks are undergoing heavy change so you will need to keep on top of things regardless of what you choose. The Ember documentation is very good, although I understand this was not always the case. I have avoided Ember Data which seems to be an ambitious and historically controversial aspect of Ember and instead used Ember Model as a low risk option which is working for me, ymmmv of course.

If you are already adept with another framework like Angular then stick with it if it works for you. There are so many to choose from so to single out Ember or Angular is unfair, all I say if your chosen framework works well for you then great, but if not there are good frameworks out there and I regard Ember as one of them based on my own experience, not because someone else says so.

To be completely impartial I would suggest you look at TodoMVC to compare and contrast frameworks if you are unsure but to be honest you wont know what things are really important until you start using it in anger. I would suggest short-listing 2 or 3 frameworks then mocking up your most critical views with the framework template language, defining some models that use fixture data and see what works best.