Стоит ли изучать haml & sass? - PullRequest
Новая
       14

Стоит ли изучать haml & sass?

27 голосов
/ 16 января 2010

В вашем профессиональном опыте оказались хамл & sass полезными? Каким образом?

Ответы [ 3 ]

43 голосов
/ 16 января 2010

Haml - это хорошо, и я часто его использую, но Sass стоит того в одиночку, особенно если вам приходится создавать сложные таблицы стилей. Например, одна из худших вещей в CSS - это то, сколько избыточности вам приходится делать при именовании селекторов. В CSS вы должны сделать 

#navbar ul 
#navbar ul li a
#navbar ul li a:hover

С Sass вы можете просто вкладывать этих потомков естественным образом. 

#navbar

  ul
    margin: 0
    padding: 0
    list-style: none
    width: 100%

    li
      margin: 0
      float: left
      margin-right: 10px
      border: 1px solid #000

      a
        text-decoration: none

        &:hover
          color: red

Вы также можете использовать переменные 

!border_color = #333

.box
  border = 1px "solid" !border_color

И вы можете использовать математику с ними 

!measure = 18px
!text_size = !measure / 1.5

body
  font-size = !text_size
  line-height = !measure

h1
  font-size = !measure
  margin-bottom = !measure

h2
  font-size = !measure + 2

#wrapper
  width = !measure * 50

Вы также можете поделиться кодом 

=rounded
  -moz-border-radius: 4px
  -webkit-border-radius: 4px
  border-radius: 4px
  border: 1px solid #000

.box
 +rounded

В этом так много силы, что вы обязаны научиться этому. Кроме того, конечный результат - простой CSS, поэтому его можно конвертировать.

Не забудьте о css2sass, который конвертирует ваши существующие css в файлы sass!

Вы можете поиграть с некоторыми примерами на http://rendera.heroku.com/, если хотите. Это сайт, который я создал, чтобы помочь людям изучать HTML5 и CSS3, и у меня там есть поддержка как HAML, так и SASS.

Кроме того, взгляните на StaticMatic (staticmatic.rubyforge.org), чтобы узнать, как работает статический веб-сайт с HAML и SASS. Он генерирует веб-сайты, которые можно загружать на статические хосты, и имеет систему макетов и шаблонов, аналогичную Ruby on Rails.

Чтобы ответить на прямой вопрос, который вы задали, посредством «стоит ли это того», ответ - да. Возможность использовать переменные, легко группировать объекты по селектору и делиться кодом через модули значительно упрощает сложные таблицы стилей. Создание таблиц стилей совсем не занимает много времени, и вы можете использовать превосходную среду Compass, чтобы пойти еще дальше. Например, вы можете использовать модули 960.gs или Blueprint, чтобы смешать эти фреймворки с вашими существующими таблицами стилей. Таким образом, вам не нужно менять разметку вашего кода. Добавление 960.gs и его классов grid_12 и container_12 ко всей разметке может оказаться невозможным, но с Compass и Sass это просто.

Sass также упрощает создание нескольких таблиц стилей для режима разработки и создание одной таблицы стилей для производства, что повышает производительность на стороне клиента (меньше обращений к серверу при загрузке страницы.)

У HAML есть свои преимущества, хотя они не так заметны, как у Sass. HAML позволяет невероятно легко вкладывать элементы и объявлять DIVS ... с использованием даже обычного 960.gs, например, легко с HAML: 

#header.container_12
  .grid_12
     %h1 Welcome!
#middle.container_12
  .grid_8
     %h2 Main content
  .grid_4
     %h3 Sidebar

Гораздо меньше печатать. И если вы решите, что по какой-то причине вам необходимо добавить обертку вокруг всего этого, просто добавьте отступ под новым тегом.

Надеюсь, это поможет. Я <3 Sass. </p>

9 голосов
/ 16 января 2010

Мой текущий веб-сайт содержит более 800 файлов Haml и 150 файлов Sass, и позвольте мне сказать вам, что это очень помогло моей разработке.

Самым большим преимуществом является быстрое развитие: создание файлов Haml / Sass требует гораздо меньшего набора текста, поэтому вы можете придать логике представления гораздо меньше нажатий клавиш, чем при использовании шаблона erb.

Я также считаю, что файлы Haml гораздо проще для чтения и менее подвержены ошибкам.

YMMV, но я дошел до того, что без использования Haml похоже на рутину.

5 голосов
/ 09 июня 2013

TL; DR - хотя и популярен, я предпочитаю не использовать HAML или SASS, но мне нравится SCSS.

Похоже, что общий консенсус по HAML в подавляющем большинстве в пользу этого, но лично мне все равно.

Если я собираюсь генерировать HTML, я предпочитаю, чтобы язык шаблонов был как можно ближе к HTML. Это избавляет от необходимости изучать другой уровень косвенности, который добавляет возможность путаницы и ошибок, а также приводит к когнитивным накладным расходам.

Я считаю, что ограничения, которые HAML накладывает на мое предпочтительное использование пробелов для удобства чтения и переноса строк, являются обременительными и часто приводят к синтаксису, который может быть трудным для чтения.

Недавно я столкнулся с тонкой ошибкой в ​​шаблоне HAML, которая была бы сразу очевидна, если бы этот шаблон был ERB, например: 

 .table
   .thead
   .tr
   .tr

Строки таблицы не внутри тега THEAD, что является совершенно допустимым HAML, но неверно по отношению к предполагаемой структуре HTML. Несмотря на то, что страница отображалась правильно, селектор CSS не работал, что привело к молчаливому сбою некоторого кода Javascript.

Я уверен, что такого рода ошибки будут очевидны для большинства пользователей HAML, как показано отдельно, но в контексте более крупного шаблона это может быть трудно обнаружить; особенно для разработчика, плохо знакомого с HAML.

С другой стороны, если это был ERB или HTML: 

 <table>
   <thead>
   <tr>...</tr>
   <tr>...</tr>

На мой взгляд, ошибку в структуре гораздо легче обнаружить благодаря тому, что ERB и HTML почти всегда имеют отступы.

Потратив почти два десятилетия на написание HTML, я должен признать, что у меня есть определенная гордость за написание хорошо сформированного HTML, и я не вижу причин изучать другой способ его представления и изучать все новые визуальные шаблоны, необходимые для выявления ошибок .

С другой стороны, мне очень нравится SCSS (в отличие от SASS), потому что SCSS по сути является надмножеством CSS. Это не добавляет совершенно новый слой косвенности, который мне нужно мысленно перевести. Он добавляет только скромное изменение в синтаксисе, которое обеспечивает более краткое (и СУХОЕ) представление CSS, которое я считаю очень простым для чтения и понимания.

Действительно, я предпочитаю не использовать ни один язык, который обеспечивает строгий синтаксис относительно того, как я должен отступать или переносить строки в моем коде, например, на python. Или языки, которые служат только косвенным слоем поверх основного языка, такого как coffeescript.

Я не говорю, что считаю абстракцию и косвенность плохими в языках программирования; только то, что я предпочитаю не использовать их в отношении конкретных языков, обсуждаемых здесь.

...