Hobo != Scaffolding
Posted by
Tom | May 7, 2007 17 Responses comments

I was very pleased recently, to come across this remark in a post about Hobo:

don’t be mistaken that this is another scaffold, it’s not, far from it.

(from Funcoder – thanks!)

IMHO scaffolding is a very widely misunderstood concept and one that has caused a good deal of confusion. The only description of scaffolding I’ve heard that really holds water is from DHH: they’re a learning aid. Ironically, I think DHH unintentionally caused a lot of the initial confusion by featuring scaffolding so prominently in the early build-a-blog screencast. A lot of people saw that screencast and thought “Wow! Rails is building a big chunk of my app for me!”. That was a misconception.

The Hobo screencasts probably give people the same impression, and this time — they’re right! Hobo is trying to eliminate a lot of code that you would otherwise have to write yourself. The result is that many people are putting Hobo in the scaffolding category. Hobo does what people thought scaffolding would do.

If you add ActiveScaffold to the mix things get even more confusing. ActiveScaffold is an example of an “Admin Interface Builder”. From their website:

Most web applications have many more model objects exposed on the backend, or admin side, than they do on the front. Coding interfaces for all those models is redundant and a waste of resources when all you need is CRUD functionality that’s smart enough to handle all your ActiveRecord associations.

So they’re using the “scaffold” term very differently to DHH. But even if this use of scaffolding has become the de-facto meaning, it’s still different from Hobo.

To get some clarity, lets drop the buzz-words and take a look at what’s actually going on here. I can see three very different kinds of things:

Show me how to use the API. This, as I understand it, is the idea behind Rails scaffolds. I think it’s an awesome idea. A live, runnable code example using a model from my own app. Brilliant. It certainly helped me learn Rails. I do wonder though – if the usage of an API is so regular, doesn’t that mean the API is too low-level?

Make me an admin interface. This is ActiveScaffold, Streamlined, and from across the fence, Django (correct me if I’m wrong people). To be honest I can’t get too excited about this idea. Don’t get me wrong – these are all very well executed projects and seem to deliver the goods to a very high standard. It’s just not something I’ve ever felt a need for. There’s an implicit assumption here: “users” need a hand crafted UI, while “administrators” can use an auto-generated UI. I’ve never found myself in a situation where that assumption holds.

Build (part of) my app for me. In this category lies a large number of Rails plugins. Want tagging? acts_as_taggable. Want log-in and sign-up? acts_as_authenticated. Those things are mostly the same every time you need them, so why re-invent the wheel? This is where Hobo lies.

With that description, Hobo sounds very different from the other two categories, so why the confusion? Well, Hobo does so much for you, that, as you’ve seen in the first screencast, it will create a working app with no programming at all outside the model layer. If you use this app as is, you’re effectively using Hobo as a “make me an admin interface” tool. That’s fine, but it’s also kinda missing the point.

The point being, that this “generated” app is customisable. Easily customisable. Completely and totally customisable. No less so that a raw Rails app. The second and third screencasts are trying to point in this direction. So design your app exactly the way you want it. Where your design is very “standard”, Hobo will provide those bits for you. Where your design is unique and specially tailored, you’ll build those bits yourself.

I think the word “scaffolding” captures the point really well. Scaffolding is sometimes a temporary fix – holding things in place while things are under construction. It’s sometimes used more permanently — around the back, for the people that don’t mind the odd rough edge. Either way it’s a perfectly valid and very useful tool. Hobo has features that can be used like this, but it’s definitely not what Hobo is about.

Reader Comments Add your comment »

ActiveScaffold may no longer be scaffolding, but originally it was generated scaffolding under the name AjaxScaffold. Later a plugin vs generator version was created, then the name change.

“Want tagging? actsastaggable. Want log-in and sign-up? actsasauthenticated. Those things are mostly the same every time you need them, so why re-invent the wheel?”

Amen!!

Thanks to Dr Nic for pointing how we came to call ourselves a ’scaffold’. We, the ActiveScaffold team, also agree that we’re being somewhat disingenious by continuing to call our project a scaffold. It is a scaffold in that it could be a starting point like standard scaffolding: you can still configure and override what ActiveScaffold gives you. But by and large it isn’t a scaffold.

