Why use rails helpers?

Hi Guys,

I was reading an article and one question come into my mind…

I know that rails view helpers, like: form_for, select_tag, makes the HTML code automatically.
But at the performance view, is it a good idea?.

I mean, using this kind of helpers will include some “server-side” calls.

My question is:
Is a good Idea use this kind of helpers or create HTML code by myself?

Thx.
Bruno Meira

Hi Guys,
I was reading an article and one question come into my mind...
I know that rails view helpers, like: form_for, select_tag, makes the HTML code automatically.
But at the performance view, is it a good idea?.
I mean, using this kind of helpers will include some "server-side" calls.
My question is:
Is a good Idea use this kind of helpers or create HTML code by myself?

Helpers keep everything following the rules. You don't have to figure out what the ID should be or what the field name should be, the helper makes it all perfectly uniform and keeps it what the controller expects.

As far as I know, there is no penalty for this, except maybe at application start time, when all of these view helpers are compiled and concatenated once and for all.

Walter

Thx for your reply Walber. :smiley:

That’s exactly the point that is my question.
The helper will be constructed at view time, isn’t it?

If it was at application start time, how ruby syntaxes that involves iteration will works?

Example:

@users.each do |user|

f.select_tag …

Well, I’m not so sure that these helpers will be work without an overhead.

For now, I think that helpers are good just as a start version of your app, after you have to change your view to work with as less erb as you can.

*Walter

Thx for your reply Walber. :smiley:
That's exactly the point that is my question.
The helper will be constructed at view time, isn't it?
If it was at application start time, how ruby syntaxes that involves iteration will works?
.....
Example:
@users.each do |user|
f.select_tag ...
.....

Well, I'm not so sure that these helpers will be work without an overhead.
For now, I think that helpers are good just as a start version of your app, after you have to change your view to work with as less erb as you can.

If you can pinpoint the erb as a source of overhead in your performance testing, then certainly, have at it. But while you are designing and iterating your application, hand-coding the views is a source of developer overhead that you really need to balance against theoretical maximum application performance. (Even if you don't pay your developers anything at all, it still takes time to make the changes, and the thought of that effort is a chilling effect on your willingness to try new things.)

Walter

The processor time required to evaluate such helpers is absolutely
trivial compared to other server side operations such as querying the
database and handling requests and responses

Colin

Thx Guys,
I understand.
Well, as I see this overload is small compared with the benefits of using these helpers.
:smiley: