Přejít k navigační liště

Zdroják » Různé » Statický web neznamená špatný web

Statický web neznamená špatný web

Články Různé

Taky si myslíte, že web, kde není použitá našlapaná serverová technologie, nejmodernější framework a databáze (ideálně NoSQL), je zastaralý, neschopný a špatný? Že jedině dynamické generování obsahu dokáže vymáčknout z webových technologií nejvíc a statický obsah nemá budoucnost? A budete si to myslet i za pět let?

Nálepky:

Slovo „statický“ má trochu smůlu.

Jeho protiklad, slovo „dynamický“, si spojujeme podvědomě s pokrokem, inovacemi, pohybem, zlepšováním, zkrátka s tím, co mnozí považují za lepší. Statické tak získává punc nevyvíjeného, tedy nemoderního, zastaralého, zkostnatělého… Ostatně i inzeráty jsou plné „mladých dynamických kolektivů, hledajících flexibilní kolegy“ (což znamená „jsme parta zmatlíků bez pevného vedení a chceme, abys dělal od nevidím do nevidím“), do „statického starého kolektivu“ nikdo pracovat nepůjde (a skutečné staré statické kolektivy se proto v inzerátech označují jako „zavedený tradiční zaměstnavatel, jistota stálého kariérního růstu“ – ale to odbočujeme).

Stejný efekt se projevuje i na webu. Každý, kdo rozumí technologii, ví, že technický rozdíl mezi „statickým“ a „dynamickým“ je jen v tom, jestli je stránka předem připravená a jen poslaná, nebo jestli ji server vytváří, až když o ni někdo požádá (a cache nechme stranou). Technicky je rozdíl mezi „statickým“ a „dynamickým“ webem jasný a pro konkrétní zamýšlené použití lze určit, zda bude statické řešení dostatečné, nebo zda bude nutné použít dynamické serverové generování (např. z databáze).

Jenže – zkuste zákazníkovi říct, že mu vytvoříte „statický web“. Statický je přece špatný, nemoderní, zastaralý, zkostnatělý – viz výše. Zákazník si žádá webu moderního, akčního, plného energie, dynamického… Hovory s některými zákazníky v tomto směru někdy připomínají legendární historku o přeskočení polovodičů a získáním náskoku před kapitalistickou cizinou rozvojem celovodičů.

Dynamický obsahem, statický technologií

To, co si zákazník představuje pod pojmem „dynamická webová prezentace“ přitom většinou neznamená, že stránky musí být nutně dynamicky generované. Nechme ale „dynamické prezentace“ ve všech ostatních významech stranou a věnujme se jen technické statičnosti / dynamičnosti.

Technický rozdíl mezi statickým a dynamickým webem má mnoho konsekvencí – například u statického webu bývají stránky sestaveny „někde jinde“, zatímco u dynamického jsou vytvářeny přímo na serveru (pro puntičkáře: cachování či oddělení generování od HTTP serveru na jednom stroji nechme stranou).

V začátcích webu nebylo dynamické generování obsahu takovou samozřejmostí, jakou je dnes, kdy na i těch nejlevnějších hostinzích naleznete alespoň PHP, častěji i další jazyky a nástroje. Vývoj technologie se projevoval na vývoji uživatelských očekávání, a ty zpětně ovlivňovaly technologie. Dovolte příklad z vlastní zkušenosti.

Jak se statické stávalo dynamickým

Když jsme v roce 2003 vytvářeli Bloguje.cz, bylo jedním ze stěžejních požadavků mít možnost nechat si vytvořené HTML stránky poslat pomocí FTP na jiný webový server. První verze tohoto blogovacího nástroje doopravdy generovala statický web – při napsání článku se vygenerovala stránka s článkem, přegenerovala se indexová stránka a nově se vygenerovalo RSS. Na konci se takto vytvořené stránky v případě, že bylo potřeba, přenesly via FTP na jiný server. Uživateli stačilo mít „běžný HTTP hosting“, bez databáze i bez možnosti spouštět vlastní skripty.

V té době byly i specializované blogovací nástroje, které fungovaly na domácím počítači, stránky vygenerovaly lokálně a poslaly je přes FTP na HTTP server – hosting. Jedním z takových nástrojů byl Easyblog od spoluautora Bloguje Libora Krayzela. V začátcích jsme dokonce uvažovali i nad tím, že by Bloguje byl jen dedikovaný HTTP hosting pro uživatele Easyblogu – tedy pro statické stránky generované tímto programem. Jenže doba přála dynamickým serverovým řešením, PHP začalo být stále dostupnější, stejně tak hostingy s databázemi, vznikaly webové nástroje pro blogování (s požadavky „PHP+MySQL“), a co víc – nabízely novinky, co offline statická řešení nabídnout nemohly.

