Here's a draft of a blog post I want to make. Any additions or corrections
or suggestions are more than welcome.

---

**Why Wouldn't You Use Erector?**

No, seriously. Why wouldn't you use Erector? Cause I think it's a pretty
awesome view framework, but for some reason it hasn't caught fire yet. So if
you think writing actual Ruby to emit HTML, with a clean, nestable syntax
with full support for Ruby features like inheritance, delegation, and yield
is neat, but there's something holding you back, then please let us know
what it is. At best we can fix it, and at worst, at least we'll know why.

Here are some reasons I think you might not use Erector:

**You love angle brackets.** If this is the case then I can't help you. I
don't think anybody can.

**You like typing every tag name twice.** Since Erector elements are Ruby
statements, every open tag gets automatically closed.

**You like invalid HTML.** Since Erector elements are Ruby statements, every
open tag gets automatically closed. (See how that works?)

**You always remember to call 'h'.** Rails 3.0 is going to HTML-escape all
output by default. Erector's been doing this the whole time. Cause, you
know, why wouldn't you?

**You like having to rewrite your code when you extract a partial, and then
again when you extract a helper method.** In ERB, templates, partials, and
helpers all have slightly (and annoyingly) different syntax for things like
referring to variables and calling other code. Erector is all Ruby, so you
can use your [favorite refactoring browser](http://www.jetbrains.com/ruby/),
or just cut and paste, to move your code around. Check out this  [excerpt
from Jeff Dean's RailsConf talk](http://www.youtube.com/watch?v=hTfCPkDV0Xo)
to see this in action, or read [the slides from the whole talk on
SlideShare](
http://www.slideshare.net/alexchaffee/advanced-views-with-erector).

**You hate encapsulation.** You think that your views should have direct
access to all the instance variables of your controller. Unless they're
partials, in which case you [shouldn't](
http://www.robertshowalter.com/articles/2007/07/24/dont-use-instance-...),
even though you can although they might mean different things. Confused yet?
So am I.

---

Okay, so those were sarcastic reasons. Here are some more possible reasons
why you wouldn't use Erector. I suspect that these next ones hit closer to
the mark. But I believe that they're all specious, if not downright false.

**Your site contains a whole lot of complex HTML and a few inserted Ruby
variables.** OK, this makes sense. Erector's not great for static sites. But
I've never personally worked on a web application where the code inside the
views didn't quickly get complex enough to require codey things like loops
and functions. And if you're writing code, then why not do it in a
programming language?

**Your designers don't know Ruby.** I've heard this complaint a lot, but I
have yet to meet this mythical designer who's smart enough to understand
modern HTML, CSS, JavaScript, ERB, and partials, but is not smart enough to
learn that "div 'foo', :class=>'bar'" outputs "<div
class='bar'>foo</div>". On the contrary, I've worked with several
designers who, after a few tutorial pairing sessions, were comfortable
checking code in and out and editing Erector view code at will. Like any
junior coder, they need to stay away from the tough stuff, but they're
pretty good at knowing what they don't know and asking for help when they
need it. (Which they would also do if working inside ERB.)

**View code needs to look as similar to HTML as possible.** Well, I hear
this, but have you looked at HAML? That language is hella popular, and it
doesn't look anything like HTML. Its structure is similar, in the abstract,
but so's Erector's, and at least in Erector the method for emitting a div is
called, you know, "div". And I don't want to turn this into a war between
HAML and Erector -- I think HAML is gorgeous -- but HAML suffers from the
same design flaw as every templating technology: views are not objects, and
markup isn't code. After a certain point of complexity, HAML's elegance
breaks down and you'd be better off doing loops and functions in code.

**You've already got a bunch of stuff in ERB and it'd take too long to
convert it.** Yes, legacy code is a pain, but we have a command-line tool
that converts ERB (or HTML) to Erector to make it a bit smoother. And you
don't have to convert your whole app to Erector at once. Erector views can
interoperate with Rails ERB or HAML.

**Erector's too slow.** Lies! Erector is faster than a greased rattlesnake
going downhill. Check out [these benchmarking results](
http://erector.rubyforge.org/faq.html#howfastiserectorcomparedtoerbha...).
Erector is about 2x as fast as ERB and 4x as fast as HAML under
typical
conditions.

**There's no documentation.** More lies! We have a whole bunch of
documentation at <http://erector.rubyforge.org>, including a FAQ and a user
guide.

**Rails has all these great helpers and I want to keep using them.** Okay,
go right ahead! Erector's Rails integration allows you to call any helper,
either directly through a proxy method, or indirectly through the helpers
object. If you find a helper that doesn't work, let us know and we'll add it
to the list of supported helpers. (We haven't done all of them yet because
it's a pain in the neck to look at each function and figure out what its
input and output semantics are. Does it return a string or emit directly
onto the output stream? Does it take a block? An options hash? An
html_options hash? Etc.) We're also slowly putting some Rails functionality
into Erector, either in the base class or in custom widgets. If there's
something you need, ask on the mailing list, or better yet, send us a patch.

**Its name is a dirty word.** I've heard this more from people who didn't
grow up in the United States, where the [Erector Set](
http://en.wikipedia.org/wiki/Erector_Set) was a popular toy among the
6-to-12-year-old DIY set in the 70s and 80s. (Apparently it was called
[Meccano](http://en.wikipedia.org/wiki/Meccano) in the UK.)
Erector is a normal word, used all the time in the [news](
http://tinyurl.com/yd55pal) and in [business names](
http://google.com/search?q=steel+erector). And as the name of a view library
it's evocative in a way that's relevant and interesting, in that it's a
builder, and you build a view up out of parts.

But we have heard this complaint, and in sympathy, changed the name of the
command-line tool (oh, sorry, guess I can't say "tool" either)-- uh,
executable-- from "erect" to "erector" even though the former is a venerable
English verb that's grammatically appropriate ("I asked him to erect the
scaffolding."). If you introduce the library and your coworkers get all
giggly then I think if you just say the name with a straight face and then
roll your eyes and mock your bawdy buddies when they snicker then all will
be well.

**You've never heard of it.** Help spread the word! Post a review on your
blog! Ask your favorite app framework whether they support it! Post code
samples in Erector and when people say "What's that?" then point them at <
http://erector.rubyforge.org>! Give a talk at a meetup! Write your
congressman and ask if she supports the Erector Mandate Bill of 2009! Buy
[ad space on the moon](
http://www.universetoday.com/2009/07/24/company-looks-to-etch-adverti...
)!

---

So, in conclusion, and despite my somewhat snarky tone throughout, I am
honestly and desperately curious to know why the world has not yet beat a
path to Erector's door. Anybody got any more ideas?

Hi Alex,
I think Erector is great and I also have no idea why people wouldn't use
it. But maybe you should ask the opposite - how often Erector is being
used in real projects comparing to other view frameworks? I think Ruby
view frameworks are not being used very often in general. If there are
any known sites which use Erector then they should be listed on the
Erector website! Another issue is that Erector is, as far as I know, the
newest view framework among all the other best known. It is like with
PostgreSQL, which is better in many means than MySQL but people still
choose MySQL because other people already use it, there is more
books/articles on it, etc. However, the most important issue for
companies may be that Erector is still in its beta/development stage, as
indicated by its version. Maybe you just need to be patient and Erector
will stand up for itself when the time comes?
Thanks for your continuous support!
Greg

The greatest fear I would have is maintainability.

There is a Rails project I recently tried to upgrade.  The usage of
Markaby essentially killed the upgrade by burning up all of the
allocated time trying to fix and/or find a working version, because of
the horribly fragmented and confused state of Markaby.  This made me
very sad and upset, not only because I looked bad by failing to finish
the upgrade, but also because I've got to either let this app languish
without an upgrade (which is causing much unrelated pain), or invest
the time to finish the upgrade (make Markaby work or rip it out).

So, even if Erector is the greatest thing since sliced bread under the
current and previous Rails versions, I'd very wary of using
non-standard shiny new technologies in an app, lest I doom the
inheritors of my app to a situation like I had with the Markaby
upgrade fiasco.  Especially after Rails 3 hits.

In other words, I'm a minimalist, and I like standard (working!)
technologies, and don't get easily bent if I can't use shiny new
technologies when old ones work fine (albeit with some extra
unnecessary work).  I'm perfectly fine with using ERB, because I'm
positive it is going to be well-maintained as Rails moves forward.
Especially after Rails 3 hits.

Anyway, that's a bit of an extreme straw man argument which I'm sure
you can easily immolate, Alex; but I'm just trying to help you out
with a POV from the devil's advocate.  It is a valid concern.

-- Chad

P.S. By the way, have I ever mentioned how I hate for the reply-to not
being set to the list?  I have, and I'll continue every time I have to
manually paste the list address to a reply.  That is wrong, you should
fix it.

Yeah, the 50-million-erb-fans-can't-be-wrong FUD.  I'm not saying that
what you're saying is untrue, but all you have to do is take action
and do something about it.

Btw how is that haml gets a pass these days?

This is much easier said than done on a low-budget maintenance
project, where the customer may freak over a day or two to upgrade,
much less a week of
patching-old-outdated-unmaintained-shit-to-work-just-so-you-can-continue-wi th-the-upgrade-to-fix-an-unrelated-problem.

I don't call it FUD, I call it reality on a maintenance project.

-- Chad

A motivation for making Erector is to make a more maintainable Markaby.
Also, you must consider Yehuda's efforts to make a solid Rails api for
supporting additional view frameworks.

Having a large community does diminish the likelihood of there being
issues with upgrades, since more people will be using the library. If
there is an issue, usually you can write an email to the project
maintainers.

Fortunately, Erector is an active project, unlike Markaby, it seems.

hi,

just to let you know: after two rails upgrade I was about to gave up
markaby and was pretty happy to find erector and ever since it went
smoothly with little hick ups here and there.

on top it I got object oriented framework which I really like, too.

and I am using it for to production site right now and recommend
erector whenever I can.

so far many thanx to the erector team for their work - it really help
my projects a lot !!!!

with regards
Kristian

ou have to do is take action

--
Kristian Meier + Saumya Sharma + Sanuka Meier
Vadakkethu House,
Edayanmula West PO - 689532,
Pathanamthitta District, Kerala, INDIA

tel: +91 468 2319577

protect your privacy while searching the net: www.ixquick.com

             _=_
           q(-_-)p
            '_) (_`
            /__/  \
         _(<_   / )_
      (__\_\_|_/__)

Yes, I await that glorious day, and I'll feel much more comfortable
when it is simply a matter of choosing a view framework which passes
everything in the rails API compatibility suite.  Unfortunately, that
day has yet to come.

Markaby was active at one time.  It still is actually -
coincidentally, I've been communicating these same concerns to one of
the guys maintaining Markaby.  That still didn't change my situation,
and I believe it is primarily due to the lack of a plugin API, not the
skill of the maintainers or persistence/disappearance of the original
authors.

-- Chad

Yehuda has assured us, when he came into Pivotal, that ActionPack's
API is going to be relatively stable. AFAIK, the api has not changed
much since 2.2.x.
Yes, this is one of the issues with developing plugins with Rails is
their sometimes poor code quality, particularly non-existent APIs.
Unfortunately, it only hurts the Rails ecosystem, as more effort needs
to be spent on making/maintaining libraries that often increase
productivity. This makes any plugin suspect, yet somehow things seem
to work out, albeit painfully.

Erector's design attempts to minimize the risks by not using complex
logic #method_missing (as does Markaby) and instead, having the logic
be in separate "proxy" helper methods. There is also integration
testing.

Yes, there is certainly a risk for regressions. There is also a
corresponding risk that no-so-optimal libraries and abstractions
introduce to your project's design.

Btw, I'm still interested in your Rails compatibility stuff. Are you
going to release it?

Thanks,
Brian

Hmm.  You're convincing me :)  Is there a Markaby-to-Erector converter?

Not sure what you mean.  You can drop me a line off-list...

-- Chad

Cool. Unfortunately, there is not a Markaby-to-Erector converter.

I'm working on an *.ert template, which is a lot like Markaby. I'm
using the templates in a side project and converting .mab templates to
.ert. The Rails helper support is also going to be better, since one
would can simply use `link_to` instead of `rawtext link_to` (`text
link_to` in the case of Markaby).
It will be in the next release.

-Brian

Is erector currently being built against edge rails?  The biggest pain
I felt with erector was having to make changes to erector after rails
was released.  On the day that edge rails becomes real rails, erector
should just work, and that hasn't been the case for the last few big
rails updates.

On Oct 5, 2:46 am, Brian Takita <brian.tak...@gmail.com> wrote:

Brian wrote the code that runs tests against Rails so he'd know for sure,
but AFAIK it checks out the latest stable Rails and runs some integration
tests against that.
The advantage of this is that since Edge Rails is changing so much it
doesn't force us to chase a moving target, and if Edge Rails does change in
a non-backwards-compatible way we don't have to maintain two branches. It
was a huge headache in the early days having multiple branches / subdirs to
support different versions of Rails so we just decided to cut our losses and
support latest stable only.

The disadvantage, as you said, is that there's a lag between new Rails and
the new Erector that supports it.

Also, as Brian noticed over the weekend, it's possible for our Rails suite
to pass and still miss some Rails regressions.

I think the right solution is to be more diligent and not try to run against
Edge unless a release is imminent.

Also, currently we have to manually increment the version of Rails that gets
checked out; we could either always check out the latest stable, or put
something in the developer guide to remind people to do it more quickly. I
personally have been the most active on the Erector codebase but I don't use
Rails so I missed the 2.3.4 upgrade. When Brian upgraded to 2.3.4, I found
and fixed some failing tests, and Brian has apparently found a few more
bugs.

---
Alex Chaffee - a...@cohuman.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

---
Alex Chaffee - a...@cohuman.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

HAML is quite popular. And they're both about the same age (2-3 years).

will stand up for itself when the time comes?

You're right that libraries need time to catch on, but I'm trying to prime
the pump. Cause Erector's awesome :-)

P.S. By the way, have I ever mentioned how I hate for the reply-to not
http://www.unicom.com/pw/reply-to-harmful.html

I subscribe to the SF Ruby Meetup list and at least once a week someone
accidentally posts a private response to 1600 people because they're used to
"[R]eply" going to one and "Reply [A]ll" going to many.

You don't have to manually paste anything; just reply to all. It's "A" in
GMail. Modern mail clients don't receive duplicates, and don't display them
when they do.

 - A

This attitude sort of contradicts Brian's (Yehuda's) assertion that
the API is stable and shouldn't be changing that much.

Why don't you run CI against the latest edge rails?  If the API is
truly getting stable, then you should be able to do version checks to
support the 2.3 branch and the master branch.  If that is too hard to
do, then perhaps my fears of forward-compatibility risk are not
entirely unfounded :)

-- Chad

I solidly prefer that risk over people wanting to reply to the list,
but instead unknowingly sending a private message because they hit
reply instead of reply all (as I've caught myself almost doing three
times in this thread).  Most mailing lists do not work the way you are
want, Chafee, they are set as reply-to-list, so your setting violates
the principle of least surprise.

Also:
* Even on the meetup list, people learn after a time or two
* There are not 1600 people (mostly recruiters anyway?) on this list
* The level of technical and email-client ability on this list is
hopefully higher than the SF Ruby meetup

It's *going* to be stable, right? Is it yet? I'm still back in "once burned,
twice shy" and "seeing is believing" land with Rails. (Like you are with
Markaby.)

That's a fine idea. Maybe some combination of you, me, and Brian could work
on getting the Rails version to be configurable in different CI builds, and
then put up a CI instance for that.

 - A

The main design goal of Erector was to be a better Markaby. We have steadily
removed magic(*). API changes have been documented and the biggest included
an upgrade guide (**). We run integration tests against Rails at will. We're
doing what we can. We're totally on your side here! :-)

(*)
http://github.com/pivotal/erector/blob/f795679773009ff7906dcf1184f38a...
(**)
http://pivotallabs.com/users/alex/blog/articles/839-erector-0-6-3-now...

You get the master-branch build working, and I'll set up a new project
for it on http://ci.pivotallabs.com/

The master branch has been green for months. The CI install seems to
have been frozen since June with

"
/home/pivotal/.cruise/projects/Erector/work pivotal$ git fetch origin
fatal: read error (Connection reset by peer)
"

I restarted it and now it's failing because nokogiri needs to be
native-compiled on the CI box. Can you sudo gem install that sucker?

---
Alex Chaffee - a...@cohuman.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

Yes, I am trying to fix that bug as we speak, but it is a hard one
(MRI 1.8.6 can't timeout IO blocking threads).  Unfortunately, it is
tricky.  Check the ccrb dev list and lighthouse for more info.

You should be able to do it yourself with GemInstaller as part of your
build.  Geminstaller runs under nopasswd sudoers.  Or even better, try
out Bundler...

I'm copying Yehuda on this.

Yehuda came to Pivotal to discuss Desert and our other Open source efforts.
Yehuda mentioned that the ActionView api was one the first things he
worked on and is relatively stable.

Yehuda, please correct any misunderstandings on my part.

To provide context, we are trying to integrate Erector with Rails.
There has been a history of integration issues due to the
monkey-patching and the changing internal api with templates and
helpers.

FYI, Erector is a html builder framework, similar to Markaby and Tagz.
The big difference is Erector uses widget objects under the hood.

Thank you,
Brian

The template handling API is pretty rock solid at this point. I don't
anticipate any future changes. The Resolver API is also pretty solid. The
only caveat I'd have is that we might be forced to change things in response
to feedback from you guys. Which is a good reason to try and make it work on
edge.
-- Yehuda

On Mon, Oct 5, 2009 at 10:27 AM, Brian Takita <brian.tak...@gmail.com>wrote:

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

Sounds pretty persuasive. Brian, if you want a pair for this, would you like
to come to my place one evening or weekend soon?
---
Alex Chaffee - a...@cohuman.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com