4 ms·

I would love to see an intermediate framework between Sinatra and not quite as huge as Rails. Hanami could fit that bill. But it appears as if it's trying to co

I would love to see an intermediate framework between Sinatra and not quite as huge as Rails. Hanami could fit that bill. But it appears as if it's trying to compete with Rails, in which case I'll never bother trying to learn it, because I already have Rails. From what I've seen of the code it looks like that's the case. What would be really awesome is a way to 'promote' projects. Currently, if I start a Sinatra project and I realize later that I needed Rails, I've no choice but to either re-engineer the entire project, or tough it out with Sinatra. If I had an upgrade path, then I could start every project off in Sinatra, then when I start finding myself wanting more functionality, fluidly migrate to Hanami or Rails.

jaequery 10y ago
Have you tried Padrino? Of all the frameworks I've tried in the past 10 years, this is as good as it comes. Love the Sinatra + Sequel + erb setup as it is simple and straightforward. Fast and elegant without the Rails lockdown architecture. http://padrinorb.com/ http://padrinorb.com/
- vinceguidry 10y ago
  Hmm, that's a good suggestion, and to be honest, I knew something like that already existed. It's fine to migrate from Sinatra to Padrino, Padrino is built on top of Sinatra, but what I really want is a path to migrate to Rails. I suppose what I could do is build according to a convention in Padrino that I know would work well in Rails, then when the time comes, write some scripts to transform the codebase. Probably a job for Rake. Really though, I can't see much of a benefit over just starting with Rails. I might try it once just to confirm.
  - cyberferret 10y ago
    No reason why you can't just stick with Padrino for full scale development. I have an app with over 22,000 lines of Ruby and HAML with about 80 database objects all written in Padrino and it runs beautifully with around 150 users at the moment... (www.hrpartner.io)
    - vinceguidry 10y ago
      I have no doubt that you can build and maintain large websites with Padrino. But I already know Rails. A new framework would have to do something for me that both Rails and Sinatra won't. Ah well, I don't think there actually is such a use case. I thought maybe because I once started a project with Sinatra that I later wished I'd built with Rails. Really it seems to boil down to what the application is supposed to be doing. If it's primarily something else that just maybe speaks HTTP, like a microservice, then Sinatra is the more flexible choice, you can encapsulate the web logic and build your own abstractions as you see fit. If it's primarily a website, then you'll want a full-fledged batteries-included framework. Projects don't start as a microservice and evolve into a website. The one project I started with Sinatra should have been Rails from the beginning, as it was really a website. I just used Sinatra because at the time I knew it better.
bdcravens 10y ago
May not be a fit for the situation you describe, but mounting a Sinatra app inside a Rails app (or mounting it at the Rack level) can be a solution. I think more people come at it the opposite direction you describe: start with Rails, and build out smaller apps in Sinatra when Rails feels too heavy.
jyunderwood 10y ago
Have you looked in to Padrino? http://padrinorb.com http://padrinorb.com You can cherry pick parts of it out in to a Sinatra app, or you can swap out `Sinatra::Application` for `Padrino::Application`.
makaio 10y ago
You might want to check out Padrino (http://padrinorb.com http://padrinorb.com). My understanding is that it is built on Sinatra, but makes it easier to add some of the Rails-like functionality in a more modular manner.
cyberferret 10y ago
+1 for Padrino - I've cut all my recent apps in it and it is superb. I can even use 90% of Rails gems in there (exception being those that are ActiveRecord specific, seeing as I use DataMapper or Sequel)...
rapind 10y ago
I've played around with it and Hanami seems to be targeting the larger complex apps that eventually become become painful with Rails due to fat models / controllers among other things. Hanami seems to be inspired by Uncle Bob's Clean Architecture. IMO it's pretty nicely done and a good example of how Clean Arch can be implemented. Worth playing with if only to get a feel for it's structure and potentially influence your Rails apps.

jaequery 10y ago

Have you tried Padrino? Of all the frameworks I've tried in the past 10 years, this is as good as it comes. Love the Sinatra + Sequel + erb setup as it is simple and straightforward. Fast and elegant without the Rails lockdown architecture. http://padrinorb.com/ http://padrinorb.com/

vinceguidry 10y ago
Hmm, that's a good suggestion, and to be honest, I knew something like that already existed. It's fine to migrate from Sinatra to Padrino, Padrino is built on top of Sinatra, but what I really want is a path to migrate to Rails. I suppose what I could do is build according to a convention in Padrino that I know would work well in Rails, then when the time comes, write some scripts to transform the codebase. Probably a job for Rake. Really though, I can't see much of a benefit over just starting with Rails. I might try it once just to confirm.
- cyberferret 10y ago
  No reason why you can't just stick with Padrino for full scale development. I have an app with over 22,000 lines of Ruby and HAML with about 80 database objects all written in Padrino and it runs beautifully with around 150 users at the moment... (www.hrpartner.io)
  - vinceguidry 10y ago
    I have no doubt that you can build and maintain large websites with Padrino. But I already know Rails. A new framework would have to do something for me that both Rails and Sinatra won't. Ah well, I don't think there actually is such a use case. I thought maybe because I once started a project with Sinatra that I later wished I'd built with Rails. Really it seems to boil down to what the application is supposed to be doing. If it's primarily something else that just maybe speaks HTTP, like a microservice, then Sinatra is the more flexible choice, you can encapsulate the web logic and build your own abstractions as you see fit. If it's primarily a website, then you'll want a full-fledged batteries-included framework. Projects don't start as a microservice and evolve into a website. The one project I started with Sinatra should have been Rails from the beginning, as it was really a website. I just used Sinatra because at the time I knew it better.

bdcravens 10y ago

May not be a fit for the situation you describe, but mounting a Sinatra app inside a Rails app (or mounting it at the Rack level) can be a solution. I think more people come at it the opposite direction you describe: start with Rails, and build out smaller apps in Sinatra when Rails feels too heavy.

jyunderwood 10y ago

Have you looked in to Padrino? http://padrinorb.com http://padrinorb.com You can cherry pick parts of it out in to a Sinatra app, or you can swap out `Sinatra::Application` for `Padrino::Application`.

makaio 10y ago

You might want to check out Padrino (http://padrinorb.com http://padrinorb.com). My understanding is that it is built on Sinatra, but makes it easier to add some of the Rails-like functionality in a more modular manner.

cyberferret 10y ago

+1 for Padrino - I've cut all my recent apps in it and it is superb. I can even use 90% of Rails gems in there (exception being those that are ActiveRecord specific, seeing as I use DataMapper or Sequel)...

rapind 10y ago

I've played around with it and Hanami seems to be targeting the larger complex apps that eventually become become painful with Rails due to fat models / controllers among other things. Hanami seems to be inspired by Uncle Bob's Clean Architecture. IMO it's pretty nicely done and a good example of how Clean Arch can be implemented. Worth playing with if only to get a feel for it's structure and potentially influence your Rails apps.