1

Personally Coffeescript is ok, but I would rather it be a supporting player in my Rails app, not most of the logic. From what I can see, you still have to duplicate a lot of the logic when using Backbone.js or Spine.js in Rails. Can I not get the benefits of these frameworks or make what is essentially a single page app with js for real time updates using just rack-pjax?

Charles
  • 50,943
  • 13
  • 104
  • 142
user1149547
  • 349
  • 4
  • 10
  • "Do you need"? No, Javascript was and is written without MVC. Would it be beneficial? Possibly. Is it overkill for you? Nobody can say but you. – deceze Feb 11 '12 at 01:41
  • no there are other options, App Engine, Pyjamas, Cappuccino. Single page web apps typically are pursued using larger frameworks. Of course, if writing your own is easier then learning one do that! Or if the single page app is relatively simple just use javascript and ajax. – Derek Litz Feb 11 '12 at 03:50

2 Answers2

1

Well what do you want to achieve? No more page refreshes? In that case rack-pjax should work. If you want more speed or a responsive UI then I'm afraid it won't be a good solution.

A single page app is preferred imo because it seriously decreases the load and complexity on the server + there is a nice abstraction between viewlogic & serverlogic.

Your server would basically be an API and your client would render all of the API data to the browser. This way the server is heavily simplified and has a lot less work to do. (win!)

On the client side we can also see a lot of improvements. If done right it rerenders itself continuously based on events and statechanges made to the data. This approach leads to much less coupling (and duplication) in your UI layer and a more responsive UI for the users. (win!)

If you don't care much about that then go ahead and use pjax :)

Keep in mind though that rewriting an existing server-side-view-rendering app to a single page app using a JS frontend is tricky business. It'll probably end up in a major rewrite. You could also experiment with writing just parts of your page in a JS frontend.

SpoBo
  • 2,100
  • 2
  • 20
  • 28
  • Client-side rendering typically shouldn't replace server-side rendering; only mirror it. Unless you absolutely don't care about older browsers and being crawlable by search bots. – devth Apr 02 '13 at 23:59
  • there are solutions like https://github.com/airbnb/rendr these days that handle those cases. haven't used it yet. – SpoBo Apr 03 '13 at 09:42
  • It depends on your requirements. For content heavy, yes it should mirror (and is why pjax is better I'm that scenario). If it's a web app, screw older browsers or seo. No need. Most older browsers are no longer supported. It's an outdated argument. – Oddman Feb 21 '14 at 14:08
0

While rack-pjax does prevent the browser from refreshing the page with each request, the server is still sending an entire HTML page with each request. If your goal is a "single page" app with no page refreshes, rack-pjax will work but you're going to save a lot of bandwidth and have a much more responsive app if you use a framework that deals with JSON instead of loading an entire page.

For a simple app, I'd recommend starting with something like Backbone or Spine. For more complicated apps, you'll quickly find yourself writing a lot of boilerplate code with those smaller frameworks and you'd probably be better off letting something like Ember or Cappuccino handle most of the heavy lifting for you.

If you want a single-page app, it's a given that some or most of your logic is going to be on the frontend, either written directly in javascript or written in coffeescript and compiled to javascript. Of course, you do still need certain logic at the server (like validations.. always assume, even with validation logic in your JS code, that people can and will send bad data to the server).

stevenh512
  • 545
  • 2
  • 8