Suggestion: reconsider the use of HAML

[Ian Young]

Hi all,

This is a message from [wilson] originally posted as a github issue, but
I'm forwarding it to the mailing list so that people will see it and
discuss as needed.

Ian

I'm sorry I missed all of the early discussion of this, but I don't read
the front-matter on login in plans very often :).

At any rate, had I been present I would have recommended against HAML.
Not on any technical grounds--it's a great tool, or aesthetic ones
(though I find it grotesque ;) ), but on long-term
maintainability-of-plans grounds.

Plans is going to need to be handed down to new volunteers on a
semi-regular basis if it is going to survive, and the barriers to entry
for new developers should, in my opinion, be as low as possible. Adding
unorthodox stuff like HAML/SASS/etc raises the bar. Any web developer
can pick up erb, since it is so similar to PHP/.NET/etc. Only a subset
of people are going to grok HAML easily, and even of those there will be
people like me who *can* write it but don't *like* writing it.

Again, nothing against HAML in general: if you're working on your own
stuff or writing stuff for a team where everyone loves it, go for it.
But for volunteer-supported projects, my recommendation is to think 2 or
3 "generations" of developers down the line and stay within the
community's broadest conventions.

[Ian Young]

And my $.02:

The question of a Haml learning curve for newbies did come up during the
strategy conference call, and at that time we decided that it wasn't too
much of an obstacle. My personal experience with learning Haml was
extremely pleasant - I felt like it made sense almost immediately.
However, I accept that others' mileage may vary.

So the question is: will interested developers [who already have a solid
understanding of HTML] struggle with learning Haml? Enough that we
should give up the cleaner view code and resilience to syntax errors?

The observant reader may have guessed by now that I'm firmly in the
pro-Haml camp. But if the consensus is that it's too much of a hurdle in
getting new people started, I will reluctantly go back to Erb.

Ian

P.S. To put one other issue to rest: there have been a couple questions
asked, here and on the conference call, about Haml's status as a
project. Let me assure everyone that it's probably the most stable and
widely-used piece of non-Rails-core code around. Many of the brightest
people and companies in the Rails community are Haml proponents. So it's
not going to suddenly become unsupported, and I would disagree that it's
"unorthodox" (whatever one's feelings on its aesthetics).

[Anna Carey]

This page (http://haml-lang.com/tutorial.html) contains the vast
majority of what you need to know about haml, perhaps all a designer
would need to know, and it's not that long. I'm not the most
accurate typist, and I really appreciate that haml forces me to be
better/cleaner and forces me to format my code better. I'm glad that
it doesn't let me forget to close tags and improperly nest them. I
think firm structure is more important when we might have a few
generations of coders.
To sum it up, I'm pro-haml, but not passionate.
As far as SASS, I'm pretty neutral/ignorant, but you're more likely to
convince me to keep the barrier to entry low there.

> --
> You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
> To post to this group, send email to grinnellplan...@googlegroups.com.
> To unsubscribe from this group, send email to grinnellplans-deve...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/grinnellplans-development?hl=en.
>
>

[Ian Young]

On 3/31/11 12:42 PM, Anna Carey wrote:
> As far as SASS, I'm pretty neutral/ignorant, but you're more likely to
> convince me to keep the barrier to entry low there.

I haven't actually written any for this project yet, but I'd like us to
use SCSS, which is the reborn form of SASS. SCSS looks remarkably
similar to CSS (in fact all CSS is valid SCSS) but comes with all the
turbocharging like nested selectors and mixins and stuff.

I expect this syntax will appeal to CSS lovers and Rails-centric folk
alike. It's so nice and natural that I find myself forgetting that
regular CSS *doesn't* have these things (and then am bitterly
disappointed when I remember). All the examples at http://sass-lang.com
are shown in SCSS by default, if you'd like to check it out.

Ian

[Lunders]

while i understand [wilson]'s concern, there will always be some
barriers to entry, and i think our primary goal should be a high-
quality end product, not just increased involvement. greenleaf seems
to think that HAML encourages the writing of better code, and i feel
that the better we can write this now, the easier maintenance will be
later, so i'm for using HAML.

of course, i don't know HAML and haven't contributed anything other
than text to this project to date, so i'll follow any decision made by
the majority (provided it is the majority of those actually coding).

On Mar 31, 2:53 pm, Ian Young <ian.greenl...@gmail.com> wrote:
> On 3/31/11 12:42 PM, Anna Carey wrote:
>
> > As far as SASS, I'm pretty neutral/ignorant, but you're more likely to
> > convince me to keep the barrier to entry low there.
>
> I haven't actually written any for this project yet, but I'd like us to
> use SCSS, which is the reborn form of SASS. SCSS looks remarkably
> similar to CSS (in fact all CSS is valid SCSS) but comes with all the
> turbocharging like nested selectors and mixins and stuff.
>
> I expect this syntax will appeal to CSS lovers and Rails-centric folk
> alike. It's so nice and natural that I find myself forgetting that
> regular CSS *doesn't* have these things (and then am bitterly

> disappointed when I remember). All the examples athttp://sass-lang.com