Mój poprzedni wpis zacząłem od pewnego oświadczenia na temat generatorów stron statycznych (dalej SSG) i niestety dzisiaj nie obejdzie się bez podobnej deklaracji, choć oczywiście w nieco innej kwestii. Jednak na tego rodzaju komunikat trzeba będzie poczekać do końcowych akapitów niniejszego tekstu. Jednak nieprzypadkowo przywołuję mój ostatni blogowy “coming out”, ponieważ dzisiejszy wpis jest poniekąd uzupełnieniem – lub jak ktoś woli „sprostowaniem” – zagadnienia, które wówczas poruszyłem.
Dlatego zanim przejdę do właściwej części dzisiejszego tekstu, przypomnę w dużym skrócie nad czym w poprzednim wpisie się pochyliłem. Otóż podjąłem trud (rzecz jasna niespecjalnie ciężki) omówienia tych narzędzi, które z jednej strony zapewniają komfort pracy oraz bogactwo funkcjonalności znanych z “tradycyjnych” CMS-ów, ale jednocześnie nie wymagają do tego żadnej bazy danych pod spodem. Pierwotne założenie rzecz jasna dotyczyło SSG i sprowokowane zostało odkryciem rodzimego rozwiązania o nawie Publii. Jednakże w efekcie dalszych poszukiwań okazało się, że w przyrodzie praktycznie nie występują tego typu rozwiązania (jeśli chodzi o SSG), więc rozszerzyłem to zagadnienie o CMS oparte na plikach płaskich. Tym sposobem na mojej bardzo krótkiej liście znalazł się również Grav CMS, którego poniekąd – uwaga spoiler – będzie dotyczyło wspomniane wyżej oświadczenie. Niestety pierwszy kontakt z tym narzędziem dość mocno mnie rozczarował, więc postanowiłem nieco jeszcze podrążyć temat. Tym sposobem mogłem się przekonać, że są jeszcze przynajmniej dwa rozwiązania, o których warto wspomnieć w tym kontekście (plus coś ekstra).
Jekyll (Ruby)
To jeden z najbardziej znanych i chyba pierwszy SSG, który trafił do masowej świadomości developerów stron internetowych, choć mam wrażenie (być może błędne), że lata świetności ma już za sobą. Od razu też przyznam się, że pobawiłem się nim góra dwie godziny, w dużej mierze za sprawą marnej jakości dokumentacji, co bardzo mnie zaskoczyło, mając na uwadze “leciwość” projektu. Druga rzecz, która sprawiła, że nie stanęło mi zapału do tego narzędzia, to język backendu, czyli Ruby, a więc obszar, którego zgłębianie jeszcze mniej mnie interesuje niż PHP.
Przyznać jednak muszę, że liczba rozszerzeń tych oficjalnych jak i przygotowanych przez społeczność robi wrażenie. Oczywiście jeśli ktoś oczekuje bizantyjskiego rozpasania w stylu WordPressa, to szybko się rozczaruje, ale wiele przydatnych funkcjonalności w ten sposób zostało zaadresowanych. W tym panel administracyjny, choć nie zwala on z nóg i przypomina raczej ten znany z Pelicana, czyli de facto pozwalający na modyfikację plików Markdown. Jeśli dorzucić do tego całkiem przyjemny system zarządzania rozszerzeniami (z wiersza poleceń), to może on stanowić naprawdę fajną opcję dla domorosłego dewelopera w rodzaju piszącego te słowa.
OCENA: 3/5
Hexo
Przyznam się bez bicia, że do soboty nie słyszałem o tym rozwiązaniu, choć na githubie ma ono ponad 30 tysięcy gwiazdek, co czyni go jednym z najpopularniejszych narzędzi w swojej klasie. Wydaje mi się jednak, że zawdzięcza to głównie osobom z krajów azjatyckich, a przynajmniej tak zakładam na podstawie nadreprezentacji autorów wielu wtyczek czy tematów dostępnych dla Hexo, którzy pochodzą z dalekiego wschodu.
Niestety oficjalna dokumentacja jest niemal tak samo marna jak w przypadku wcześniej omawianego Jekylla, a chałupniczych tutoriali w języku angielskim jest jak na lekarstwo. Tym niemniej jest to rozwiązanie na tyle proste, że osoba zaznajomiona z Hugo czy Jekyllem powinna sobie poradzić, choć jest tu trochę więcej zabawy z konfigurowaniem różnych dodatkowych plików yaml.
Liczba rozszerzeń być może jest porównywalna z tą dostępną dla Jekylla, ale wydaje mi się mniej przydatna niż w przypadku tego ostatniego, a przynajmniej nie adresuje tych zagadnień, które z mojej perspektywy wydawały się kluczowe. No i chyba jest bardzo różnie z ich jakością, a przynajmniej tak sądzę na bazie kilku dostępnych paneli administracyjnych czy raczej edytorów plików, które są straszliwie ubogie, tak w funkcjonalności jak i pomoce dostępne dla edycji treści. To samo dotyczy gotowych tematów, które w ogromnej większości są wyjątkowo nieatrakcyjne.
Na na plus – z mojej perspektywy – można zaliczyć język programowania, czyli Javascript. Dlatego wydaje się to być bardzo dobra propozycja dla wszystkich amatorów tego języka, którzy – jak piszący te słowa – brzydzą się Reacta i dlatego omijają Gatsby’ego szerokim łukiem.
OCENA: 2,5/5
Netlify CMS
Wbrew nazwie nie jest to CMS sensu stricto ani żaden z niego SSG, choć tak naprawdę w pracy z tymi ostatnimi może się okazać szalenie pomocny. Nie wiem czy to najtrafniejsze określenie, ale jest to coś w rodzaju nakładki na SSG, czy właściwie narzędzie, które może sprawić, że tworzenie kontentu będzie nieco przyjemniejsze. Tak naprawdę jest to biblioteka JS, którą można wykorzystać do pracy z właściwie dowolnym SSG. Wystarczy bowiem dodać ją do naszego projektu i tym sposobem dostajemy poręczny edytor plików MD. Oczywiście Netlify CMS nie adresuje wszystkich tematów, jak ma to miejsce w przypadku paneli administracyjnych dla CMS-ów, ale na pewno wydaje się ciekawą opcją dla każdej hobbystycznej strony, który powstaje chociażby przy pomocy Hugo.
Zamiast podsumowania
Wspomniałem wyżej, że moje pierwszy doświadczenia z Grav okazały się niespecjalnie udane. To nie czas i miejsce, by rozwodzić się nad tym, co nie zagrało na początku, tym niemniej obecnie jest bardzo kontent z tego jak zostało pomyślane to rozwiązania i to na tyle, że postanowiłem się ostatecznie pożegnać z Ghostem. Oznacza to, że nie minął jeszcze pełen rok od startu mojego bloga, a za chwilę będę miał za sobą drugą migrację. Mam jednak nadzieję, że tym razem nie znudzę się czy też nie zniechęcę się tak szybko, jak to się stało z udziałem Ghosta, który od pewnego czasu coraz bardziej mnie irytuje.
Co to jednak oznacza dla tego bloga? Otóż postanowiłem sobie zrobić przerwę od pisania tutaj co najmniej do grudnia, by w spokoju popracować nad nowym wyglądem strony i przenieść dotychczasowe teksty do Grava (pewnie kilka z nich przy okazji pójdzie w niepamięć). Długość tego przestoju w żadnej mierze nie wynika z ilości roboczogodzin do tego celu potrzebnych, bo jeden w całości na tyłku spędzony weekend zapewne by wystarczył, ale nie chciałbym tego robić na siłę, a przy okazji będę mógł nadgonić pewne zaległości w innych obszarach. Tym niemniej podejrzewam, że po powrocie zacznę od cyklu wpisów temu rozwiązaniu poświęconych, co zapewni mi tematy do końca tego roku co najmniej. A tymczasem do zobaczenia.
