
HAML Brings Seaside  To Ruby - astrec
http://gilesbowkett.blogspot.com/2009/01/haml-brings-seaside-awesome-to-ruby.html
======
jraines
_when you're writing HAML, you're programming more and marking up less . . .If
you like programming and you don't like writing markup, then the advantage is
you have more fun._

I second that. I used Sinatra and HAML when I wrote Feedstomper.com and the
whole thing just felt lighter and more fun than some Rails apps I've written
(when I was also using erb).

Granted, the whole concept was lighter than those apps, but still -- I like
HAML.

One issue: sometimes you can stumble over javascript:
[http://b.lesseverything.com/2008/2/19/haml-doesn-t-like-
java...](http://b.lesseverything.com/2008/2/19/haml-doesn-t-like-javascript)

Oh, and if you're interested in Sinatra (and why not, while we're waiting on
Mrailerbs), you can learn it from just this page:

<http://github.com/bmizerany/sinatra/tree/master>

~~~
rufo
I read your comment, and was a bit taken aback.. "isn't that what :javascript
is for?"

Reading through the comments, though, :javascript was developed specifically
in response to that post - it wraps everything indented in script tags, and
does the right thing with special characters/etc.

~~~
jraines
Ah -- I didn't know about that. I was just putting my script tags in strings.
Thanks!

 _The More You Know_

~~~
rufo
No problem. I don't think I caught it until I went through the Haml docs a
second or third time - lots of handy little tidbits floating around in there I
missed the first time.

------
jstraszheim
The real amazing part of Seaside is how is uses continuations to turn the http
request/response cycle inside-out. HAML doesn't appear to do anything like
that, so comparing it to Seaside seems misguided.

~~~
jon_dahl
I'm pretty sure the article was just trying to compare HAML to a small part of
Seaside. ("Seaside packs a lot of ideas into one framework. _One_ innovation
[ed. not _The primary_ innovation]: you don't write HTML.")

I think the real point wasn't even that Seaside's HTML generation is
smart/powerful/fun. It's this:

 _I enjoy programming in Seaside because when I'm programming in Seaside, I'm
programming. I'm not wrestling with markup; that's for computers to do. I get
the same pleasure out of using HAML._

~~~
jamesbritt
" I'm programming. I'm not wrestling with markup; that's for computers to do.
I get the same pleasure out of using HAML."

Anecdotal counterpoint:

I'm one of those who has the opposite experience with Haml. It's a constant
fight. OTOH, XML/HTML is stupid easy; my editor takes care of the annoying
parts, and I never fight with cryptic errors. It's easy to cut-n-paste for
assorted sources, and use WYSIWYG editors if and when I want to.

I think I could live with Haml (I'm sort of compelled to deal with it since I
took over an abandoned Rails project) if it did not use significant
indentation. It works ok for small chunks of text, utter pain when there's
much nesting going on.

The application of the description "terse" is quite on the money. It's not a
feature.

------
ivey
I get why some people will object, since Haml is an alternate markup language,
and Seaside is a framework. I basically agree. However, the point of this
post, and the point of the discussion here, should be about how awesome Haml
is.

I wanted to hate it. I don't like significant whitespace _at all_ and so
dismissed Haml at first as not something I would ever look at. Enough people
told me it was awesome that I had to try it for 10 minutes, and it really grew
on me.

Like Sinatra, it's just fun. They pair really well together.

~~~
joe_the_user
"One innovation: you don't write HTML. You tell Seaside what HTML you want,
and it does all the dirty work."

I'm sorry. I really think it is legitimate to dismiss Haml out of hand. The
ideal framework writes everything for me _but_ the html. If there is one think
about the web that _works_ , it is html. HTML is the first markup language
used widely by non-programmers. You can come up with whatever argument you
want for its undesirability but its like trying to fight the need for a qwerty
keyboard in a PDA.

Not only is Html a great, proven, standard language for representing rich text
on a page, it is a language that even your customers can understand (not to
mention your web designer..). I'm sure someone once came out with a great,
non-ascii word processor...

~~~
gnaritas
HTML is nothing more than a syntax that represents a tree of nodes with
attributes, that's it, and there are other syntaxes that can also represent
that same structure just as good.

When you have a language who's syntax is directly capable of representing that
structure natively, it's a huge programmatic boon to simply write the markup
directly in the host language.

In Seaside for example, since HTML is written in Smalltalk directly, I can use
all of Smalltalk's automated refactoring tools on it, extracting methods,
renaming things, pushing methods up and down the class hierarchy, etc. You can
slice and dice pages in a way not possible with text files.

This is a huge advantage over raw HTML templates for the programmer. Seaside
firmly insists that the programmer, not the designer, should be generating the
proper markup; the designer has CSS. If this fits your work style, or if
you're both the designer and the programmer, this style will benefit you and
is much more enjoyable that raw HTML.

~~~
davidw
> When you have a language who's syntax is directly capable of representing
> that structure natively, it's a huge programmatic boon to simply write the
> markup directly in the host language.

 _IFF_ the other people you have to collaborate with, such as designers,
artists, new programmers, etc... are all fluent in that language. That's a big
'if' in my opinion. I can hand someone a Rails template file, and they can
hack at it even if they don't know Ruby.

~~~
gnaritas
It's not a big if at all, representing a tree of nodes with attributes in an
alternate syntax doesn't change the semantics of the markup. If they know
HTML, they can learn an alternate markup style in minutes, it ain't rocket
science.

------
rufo
In addition, Sass (Haml's CSS counterpart) is almost worth the price of
admission by itself - the way it handles nested CSS rules and families is very
smart, and that's not including constants and calculation functionality.

<http://haml.hamptoncatlin.com/docs/rdoc/classes/Sass.html>

~~~
gommm
I really enjoy using sass with compass... it makes css much more bearable...

------
bprater
I have yet to see a good case made for when abstracting HTML back is a "really
great idea".

~~~
nonrecursive
I wouldn't call HAML "really great", but after using it for a few months I can
say it's a pleasant improvement over writing straight HTML. It's just a matter
of taste.

------
compay
If HAML's not your thing then ok, to each his own. But the people here
dismissing HAML out of hand because it's "easier" to just write the HTML by
hand sound like people advocating typewriters over word processors. The whole
reason to abstract HTML away is because it's easy. Writing HTML by hand is
repetitive and boring. If you still enjoy it, you probably haven't been doing
it for very long.

------
richcollins
He totally misses the point of seaside. It isn't about slick html generation.
It's about keeping the client state entirely in the server through
continuations. Seaside would be nearly as powerful if you still had to
generate all of the html by concatenating strings.

Having said that, I think Seaside is headed the way of the dodo as javascript
clients become easier and more powerful.

------
jhancock
well, both technologies are interesting on their own. but comparing them is a
stretch.

Instead of bringing seaside to ruby, can we bring a merb-like framework in
smalltalk? seaside's continuations are very cool. But I do not need them for
most interactions, just the more complex ones.

------
kuniklo
The minute you have to start working with designers HAML is a no-go.

------
dustineichler
even after reading this, i can only speak to haml. it does beautify your
markup, but like anything... it can still become a pain to read when files
become verbose.

~~~
jamesbritt
It seems that, as with YAML, examples tend to be quite short, with limited
indentation.

------
jamongkad
Does Python have an equivalent to HAML?

