Rails每周一题(十九): HAML和Sass

 

  在新项目里使用了Haml -- Html Abstraction Markup Language.

 

  较之于Html,个人感觉Haml有这样几个优点:

 

  1. 对于人来讲,Haml更加规范,更加优美. Html对空格,换行等字符的不敏感对于浏览器来说是好事,但对于人来说并不一定是好事.因为这会放任写代码的人忽略代码的规范,忽略代码的结构,忽略代码的优美.而Haml严谨的格式要求,让代码更加规范,优美. 代码不仅要让机器读懂,更要让人易读.

 

  2. DRY. 这是对Rails DRY原则一个很好的传承. 消除重复,那么也该消除ERB中的重复. Haml依赖于缩进来定义层级关系,消除了Html,ERB中大量的重复:开启tag和关闭tag.

 

  3. Not only markup -- Haml不再仅仅是标记语言. Haml不再是纯粹的标记语言,它可配置,它可以添加注释(不会出现在html中的注释),它可以.... 程序员对之的控制更加方便和强大.

 

  4. 与JavaScript的隔离. Haml的良好结构化,优美和简洁使你不忍心在haml文件上写javascript代码,虽然这是允许的. 它促使你利用事件驱动来更好地隔离标记代码和javascript代码.

 

  任何事情都有两面,Haml具有上面这些好处,但它采用的缩进结构确实使代码的编写和维护更加繁琐,更需要小心.但这种代价明显是值得的.

 

  最后,推荐一下它的孪生兄弟: Sass . 这家伙,带着一个交互shell,甚至可以定义变量...

 

一直在使用haml，视层间代码也可以很简洁了
Rails对haml的支持也是很完善，erb后缀相当于换成haml就可以了

如果你没使用过，haml学习成本并没有想像中的高
只要多看看这个官方说明，边写边学，半天就可以熟悉了

http://haml-lang.com/docs/yardoc/HAML_REFERENCE.md.html

Sass 不是家伙, 他们是孪生兄妹的关系.
与 Rails 的集成度也不错, 改下设置可以把 .sass 文件放在 app/styles 里, 访问 .css 的时候会自动解析 .sass 编译后放在 public/stylesheets 下面, 保持原有的目录结构, 改动后立即生成, 而且支持缓存.
不过前端不能把 CSS 当成静态文件来过滤了, 因为 Rails 要是接收不到请求, Sass 也没法判断是否需要编译.

haml 很简洁,但对于缩进,一不留神就会出错.

另外,如果有现成的html,可以很方便的转成haml,命令是html2haml 源文件名 [目标文件名].

想ERB转成haml的话,可以先转为html,再转haml.

一直觉得靠缩进开进行逻辑的东西不靠谱，一个地方不小心乱了咋办

这句话跟 "一直觉得靠程序这种严谨的东西不靠谱,一个地方不小心写错了咋办" 具有异曲同工之妙

这东西会不会很容易引起性能问题？
相比erb这东西的性能是怎么样的？

看这里http://nex-3.com/posts/87-haml-benchmark-numbers-for-2-2

所以我觉得lesscss反而好一些