Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby Frameworks? Which one? Bye bye Rails.

slideshare.net

Post reply on HN
Print view View original

51–60 of 93 posts

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

#51

Post by timinman »

base wrote: post #11
timinman wrote: 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.

Thanks for that. I mistakenly thought it only supported the two listed in the presentation.

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

#52

Post by rapind »

raganwald wrote: post #29

I empathize with the comments from the folks who are already heavily invested in Rails. It’s so easy to “just throw the whole stack at a problem” or “kill a fly with a shotgun.” This is always the way, and it’s why new ideas rarely displace the old ones directly. Instead, they have to appeal to a younger, nascent “market” that are not attached to the old product. Padrino’s best bet is to appeal to a younger, fresher…

I'm utterly content with Rails 3. Having used versions 1 & 2, I can definitely say 3 is quite an upgrade and decoupling which is competitive on most of the points in this slide. It's almost like this slide was based on a Rails 2 comparison.

I find rails popularity picking up, but I don't think we're anywhere near comparing it to struts yet (I used to be a j2ee dev and used struts quite a bit... painful).

When I want to play around with the next big thing I mess around in Node.js.

I've known about Padrino for a while now (and built some small apps with Sinatra), and I'm sure it fits some peoples needs and is a great project... but I have yet to become interested enough to bother. It's just not that appealing right now, and I don't think it's because I've become too comfortable or conservative etc. Of course if I start to hear a lot about it I'll spend a little more time playing with it.

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

#53

Post by davidw »

mattdeboard wrote: post #26
davidw wrote: post #16

Earlier quoted context omitted.

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?

> I'm not sure that's 100% accurate It is. You're conflating several different notions. A sunk cost fallacy is the idea that because you've invested a certain amount of resources (time, in this case) in a particular approach, it would be foolish to switch because all the resources you've already expended would be "wasted."

My understanding is that sunk cost fallacies are where people consider the past when they should be only looking at the future. However, the future in his case means that he has Rails knowledge X, and has Padrino knowledge 0, so looking at the future from right now, Rails still makes sense unless Padrino is so much better that it outweighs the switching costs.

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

#54

Post by tptacek »

Argorak wrote: post #48
automach wrote: post #41

Earlier quoted context omitted.

I'm all for new ideas and tools, but you have to bring something to the table other than just being different. And just being "smaller" is not enough. This is the problem with Padrino- it isn't different enough. We don't need a smaller MVC Ruby framework, as there isn't much space between what Sinatra is great for and what Rails is great for. There is also an assumption that scaling Sinatra up is a good idea. I'd pro…

I beg to differ. There is a lot of space to cover between a bare-bones HTTP DSL (which Sinatra is) and an opinionated full-stack like Rails. For example, Padrino allows you to freely choose between a lot of Ruby ORMs _and provides support_ to use them. Try that with Rails. As another example, Padrino allows you to do Rails-Engine-like things in a very natural way (by hosting multiple applications in one Stack etc.).…

What's the support Padrino provides for non-ActiveModel ORMs? How does Rails not provide that support?

You can host arbitrary Rack applications inside Rails with a single line in routes.rb.

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

#55

Post by Xylakant »

tptacek wrote: post #34
Xylakant wrote: post #28

Earlier quoted context omitted.

