4 ms·

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

by keeran 15y ago

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?'.

tptacek 15y ago
This is exactly what happens to me, and is also the sense I've gotten the couple times I've had the opportunity to review other people's Padrino apps. It's not that there's anything wrong with Sinatra and Padrino. The problem is twofold: the idea behind those two frameworks is seductive, but Rails 3 is really good. It's just not a stupid framework.
Xylakant 15y ago
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.x and to a lesser extend the 2.x version were too magic sometimes etc.) Most middleware is rack-based anyways. For me the winner is that a padrino app is a full, mountable rack application so I can mount any padrino application anywhere inside any other application. I can actually implement complete components as a padrino app and mount and reuse them anywhere I wish. (The padrino admin works that way)
- tptacek 15y ago
  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 easier sell in the Rails 1.x and 2.x era, before Rails ate Merb.
  - Xylakant 15y ago
    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.)
    - tptacek 15y ago
      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.
darkxanthos 15y ago
I only use Sinatra and have been developing, maintaining, and using http://PocketLoot.com http://PocketLoot.com for a year now. I completely love Sinatra.
binarysoul 15y ago
My problem with sinatra is that I rarely work on a small well defined project. Usually these projects grow beyond their original scope and sinatra is not equipped to deal with that. I don't see the problem with creating a nearly empty rails app. http://rawsyntax.com/blog/the-problem-with-micro-frameworks/ http://rawsyntax.com/blog/the-problem-with-micro-frameworks/
lobster_johnson 15y ago
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.

by keeran 15y ago

tptacek 15y ago

This is exactly what happens to me, and is also the sense I've gotten the couple times I've had the opportunity to review other people's Padrino apps. It's not that there's anything wrong with Sinatra and Padrino. The problem is twofold: the idea behind those two frameworks is seductive, but Rails 3 is really good. It's just not a stupid framework.

Xylakant 15y ago

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.x and to a lesser extend the 2.x version were too magic sometimes etc.) Most middleware is rack-based anyways. For me the winner is that a padrino app is a full, mountable rack application so I can mount any padrino application anywhere inside any other application. I can actually implement complete components as a padrino app and mount and reuse them anywhere I wish. (The padrino admin works that way)

tptacek 15y ago
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 easier sell in the Rails 1.x and 2.x era, before Rails ate Merb.
- Xylakant 15y ago
  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.)
  - tptacek 15y ago
    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.

darkxanthos 15y ago

I only use Sinatra and have been developing, maintaining, and using http://PocketLoot.com http://PocketLoot.com for a year now. I completely love Sinatra.

binarysoul 15y ago

My problem with sinatra is that I rarely work on a small well defined project. Usually these projects grow beyond their original scope and sinatra is not equipped to deal with that. I don't see the problem with creating a nearly empty rails app. http://rawsyntax.com/blog/the-problem-with-micro-frameworks/ http://rawsyntax.com/blog/the-problem-with-micro-frameworks/

lobster_johnson 15y ago

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.