7 ms·
HAML Brings Seaside To Ruby
- bprater 18y agoI have yet to see a good case made for when abstracting HTML back is a "really great idea".
- nonrecursive 18y agoI 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.
- rufo 18y agoPerhaps, 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.
- shaunxcode 18y agoAre 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.
- jstraszheim 18y agoThe 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.
- giles_bowkett 18y agois it really? have you built anything in seaside?
- jstraszheim 18y agoNothing big. I've played around with it.
- astrec 18y agodidn't i see a see a screen grab of news.yc redirected to localhost on your box? off the wagon? ;)
- dfox 18y agoContinuation 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.
- hboon 18y agoDoesn'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).
- jon_dahl 18y agoI'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 18y ago" 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.
- mattmcknight 18y agoIt's worse than using Builder for XML templates. Builder rocks- it is much more concise and comprehensible. http://builder.rubyforge.org/ http://builder.rubyforge.org/ xml.form { xml.label "zipcode" xml.input :type => 'text', :name => "zipcode' xml.input :type => 'submit' }
- jraines 18y agowhen 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-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 http://github.com/bmizerany/sinatra/tree/master
- rufo 18y agoI 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 18y agoAh -- I didn't know about that. I was just putting my script tags in strings. Thanks! The More You Know
- rufo 18y agoNo 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.
- cschneid 18y agoFYI: The new official github for sinatra is at http://github.com/sinatra/sinatra http://github.com/sinatra/sinatra
- rufo 18y agoIn 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 http://haml.hamptoncatlin.com/docs/rdoc/classes/Sass.html
- gommm 18y agoI really enjoy using sass with compass... it makes css much more bearable...
- ivey 18y agoI 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 18y ago"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 18y agoHTML 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.
- richcollins 18y agoHe 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.
- dustineichler 18y agoeven 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 18y agoIt seems that, as with YAML, examples tend to be quite short, with limited indentation.
- jamongkad 18y agoDoes Python have an equivalent to HAML?
- jhancock 18y agowell, 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.
- compay 18y agoIf 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.
- kuniklo 18y agoThe minute you have to start working with designers HAML is a no-go.