1. I dumped view helpers for decorators (namely, the Draper gem). I got rid of complex logic in my view templates. Most of the logic I need in my views is transformed object properties. I need a date to appear as mm/dd/yy. I need a filesize in bytes to appear as KB/MB. I want a comment formatted as Markdown to be HTML. So now I'll decorate my objects so I have a nice post.formatted_date instead of needing to write the helper formatted_date(post). At worst I have some conditional statements in my views looking for the existence of a property. CSS also comes into play; the :empty selector allows me to cheat in some cases.
2. I write my view templates in a JavaScript templating language. I am a fan of slim for Ruby, so I went with Jade for JavaScript. I use therubyracer to call on these precompiled templates within Ruby itself, and render them like anything else. I then go on to use these same templates client-side. The reason why I abandoned view helpers to a large extent is because of this. Any logic that I need within a template would have to be duplicated server-side and client-side, which is antithetical to the goal. For my use-cases I've been able to do this successfully. It requires an adjustment to mindset, but is feasible. And really, my templates are a lot cleaner now than they've ever been.
3. When a user lands on a page, they get rendered HTML. Subsequent requests use AJAX and JSON responses to load things dynamically from there. Best of both worlds. Also, users who have JavaScript disabled can use the site albeit with not as much slickness.
4. Using to_json is hell; don't do it. I use the RABL gem for assembling my JSON, and use the same decorated objects. In the case of JSON, depending on your API, you might want to include say an ISO8601 date as well as a formatted date. Not a big deal, just vaguely duplicative.
The downside was how much code I had to write for myself. Using JavaScript templates was a biggy. But this is something that could probably be packaged as a gem, if I or someone else took the time. The framework (in my case, Padrino) still provides lots of tools that I need. Ruby ORMs are a big part of this.
There's still the issue of duplicative routes. I have routes defined in the app itself, and then within my JavaScript framework (currently Spine, but previously Backbone) I have to hardcode these same routes. I don't like this, however, routes are probably the last thing to change in my app if I put any thought into them ahead of time. This is something that requires additional thought, but I'm thinking there should be a way to get my app routes available client-side.
1. I dumped view helpers for decorators (namely, the Draper gem). I got rid of complex logic in my view templates. Most of the logic I need in my views is transformed object properties. I need a date to appear as mm/dd/yy. I need a filesize in bytes to appear as KB/MB. I want a comment formatted as Markdown to be HTML. So now I'll decorate my objects so I have a nice post.formatted_date instead of needing to write the helper formatted_date(post). At worst I have some conditional statements in my views looking for the existence of a property. CSS also comes into play; the :empty selector allows me to cheat in some cases.
2. I write my view templates in a JavaScript templating language. I am a fan of slim for Ruby, so I went with Jade for JavaScript. I use therubyracer to call on these precompiled templates within Ruby itself, and render them like anything else. I then go on to use these same templates client-side. The reason why I abandoned view helpers to a large extent is because of this. Any logic that I need within a template would have to be duplicated server-side and client-side, which is antithetical to the goal. For my use-cases I've been able to do this successfully. It requires an adjustment to mindset, but is feasible. And really, my templates are a lot cleaner now than they've ever been.
3. When a user lands on a page, they get rendered HTML. Subsequent requests use AJAX and JSON responses to load things dynamically from there. Best of both worlds. Also, users who have JavaScript disabled can use the site albeit with not as much slickness.
4. Using to_json is hell; don't do it. I use the RABL gem for assembling my JSON, and use the same decorated objects. In the case of JSON, depending on your API, you might want to include say an ISO8601 date as well as a formatted date. Not a big deal, just vaguely duplicative.
The downside was how much code I had to write for myself. Using JavaScript templates was a biggy. But this is something that could probably be packaged as a gem, if I or someone else took the time. The framework (in my case, Padrino) still provides lots of tools that I need. Ruby ORMs are a big part of this.
There's still the issue of duplicative routes. I have routes defined in the app itself, and then within my JavaScript framework (currently Spine, but previously Backbone) I have to hardcode these same routes. I don't like this, however, routes are probably the last thing to change in my app if I put any thought into them ahead of time. This is something that requires additional thought, but I'm thinking there should be a way to get my app routes available client-side.