Bạn có nên học haml & sass không?

Question

Trải nghiệm chuyên môn của bạn có haml & sass tỏ ra hữu ích? Theo cách nào?

Answer 1

Haml là tốt đẹp, và tôi sử dụng nó rất nhiều, nhưng Sass là giá trị nó một mình, đặc biệt là nếu bạn phải xây dựng stylesheets phức tạp. Ví dụ, một trong những điều tồi tệ nhất về CSS là lượng dự phòng bạn phải làm khi đặt tên các bộ chọn. Trong CSS, bạn phải làm

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

Với Sass, bạn có thể dễ dàng lồng những phần tử này một cách tự nhiên.

#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 

Bạn cũng có thể sử dụng các biến

!border_color = #333 

.box 
    border = 1px "solid" !border_color 

Và bạn có thể sử dụng toán học với họ

!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 

Bạn cũng có thể chia sẻ mã

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

.box 
+rounded 

Có rất nhiều sức mạnh trong điều này mà bạn nợ nó cho chính mình để tìm hiểu nó. Thêm vào đó, kết quả cuối cùng là CSS đơn giản để nó có thể được chuyển đổi.

Đừng quên css2sass chuyển đổi tệp css hiện có của bạn thành tệp sass!

Bạn có thể chơi với một số ví dụ tại http://rendera.heroku.com/ nếu muốn. Đó là trang web tôi xây dựng để giúp mọi người tìm hiểu HTML5 và CSS3 và tôi có hỗ trợ cho cả HAML và SASS ở đó.

Ngoài ra, hãy xem StaticMatic (staticmatic.rubyforge.org) để có một cách tuyệt vời để làm trang web tĩnh hoạt động với HAML và SASS. Nó tạo ra các trang web mà bạn có thể tải lên các máy chủ tĩnh và có một hệ thống bố trí và mẫu tương tự như Ruby on Rails.

Để giải quyết câu hỏi trực tiếp bạn đã hỏi, bằng cách "đáng giá", câu trả lời là có. Có thể sử dụng các biến, dễ dàng nhóm mọi thứ bằng bộ chọn và chia sẻ mã thông qua các mô-đun làm cho các bảng định kiểu phức tạp dễ dàng hơn nhiều. Việc xây dựng các bản định kiểu không mất nhiều thời gian và bạn có thể sử dụng khung La bàn tuyệt vời để tiến xa hơn nữa. Ví dụ: bạn có thể sử dụng mô-đun 960.gs hoặc Blueprint để trộn các khung đó vào các bảng định kiểu hiện có của bạn. Bằng cách này, bạn không phải thay đổi mã đánh dấu của mình. Việc thêm 960.gs và các lớp "grid_12" và "container_12" vào tất cả các đánh dấu của bạn có thể không thực hiện được, nhưng với Compass và Sass thì thật dễ dàng.

Sass cũng làm cho nó dễ dàng hơn để có nhiều stylesheets cho chế độ phát triển và tạo ra một kiểu duy nhất cho sản xuất, do đó cải thiện hiệu suất client-side (ít cuộc gọi đến các máy chủ trên tải trang.)

HAML có những lợi ích riêng của mình , mặc dù chúng không đáng chú ý như Sass. HAML không làm cho việc lồng ghép các phần tử và khai báo DIVS dễ dàng đến mức vô cùng dễ dàng ... bằng cách sử dụng 960.gs thường xuyên, ví dụ dễ dàng với HAML:

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

Nhập ít hơn nhiều. Và nếu bạn quyết định bạn cần thêm một trình bao bọc xung quanh tất cả điều đó vì một lý do nào đó, chỉ cần thụt lề toàn bộ nội dung bên dưới một thẻ mới.

Hy vọng điều đó sẽ hữu ích. I < 3 Sass.

Answer 2

