Po ogromnym zawodzie, jakim okazał się dla mnie Javascript, mniej więcej dwa tygodnie temu wpadłem na pomysł, żeby nauczyć się wreszcie jakiegoś “prawilnego” języka, czyli takiego ze statycznym typowaniem, który jednocześnie kompilował się bezpośrednio do kodu maszynowego. W efekcie tego ostatniego założenia w przedbiegach odpadł pierwszy kandydat, który od jakiegoś czasu chodził mi po głowie, czyli Java. Dlatego po krótkich poszukiwań ostatecznie zdecydowałem się na Golang ze względu na wciąż relatywnie niedużą jego popularność, ale nade wszystko mając na uwadze podnoszoną w Internetach zaletę w postaci błyskawicznego kompilowania, która sprawia, że do pewnego stopnia da się z nim pracować jak z językami interpretowanymi. Dodatkowo dość popularna jest opinia, że to język relatywnie prosty w opanowaniu podstaw (choć głównie mówią to osoby z trochę innym backgroundem niż mój własny), co tylko wzmogło moje zainteresowanie, zaś już przysłowiową wisienką na torcie okazał się fakt, że kompilator ma wbudowany mechanizm odśmiecania pamięci (garbage collection).
Jednakże dzisiejszy tekst poświęcony jest innemu zagadnieniu, tym niemniej wspominam o Golangu, ponieważ to właśnie z jego powodu zainteresowałem się bohaterem tego wpisu, czyli Hugo. Otóż wykoncypowałem sobie, że tym razem podejdę inaczej do kwestii nauki kodowania w nowo poznawanym języku, czyli kompetencje będę budował przy okazji mierzenia się z jakimś praktycznym projektem. Dlatego od razu zajrzałem na Githuba, by sprawdzić, co się cieszy największą popularnością społeczność wokół tego języka skupionej. Dwa pierwsze miejsca pod względem liczby gwiazdek zajmowały projekty dotyczące konteneryzacji, czyli czegoś niespecjalnie znajdujące się w orbicie moich zainteresowań. Na szczęście na ostatnim miejscu podium znajdowało się właśnie Hugo z liczbą prawie 53 tysięcy gwiazdek. Zaiste wynik imponujący, więc wybór wydawał się oczywisty, bo jakoś też dobrze się komponuje z tym, o czym od pół roku piszę.
Niestety dość szybko okazało się, że choć Hugo został napisany w Go, to korzystanie z niego – przynajmniej na podstawowym poziomie – nie wymaga znajomości tego języka nawet w najmniejszym stopniu. Tym niemniej to co przy tej okazji udało mi się przeczytać, na tyle mnie zainteresowało, że postanowiłem się zająć się tym najszybszym frameworkiem – jak reklamują go autorzy projektu – do budowania stron.
Generatory stron statycznych: a na co to?
To nie tak, że jak dotąd zupełnie nic nie słyszałem o generatorach stron statycznych (dalej SSG od Static Site Generator). Ot chociażby w przypadku Nuxta, o którym wspominałem w jednym z pierwszych tekstów na tym blogu, w momencie konfigurowania projektu jest opcja wyboru pracy właśnie w tym trybie. Dodatkowo coś mi tam się o uszy obiło (czy raczej oczy) w tekstach, gdzie jeden czy drugi autor wspominał chociażby o Gatsby czy Pelicanie (chyba najpopularniejszy SSG dla Pythona). Tym niemniej nigdy specjalnie tym zagadnieniem się nie interesowałem i dlatego też zupełnie nie rozumiałem idei tego rodzaju generatorów, bo przecież można klepać te strony bezpośrednio w HTML-u oraz CSS i przy mniejszym lub większym udziale Javascripts. Czemu więc miałoby służyć tego typu narzędzie? To pytanie pozostawało długo bez odpowiedzi, ponieważ tak naprawdę kwestia ta specjalnie mnie zajmowała, bo wiadomo: jak tworzenie stron to wyłącznie przy pomocy CMS. Okazuje, że czasami warto mieć nieco bardziej otwarty umysł, dlatego w tej części wpisu chciałbym się pochylić (nieprzesadnie nisko) nad tą kwestią, bo może nie jestem odosobniony w swoim niedoinformowaniu.
O co więc chodzi z tymi statycznymi stronami? Można powiedzieć, że są to takie strony, których zawartość jest – jak sama nazwa wskazuje – względnie niezmienna. Oczywiście nie oznacza to braku jakiejkolwiek interaktywności albo całkowitej identyczności wrażeń wizualnych dla osób odwiedzających daną witrynę, choć to ostatnie zazwyczaj jednak idzie w parze z omawianą “statycznością”. Bardziej tutaj chodzi o to, że w przypadku tego typu rozwiązań każdy identyczny request przekazany do serwera spowoduje zwrócenie dokładnie tego samego kodu do klienta webowego.
W kontrze do tego rozwiązania dynamiczne generowane strony działają jak normalne aplikacje, gdzie obok kodu przygotowanego dla klienta webowego (frontend) mamy do czynienia z mniej lub bardziej rozbudowaną warstwę po stronie serwera (backend), na którym najczęściej posadowiona jest jakaś baza danych wykorzystywana do każdorazowego wygenerowania pliku html, który na końcu trafia do przeglądarki. Oczywiście to drugie podejście nie pozostaje bez wpływu na responsywność naszej witryny oraz raczej nie zwiększa jej bezpieczeństwa (zwłaszcza jeśli używamy popularnych CMS-ów i jednocześnie nie dbamy należycie o ich aktualizację).
Oczywiście dostępne są przeróżne mechanizmy, które próbują rozwiązać chociażby problem niższej responsywności witryn opartych na CMS-ach, czyli na ten przykład wykorzystywanie jest cache’owanie wcześniej wygenerowanych stron, tak by za każdym razem nie budować ich od nowa, jeśli efekt końcowy ma być identyczny. Tym niemniej ze zwiększonym zapotrzebowaniem na zasoby, które są potrzebne dla utrzymania bazy danych czy samego CMS-a niewiele da się już zrobić.
Tym niemniej to nie jest tak, że tworzenie stron w “tradycyjny” sposób to samo dobro, nawet w przypadku niezbyt złożonych projektów, które nie mają ambicji wspierania jakiś wymyślnych usług, a są jedynie wizytówką czy nośnikiem – względnie stałym – informacji, które chcemy udostępnić w sieci. Niestety nawet wówczas pisanie stron w „czystym” HTML-u mocno odbija się na ilości pracy, którą należy każdorazowo poświęcić takiemu przedsięwzięciu, co akurat znakomicie rozwiązują CMS, gdzie po prostu wybieramy jakiś motyw, który stanowi szkielet tworzonej witryny i uzupełniamy go konkretną treścią wszędzie tam, gdzie jest taka potrzeba.
SSG to swoisty kompromis między tworzeniem zupełnie od podstaw statycznych stron, a pełnoprawnym CMS-em, czyli mamy tutaj faktycznie do czynienia z sytuacją, gdy cała witryna jest generowane tylko raz (czy też dokładniej: tylko i wyłącznie wtedy, gdy zachodzi potrzeba intencjonalnego wprowadzenia zmian w jej zawartości) i następnie umieszczana na serwerze w postaci gotowych plików HTML. Tym niemniej do tego celu używane są podobne mechanizmy oraz narzędzia, które doskonale znamy z przeróżnych CMS-ów – na ten przykład wykorzystywany jest zawsze jakiś język szablonów czy tam znaczników, który pozwala uniknąć niepotrzebnego powielania kodu i skraca proces składania całości. Jeśli zaś chodzi o tworzenie i utrzymywanie treści, którymi chcemy następnie wypełnić te szablony, to można z powodzeniem zapisywać i pobierać je z dedykowanych do tego celu baz danych, choć – z tego co zdążyłem się zorientować – najczęściej rolę takich nośników spełniają pliki Markdown.
Tym niemniej w przypadku SSG na próżno szukać charakterystycznych dla CMS-ów paneli administracyjnych czy page builderów, choć i od tego są wyjątki, jak chociażby zyskujący coraz większą popularność Publii. Dlatego należy zaznaczyć, że nie jest to rozwiązanie dla każdego, a zwłaszcza powinny je omijać szerokim łukiem osoby nietechnicznych, ponieważ próg wejścia w porównaniu do takiego WordPressa jest zdecydowanie wyższy.
Dlaczego właśnie Hugo?
Skoro już mamy jakieś pojęcie dlaczego warto – przynajmniej w pewnych przypadkach – porzucić ulubionego CMS-a na rzecz SSG, warto na sam koniec odpowiedzieć na pytanie, dlaczego postawić właśnie na Hugo?
Jak już wspomniałem wcześniej twórcy Hugo reklamują swoje narzędzie jako najszybsze rozwiązanie tego typu i z tego co czytałem nie ma w tym wiele przesady. Tym niemniej ta flagowa cecha ma niewielkie znaczenie w przypadku małych lub co najwyżej średnich projektów. Tym bardziej, że generowanie plików wynikowych najczęściej odbywa się na wydajnej maszynie po stronie dewelopera i wówczas kwestie wydajnościowe są tutaj drugorzędne (kilka sekund czy minut w jedną czy drugą stronę nie mają większego znaczenia).
To co na co osobiście zwróciłbym uwagę to względna prostota (z tego co czytam) rozwiązania oraz spore możliwości oferowane już na start. Oczywiście w przypadku pierwszej z wymienionych zalet trzeba brać poprawkę, że porównujemy tutaj Hugo do innych narzędzi tego typu, więc niestety bez kodowania się nie obejdzie, ale – jak już wspominałem – znajomość Golang na nic nam się tutaj nie przyda. Być może jakieś bardziej wyszukane rozwiązania wymagają opanowania podstaw Go, ale po przejrzeniu fragmentów dokumentacji Hugo odnoszę wrażenie, że niewiele wskazuje, że będzie w ogóle taka potrzeba (a przynajmniej w podstawowym zakresie posługiwania się tym generatorem).Tym niemniej do przyswojenia pozostaje praktyczna znajomość architektury całości tego rozwiązania oraz wykorzystywanego w Hugo języka szablonów, a także znaczników Markdown. Oczywiście trudno sobie wyobrazić – jak w przypadku każdego SSG – zabawę z Hugo bez podstaw HTML, chyba że ograniczymy się wyłącznie do korzystania z gotowych tematów, a takowych jest naprawdę sporo. Tym niemniej widziałem na Githubie projekt page buildera dla Hugo, który być może pozwoli ukrócić cierpienia osób, które jak ja nie czują się komfortowo w tematyce frontendu i nie zamierzają specjalnie tego stanu zmieniać.
Jednak w zamian za ten cały wysiłek poznawczy twórcy obiecują dość liczne bonusy w pakiecie startowym jak chociażby zintegrowana obsługa komentarzy Disqus, wsparcie dla Google Analytics czy automatyczne tworzenie kanałów RSS. Ponadto jakieś dwa lata temu w Hugo pojawiła się możliwość dodawania tzw. modułów, dzięki którym znacznie można rozszerzyć funkcjonalności dostępne dla tego narzędzia o własne rozwiązania czy udostępnione przez innych użytkowników.
Od siebie na koniec mogę dorzucić jeszcze naprawdę porządną dokumentację, a przynajmniej na taką wygląda po pierwszej pobieżnej lekturze, ponieważ nie miałem za bardzo okazji przetestować jej w praktyce. Z resztą mam nadzieję, że za kilka tygodni (znaczy się weekendów) będę mógł z większym przekonaniem pisać o tym, czy Hugo wywiązuje się z obietnic złożonych przez jego twórców. Gdyby ktoś chciał jednak poczytać więcej w temacie to mogę jedynie zachęcić do odwiedzenia oficjalnej strony projektu, gdzie część z tych “ficzerów” jest wymieniona.