Největší killing feature dynamických blogovacích systémů v té době byly komentáře. Čtenář měl k dispozici formulář, do něj napsal svůj příspěvek („Ahoj, koukni na můj blog“), odeslal a hned ho viděl na webu. Během půl roku musely mít komentáře všechny blogy, jinak…

Komentáře se ale u statického webu řeší těžko. Autor Easyblogu, donucen okolnostmi a uživateli k implementaci komentářů, to řešil oklikou přes vlastní server s diskusemi (články zůstávaly statické, komentáře se ukazovaly v iframe z jeho serveru) a nakonec to vyřešil v roce 2005 ukončením vývoje a podpory. Ve svém rozlučkovém článku se omlouval uživatelům a odkazoval je na „vyspělejší online systémy“.

Dynamická nutnost

Během dvou let se vývoj přehoupl od „nutnosti nabídnout statické generování obsahu“ k „nutnosti generovat obsah dynamicky“. Náhle se začalo generovat dynamicky snad vše a ten, komu URL končilo „.html“, byl out. Někde to mělo smysl – například u zmíněných publikačních systémů, e-shopů či webů, založených na intenzivní práci s databází. Ovšem někde to smysl nemělo a nemá.

Typický příklad: Stránky truhlárny, včelařství, penzionu, … Někteří tvůrci nacpali kompletní obsah, včetně obrázků a ikon, do databáze a vše posílal dynamicky přes ASP nebo PHP. Důvod (spíš „důvod“) pro takové řešení se vždycky našel. V nejhorším případě šlo vždy alespoň uvést na konci každé stránky informaci „Tato stránka byla vygenerována za 0.00076251744­8 sec“. Přitom by jednoduchá prezentace v prostém HTML stačila.

Ona stačí dodneška, a s rozvojem client-side technologií je čím dál tím míň důvodů (a „důvodů“) pro prosté informační weby používat dynamická serverová řešení. Většina věcí, pro které se na takových webech používá dynamické generování, spadá do jedné z následujících kategorií:

  1. lze ji vyřešit pomocí client-sice technologie
  2. lze ji obejít či nahradit podobným řešením
  3. lze je bez ztráty kvality zahodit

Webové prvky spadající pod bod 3 („Kdo má dnes svátek“, „Stránka byla vygenerována…“), by měly být vyhozeny tak jako tak. Pokud se vše ostatní, co řeší server, dá zařadit do kategorie 1 nebo 2, je na místě zvážit, jestli neudělat web statický.

Co budeme mít ze statického webu?

Co tím získáme? Statický web bude pravděpodobně o něco rychlejší než cachované řešení (a o hodně rychlejší než necachované). Čím míň technologií se na vytvoření stránky podílí, tím míň je v řetězci zpracování míst, které se mohou pokazit. No a nakonec je prostý HTTP server nenáročnější (a tedy levnější) než např. LAMP. (Námitka, že většina hostingů stejně nabízí LAMP, a úspora je tedy iluzorní, padá, pokud se se svou aplikací přestěhujeme do cloudů.)

Pro drobné webové prezentace, vizitky a podobné weby je statické serverové řešení dostatečné. Dokonce i pro klienty, co si chtějí „čas od času“ něco změnit – mohou, je k tomu spousta nástrojů, od prostého textového editoru po specializované nástroje, které dovolí upravit editable prvky a opět je nahrát na server. Přitom takové prezentace stále tvoří většinu požadavků na webdesignérská studia – ne každý chce dělat portál či katalog webů.

A co něco složitějšího, řekněme třeba zmíněné blogy? Šlo by nahradit dnes nejpoužívanější řešení první volby (HTTP+skriptovací jazyk+databáze+CMS) staticky generovanými HTML stránkami? Přišli bychom tím především o komentáře (a stranou ponechme otázku, nakolik by to byla ztráta)… Existuje ale řešení – mohli bychom použít nástroj typu Disqus nebo facebookové komentáře. Nevýhoda těchto řešení je v tom, že jsou komentáře do stránky vkládány až na straně klienta JavaScriptem, takže je vyhledávací roboty nezaindexují (a opět – nakolik je to škoda, si rozhodněte sami).

