Haml & Sass를 배우는 것이 가치가 있습니까?

StackOverflow https://stackoverflow.com/questions/2075621

  •  21-09-2019
  •  | 
  •  

문제

당신의 전문적인 경험에서 햄 & 사스 유용한 것으로 판명 되었습니까? 어떤 식으로?

도움이 되었습니까?

해결책

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이므로 변환 할 수 있습니다.

기존 CSS를 SASS 파일로 변환하는 CSS2SASS를 잊지 마십시오!

몇 가지 예제를 가지고 놀 수 있습니다 http://rendera.heroku.com/ 원한다면. 사람들이 HTML5와 CSS3을 배우도록 돕기 위해 제작 한 사이트이며 Haml과 Sass를 모두 지원합니다.

또한 Haml 및 Sass와 정적 웹 사이트 작업을 수행 할 수있는 놀라운 방법을 찾으려면 STATICMATIC (staticMatic.rubyforge.org)를 살펴보십시오. 정적 호스트에 업로드 할 수있는 웹 사이트를 생성하고 Ruby on Rails와 유사한 레이아웃 및 템플릿 시스템이 있습니다.

"가치가있는 것"을 통해 당신이 요청한 직접적인 질문을 해결하기 위해, 대답은 예입니다. 변수를 사용하고, 선택기별로 물건을 쉽게 그룹화하고, 모듈을 통해 코드를 공유 할 수있게되면 복잡한 스타일 시트가 훨씬 쉬워집니다. 스타일 시트를 구축해도 오래 걸리지 않으며 훌륭한 나침반 프레임 워크를 사용하여 더 나아갈 수 있습니다. 예를 들어, 960.GS 또는 BluePrint 모듈을 사용하여 해당 프레임 워크를 기존 스타일 시트에 혼합 할 수 있습니다. 이렇게하면 코드의 마크 업을 변경할 필요가 없습니다. 960.gs와 그 "grid_12"및 "container_12"클래스를 모든 마크 업에 추가 할 수는 없지만 나침반과 Sass는 산들 바람입니다.

SASS는 또한 개발 모드를위한 여러 스타일 시트를 쉽게 갖추고 생산을위한 단일 스타일 시트를 생성하여 클라이언트 측 성능을 향상시킬 수 있습니다 (페이지로드에서 서버에 대한 통화가 줄어 듭니다).

Haml은 Sass만큼 눈에 띄지 않지만 자체 혜택을받습니다. Haml은 요소를 둥지에 쉽게 둥지로 만들고 div를 선언합니다.

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

훨씬 적은 타이핑. 그리고 어떤 이유로 든 그 주위에 래퍼를 추가해야한다고 결정했다면 새 태그 아래에 모든 것을 들여 보내십시오.

도움이되기를 바랍니다. 나는 <3 sass.

다른 팁

내 현재 웹 사이트에는 800 개가 넘는 HAML 파일과 150 개의 SASS 파일이 있으며, 내 개발이 엄청나게 도움이되었다고 말씀 드리겠습니다.

가장 큰 혜택은 빠른 개발 측면에서 다음과 같습니다. Haml/Sass 파일을 만드는 데 타이핑이 훨씬 적으므로 ERB 템플릿을 수행하는 것보다 훨씬 적은 키 스트로크로 프레젠테이션 논리를 못 박 릴 수 있습니다.

또한 Haml 파일을 읽기가 훨씬 쉽고 오류가 적습니다.

YMMV, 그러나 나는 Haml을 사용하지 않는 것이 집안일처럼 느껴진다는 점에 도달했습니다.

TL; DR- 인기가 있지만 Haml 또는 Sass를 사용하는 것을 선호하지만 SCS를 좋아합니다.

Haml에 대한 일반적인 합의는 압도적으로 유리한 것으로 보이지만 개인적으로 나는 그것을 신경 쓰지 않습니다.

내 의도가 HTML을 생성하려는 경우 템플릿 언어가 가능한 한 가까운 HTML을 선호합니다. 이것은 또 다른 간접 계층을 배우지 않아도되는 지식과 오류가 발생할 수있는 기회를 더할 수있을뿐만 아니라인지 오버 헤드를 발생시킵니다.

나는 Haml이 가독성과 선 포장을 위해 선호하는 공백을 사용하는 것이 번거롭고 종종 읽기 어려운 구문을 초래하는 제약을 발견합니다.

최근에 HAML 템플릿에서 미묘한 오류가 발생했는데 예를 들어 템플릿이 ERB 인 경우 즉시 분명 할 것입니다.

 .table
   .thead
   .tr
   .tr

테이블 행입니다 ~ 아니다 완벽하게 유효한 haml이지만 의도 된 HTML 구조와 관련하여 잘못된 태그 태그 내에서. 페이지가 올바르게 렌더링되는 것처럼 보이지만 CSS 선택기가 실패하여 일부 JavaScript 코드가 조용히 실패했습니다.

나는 이런 종류의 오류가 대부분의 Haml 사용자에게 분명 할 것이라고 확신하지만, 더 큰 템플릿의 맥락에서는 발견하기 어려울 수 있습니다. 특히 Haml을 처음 접하는 개발자에게.

반면에, 이것이 ERB 또는 HTML이라면 :

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

내 눈에는 ERB와 HTML이 거의 항상 들여 쓰기로 인해 구조의 오류가 훨씬 쉽게 발견되기가 훨씬 쉽습니다.

거의 20 년 동안 HTML을 쓰는 데 많은 시간을 보낸 후, 나는 잘 형성된 HTML을 쓰는 데 자부심이 있다는 것을 인정해야하며, 그것을 대표하는 다른 방법을 배우고 오류를 발견하는 데 필요한 모든 새로운 시각적 패턴을 배울 이유가 없습니다.

반면에, 나는 SCSS가 본질적으로 CSS의 슈퍼 세트이기 때문에 SCSS (SASS와 반대로)와 매우 흡사합니다. 정신적으로 번역 해야하는 완전히 새로운 간접 계층을 추가하지는 않습니다. 그것은 구문의 약간의 변화 만 추가하여 읽고 이해하기가 매우 쉬운 CSS의보다 간결하고 건조한 표현을 제공합니다.

실제로, 나는 파이썬과 같은 내 코드를 랩핑하는 방법에 관한 엄격한 구문을 시행하는 언어에 사용하지 않는 것을 선호합니다. 또는 CoffeeScript와 같은 기본 언어 위에 간접 계층으로만 사용되는 언어.

나는 프로그래밍 언어에서 추상화와 간접이 나쁘다고 믿는다 고 말하는 것은 아닙니다. 여기서 논의 된 특정 언어와 관련하여 사용하지 않는 것을 선호합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top