Miért nincs build-lépés ezen az oldalon?
Ezt a lapot kézzel írt HTML adja. Nincs mögötte keretrendszer, csomagkezelő és fordítás — a bizonyíték az, amin épp állsz.
Kezdem azzal, ami nem érv: nem azért, mert a build-eszközök rosszak. Kiváló okok szólnak mellettük, és a legtöbb projektben helyük van. Ez a döntés ehhez az egy oldalhoz szól, és az indoklása is csak addig terjed.
Amit a hiánya megszüntet
Az első, hogy a forrás azonos azzal, ami fut. Amit a szerkesztőben látok, azt kapja a böngésző. Nincs fordítási lépés, ami közben átalakítana valamit, és nincs olyan hiba, ami csak élesben jelentkezik. Hibakereséskor ez több időt spórol, mint amennyit a komponensek megspórolnának.
A második, hogy nincs mit frissíteni. Nincs függőségfa, amiben egy biztonsági javítás nyolc másik csomagot rántana magával, és nincs olyan eszköz, ami két év múlva már nem futna le a gépen. Egy statikus lap, amihez senki nem nyúl, öt év múlva is ugyanaz — erről szól bővebben az az írás, ami azt veszi végig, mi történik egy magára hagyott oldallal.
A harmadik a nulla külső kérés. A lap megjelenítéséhez a böngésző egyetlen idegen kiszolgálót sem keres meg: nincs CDN-ről töltött betűtípus, nincs beágyazott térkép, nincs analitika. Ennek a legfontosabb következménye nem a sebesség, hanem az, hogy a látogatóról nem kerül adat harmadik félhez — és ezért nincs is szükség süti-elfogadó ablakra.
build-lépéssel
- forrás
- fordítás
- csomagok
- CDN
- böngésző
enélkül
- forrás
- böngésző
Amit cserébe elveszítek
Ezt is ki kell mondani, különben a fenti lista propaganda.
Nincs komponens. A fejléc, a lábléc és a navigáció minden lapon külön példányban él. Ha ezek közül valamelyik változik, azt minden érintett lapon át kell vezetni. Ez a legnagyobb ára a döntésnek, és nem lehet elbeszélni fölötte.
Nincs típusellenőrzés és fordítási hiba. Egy elgépelt osztálynév nem áll meg semmilyen fordítónál: a lap megjelenik, csak épp stílus nélkül. Ez pontosan az a hibafajta, amit a build kiszűrne.
És nincs automatikus optimalizálás: nem tömörödik a CSS, nem darabolódik szét a JavaScript. Ekkora oldalnál ennek nincs mérhető következménye, de nagyobbnál lenne.
A hiányzó fordítót itt egy ellenőrző szkript pótolja, ami minden változtatás után lefut: azt nézi, amit a fordító nézne, és azt is, amit egyetlen általános eszköz sem tudhat a lapról. Erről külön darab szól: mit bízz gépre egy weboldal ellenőrzéséből.
Hol van a határ
Ez a döntés nem skálázódik, és nem is állítom, hogy skálázódna. Három feltétel közül bármelyik megdönti:
Ha nem a fejlesztő szerkeszti a tartalmat. Amint egy ügyfélnek magának kell szöveget írnia, kell egy felület — és onnantól rendszer kell, nem fájlok.
Ha sok az azonos szerkezetű lap. Néhány tucatnál a kézi karbantartás még átlátható. Több százzal a másolt részek elkezdenek egymástól elcsúszni, és az ember ezt nem veszi észre.
Ha a tartalom adatból generálódik. Terméklista, naptár, árazás — ezeket kézzel karbantartani nem elv, hanem hiba.
A valódi mérce
Nem az a kérdés, hogy van-e build-lépés, hanem hogy átvehető-e a rendszer. Egy kézzel írt oldalhoz elég a HTML és a CSS ismerete; egy nyolc csomagra épülő projekthez ismerni kell a keretrendszert, a verzióit és a konfigurációját is.
Mindkettő lehet jó választás. A különbség az, hogy az elsőnél az átvehetőség alapból adott, a másodiknál külön munka — és ha ez a munka elmarad, abból lesz az a rendszer, amihez mindig ugyanazt az egy embert kell hívni.
Kérdések a témáról
Nem lassabb kézzel írni a HTML-t?
Az első lapnál igen, a huszadiknál már nem feltétlenül. Ami időt visz, az nem a gépelés, hanem az ismétlődő részek karbantartása. Néhány tucat lapig ez kezelhető; ahol a szerkezet gyakran változik vagy több száz lapról van szó, ott a generálás gyorsabb.
Mit jelent az, hogy nulla külső kérés?
Azt, hogy a lap megjelenítéséhez a böngésző egyetlen idegen kiszolgálót sem keres meg: nincs CDN-ről töltött betűtípus, nincs beágyazott elem, nincs analitika. Ennek a legfontosabb következménye nem a sebesség, hanem az, hogy a látogatóról nem kerül adat harmadik félhez.
Mikor rossz választás a build nélküli megoldás?
Ha a tartalmat nem a fejlesztő szerkeszti, ha sok az azonos szerkezetű lap, vagy ha az oldal adatokból generálódik. Ilyenkor a kézi karbantartás emberi hibát termel — pontosan azt, amit a build kizárna.
Hogyan lehet ismétlődés nélkül dolgozni build nélkül?
Sehogy: az ismétlődés megmarad, és ezt vállalni kell. Amit tenni lehet, az az, hogy a másolt részek eltérése ne csússzon el észrevétlenül — erre való egy ellenőrző szkript, ami a lapok közti kötelező egyezéseket vizsgálja.