Nejrůznější kalendáře by šly opět řešit nějakým souborem na serveru (JSON), z něhož by si skript pro kalendář načetl data vydání článků. Upřímně řečeno jako největší problém vidím nutnost přegenerování celého obsahu v případě změny nějakých site-wide informací („Oblíbené odkazy“ třeba), což bude v případě plodného autora s mnoha sty článků zdlouhavé. Pokud se ale na blogu nechystáte dělat podobné změny často, nemusel by být se statickým generováním problém.

Je tedy čas oprášit Easyblog a upravit ho (třeba) pro webserver Amazon S3? Inu, proč ne, možné by to bylo – otázka je, jestli to zrovna u blogů, které dnes nabízí skoro každý, zdarma a v dostatečné kvalitě, zapotřebí. Ale co třeba z něj udělat dedikovaný nástroj pro úpravy editable obsahu v malých webových prezentacích, který by dostali do rukou klienti, co nepotřebují dynamicky generované weby…?

„Statický web“ jako by dnes chytal druhý dech. Mnohé webové aplikace mohou pracovat čistě na straně klienta a nové možnosti JavaScriptu tomuto trendu nahrávají. Dělat nad „obyčejným“ HTTP serverem kříž by tedy bylo předčasné. Předělávat weby horem pádem do statické podoby bez důkladného rozmyšlení by bylo samosebou nesmyslné. Ale je na místě si říct, že „statický web“ není rozhodně nehybný a zkostnatělý a své místo mezi webovými technologiemi rozhodně má.

Dnešní glosu berte jako takovou „tematickou předehru“ – brzy se na těchto stránkách podrobněji pobavíme o možnostech nástrojů pro generování statických webů (nanoc, Jekyll, yst, Hyde, Hakyll, Pagegen a další), o „publikování přes Git“ a o jiných věcech, spojených se „staticky generovaným webem“ – pozn.red.

Komentáře

Subscribe
Upozornit na
guest
28 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Naith

Levné statické prezentační weby občas dělám, takže pár poznámek.

Pokud nemáte dobrý nástroj pro generování statického webu, tak při častějších úpravách se mění v peklo mrtvých, nebo chybných linků, hlavně menu. Další možnou zradou jsou nekonzistentní podstránky, které vznikají při úpravách společných částí webu, kde můžete občas na některou pod stranu zapomenout. Pokud dynamičtější části děláte linkováním služeb, tak rychlost se zhorší i když je pravda, že jen u těchto části. Pokud jsou napsány části v JS riskujete nefunkčnost na mobilech, protože ne každý má Android, iOS a pod.

Shrnuto bez generátoru statického webu se to hodně špatně udržuje a riskujete mnoho chyb.

tdvorak

Ja to jednomu klientovi resil tak, ze jsem vytvoril v jave swingovou aplikaci, ktera mu umoznovala nektery casti webu doplnovat (typicky reference, tj obrazek, popis, ulozilo to do xml), nasledne to vzalo sablony stranek a dorenderovalo na desktopu. Pak uz na dalsi kliknuti probehl upload na ftp. Aplikace bezi jiz spoustu let, jen se parkrat upravily sablony. A troufnu si tvrdit ze vyvoj aplikace se davno zaplatil levnym hostingem, ktery pak lze pouzit. Dnes uz je to asi uplne jedno, ale pred par lety to bylo klidne 1-2k rozdil rocne…

Naith

To mě zajímá, je to někde k dispozici?

tdvorak

Zkusim se podivat jestli to jeste nekde vyhrabu. Ale je to pekna radka let, o verzovani jsem tenkrat nic nevedel, tak snad nekde dohledam kopii v zalohach :)

tdvorak

Ale jinak bych asi spis doporucil podivat se na nastroje co nize zminuje pan Maly, tedy „nanoc, Jekyll, yst, Hyde, Hakyll, Pagegen“. Bude to resit stejne veci, jen to nebude bastl jednoho studenta, ale poradnej nastroj (predpokladam, neznam je).

Naith

Asi budu doufat, že to najdete. Zběžně jsem se mrknul na vyjmenované generátory a jsou v Ruby, Pythonu, Hasskellu a pod. Potřebuji něco normálního jako je C, JAVA, C++. :)

František Kučera

A co XSLT? Té Javy tam taky trošku je :-)

rony spravodaj

tak jeden staticky web som vyrobil pomocou Movable type, ktore defacto generuje staticky obsah. a zaroven je to redakcny system na spravu obsahu. takmer idealny nastroj aj na zmeny v obsahu a nielen v navigacii a pod.

tdvorak

Super, tesim se na dalsi clanek :)

Naith