I do all my production app in sinatra/padrino. I like the fact that I can do pretty much every app from a simple api to a full webapp with the same stack without changing the framework. I never miss ActionView, but sometimes include parts or all of ActiveSupport, so I don't miss that either. I love the simplicity of the sinatra stack and I've never been much of a rails fan (too tightly integrated for my taste, the 1.…

Can you be more specific? I'm curious. What are the bits of ActionView that get in your way? I ask because to me, as far as views go, both Rails and Sinatra are just hosting systems for Haml. If anything, it's Sinatra that got in my way (it doesn't have explicit partial support, so there were minor things I had to tweak). I can't think of many "features" of ActionView I used. I generally agree that Sinatra was an eas…

Sorry, I didn't want to imply that ActionView gets in my way - I just don't miss it. Padrino uses the excellent Tilt templating library and it loads pretty much all template engines I could wish for and it does add explicit partial support to sinatra. That's about all I could want from ActionView. I don't like or use form-builders for instance, I prefer not to use the js/ajax-helpers etc.

I guess it boils down to a matter of preference: I prefer my stack to be built from the ground up on a solid foundation by adding pieces I want and need in my app - and that's what I can do with padrino. If I'm writing a pure API it's sinatra plus the padrino router, tilt, maybe an orm and that's about it. If I need something more comprehensive I can add components on top of that that add the required functionality (render-helpers such as partials etc.)

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

#56

Post by tptacek »

Xylakant wrote: post #55
tptacek wrote: post #34

Earlier quoted context omitted.

Can you be more specific? I'm curious. What are the bits of ActionView that get in your way? I ask because to me, as far as views go, both Rails and Sinatra are just hosting systems for Haml. If anything, it's Sinatra that got in my way (it doesn't have explicit partial support, so there were minor things I had to tweak). I can't think of many "features" of ActionView I used. I generally agree that Sinatra was an eas…

Sorry, I didn't want to imply that ActionView gets in my way - I just don't miss it. Padrino uses the excellent Tilt templating library and it loads pretty much all template engines I could wish for and it does add explicit partial support to sinatra. That's about all I could want from ActionView. I don't like or use form-builders for instance, I prefer not to use the js/ajax-helpers etc. I guess it boils down to a m…

Yeah, I haven't used the form helpers in ages, I just write normal jQ Javascript code and pretend Rails doesn't have "ajax" support, and I hardcode my links instead of using link_to. You're right, there's a bunch of stuff ActionView does that I've had to opt out of using.

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

#57

Post by amalag »

Argorak wrote: post #48
automach wrote: post #41

Earlier quoted context omitted.

I'm all for new ideas and tools, but you have to bring something to the table other than just being different. And just being "smaller" is not enough. This is the problem with Padrino- it isn't different enough. We don't need a smaller MVC Ruby framework, as there isn't much space between what Sinatra is great for and what Rails is great for. There is also an assumption that scaling Sinatra up is a good idea. I'd pro…

I beg to differ. There is a lot of space to cover between a bare-bones HTTP DSL (which Sinatra is) and an opinionated full-stack like Rails. For example, Padrino allows you to freely choose between a lot of Ruby ORMs _and provides support_ to use them. Try that with Rails. As another example, Padrino allows you to do Rails-Engine-like things in a very natural way (by hosting multiple applications in one Stack etc.).…

The Rails 3 rewrite / MERB integration was supposed to accomplish this by allowing pluggable ORM's and different libraries. Is Padrino trying to be the new MERB? I think extending Rails to be more modular is the way to go, not more frameworks.

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

#58

Post by Xylakant »

tptacek wrote: post #54
Argorak wrote: post #48

Earlier quoted context omitted.

I beg to differ. There is a lot of space to cover between a bare-bones HTTP DSL (which Sinatra is) and an opinionated full-stack like Rails. For example, Padrino allows you to freely choose between a lot of Ruby ORMs _and provides support_ to use them. Try that with Rails. As another example, Padrino allows you to do Rails-Engine-like things in a very natural way (by hosting multiple applications in one Stack etc.).…

What's the support Padrino provides for non-ActiveModel ORMs? How does Rails not provide that support? You can host arbitrary Rack applications inside Rails with a single line in routes.rb.

Can you host arbitrary Rails applications in other rails applications like you can host arbitrary Padrino applications within another Padrino application? (it should even be possible to host padrino apps in any other rack app, though I've never done that so far, it might need a little hackery)

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

#59

Post by jenius »

The only thing I see wrong with this is lack of coffeescript. I love coffeescript like bill clinton loved getting dome in the oval office, and if anything is without it, i will either cry, build support in myself, or both (at the same time?)

Anyway the point of this comment is please give us coffee! It looks like padrino has everything else covered and I really like the idea.

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

#60

Post by nyrb »

DAddYEz wrote: post #50
nyrb wrote: post #44

Earlier quoted context omitted.

I am not against the Padrino web framework. I still like it. :-) So your benchmark only have tested against the small "Hello World" app. Maybe that's why I suggested that Padrino framework is pretty ideal for small/personal/API projects for fastest responses. Have you tried benchmarking your one of biggest padrino apps?

That's not 100% true, there are more than `hello world` benchs. Check it out here: https://github.com/DAddYE/web-frameworks-benchmark/tree/more... Yep, speed is 4-6x faster, but most important for me is memory usage is much much less. On every Rails project I need to use monit/god to stop/start when for xx cycles memory is > 100mb or so. Without that a rails project can sucks 1-2gb of ram. Isn't quite normal to my st…

Sorry if I have to ask, what part is not 100% true? You mean that padrino app can be still faster with large app?

You said there are more than "Hello World" benchmarks? I looked at the link that you provided and then looked at this source code of the Padrino app and its still "Hello World":

https://github.com/DAddYE/web-frameworks-benchmark/blob/more...

I expected to see something more than just Hello World app.

I am trying to see why you are suggesting me that Padrino is better than Rails. :-) Sounds like you are completely against Rails. Maybe I am wrong.

Post reply on HN