Hi Richard – nice to see you on the blog :-) I think your usage of the term scaffold is closer to the ‘popular’ understanding of the term.

On another point, I’m kind of surprised to see a number of people wanting to integrate ActiveScaffold and Hobo. Do you have any opinions on that idea?

@Tom: I’m somewhat surprised by it as well. We should talk offline about what such an integration would entail and whether it fits with each project’s separate mission.

I can’t find your contact email on here so just drop me a line rrwhite|gmail. Thanks

The popular connotation of scaffold is pretty much the only reason we kept it in the name.

So hey, we’re trying to start a BoF for anything/anyone that does or is interested in automated model management. I know that doesn’t peg Hobo exactly, but there’s some relationship there, right? And it could be a good time to really hash out our different purposes.

http://conferences.oreillynet.com/cs/rails2007/view/e_sess/14579

Tom, do email me when you see this comment. I would love to discuss something private with you. Thank you.

wow

I am somewhat familiar with ActiveScaffold but I had never heard of Hobo until a few minutes ago. Hobo sure sounds something very very interesting.
Tom,
Can you please comment a little about how Hobo is different from ActiveScaffold and Streamlined? A short list of feature comparison would be great and probably help many people. I am a little confused about what features are provided by each of these out of box.

Thanks a lot and keep up the great work.

Joshi. Have a read of the What is Hobo? post to get an overview of Hobo’s features.

Hobo is really quite a different beast to both Streamlined and ActiveScaffold. But, compared to ActiveScaffold in particular, Hobo is at a fiarly early stage.

I really love Hobo. It is to Rails as Rails is to Ruby. Every time I want to write some code it seems someone has written a tag I can use :)

I am trying to use Hobo in a project. I want to generate scaffold code. (I do have hobo_model line in my models.) When I do
ruby script/generate scaffold Friendship

I got message
dependency model
The name ‘Friendship’ is reserved by Ruby on Rails. Please choose an alternative and run this generator again.

Any model name I choose, it always say the same thing. Does hobo have something to do with this? Tom, do you have any idea what can cause this? Thanks.

Hmmm – I’ve seen this a few times in Hobo apps too, so I think it is caused by Hobo, but I don’t yet understand why. As a workaround, try moving app/models/friendship.rb out of you app into a safe place while you run the generator, then move it back.

I was about to make a comment about pros and cons of starting to use Hobo but realized it slowly evolved into an analysis that I may want to adjust/expand so I’ve posted it on my blog instead:
http://devanturat.primaevus.com/2007/12/01/hobo/

[...] Hobo != Scaffolding – An attempt to explain the positioning of the Hobo extensions to Rails. [...]

Regarding the integration of Hobo and ActiveScaffold, I’d be very interested in it, so let me give a few reasons why.

First off, let me point out that (as you say) your purposes are different, and therefore it only makes sense that many people might want both what Hobo offers and what ActiveScaffold offers together.

To be more specific, I’m very interested in using Hobo because of all it offers for front-end ease of development, but I really like several things about ActiveScaffold as well:
1. out of the box, without configuration it creates (in my opinion–and this could be because of my ignorance of Hobo) a better admin UI. It does cool stuff with relations (nested subforms) and so forth. This stuff really rocks.
2. it supports things that Hobo doesn’t, like polymorphic associations, which I’m quite sure my current project will need at some point in the future.
3. the documentation appears to be (in my limited experience) more complete.

This is not to knock Hobo. It really rocks in its own way, and does many of the things I always felt Rails ought to have available. In fact some of the things it does are things I thought to myself I’d build a plug-in for once I was sufficiently sophisticated in my Ruby & Rails skills. Then I discovered I didn’t need to… and then I discovered limitations that led me to put my use of Hobo on hold for now.

If I could use both ActiveScaffold and Hobo together, and if I wouldn’t be stung by limitations like lack of support for polymorphic associations (it’s hard to know what would happen if you use them, when the only thing you can find is that they’re not supported), I’d be really happy about having the best of both worlds available in one single project.

assumption here: “users” need a hand crafted UI, while “administrators” can use an auto-generated UI

In the PHP world, at least, I’ve seen plenty of apps that just depend on admins using phpMyAdmin on the DB…


Write a Comment

Comments are formatted using markdown. To include code, either quote it in `backticks` or indent a code-block by 4 spaces.