31–40 of 93 posts
I use rails for everything, there is so much going on for you behind in the scenes in the way of security and configuration that it doesn't make sense to go back and roll your own on a minimal framework.
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 proble…
The asset pipeline you can easy do without. I've forgotten Rails even did Scaffolds. But even though AR is "pluggable", you're working against the grain in Rails if you don't use it.
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…
I completely love Sinatra.
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…
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.…
I generally agree that Sinatra was an easier sell in the Rails 1.x and 2.x era, before Rails ate Merb.
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…
This is a weirdly emotional appeal that ignores the fact that Rails is not Struts, is nothing like Struts, isn't standing still, was more or less rewritten not very long ago by assimilating its best competitor, and that the next ORM or gem that isn't popular today on Rails is very likely to be bootstrapped and implemented in the context of Rails --- unless its key distinguishing value is "a not-Rails replacement for…
You pick and choose your battles, you pick and choose where you’re going to trade a little risk for reward. For the things Rails does well, there’s very little attraction in replacing it with something that is not-Rails if you already use Rails. Ergo, something not-Rails has to either do somethingRails doesn’t do well or appeal to people who don’t already know Rails.
Rails isn’t standing still but neither is Java web development. My ex-colleagues are constantly boasting of the great new things going on in my old ‘hood. But even so, the great new things are centered around the old things it already did well. Same with Rails, it does a particular thing well and “not standing still” doesn’t mean it will magically turn into node.js one day.
If we were talking about startups, nothing I am saying would arouse the slightest controversy, it’s the old “crossing the chasm,” “disruptive innovation,” or “innovator’s dilemma” mechanics, only for a free tool instead of a business or service.
You can even write a Sinatra clone in very little code on top of Rails: http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on-rai...
If you already know Rails, there is very little reason to build a substantial app in anything "smaller". The reality is that for any moderately-sized app, you will end up using many of the parts of Rails that you think are unnecessary in the beginning. Especially as your app grows.
I tried using Padrino for an app a year ago, and while the framework has probably matured since then, I moved back to Rails fairly quickly due do a lack of polish/documentation/community/benefit other than being different.
There is a common tendency to find a part of a framework that doesn't work exactly the way you want, and in turn throw the entire framework out and seek out or write something new. I still prefer the way Merb and Sinatra handle responses, where the controller action return value is the response sent to the client. But the benefits that Rails provides so outweigh many of these kind of preferences that it's usually best to just embrace the way the framework works and move on to actually building an app that does something.
It's also short sighted to discount how valuable the wealth of existing documentation and extentions exist for an established framework such as Rails.
The presentation makes it sounds as though by using Rails you have to use SASS and Coffeescript. This is not true, you can easily use plain JavaScript and CSS if you want.
The majority of developers will be more productive in Rails.
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…
This is a weirdly emotional appeal that ignores the fact that Rails is not Struts, is nothing like Struts, isn't standing still, was more or less rewritten not very long ago by assimilating its best competitor, and that the next ORM or gem that isn't popular today on Rails is very likely to be bootstrapped and implemented in the context of Rails --- unless its key distinguishing value is "a not-Rails replacement for…
I would love something more simple, that operated with less magic, and had code that was easier to understand. I'm not sure if Padrino is the answer, but it certainly merits a second look.
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…
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.
I can see where you are coming from, but ruling something out because another thing is doing it's job (in your opinion) is parochial. Unless you try new things out, you can never improve your existing workflow. You don't know what you don't know unless you explore.
My point is, I like trying new things, but I prefer to stick with tested and supported tools when working in a job, and leaving these new things to personal projects or hobbies.
Rails has not only a huge community, but a huge support of third party libraries that while they may not be the best performance-wise, they allow you to accomplish the project's goals.
Earlier quoted context omitted.
This is a weirdly emotional appeal that ignores the fact that Rails is not Struts, is nothing like Struts, isn't standing still, was more or less rewritten not very long ago by assimilating its best competitor, and that the next ORM or gem that isn't popular today on Rails is very likely to be bootstrapped and implemented in the context of Rails --- unless its key distinguishing value is "a not-Rails replacement for…
I disagree. The main reason I dislike Rails is that it is too complicated. When working with it every day, I regularly come across issues with it that require that I delve into the source code. More often than not that is a depressing venture. I would love something more simple, that operated with less magic, and had code that was easier to understand. I'm not sure if Padrino is the answer, but it certainly merits a…
I'm asking seriously, because I spend about 20% of my work time writing Rails code for a bunch of different Rails apps, and --- at least since Rails 3 --- I never have to do this. And I'm a C programmer, so "diving into the code to figure shit out" is a first instinct for me too.