Tak se budu těšit, neboť u malých prezentaci, případně podpůrných webů je to dobré řešení.

karf

Jé, vzpomněl jsem si na PPWizard, pamatujete někdo? Kdysi dávno o tom tuším psával Marek Prokop v Sově ještě coby newsletteru.

A víte co? Ono to pořád existuje! http://dennisbareis.com/ppwizard.htm :D

Dlouhán

Jako generátor jde použít PHP a případně i databázi, a pak stáhnout web z localhostu programem na stahování webů.

Pár lidí, třebas Yuhů (Dušan Janovský) používá jako generátor statického webu FrontPage právě na tu správu obsahu, nemůže si ho vynachválit, a to už vyzkoušel spoustu jiných programů, ale na správu obsahu doposud nic lepšího nenašel.

Pepa

vždycky bych zpřerážel webmasterovi pracky, když vidím web o 5 stránkách nasazenej na Drupalu nebo podobné šílenosti.

tdvorak

Dost ortodoxni nazor ne? Treba k tomu ma duvod. Treba se tak firemni web sekretarce dobre udrzuje. A pokud na to nemusej kazdej rok volat firmu co jim to tenkrat rozchodila a zvladnou to sami, urcite usetrili slusny penize.

Pepa

Pokud by k tomu měl důvod, tak je to v pořádku. Ale častokrát chce klient obyčejnou „prezentaci“ a realizátor jim nabulíkuje že to „musí být dynamický“ a nasadí tam něco, co je totální overkill. Speciálně v malých firmách bez IT oddělení je problém najít někoho, kdo by ten Drupal dokázal obsluhovat, přestože nám „klukům od počítačů“ se to zdá jako jednoduchá věc.

jlx

Hmm, takže obsluhovat 5 statických HTML stránek je pro malou firmu jednodušší než obsluhovat web v Drupalu?
No nevim, podle mých zkušeností se u statických webů musela každá pidiúprava vždycky řešit s kodérem, teďka si většinu věcí prostě změní sami.

Pepa

Jo, protože s tím drupalem neumějí dělat a protože těch změn je tak málo, že je jednodušší zavolat webmasterovi, kterýmu to zabere 5 minut. Drupal je často zbytečná investice – moje zkušenost z malých firem je, že se tam nikdy nikdo nenaloguje a žádný změny neudělá.

kandidát přeražení pacek

Upřímně, já klidně dělám i malé weby na Drupalu. Zjistil jsem, že je pro mě efektivnější udělat klientovi i ten pětistránkový web v Drupalu, protože se to i mě snadno udržuje a všechny klientské weby mám na stejné platformě (a nemusím hledat, co jsem to tam tehdy dávno vlastně udělal a jak všude vedou odkazy apod.).
Hlavně je pak pro mě jednoduché ten web kdykoliv podle požadavků klienta rozšířit, protože on sice chtěl na začátku jednoduchý ‚statický‘ web, ale pokud to funguje, tak chce časem přidat tuhle funkci a tamhleto a … Když zákazník takové rozšíření nechce, nic se neděje, ale když jo, je to relativně jednoduchá práce.
A i když je ten web prakticky nenáročný, tak klidně použiju jako kanón na vrabce boost a každou noc web automaticky předgeneruju – a jak vlastně poznáte, jestli je to statický nebo dynamický web?
Mimochodem, z mých klientů se toho ‚svého‘ Drupalu přihlašuje mírně nadpoloviční většina (a nejsou to rozhodně žádní ajťáci), minimálně přidávat novinky a spravovat fotky. když se to pro klienty maximálně zjednoduší a naučí se ty dvě/tři operace, které potřebují provádět, tak to jde. A s čímkoliv nestandardním volají mě – ale to by volali i u statického webu, i kdyby měli nějaký offline nástroj pro jeho správu.

TO JE JEDNO

Mejme „staticky web“ o 5 stranach. Mejme nasledujici pozadavky na upravu:
– vytvorit a do menu pridat stranky „to je jedno co“ kterou bude sekretarka jednou mesicne aktualizovat
– zmenit nazev polozky menu „O nas“ na „Homepage“

V cem to zvladne cvicena opicka za 2 minuty a v cem bude muset resit jak aktualizovat „o nas“ v 5 ruznych souborech, zjistovat co to je pripojit se na ftp, proc to sakra nefunguje kdyz napsal „o nás.html“ namisto „o-nas.html“?

Pokud firma nema vlastni cvicenou opicku a zavola adminovi, ze chce tuhle zmenu v cem to admin udela rychleji a odkudkoliv ze sveta, treba pres mobilni telefon – v drupalu nebo samo-domo statickem html?

