Disclaimer: I'm one of the maintainers of Hobo. But I got into that position after I fell in love with it.
Hobo isn't primarily an admin interface, it's designed for rapid development of CRUD+state machine apps. In essence you start your app with an "admin" style interface and iterate until you get your full app. You can of course also add an additional scoped admin interface.
I haven't used RailsAdmin yet, but from your analysis, I would feel hesitant to suggest people start of with it.
I found working with ActiveAdmin to be very straightforward, and it sounds like getting the equivalent of RailsAdmin up and running may take an extra 30 minutes.
The big win after those 30 minutes is that you have a flexible admin module that you can continue to tweak / improve where necessary.
ActiveAdmin feels like the solution with the smallest chance of painting yourself into a corner and therefore seems like the best recommendation of the both.
Even if you would have to invest 2 extra days into ActiveAdmin compared to RailsAdmin, I'd say the flexibility is definitely worth it.
Bonus tip:
ActiveAdmin is in heavy development, and the documentation tends to lag behind a bit. I've found the github issues for the project to be a great source of information though.
I am also a huge Hobo devotee. I have been in Rails for about 5 years, and Hobo provides amazing leverage and power. It lets you think more about users and less about conventional code worries.
As developer of Typus I've followed the development of RailsAdmin and ActiveAdmin and I'm very impressed on how they have positioned the product into the market. Many of the customization problems people find with RailsAdmin and ActiveAdmin, are those who I've tried to solve during the last 5 years while developing Typus, and with people feedback.
Last version of Typus is fully compatible with Rails 3.1 and there are also branches compatibles with Rails 2.3 and 3.0, MIT-License, bla bla bla ...
Another thing to keep in mind is the use case for
RailsAdmin - it is pretty much an automatic backend,
that you’re not supposed to modify a lot. In its spirit
it’s very close to what Django’s admin backend is."
I can only reason that the author has never spent more than a few minutes with django's admin.
Just to put a counterpoint out there: My experience is that apps built on top of taller stacks tend to have more maintenance issues. This is because there are more moving pieces under you, and at any moment one of those pieces could cease to be maintained, start working at cross purposes to where you want to take your app, or turn out to be unacceptably inefficient. Having done it both ways, I now prefer to build as much of my app using libraries that I trust and code we write ourselves, rather than use plugins or builders. It's much easier to optimize and maintain in the long run, and a lot of it is easier to write than you may think (especially if you are not trying to solve for the general case). Also, it makes it easier to keep up to date with rails.
If you are rapidly developing a prototype it's different, but IMHO you should replace these components before the refactor becomes too much of a bugbear.
ActiveScaffold is the mother of CRUD interfaces. Strange thing is that few know and use it. None of the alternatives compares to it in terms of: instant gratification (usable by default), customization (fully customizable), interoperability (bridges for many major plugins like Devise, CanCan, CarrierWave, Paperclip, and many more). Has some legacy issues being ~ 4 years old - but of little concern. Rails 3.1 ready. https://github.com/activescaffold/active_scaffold
It just isn't actively maintained by multiple people and marketed like the other two are. They haven't even bothered to write a description on GitHub that would appear in the news feed of everyone following a GitHub user who watches it. I got an error when I tried to visit the website.
Edit: I added an issue asking about adding a description.
I'm genuinely curious to know what is the sweet spot for these admin interfaces and Hobo for that matter?
I find prototyping plenty fast with vanilla Rails, a few backend plugins, and Twitter Bootstrap. And on the far end of the scale, my experience is that larger projects require an amount of customization that does not easily fit into the auto-admin paradigm.
Hobo works great for both quick prototypes and huge applications. The USDA is using it for a couple of huge enterprise applications, for example.
Hobo is not an admin interface. It basically is a system to enable smart re-use of components that's tightly integrated into your entire stack.
For instance, in Hobo you can type `<input/>` and Hobo will do the right thing automatically: plop down a text input if the current context is a string, a fully filled out select box if it's a belongs_to or a datepicker if it's a date. The name and default value of that input will also be automatically and correctly inserted.
Change the definition of `<input for="Date"/>` and you can change the options on your datepicker or switch datepickers everywhere or just on that page or that section.
Beginners love Hobo because they can get an app up quick. Experts love it because you can package all of your components up in DRYML and dramatically reduce the number of lines of code in your program. Where Hobo has trouble is in the middle: until you're comfortable with DRYML you're stuck with the components that come with Hobo.
Yes, I'm less interested in quick scaffolding, be it via code generation or ready components, but clean reusable view components does sound appealing.
Rails helpers are great for some things but more complex cases like custom form builders can get ugly (no, formtastic is not always the answer). Will give Hobo a look next time.
14 comments
[ 5.8 ms ] story [ 38.1 ms ] threadDisclaimer: I'm one of the maintainers of Hobo. But I got into that position after I fell in love with it.
Hobo isn't primarily an admin interface, it's designed for rapid development of CRUD+state machine apps. In essence you start your app with an "admin" style interface and iterate until you get your full app. You can of course also add an additional scoped admin interface.
I found working with ActiveAdmin to be very straightforward, and it sounds like getting the equivalent of RailsAdmin up and running may take an extra 30 minutes.
The big win after those 30 minutes is that you have a flexible admin module that you can continue to tweak / improve where necessary.
ActiveAdmin feels like the solution with the smallest chance of painting yourself into a corner and therefore seems like the best recommendation of the both.
Even if you would have to invest 2 extra days into ActiveAdmin compared to RailsAdmin, I'd say the flexibility is definitely worth it.
Bonus tip: ActiveAdmin is in heavy development, and the documentation tends to lag behind a bit. I've found the github issues for the project to be a great source of information though.
Last version of Typus is fully compatible with Rails 3.1 and there are also branches compatibles with Rails 2.3 and 3.0, MIT-License, bla bla bla ...
Documents: http://docs.typuscmf.com/
Demo: http://demo.typuscmf.com/
Code: http://github.com/fesplugas/typus
I can only reason that the author has never spent more than a few minutes with django's admin.
If you are rapidly developing a prototype it's different, but IMHO you should replace these components before the refactor becomes too much of a bugbear.
It just isn't actively maintained by multiple people and marketed like the other two are. They haven't even bothered to write a description on GitHub that would appear in the news feed of everyone following a GitHub user who watches it. I got an error when I tried to visit the website.
Edit: I added an issue asking about adding a description.
I find prototyping plenty fast with vanilla Rails, a few backend plugins, and Twitter Bootstrap. And on the far end of the scale, my experience is that larger projects require an amount of customization that does not easily fit into the auto-admin paradigm.
Hobo is not an admin interface. It basically is a system to enable smart re-use of components that's tightly integrated into your entire stack.
For instance, in Hobo you can type `<input/>` and Hobo will do the right thing automatically: plop down a text input if the current context is a string, a fully filled out select box if it's a belongs_to or a datepicker if it's a date. The name and default value of that input will also be automatically and correctly inserted.
Change the definition of `<input for="Date"/>` and you can change the options on your datepicker or switch datepickers everywhere or just on that page or that section.
Beginners love Hobo because they can get an app up quick. Experts love it because you can package all of your components up in DRYML and dramatically reduce the number of lines of code in your program. Where Hobo has trouble is in the middle: until you're comfortable with DRYML you're stuck with the components that come with Hobo.
Yes, I'm less interested in quick scaffolding, be it via code generation or ready components, but clean reusable view components does sound appealing.
Rails helpers are great for some things but more complex cases like custom form builders can get ugly (no, formtastic is not always the answer). Will give Hobo a look next time.