4 ms·

People who paid attention to Rails upgrade issues over the years saw issues with heavy frameworks that abstract a bit far from the input & output. Simple libra

People who paid attention to Rails upgrade issues over the years saw issues with heavy frameworks that abstract a bit far from the input & output. Simple libraries often mean less maintenance headaches, more flexibility, and better productivity over the long term. YMMV of course ;-) Exoskeleton looks like a promising microframework replacement for Backbone.js - http://exosjs.com/ http://exosjs.com/ --- Edit: re: downvotes. I know, sometimes it hurts to hear there are other ways that may be more optimal. Been there. Developing software is hard sometimes but it's a craft :-)

bbcbasic 12y ago
Why is maintaining a Rails application a mess? Yes if everything gets stuffed into controllers/models then maybe. But you don't have to do that.
- briantakita 12y ago
  The upgrades have been historically been quite painful. Especially from v2 to v3. Perhaps it's better now that the api has stabilized a bit. I've been using node.js & some Sinatra lately. Upgrades tend to be smoother & due to less monolithic libraries. Also, the app startup time & TDD cycle tends to be faster with slimmer libraries. It's also nice to be close to http vs the ambiguous controller methods & complicated route files. Plus ActiveRecord is slow, especially with collections. The business logic can often be implemented in simple functions, resulting is less abstraction overhead.
  - bronson 12y ago
    True, v2->v3 was hard due to escaping-by-default, but that was a long time ago. v3 to v4 was trivial and v4 to v5 looks to be similarly easy. Also, I find business logic sql libs written by typical devs tend to be unreadable and much buggier than AR code. They start clean, but once some other devs make some edits, they end up a jumble of sql concatenation nightmares (even if you use prepared statements, and especially if you've ever switched sql dialects). Given the choice, I think I'd rather see them written as stored procedures. At least that enforces decoupling. I agree with your other points -- less code is more better.
krebby 12y ago
I work on Exoskeleton and Backbone. How are you liking it in your project? Anything you'd like to see different?

bbcbasic 12y ago

Why is maintaining a Rails application a mess? Yes if everything gets stuffed into controllers/models then maybe. But you don't have to do that.

briantakita 12y ago
The upgrades have been historically been quite painful. Especially from v2 to v3. Perhaps it's better now that the api has stabilized a bit. I've been using node.js & some Sinatra lately. Upgrades tend to be smoother & due to less monolithic libraries. Also, the app startup time & TDD cycle tends to be faster with slimmer libraries. It's also nice to be close to http vs the ambiguous controller methods & complicated route files. Plus ActiveRecord is slow, especially with collections. The business logic can often be implemented in simple functions, resulting is less abstraction overhead.
- bronson 12y ago
  True, v2->v3 was hard due to escaping-by-default, but that was a long time ago. v3 to v4 was trivial and v4 to v5 looks to be similarly easy. Also, I find business logic sql libs written by typical devs tend to be unreadable and much buggier than AR code. They start clean, but once some other devs make some edits, they end up a jumble of sql concatenation nightmares (even if you use prepared statements, and especially if you've ever switched sql dialects). Given the choice, I think I'd rather see them written as stored procedures. At least that enforces decoupling. I agree with your other points -- less code is more better.

krebby 12y ago

I work on Exoskeleton and Backbone. How are you liking it in your project? Anything you'd like to see different?