Trang web hiện tại của tôi có hơn 800 tệp Haml và 150 tệp Sass, và hãy để tôi cho bạn biết điều đó đã giúp tôi phát triển rất nhiều. Lợi ích lớn nhất là phát triển nhanh chóng: tạo các tệp Haml/Sass yêu cầu nhập ít hơn, vì vậy bạn có thể vẽ logic trình bày của mình với ít tổ hợp phím hơn so với khi bạn đang làm mẫu erb.

Tôi cũng tìm thấy tệp Haml dễ đọc hơn và ít bị lỗi hơn.

YMMV, nhưng tôi đã đạt đến điểm không sử dụng Haml giống như một việc vặt.

Answer 3

TL; DR - Trong khi phổ biến, tôi không muốn sử dụng HAML hoặc SASS, nhưng tôi thích SCSS.

Dường như sự đồng thuận chung về HAML là một cách áp đảo, nhưng cá nhân tôi không quan tâm đến nó.

Nếu ý định của tôi là tạo HTML, thì tôi thích ngôn ngữ mẫu càng gần HTML càng tốt. Điều này tránh phải tìm hiểu một lớp khác của indirection mà thêm cơ hội cho sự nhầm lẫn và lỗi cũng như phát sinh chi phí nhận thức.

Tôi tìm thấy những ràng buộc mà HAML đặt vào việc sử dụng khoảng trắng ưa thích của tôi để dễ đọc và gói dòng là hợp lý và thường dẫn đến cú pháp khó đọc.

Gần đây tôi gặp một lỗi tinh tế trong một mẫu HAML mà có thể đã được ngay lập tức rõ ràng nếu mẫu là ERB, ví dụ:

.table 
    .thead 
    .tr 
    .tr 

Các hàng bảng là không trong thẻ thead, đó là HAML hoàn toàn hợp lệ, nhưng không chính xác đối với cấu trúc HTML dự định. Trong khi trang xuất hiện để hiển thị chính xác, bộ chọn CSS không thành công, dẫn đến lỗi im lặng của một số mã Javascript.

Tôi chắc chắn loại lỗi này sẽ hiển nhiên đối với hầu hết người dùng HAML, như được minh họa trong sự cô lập, nhưng trong ngữ cảnh của mẫu lớn hơn, có thể khó phát hiện ra; đặc biệt là một nhà phát triển mới cho HAML.

Mặt khác, nếu điều này là ERB hoặc HTML:

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

Để mắt của tôi, lỗi trong cấu trúc là dễ dàng hơn nhiều để phát hiện do cách ERB và HTML là gần như luôn luôn thụt vào. Sau khi trải qua gần hai thập kỷ viết HTML, tôi phải thừa nhận rằng tôi có niềm tự hào nhất định trong việc viết HTML và tôi không thấy lý do gì để tìm hiểu một cách khác để đại diện cho nó và học tất cả các mẫu hình ảnh mới cần thiết lỗi.

Mặt khác, tôi rất giống SCSS (trái ngược với SASS) vì SCSS về bản chất là một siêu của CSS. Nó không thêm một lớp hoàn toàn mới mà tôi cần phải dịch. Nó chỉ thêm một sự thay đổi khiêm tốn trong cú pháp, cung cấp một biểu diễn ngắn gọn (và DRY) của CSS mà tôi thấy rất dễ đọc và dễ hiểu. Thực tế, tôi không thích sử dụng bất kỳ ngôn ngữ nào thực thi một cú pháp nghiêm ngặt về cách tôi nên thụt lề hoặc dòng bọc mã của tôi, chẳng hạn như python. Hoặc các ngôn ngữ chỉ phục vụ như một lớp không giới hạn ở trên cùng của ngôn ngữ cơ bản như coffeescript.

Tôi không nói rằng tôi tin rằng trừu tượng và vô hướng là xấu trong ngôn ngữ lập trình; chỉ rằng tôi không muốn sử dụng chúng đối với các ngôn ngữ cụ thể được thảo luận ở đây.