I''ve been looking for a new gig lately, and have noticed that an alarming (to me, since I don''t yet speak HAML) number of the openings mention HAML as a required or desired skill. I noticed HAML out of the corner of my eye back when it first came on the scene, and at the time considered it to be not worth the effort to learn yet another syntax. It looks like maybe since that time it has become more common and gained some traction. What do you think? Still just a "contender", or is it gaining substantial "market share" and taking over the Rails universe? thanks, jp (p.s. looks like maybe it goes hand in hand (expectation-wise) with SASS, so comments on that welcome also) -- Posted via http://www.ruby-forum.com/.
On Aug 28, 7:38 pm, Jeff Pritchard <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I''ve been looking for a new gig lately, and have noticed that an > alarming (to me, since I don''t yet speak HAML) number of the openings > mention HAML as a required or desired skill. > > I noticed HAML out of the corner of my eye back when it first came on > the scene, and at the time considered it to be not worth the effort to > learn yet another syntax. > > It looks like maybe since that time it has become more common and gained > some traction. > > What do you think? Still just a "contender", or is it gaining > substantial "market share" and taking over the Rails universe? > > thanks, > jp > > (p.s. looks like maybe it goes hand in hand (expectation-wise) with > SASS, so comments on that welcome also) > -- > Posted viahttp://www.ruby-forum.com/.I wouldn''t really know, as the few gigs I''ve worked have all already had ERB templates. I also tend to care very little about "market share" or the next hot thing; if I have the choice and one tool is easier/faster for a certain task than another (and yes, HAML is better for producing HTML or XHTML markup than anything else right now), I''ll use the better tool. However, HAML is **braindead simple** to learn and become proficient with (really, http://haml-lang.com/tutorial.html doesn''t exaggerate at all about its simplicity), and since when was learning more technologies ever a bad thing?
pharrington wrote: I also tend to care very little about "market> share" or the next hot thing; if I have the choice and one tool is > easier/faster for a certain task than another (and yes, HAML is better > for producing HTML or XHTML markup than anything else right now), I''ll > use the better tool. However, HAML is **braindead simple** to learn > and become proficient with (really, http://haml-lang.com/tutorial.html > doesn''t exaggerate at all about its simplicity), and since when was > learning more technologies ever a bad thing?learning more technologies is only a bad thing when it turns out to be a waste of time. A broad category of development such as dynamic web app development doesn''t just move forward, it tends to move back and forth quite a bit. Many people think they have a better idea, but many of them are wrong. One could waste a lot of time if one learned/tried-to-use every new fad that came out. I''m hoping to find out from this thread if HAML is side-to-side, or forward motion. Sounds like your vote is "forward". thanks, jp -- Posted via http://www.ruby-forum.com/.
On Aug 29, 2009, at 10:33 AM, Jeff Pritchard wrote:> > pharrington wrote: > I also tend to care very little about "market >> share" or the next hot thing; if I have the choice and one tool is >> easier/faster for a certain task than another (and yes, HAML is >> better >> for producing HTML or XHTML markup than anything else right now), >> I''ll >> use the better tool. However, HAML is **braindead simple** to learn >> and become proficient with (really, http://haml-lang.com/ >> tutorial.html >> doesn''t exaggerate at all about its simplicity), and since when was >> learning more technologies ever a bad thing? > > learning more technologies is only a bad thing when it turns out to > be a > waste of time. A broad category of development such as dynamic web > app > development doesn''t just move forward, it tends to move back and forth > quite a bit. Many people think they have a better idea, but many of > them are wrong. One could waste a lot of time if one > learned/tried-to-use every new fad that came out. > > I''m hoping to find out from this thread if HAML is side-to-side, or > forward motion. Sounds like your vote is "forward".Neither Haml nor Sass have "moved side to side." There has been consistent forward progress, the churn is non-breaking, so working code is seldom (if ever) affected by changes. Time-to-bug-fix is extremely fast if you can produce a reproducible bug, and the developers remain completely engaged in the project. If you want a better flavor for what''s going on with Haml and Sass, check the Haml group: http://groups.google.com/group/haml You may also be interested in Compass, a Sass framework that takes advantage of Sass features to put an abstraction layer on top of CSS. http://groups.google.com/group/compass-users My approach to this whole kind of decision making is to try the technology and if it suits my needs, then fine. Use it. I try not to invest my learning time in dead technologies, so it''s probably right of you to ask what people think about Haml''s current state in the development community. It is currently supported by (or currently supports): Rails Sinatra Merb Webby StaticMatic Compass And probably a bunch of other Ruby tools I haven''t named. Do a "hello world" app with it and see whether you find the style useful for your needs. Hope this helps and do check out the Google groups.
Steve Ross wrote:> On Aug 29, 2009, at 10:33 AM, Jeff Pritchard wrote: > >>> tutorial.html >> learned/tried-to-use every new fad that came out. >> >> I''m hoping to find out from this thread if HAML is side-to-side, or >> forward motion. Sounds like your vote is "forward". > > Neither Haml nor Sass have "moved side to side." There has been > consistent forward progress, the churn is non-breaking, so working > code is seldom (if ever) affected by changes. Time-to-bug-fix is > extremely fast if you can produce a reproducible bug, and the > developers remain completely engaged in the project.Thanks Steve, this is useful and interesting info. Just to clarify, my "side to side" analogy was intended to convey that some new tools did nothing to improve the Rails toolset -- some new tools moved app development sideways rather than forward. There have been plenty of "best thing since sliced bread" new ways to do things with Rails that have turned out to be just a distraction and which, in my view, were not an improvement over the "old way", and which have since faded away (apparently others agreed). Sadly, some of those "bright ideas" were adopted by the Rails team, so we''re stuck with those (like REST). Thanks for the info on HAML and Compass jp -- Posted via http://www.ruby-forum.com/.
Jeff Pritchard wrote: [...]> Thanks Steve, this is useful and interesting info.If you''d like another data point, I completely agree with Steve. Haml is wonderful, and Sass is to ny knowledge the *only* tool that makes it feasible to make CSS truly semantic and free of presentation classes. I can''t imagine doing without them again.> > Just to clarify, my "side to side" analogy was intended to convey that > some new tools did nothing to improve the Rails toolset -- some new > tools moved app development sideways rather than forward. There have > been plenty of "best thing since sliced bread" new ways to do things > with Rails that have turned out to be just a distraction and which, in > my view, were not an improvement over the "old way", and which have > since faded away (apparently others agreed).There''s always some of that in any evolving technology.> Sadly, some of those > "bright ideas" were adopted by the Rails team, so we''re stuck with those > (like REST).REST is a big step forward, so this is probably an inapt example...> > Thanks for the info on HAML and Compass > jpBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
Marnen Laibow-Koser wrote:> Jeff Pritchard wrote: > [...] >> Thanks Steve, this is useful and interesting info. > > If you''d like another data point, I completely agree with Steve. Haml is > wonderful, and Sass is to ny knowledge the *only* tool that makes it > feasible to make CSS truly semantic and free of presentation classes. I > can''t imagine doing without them again. > >> >> Just to clarify, my "side to side" analogy was intended to convey that >> some new tools did nothing to improve the Rails toolset -- some new >> tools moved app development sideways rather than forward. There have >> been plenty of "best thing since sliced bread" new ways to do things >> with Rails that have turned out to be just a distraction and which, in >> my view, were not an improvement over the "old way", and which have >> since faded away (apparently others agreed). > > There''s always some of that in any evolving technology. > >> Sadly, some of those >> "bright ideas" were adopted by the Rails team, so we''re stuck with those >> (like REST). > > REST is a big step forward, so this is probably an inapt example... > >> >> Thanks for the info on HAML and Compass >> jp > > Best, > -- > Marnen Laibow-Koser > http://www.marnen.org > marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.orgThanks Marnen. I''ve been studying HAML and SASS and Compass over the weekend, and I think I''m convinced. I''m going to do my next project with them and see how it goes.>> Sadly, some of those >> "bright ideas" were adopted by the Rails team, so we''re stuck with those >> (like REST). > > REST is a big step forward, so this is probably an inapt example...THE EMPEROR HAS NO CLOTHES! :) (I know there are plenty of otherwise intelligent people who like it, but in my opinion, REST is dumb if you''re not writing a web service - I see no advantage at all for a normal web application - and my feeble old brain refuses to be able to remember the darn path names - much easier to just use a hash of controller/action - and none of my clients is ever willing to allow a UI organization that is just straight-forward CRUD, always need custom actions, and the ''standard'' crud just winds up as dead code ) -- Posted via http://www.ruby-forum.com/.
When I came across HAML & SASS, there was no doubt in my mind that this is certainly much better and lesser time consuming that normal erb files.After having worked on the two for a good 2 months I again hold my belief, but recently I have been facing quite a lot of issues when I tried deploying my application to my web hosting, which was giving the error for any of rake operations saying !rake aborted invalid file -- haml [almost like this] Thanks & Regards, Dhruva Sagar. Samuel Goldwyn<http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html> - "I''m willing to admit that I may not always be right, but I am never wrong." On Tue, Sep 1, 2009 at 8:29 AM, Jeff Pritchard < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Marnen Laibow-Koser wrote: > > Jeff Pritchard wrote: > > [...] > >> Thanks Steve, this is useful and interesting info. > > > > If you''d like another data point, I completely agree with Steve. Haml is > > wonderful, and Sass is to ny knowledge the *only* tool that makes it > > feasible to make CSS truly semantic and free of presentation classes. I > > can''t imagine doing without them again. > > > >> > >> Just to clarify, my "side to side" analogy was intended to convey that > >> some new tools did nothing to improve the Rails toolset -- some new > >> tools moved app development sideways rather than forward. There have > >> been plenty of "best thing since sliced bread" new ways to do things > >> with Rails that have turned out to be just a distraction and which, in > >> my view, were not an improvement over the "old way", and which have > >> since faded away (apparently others agreed). > > > > There''s always some of that in any evolving technology. > > > >> Sadly, some of those > >> "bright ideas" were adopted by the Rails team, so we''re stuck with those > >> (like REST). > > > > REST is a big step forward, so this is probably an inapt example... > > > >> > >> Thanks for the info on HAML and Compass > >> jp > > > > Best, > > -- > > Marnen Laibow-Koser > > http://www.marnen.org > > marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > > > Thanks Marnen. I''ve been studying HAML and SASS and Compass over the > weekend, and I think I''m convinced. I''m going to do my next project > with them and see how it goes. > > >> Sadly, some of those > >> "bright ideas" were adopted by the Rails team, so we''re stuck with those > >> (like REST). > > > > REST is a big step forward, so this is probably an inapt example... > > THE EMPEROR HAS NO CLOTHES! :) > (I know there are plenty of otherwise intelligent people who like it, > but in my opinion, REST is dumb if you''re not writing a web service - I > see no advantage at all for a normal web application - and my feeble old > brain refuses to be able to remember the darn path names - much easier > to just use a hash of controller/action - and none of my clients is ever > willing to allow a UI organization that is just straight-forward CRUD, > always need custom actions, and the ''standard'' crud just winds up as > dead code ) > > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---