HAML Brings Seaside To Ruby | Hacker News Reader

HAML Brings Seaside To Ruby

gilesbowkett.blogspot.com

30 pointsastrec32 comments

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...

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

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.

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

The More You Know

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.

FYI: The new official github for sinatra is at http://github.com/sinatra/sinatra

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.

is it really? have you built anything in seaside?

Nothing big. I've played around with it.

didn't i see a see a screen grab of news.yc redirected to localhost on your box? off the wagon? ;)

Continuation magic of this kind is interesting and useful but only when you don't want to use anything outside the Smalltalk VM (for example some database), when you start to communicate with something external to VM you have only moved problem to different place and probably made it harder to solve. There is reason why call/cc is sometimes called "functional goto".

But apart from continuations seaside also provides system to abstract out HTML generation, that not only changes syntax of HTML but also has support for building page from tree of prepared components (like you would construct desktop application). And this HAML thing only seems to change syntax of HTML and not add any similar capability, so comparing it to Seaside probably is misguided.

Doesn't look like HAML is as readable as Seaside HTML building, maybe it just takes getting used to. The beauty of Seaside is now less in continuations, but more of reusable code and components. (I have always used and read the term reusable as within a project, not necessary as libraries).

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.

" 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.

It's worse than using Builder for XML templates. Builder rocks- it is much more concise and comprehensible. http://builder.rubyforge.org/

  xml.form {
    xml.label "zipcode"
    xml.input :type => 'text', :name => "zipcode'
    xml.input :type => 'submit'
  }

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.

"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...

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.

> 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.

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.

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

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

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

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.

Perhaps, but Haml isn't an abstraction layer. You're still using exactly the same HTML tags and attributes, just expressing them in a different way.

A better way of thinking about it would be simply an alternative syntax for HTML, eliminating most of the tag soup that's inherent in HTML + ERB.

Are you serious? What about when you want to target multiple platforms with the same interfaces but don't want to commit to one form of markup/generated code? Imagine being able to easily render to flex, jquery ui, ext js, clean css/xhtml, gross but effective tables etc.

If you abstract it the idea will come.

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.

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.

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.

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

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.

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

Does Python have an equivalent to HAML?

Reply on news.ycombinator.com