Live data from Hacker News

Ruby Frameworks? Which one? Bye bye Rails.

slideshare.net

11–20 of 93 posts

Re: Ruby Frameworks? Which one? Bye bye Rails.

#11
post #3

I definitely love Sinatra, and I'm impressed by the admin interface, but it looks like there's no support for DataMapper as an ORM. I also wonder if this is just turning Sinatra into Rails. I think for the now I prefer to just build a Sinatra app and add gems and plugins as I need them.

Padrino supports the following ORMs out of the box: mongoid, activerecord, datamapper, couchrest, mongomatic, ohm, ripple, sequel. Take a look here: http://www.padrinorb.com/guides/generators

Padrino is just a Sinatra app with a very basic skeleton and some added functionality. Almost all the pieces are modular and doesn't have many requirements from the start.

Re: Ruby Frameworks? Which one? Bye bye Rails.

#13
I love the idea. No unnecessary crud, simple, clean. What's not to love?

It's the practice that I'm having problems with. Medium-large projects have tendency to actually use big part of the bag of tricks Rails provides.

But smaller ones, where Padrino should shine... it doesn't. When running one or two server processes, I don't care that it consumes 30MB more RAM than it should, or renders take two milliseconds longer than they could. If I did, I would use something else instead of ruby. However, when I actually try to use that one neat feature, only to remember that it's Rails-specific, or find out that this gem I'm not familiar with has documentation only as far as Rails-integration is concerned, that's a real and measurable dip in my productivity.

These small projects are usually weekend hacks where I would rather not spend time writing boilerplate I know can be replaced by one line by that other framework, or digging through sources of a library before I can start using it. It gets very tempting to just throw in the whole Rails stack and focus on the interesting bits.

These problems could be alleviated by more widespread use of other Ruby web frameworks (and I do wish they gain more traction!). But right now, my laziness keeps me from 'being part of the solution'.

Re: Ruby Frameworks? Which one? Bye bye Rails.

#14
post #6

This reminds me of Flask for Python (nb. although more is built in to Padrino, most of the functionality for Flask is provided by plugins). I've recently started using Flask for new projects in favor of Django. I feel that most of the libraries I use are framework agnostic, stuff like ORM (SqlAlchemy), PDF generation, redis/mongodb adapters etc, so being able to pick what fits and leave the cruft out is great. But be…

Have you try Pyramid? It's similar to Flask.

Re: Ruby Frameworks? Which one? Bye bye Rails.

#15
post #6

This reminds me of Flask for Python (nb. although more is built in to Padrino, most of the functionality for Flask is provided by plugins). I've recently started using Flask for new projects in favor of Django. I feel that most of the libraries I use are framework agnostic, stuff like ORM (SqlAlchemy), PDF generation, redis/mongodb adapters etc, so being able to pick what fits and leave the cruft out is great. But be…

I'm working on Fiasco, which intends to be similar to Flask but for Ruby. It is still a work in progress, but you can see it here: http://tizoc.github.com/fiasco

Re: Ruby Frameworks? Which one? Bye bye Rails.

#16

As someone that's just crossed a year or Ruby/Rails learning, having scaled the majority of the now massively steep learning curve, I'll stick with the complexity that is Rails.

Ah the old sunk cost fallacy.

I'm not sure that's 100% accurate.

"sunk costs are retrospective (past) costs that have already been incurred and cannot be recovered", says Wikipedia. However, investment in Rails can be "recovered", because it's a useful, marketable skill. Switching to something else will incur costs as well, so the benefits would need to be both high and certain to really make it a 'sunk cost fallacy', no?

Re: Ruby Frameworks? Which one? Bye bye Rails.

#17
post #8

Padrino is really nice web framework for Ruby. I have used it for experimental projects. My work was using latest Padrino framework at work, but extremely unhappy with the its performance (slow response). We had ported the app to Rails 3.1 for better performance. (We will upgrade it to 3.2 soon) In fact, I think Padrino is pretty ideal for personal and small apps. Not really ideal for medium to large apps. Just my op…

Warn: is opinionated

Btw I switched lots of projects from rails to padrino due to the slow performances of rails.

I built a small test suite where you can find that Padrino is upto 4x faster than rails.

Check it out: https://github.com/DAddYE/web-frameworks-benchmark

Feel free to show me that Im wrong.

Re: Ruby Frameworks? Which one? Bye bye Rails.

#18
Thanks but no thanks. Having just become a productive Rails programmer and grasped a lot of complexities, use cases and diversity of the framework, I'd rather use the shotgun that Rails is to kill any fly that stands in my way.

As long as the fly is dead, Rails did its job.

Re: Ruby Frameworks? Which one? Bye bye Rails.

#19
Not sure why the author of the slides presents rails as a confusing mess. If you don't like the asset pipeline then don't use it. If you don't like the scaffolds then don't generate it. If you don't like active record, then don't use it.

I love the fact that these new frameworks are popping up, but why try to pull down rails in the process? If this addressed legitimate issues rails has, then I would not have a problem, but what's presented seems superficial.

I would love to know how Padrino lives with mongodb. Will the admin generator work with mongomapper or mongoid?

Re: Ruby Frameworks? Which one? Bye bye Rails.

#20
Would like to hear from people who have taken a user-facing Padrino/Sinatra app all the way through production and into maintenance.

I have a few tiny services and extremely specific apps running on Sinatra, but any time I've needed to expose any kind of richness to the user I've ended up reimplementing in Rails as I kept reaching for things in ActiveSupport / ActionView etc.

At some point I notice myself essentially recreating Rails' structure in my 'lightweight' app and think 'why don't I just use Rails?'.

Post reply on HN