Hugo in Action

Bosszantóan nem tudok eligazodni a Hugo dokumentációjában, pedig programnyelvekében és keretrendszerekében is sikerülni szokott.¹ Elegem lett, és megvettem az ajánlott könyvet a Manningtól² (Early Access), mert a Hugót kiváló szoftvernek tartom, és bár a minimumot tudom és értem, használtam is már, de jó lenne még magabiztosabban használni jövőbeli projektekben.

A webes fejlesztéshez sokféle eszközt és technológiát kell ismerni (webstack), melyek közül a front oldali HTML+CSS+JS kombót utálom a legjobban. Evvel ugyebár a kezdetektől össze lehetett rakni weboldalakat, jóval azelőtt, hogy Jamstacknek hívták volna, vagy megalkották volna a Hugót és egyéb generátorokat (SSGs). Sőt, kicsit hunyorítva úgy is tűnhet, hogy visszatérünk a hőskorba, amikor a lokális gépen szerkesztett forrásfájlokat FTP-n felmásoltuk a távoli gépre, de e látszat messze van attól a valóságtól, amit mai eszközeink (és tapasztalataink) lehetővé tesznek.

Két nagyobb problémakör van a Jamstackkel. Az egyik a kereshetőség megoldása, mivel a legfontosabb felhasználási területek a dokumentáció, tudásbázis építése és hosszabb szövegek, művek közlése. A másik, hogy ugyan eliminálja a backendet (a hosztolás megoldásán kívül), de webdizájnerek és tartalommenedzserek számára még mindig túl összetett. Kevés olyan grafikus-dizájnert láttam, aki otthonosan mozgott a HTML+CSS-ben, netán ismerte a SASS-t vagy különféle CSS-keretrendszereket, és akkor még nem beszéltünk a továbbiakról (JS, npm, Webpack, valamelyik SSG stb.).

A tartalmi oldal ugyan jóval egyszerűbb, de a valóságban a CMS-ek adminjával vagy a Worddel is küzdeni szoktak a kollégák, itt pedig szövegfájlokat kellene szerkeszteni, majd azokat publikálni. (Nem tudom, a Netlify CMS mennyit segíthet ezen, de gittel is elég jól automatizálható a publikálás.) Úgyhogy a gyakorlatban a Hugo egyetlen felhasználójává a (backend-)fejlesztő válhat, aki így megnyerheti a tartalommenedzsmentet is a webdizájn mellé. Sajnos, innen nézve eléggé beszűkül a felhasználási területe e tényleg kiváló eszköznek.

Végül is mire jó és kinek való a Hugo? Olyanoknak, akik amúgy is képesek voltak összerakni és élesíteni egy weboldalt. Olyan esetben, ha

• a cm nem érdekli a megrendelőt, és a tartalom ritkán változik: átlagos kkv weboldal, egyszerű tájékoztató vagy marketingoldal, landing page;
• a cm nem érdekli a megrendelőt, és a tartalom feltöltésével is megbízza a fejlesztőt (értsd: fizet érte);
• egy geek vagy fejlesztő(csapat) magának csinál oldalt: dokumentáció, kis híroldal vagy blog (jegyzetek); a tartalomszerkesztőknek nem okoz gondot a markdown és a git.

Tehát akkor, amikor nagy biztonsággal kiiktatható a hagyományos CMS, ez ugyanis jelentősen egyszerűsíti a fenntartást és növeli az időtállóságot. Apropó biztonság: szinte mindig a stack tetején lévő applikációt törik fel, illetve azon keresztül férnek hozzá az adatbázishoz, fájlrendszerhez stb. Nos, itt nincs applikáció.

Melyik a legjobb SSG? Erre nem tudok válaszolni, mert nem próbáltam ki mást. Az utam a Hugóhoz elég egyenes volt: a Next.js, a Gatsby és a Hexo Node.js-re épül, a Jekyll pedig Rubyra, ez befolyásolja a használatukat is. A Hugo egy önálló bináris parancsfájl függőségek, pluginek nélkül, a forrása Go-kód, de a használatát illetően a Góhoz csak a Go Templates által van köze (amely – ne szépítsünk – gagyi, de megszokható). Hasonló alternatíva a fiatalabb Zola.

A könyv szokás szerint túlírt, de használható. A technikai könyvek baromi drágák, és általában nem sok újat hoznak a konyhára, ha nem teljesen új területet/koncepciót/eszközt mutatnak be az olvasónak. Úgyhogy bár leértékelve vettem, tisztában voltam vele, hogy 30% körüli hasznosítást várhatok tőle. Ezt talán hozza, nem kiváló könyv, igaz, még nem is végleges. Az egyértelműen kiderül, hogy a szerző érti a dolgát, nincs nyoma kókler ollózásoknak vagy divatos frázisok puffogtatásának, ami a lelkes amatőröket rögtön felismerhetővé teszi.