Hanami – web framework for Ruby
hanamirb.org
hanamirb.org
[0] http://solnic.eu/2016/05/22/my-time-with-rails-is-up.html
* Padrino (http://padrinorb.com) built on top of Sinatra
* Volt (http://voltframework.com) which allows you to write Ruby both in the backend and front-end
* Cuba (http://cuba.is) is a web microframework
* Roda (http://roda.jeremyevans.net) is also a microframework (both Cuba and Roda are like toolkits with very basic cored and a bunch of plugins distributed together with the framework)
We started at the same time, but unfortunately I never had the chance to play with Phoenix.
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.
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.
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.
You can cherry pick parts of it out in to a Sinatra app, or you can swap out `Sinatra::Application` for `Padrino::Application`.
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.
% hanami new bookshelf
18 files successfully created
Description is a little misleading, I was expecting to see something sinatra-like but found something rails-like. It might be more apt to call it "The lightest full-featured ruby web MVC framework".Obviously that doesn't make for a good tagline, maybe: "A full-featured yet light-weight web framework, for Ruby."
A few years ago there weren't a lot of great options but now we have Go, Scala, Clojure, C# on Linux, Elixir, Swift (maybe eventually) etc.
I am wondering if there are components for common scenarios like authentication etc?
What came to mind looking at scripta is that you might find it useful to look at https://edwardtufte.github.io/tufte-css/
What do you use for persistency? Sequel?
I use postgres for persistency -- mostly throgh Hanami's model component, though I do some parts directly in sequel.
it's not rails.
Most things are just plain old ruby objects and you include the modules you need. This is an oversimplification, but for example: When I build out controller actions in a Rails app, I typically will break out complex actions into service/action/command classes. This allows me to test the logic in isolation from the controller, and allows for true unit tests without need to actually make real requests. Hanami, on the other hand, right from the get go, makes actions there own classes for this very reason.
Also the idea of an "Application" is a bit more vague. Your main app is more a meta-app. This, in theory, helps you develop separate service like applications that are then mounted within this meta-app. This may make it easier to break out into actual services later on.
If you just follow "Rails conventions" and the app is long living, it can get pretty damn unwieldy. I guess the idea here is you can follow Hanami conventions and the app will be more maintainable even at large sizes.
I can imagine a lot of stuff that could benefit from this on the other hand I can see why it has not been done (costs, complexity etc).
Anyway I am sad that RubyMotion is not just as popular as Rails is. That is...very surprising...