Why do Ruby on Rails professionals NOT use Scaffolding?

I read sometimes from people that seem to be working with rails since longer, that one important lesson they learnt would be "Don't use scaffolding". Also on irc I read commonly hints from this direction. My question is why, what is the bad thing about it? And is nifty_scaffolding bad as well?

My guess would be it is bad because it generates by default an xml version of your controller action, which would expose the field names of our application to anybody and make it more vulnerable for attacks, so maybe it's this?

What are your reasons to not do scaffolding?

I'm experienced with rails and I rarely use scaffolding simply because my end goal is far from simple CRUD actions. However, there's no strict rule to not use scaffolding. Some coders frown on it because it is actually scaffolding, literally. It's not a finished product. Scaffolding supports you as you build the actual product. Search google images for "scaffolding" and you should get the idea.

Keep in mind scaffold is just one of many built-in generators in Rails. A Rails generator is simply a script that outputs some generic code. Generators are very useful time-savers, and you'll quickly find yourself writing generators for your own custom needs.

I believe most professionals avoid scaffolding because they prefer a test driven development approach to writing production code. This means they want to write a failing test first and then write the code that makes the test pass. This is a great way of producing strong code, but it works best at a very granular level. Scaffolding seems to do too much at one time and so it disrupts a tight loop of writing a failing test for a specific features then writing the code that makes that particular feature pass. It may be more important to get into that habit above and beyond the ease of use of scaffolding.

That said scaffolding can be pretty powerful in its own right.

It is important to understand the use of rails generate scaffold and be aware of its limitations. Scaffolding helps you to get something running quickly and test an assumption. But in the real world it will not get you too far. Lets say you created a model with scaffolding

rails generate scaffold Article title:string body:text

Great! You now have a prototype ready. But now lets say you have to add another field "author".

rails generate migration add_to_article_author author:string
rake db:migrate

now the table articles has a new column but the files in /app/views/articles are in the same old state i.e. the form will not have author field etc. If you run scaffold again

rails generate scaffold Article title:string author:string body:text --skip-migration

This time you have added --skip-migrate because that has been done before and Rails will really complain if you were to migrate the same table again. Now scaffold will prompt you to overwrite the file it created the first time. Overwriting will also destroy any changes you made to your controller /app/controllers/article_controller.rb or views files like /app/views/article/show.html.erb or index.html.erb

Since any worthwhile Rails app has custom code (and not boilerplate code created by scaffold) a Rails programmer should use scaffold only to test an idea. Use scaffold to give your client something to play with. But in real world boilerplate scaffold code is not used.

Scaffolding isn't really meant for production use. It's meant to get an application bootstrapped quickly and then it can be modified or done away with.

The Rails 3 scaffolding is actually pretty decent, but it still lacks some things like a way to handle nested resources and it doesn't use the simpler respond_with (over respond_to, which encourages verbosity where it isn't needed or welcome).

It's unlikely that the default scaffold forms will work un-modified, either — you probably have relationships between your models that translate to a column in the database like user_id. When creating a scaffold of a model with a relationship, this column shows up as a text field in the form when clearly it should be inferred from the URL or selected via another, more user-friendly, interface.

There are a lot of small details like this that make scaffolding a really unlikely candidate for production-ready-out-of-the-box code. You can certainly build an application by generating the scaffold and then filling in the gaps and cleaning up areas you don't need, though, and I suspect most Rails developers do this to some extent.

I don't use scaffolding for two reasons:

• Rails scaffolding puts everything in a html tables - I don't like that
• I prefer to use rails_admin gem for my admin pages so there is no need for 90% of the scaffold code

Your xml concerns are not the reason why people advise against using scaffolding. I don't bother with XML versions of my pages as it doubles the number of routes your app must generate, which in turn increases the overheads a little...

People thus far have said that experienced rails programmers don't use scaffolding, and for good reasons mainly. I advocate that beginners don't use scaffolding either.

You may have been plodding along happily for some time with scaffolding, and then you realise that you forgot to include the published boolean field for your Post model, so you generate a migration to add the attribute to the table (you've managed to work that out). You then also have to work out how to add that to the form that scaffold produced. Then for the life of you you can't work out why it's not updating when you submit your form, and after much strife and wasted time you figure out you haven't permitted mass assignment on that attribute like scaffold did for you on the others. Turns out you don't really know anything about how Rails works.

If you're learning Rails, you'd understand much more about MVC if you built the M the V and C yourself.

I am professional Rails developer and I use scaffolding all the time, in fact I can make a pretty decent argument that reproducibility and predictability of scaffolding can make the whole process of learning rails and using rails easier.

The approach we use is to always start with scaffolding and then as time goes along and we see patterns customise the scaffolding for the project.

This approach means that we have an approach when we learn we bake knowledge back into the project and when we find issues we fix them in one place and all subsequent uses of the scaffold have that learning instead of constantly having to explain, justify and educate different developers at different skill levels.

In my experience the biggest issue with rails is its greatest strength! It is the malleability of a rails project is what causes it to be hard to maintain. Lots of ways to achieve the same-thing which is not wrong but does make it hard to pick up from somebody else who has started the project.

Is our approach fUN , debatable! Is it reproducible, effective, efficient while leaning on rails instead of fighting it , 100% yes!

I think scaffolding is very good to check out the new stuff of new rails versions (for example now in rails 4 the params permit stuff in a controller). You can use it for fast prototyping. Often it is simple not necessary to generate a full scaffold..