Czy warto uczyć się haml & sass?

Question

W swoim doświadczeniu zawodowym okazało się, że przydaje się sass sass? W którą stronę?

Answer 1

Haml jest fajny, a ja go często używam, ale Sass jest tego wart sam, zwłaszcza jeśli trzeba zbudować skomplikowane arkusze stylów. Na przykład jedną z najgorszych rzeczy dotyczących CSS jest to, ile redundancji musisz zrobić, gdy nazywane są selektory. W CSS, musisz zrobić

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

Z Sass, możesz po prostu zagnieździć w naturalny sposób te spadki.

#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 

Można również używać zmiennych

!border_color = #333 

.box 
    border = 1px "solid" !border_color 

i można korzystać z matematyki z nich

!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 

Można także udostępniać kod

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

.box 
+rounded 

Jest tak dużo energii w to, że jesteś to winien sobie aby się tego nauczyć. Dodatkowo końcowy wynik to zwykły CSS, aby można go było przekonwertować.

Nie zapomnij o css2sass, który konwertuje istniejące pliki css do sass!

Możesz grać z kilkoma przykładami pod numerem http://rendera.heroku.com/, jeśli chcesz. Jest to strona, którą zbudowałem, aby pomóc ludziom uczyć się HTML5 i CSS3 i mam wsparcie dla HAML i SASS.

Zobacz także StaticMatic (staticmatic.rubyforge.org), aby przekonać się, jak działa statyczna strona internetowa z HAML i SASS. Generuje strony internetowe, które można przesłać do hostów statycznych, a także ma układ i system szablonów podobny do Ruby on Rails.

Aby odpowiedzieć na bezpośrednie pytanie, które zadałeś, jako "czy warto", odpowiedź brzmi "tak". Możliwość korzystania ze zmiennych, łatwego grupowania elementów za pomocą selektora i udostępniania kodu za pomocą modułów znacznie upraszcza złożone arkusze stylów. Budowanie arkuszy stylów nie trwa długo i możesz użyć doskonałej struktury Compass, aby pójść jeszcze dalej. Na przykład można użyć modułów 960.gs lub Blueprint, aby wymieszać te struktury z istniejącymi arkuszami stylów. W ten sposób nie musisz zmieniać znaczników swojego kodu. Dodanie 960.gs i jego klas "grid_12" i "container_12" do wszystkich znaczników może nie być możliwe, ale w przypadku Compass i Sass jest to proste.

Sass ułatwia również mieć wiele stylów dla trybu rozwoju i generuje pojedynczy arkusz stylów dla produkcji, poprawiając w ten sposób wydajność po stronie klienta (mniej połączeń do serwera na stronie obciążenia).

haml ma swoje zalety , chociaż nie są tak zauważalne, jak Sass. Haml robi to niezwykle łatwe do elementów gniazdowych i deklarują div ... używając nawet regularne 960.gs na przykład jest prosta haml:

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

znacznie mniej pisać. A jeśli z jakiegoś powodu zdecydujesz, że chcesz dodać opakowanie, po prostu umieść wcięcie w całość pod nowym znacznikiem.

Nadzieję, że pomaga. I < 3 Sass.

Answer 2

Moja obecna strona ma ponad 800 plików Haml i 150 plików Sass, i powiem wam, że bardzo pomógł mi w rozwoju.

Największym dobrodziejstwem jest szybki rozwój: tworzenie plików Haml/Sass wymaga znacznie mniejszej pisowni, dzięki czemu można znacznie poprawić układ logiczny prezentacji za pomocą mniejszej liczby naciśnięć klawiszy niż w przypadku szablonu erb.

Uważam również, że pliki Haml są znacznie łatwiejsze w czytaniu i mniej podatne na błędy.

YMMV, ale doszedłem do tego stopnia, że ​​nie używanie Haml jest jak uciążliwe.

Answer 3

TL; DR - Chociaż popularny, wolę nie używać HAML lub SASS, ale lubię SCSS.

Wygląda na to, że ogólny konsensus w sprawie HAML jest w przeważającej mierze na jego korzyść, ale osobiście nie dbam o to.

Jeśli moim zamiarem jest generowanie HTML, wolę, aby język szablonu był jak najbliżej HTML. Dzięki temu nie trzeba uczyć się kolejnej warstwy pośredniej, która zwiększa ryzyko pomyłek i błędów, a także zwiększa obciążenie poznawcze.

Znajduję ograniczenia, które HAML umieszcza na moim preferowanym użyciu białych znaków, aby czytelność i zawijanie wierszy były uciążliwe i często skutkują składnią, która może być trudna do odczytania.

Ostatnio natknąłem się na subtelny błąd w szablonie haml który byłby od razu oczywiste, jeśli szablon były ERB, na przykład:

.table 
    .thead 
    .tr 
    .tr 

Wiersze tabeli są nie w tagu THEAD, która jest doskonale działający HAML, ale niepoprawny w stosunku do zamierzonej struktury HTML. Wygląda na to, że strona prawidłowo renderowała się, ale selektor CSS nie powiódł się, co spowodowało cichą awarię niektórych kodu JavaScript.

Jestem pewien, że ten rodzaj błędu byłby oczywisty dla większości użytkowników HAML, jak pokazano w izolacji, ale w kontekście większego szablonu może być trudny do wykrycia; zwłaszcza dla programisty nowego w HAML.

Z drugiej strony, gdyby to było ERB lub HTML:

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

Do mojego oka, błąd w strukturze jest o wiele łatwiejsze do wykrycia ze względu na sposób ERB i HTML są prawie zawsze wcięte.

Po prawie dwóch dekadach pisania HTML, muszę przyznać, że mam pewną dumę z pisania dobrze uformowanego HTML i nie widzę powodu, aby nauczyć się innego sposobu reprezentowania go i poznania wszystkich nowych wzorów wizualnych potrzebnych do wykrycia błędy.

Z drugiej strony bardzo podoba mi się SCSS (w przeciwieństwie do SASS), ponieważ SCSS jest w istocie nadzbiorem CSS. Nie dodaje zupełnie nowej warstwy pośredniej, którą muszę przetłumaczyć mentalnie. Dodaje tylko skromną zmianę składni, która zapewnia bardziej zwięzłą (i DRY) reprezentację CSS, którą uważam za łatwą do odczytania i zrozumienia.

Rzeczywiście, wolę nie używać do żadnego języka, który wymusza ścisłą składnię dotyczącą tego, w jaki sposób powinienem wcięcie lub zawinięcie linii mój kod, taki jak python. Lub języki, które służą tylko jako warstwa pośrednia na bazie języka bazowego, takiego jak coffeescript.

Nie mówię, że uważam, że abstrakcja i pośredniość są złe w językach programowania; tylko że wolę nie używać ich w odniesieniu do konkretnych języków omawianych tutaj.