Kalanis

Drupal/Wordpres­s/Joomla taky považuju na podobné stránky za overkill. A jelikož mi nevyhovovaly, tak jsem si naškrábal něco vlastního.
Problém č.1 byla databáze – je to divné, ale občas není – se mi reálně párkrát na malých projektech stalo.
Problém č.2 byly vlastní moduly – z dodávaných mi nic nevyhovovalo a spáchat vlastní bylo též na dlouhé lokte (žádný pevně definovaný vstup a výstup; ppro začátek například pro dump z funkce phpinfo).

František Kučera

Ad „Typický příklad: Stránky truhlárny, včelařství, penzionu, …“

Pro takové případy jsem udělal XML Web generátor (viz také článek tady na Zdrojáku). Souhlasím, že dynamické weby jsou tak trochu mánie a cpou se někdy i tam, kde to nemá opodstatnění — a pak to nadělá víc škody než užitku (nižší bezpečnost, vyšší cena za provoz, nestabilita, přeplácanost…).

Na druhou stranu: spíš než pomalý a nekonsistentní (vzhledově, funkčně) web poslepovaných z různých externích služeb načítaných javascriptem budu mít radši dynamický web, kde se celá stránka načte jedním HTTP požadavkem z jednoho serveru.

Ad „pokud se se svou aplikací přestěhujeme do cloudů“

U statických webů dává použití takových služeb málokdy smysl a spadá do kategorie „vyzkouším si, jak ta nová technologie funguje“. Opodstatnění to má u velkých a často stahovaných souborů, což textové weby nejsou prakticky nikdy (využití to má např. u videa nebo obrazů instalačních CD/DVD).

alancox

Kolem webů se tu na rootu vedou nějaké svaté války. Nejdříve proti tabulkám, pak proti dynamickému webu, předtím zase proti ničemu.

Dynamický web s cachováním může být svou funkcí plně statický web.

Statický web není špatný web – pokud je obsah plně statický. Což je téměř málokdy splněno, pokud vůbec.

Jak čtu diskusi, tak se tu všichni hodlají patlat s nějakými nástroji, kterými doma vygenerují statické stránky z dynamického generátoru.

Není pak lepší mít dynamický web, který je schopen toto udělat a prostě mu zapnout cachování výsledku?

Zase někdo vymýšlí jak se drbat levou rukou za pravým uchem. A vymýšlí ideologii co je správné a špatné – namísto toho aby se řídil praxí a selským rozumem.

MW

Pokud si to vygeneruju u sebe a jenom nahraju statický výsledek někam na web, můžu místo hostingu použít třeba S3, kde je úložiště mnohem levnější než čas CPU. A ve výsledku to může být levnější, než běžný hosting.

Viktor

přesně tak, nebo můžete třeba použít GAE kde je trafic do 1GB zdarma, CPU samozřejmě neřešíte, a to je také plus pro statický web, v případě že se informace mění velmi málo (typicky prezentace, portfolia)

František Sabovčik

Nedávno jsem si kvůli neočekávané absenci databáze musel stáhnout statickou verzi drupalovského webu pres HTTrack a všechno fungovalo jak mělo (během 5m), až na to, že si to klient nemohl editovat online. A právě potom, co se nahrávala „správná“ verze, už se objevovaly různé problémy s nekompatibilitou apod. :- )

František Sabovčik

Tak mě článek nepřesvědčil. Ano, takový statický web můžeme použít u jednoduchých prezentacích, kde je jistota, že si to zákazník sám nebude chtít nikdy měnit a že nikdy nebudeme potřebovat web doplnit o dynamické prvky. Jinde zkrátka ne. Ale článek je psaný formou „to může stačit“, ale zároveň je pravda, že „může stačit“ jednoduché cms.

Obecně mi připomínají některé komentáře skutečně zase nějakou evangelizaci, sházejí mi výhody, jediná reálná výhoda je možná ta cena hostingu v cloudu, zbydou nevýhody (bavíme se o malých webech), ta myšlenka blogu mě pobavila :).

A taky tady někdo chtěl sekat ruce za drupal na malých webech, sice nevím proč, ale skutečně je spíše problém špatného cms – tím myslím špatný výběr cms podle jeho účelu a komplexnosti, která je opravdu u drupalu pro malé weby příliš vysoká, ten web by staticky šel udělat ještě mnohem rychleji, něž pomocí nějakého cms (a bez generování).

Doporučí někdo cms, které by se dalo použít namísto statického webu?

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.