I love Padrino so much that I started to write a book about it and my experience in developing an app with it https://github.com/matthias-guenther/padrino-book.
Ruby Frameworks? Which one? Bye bye Rails.
91–93 of 93 posts
Re: Ruby Frameworks? Which one? Bye bye Rails.
#92Padrino 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…
What even constitutes as a "small" or "large" application? My current Padrino project is around 2000 LOC, excluding tests. As it has grown more complex, I've broken off larger parts of its functionality into smaller apps within the same project. These apps share some resources -- particularly models -- but in terms of controllers and helpers, they are very much distinct in their roles in the overarching project. Padr…
+1 ... Divide et impera :D
Re: Ruby Frameworks? Which one? Bye bye Rails.
#93Would 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…
We have been transitioning from the "big Rails app" model to "many small [whatever] apps". Usually, "whatever" is Sinatra.
A new project, instead of being one monolithic Rails app, is a small frontend communicating with 20-odd small micro-services, each service with its own data backend tailored to its use case.
What I like about the Sinatra model is that creating an app feels less like a "Sinatra app" than a "Ruby app" which happens to use a bunch of libraries that together make up a web stack. With Rails it feels like you live inside a big, elusive container that is in control at all times. In other words, you are in control; you mount your Rack classes and build your stack from scratch.
Doing it this way doesn't mean we don't reap the benefits of the Rails universe. We use ActiveRecord, ActiveSupport, HAML, SASS, Sprockets, Compass, Unicorn, etc. -- pretty much the same range of technologies we would use with Rails. But we are less constrained about what we choose (or reject), and we don't have to be compatible with whatever convention Rails imposes at the moment.