For those unaware, this project was previously called Lotus. I think this is being upvoted because it was mentioned in the recently popular solnic[0] blog post.
* 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)
Thank you! They changed the whole site so I thought Hanami popped up from nowhere. I checked it out when it was still called Lotus, looked really interesting. Good to see this project gaining ground.
That's not what the link shows. It seems from that thread that IBM never contacted them, they just changed the name preemptively and out of an abundance of caution.
I need advice .. i been using idcms for long time since 2006 for open source product at sourceforge and suddenly ibm using the name idcms also.
http://dita.xml.org/resource/idcms-blue-ibms-information-dev....
For now, nobody complain anything about it because not so famous product.
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.
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/
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.
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)
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.
You might want to check out Padrino (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.
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.
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.
+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)...
% 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."
I'm happy to see some new ideas in Ruby frameworks but at this point if I'm going to go to all the trouble of learning a new framework I'll learn a new language too. A lot of the problems of Rails (slow, poor concurrency story, dynamic typing) are Ruby problems not Rails problems.
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.
From my experience it is still pretty alpha quality. I ran into a weird issue with the inflector library they rolled themselves and had to dig through the code to figure out what was going on. This was about a month ago, so things could have changed, but I wouldn't recommend this for production app just yet. At least one that you have a timeline on.
I still cannot believe that auto-inflection continues to be a thing that people use in projects... seems like the sort of thing that will break all the time to bring pretty small amount of benefits.
In essence it tries to be a framework like Rails, in that it is all inclusive, but without all the "magic" that has been discussed about Rails lately.
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.
My (limited)experience is that when a rails app gets too big, it becomes hard to manage. That was my case, anyway. The architecture of hanami promotes longterm developer sanity. The fact that views are objects and the existence of interactors is a real plus. See this old Uncle Bob video re interactors: https://www.youtube.com/watch?v=WpkDN78P884
I'd like to see some high performance ruby implementation for backend stuff (even if limited to some extent ...) sort of like what RubyMotion is for iOS/OS X.
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...
[0] http://solnic.eu/2016/05/22/my-time-with-rails-is-up.html