Haml i Sass, czyli tragedia w dwóch aktach.

1

Warning! contains Haml!

Przytoczona obok sentencja Einsteina najlepiej przedstawia moje podejście do tych dwóch wynalazków. Są to kolejne rzeczy, które delikatnie mówiąc, nie przypadły mi do gustu. Rzeczy powinny być tak proste, jak to tylko możliwe - ale gdy próbujemy je uczynić jeszcze prostszymi to otrzymujemy (profesorze, przepraszam!) gówno, jakim jest standard haml.

Nie dość, że w moim przypadku wygenerowany narzędziem html2haml kod HAML strony stworzonej wcześniej (link do index.haml) jest autentycznie większy o 112 bajtów od kodu HTML, to jeszcze ma szereg innych wad.

Piękno haml jest wg mnie dalece przesadzone. Wg mnie haml jest zwyczajnie brzydki. Standard XML, w jakim obecnie zapisuje się HTML (tworząc XHTML) jest uniwersalny, logiczny i doskonale czytelny. Zaczynanie prawie każdej linii od "dziwnego" znaku procentu lub kropki w HAML nie jest moim rozumieniem pięknie napisanego kodu. Dodatkowo przenoszenie atrybutów tudzież klas css do nowej linii sprawia jedynie wrażenie braku logiki - tak, jakby były to oddzielne polecenia. Natomiast nieużywanie tagów sprawia wizualne wrażenie, że można pomylić własny text z fragmentem kodu.

html:

<p class="notice">The menu is in another castle!</p>

haml:

        %p.notice
          The menu is in another castle!

Haml nie jest uniwersalny. Przenosząc stronę na inny serwer z dużym prawdopodobieństwem okaże się, że nic nam po plikach haml, gdyż zwyczajnie na serwerze nie ma żadnego generatora.
Haml jest sztucznym tworem, bo i tak musi być tłumaczony na HTML. Każda najmniejsza modyfikacja strony wymaga jej tłumaczenia (co może się wiązać z chociażby tak upierdliwą czynnością jak łączenie się przez ssh z serwerem i manualnie wpisywanie polecenia konwertującego), podczas gdy przy edytowaniu XHTML/PHP/CSS zmiany są natychmiastowe.
Przy XHTML zapomnienie przez webmastera wcięcia czy spacji to nic specjalnego. Wręcz DOBRZE, że czasem krótki kod lepiej jest zapisać w jednej linii, a czasem lepiej go dla czytelności uporządkować. Haml za to wybitnie stawia na dokładnie odliczoną ilość spacji, co jest niepotrzebnym zmuszaniem użytkownika do restrykcji.
Jak już mówiłem - konwersja na Haml wcale nie musi oznaczać oszczędności w pisaniu znaków kodu. W moim przypadku jest wręcz odwrotnie. plik index.html ma 3331 bajtów, plik index.haml - 3543 bajtów, a jestem pewien, że tą różnicę możnaby jeszcze powiększyć usuwając z mojego htmla niepotrzebne puste linie i nadmiarowe spacje. Dodatkowo wygenerowany z hamla index2.html waży 4038 bajtów, a więc rozmiar mojego pierwotnego pliku zwiększył się o 21%.
I na koniec szczyt wszystkiego: wygenerowany w index2.html kod jest
NIEPOPRAWNY
. Owszem, waliduje się na W3, ale w przypadku jednego z linków tag </a> przewędrował na sam koniec paragrafu, co sprawiło, że pół paragrafu jest jednym, wielkim linkiem. Haml może w ten prosty sposób zupełnie rozwalić stronę. Wypomnę jeszcze, ze najwyraźniej do każdego linka konwerter dodał sobie spację -_-

Nie potrafię znaleźć zalet Haml'a. O ile los pozwoli, nie będę więcej dotykał tego paskudztwa. Wracajac do sentencji Einsteina z początku: Haml jest własnie takim przykładem, kiedy z czegoś dobrego i prostego starano się zrobić coś jeszcze lepszego i prostszego. A spieprzono dokumentnie całość.

2

Akt drugi - SASS. Tu jest odrobinę lepiej, ale wciąż dalekie jest to od "ulepszenia" CSS.

W pierwszej chwili już myślałem, że konwersja css2sass daje faktycznie oszczędność kodu. Ale już wkrótce się okazało, że ta oszczędność jest pozorna. A to dlatego, że konwerter ten usuwa komentarze z pliku - w oryginalnym css blueprinta było ich trochę, więc nic dziwnego, że plik wynikowy cass był mniejszy. Jednakże po manualnym usunięciu komentarzy statystyki są następujące:

screen.css	1602 B
screen.Sass	1837 B
screen2.css	2006 B

Mamy więc wybitnie tendencję wzrostową. Wygenerowany za pomocą Sass wtórny kod css jest większy od pierwotnego o 25%, a pisanie samego kodu w cass pomimo uproszczonej składni zawiera o 15% więcej znaków, z czego prawie wszystkie 'nadmiarowe' znaki to oczywiście spacje i znaki końca linii.

Dobrze, że przynajmniej strona po wtórnym wygenerowaniu css tym razem wygląda tak samo.

Sass to kolejny wynalazek, który zmusza użytkownika do maniakalnego wciskania 'enter' po każdym słowie i dbania o wszelkiego rodzaju spacje i wcięcia. Trzeba przyznać, że składnia jest przyjemniejsza dla oka - pozbawiona nawiasów klamrowych i średników.

css:

h1 {font-size:3em;line-height:1;margin-bottom:0.5em;}

sass:

h1
  font-size: 3em
  line-height: 1
  margin-bottom: 0.5em

Aczkolwiek osobiście chyba jednak wolę wcisnąć średnik niż enter i dwie spacje - nawet kosztem czytelności. Przypomnijmy jeszcze, że Sass, podobnie jak Haml wymaga generatora docelowego języka.

Więc może tym razem cel został osiągnięty, zakładając, że celem było "upiększenie" składni css. Ale jest to dalekie od stwierdzenia wyższości Sass nad css.

Haml i Sass, czyli tragedia w dwóch aktach.

1

NIEPOPRAWNY

2