Hacker News new | past | comments | ask | show | jobs | submit login

This reminds me of HAML. I've never really seen the benefit of adding a layer that doesn't really add much onto something that is well-known and thus easily maintainable.

Performance benefits seem mostly irrelevant, as pointed out by others.




I didn't see the point of HAML - until I used it. I'm a complete convert now: the syntax is just so superior to being productive in markup for me. In my current app I'm including a small ember app, having to write straight markup for handlebars (hamlbars is a bit awkward) is painful compared to how quickly you can produce markup with HAML.

Personal preference of course, but to me the difference is night and day in terms of my productivity with producing markup.


I guess the thing for me is that my HTML is usually simple enough that there isn't significant time spent writing it.

So I can see there could be productivity gains, but I don't see they would be sufficient to justify the technical debt in introducing a new syntax.


I seriously think you're overstating the technical debt incurred by HAML. The docs aren't the best - they cover stuff, but are hard to navigate sometimes - but the actual language has a very shallow learning curve in my experience picking it up myself and bringing front-enders up to speed with it when I work with them on projects.


Oh, sure, learning it is pretty trivial if you know CSS. But there are a lot of hidden things, like cutting + pasting snippets of code from the Text Editor to/from the browser/jsfiddle/wherever, providing code samples on Stack Overflow, etc etc etc etc.

I think they made the right call when they went SASS -> SCSS for these kind of reasons. I know that coverting CSS blocks into the equivalent SASS was one of my least favourite things :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: