Weblabor

A HTML alapú adattárolás és -megjelenítés számtalan gonddal küzd, ráadásul nagyon kevés olyan fejlesztő vagy döntéshozó van, aki komolyabban foglalkozna velük. Álljon itt egy lista a legsúlyosabbakról, s végül arról, hogyan lehetne a mostani spirálból kikeveredni.

Problémák

Statikus

A HTML az SGML-re épül, amelyet kormányzati és ipari projektek dokumentumainak közzétételére fejlesztettek ki; ezek jellegükből adódóan nem vagy csak nagyon ritkán változnak. Amikor a web a kilencvenes évek vége felé rohamosan kezdett elterjedni, kiegészítették pár aprósággal (CSS), de a nyelv, valamint a böngészők alapvetően továbbra is igazán csak statikus tartalom megjelenítésére voltak felkészítve, és ez igaz a mai napig is.

Statikus például egy Word dokumentum (a HTML elemek elnevezései is mind arra mutatnak, hogy ilyenek létrehozására találták ki) vagy egy .txt fájl, de ilyet elvétve találunk a weben; amint egy oldalon legalább két tartalmi blokk van, amelyeknek más és más a módosítási ideje (például egy menü és egy cikk), ha bármelyik megváltozik, a kódot minden esetben újra kell generálni. Ez jelentős terhet ró a webszerverekre és a programozókra, mert a különböző tartalmi szekciók gyorstárazását (ha egyáltalán foglalkoznak ilyennel) az utóbbiaknak kell megvalósítaniuk. Egy kép vagy egy szkript már most is saját létrehozási, lejárati idővel rendelkezik, így a böngészőnk csak akkor tölti le újra, ha szükséges, de a HTML-ben lévő különböző tartalmi egységeknél ezt kliensoldali szkriptelés nélkül megoldani csak kompromisszumokkal lehetséges.

A legnagyobb problémát a statikusság a webes alapú alkalmazásokban okozza, ahol az adatok állandóan változnak, és amelyeket sokszor nem hagyományos URL-en érünk el, hanem AJAX segítségével töltenek be mindent. Ez felhasználói szemszögből különböző webes szolgáltatásoknál különböző élményt jelent, attól függően, hogy a fejlesztők mennyire profik vagy mennyire fizették meg őket, hogy jó munkát adjanak ki a kezükből. Nagyon nehéz, hacsak nem lehetetlen találni olyan AJAX-os oldalt vagy alkalmazást, amely használhatóságban ugyanazt az élményt nyújtja, mint egy statikus oldal, ehhez sem szabványügyileg, sem pedig a böngészőkben nincs teljes támogatás.

A sablonozás hiánya

Mivel a HTML nem támogatja a sablonok használatát (ugyanannak a dokumentumszerkezetnek a felépítését más adatokkal), a problémára ezer különböző megoldás született: a legtöbbször a szerveroldali keretrendszerekben állítják elő a HTML-t, de az AJAX elterjedésével egyre többször saját adatformátumban küldik az adatokat a kliensnek, például JSON-ban, ez alapján ott készítik el a behelyettesítést és a végleges kódot. Ez utóbbi átlag weboldalaknál (nem web alapú alkalmazásoknál) azzal a hátránnyal jár, hogy a keresők nem mindig tudnak mit kezdeni a kapott adatokkal (sokszor már a lekérdendő adatok URL-jét is szkriptből készítik), valamint ugyanannak a HTML kódrészletnek a generálását legtöbbször két helyen végzik el (először a szerveroldalon az eredeti oldalét, majd később az adatcsere után a kliensen), azaz dupla munka, kétszeres hibázási lehetőséggel. Mivel mindenkinek magának kell a sablonozást megvalósítania, a használhatóságuk nagy szórást mutat.

Az adatok és a megjelenés összefonódása

Első munkahelyemhez 2004-2005 körül ért el a hullám, hogy oldalainkat ne az addig szokásos táblázatokkal készítsük, hanem ami megjelenéssel kapcsolatos, az kerüljön külön CSS-be, ami a működéssel, az pedig (lehetőleg) saját JavaScript fájlba, és az elemeket használjuk arra, amire valók: a listákat tegyük <ul>-be, a címek kerüljenek <h2>-be és így tovább, a cél az, hogy a megjelenést válasszuk el a tartalomtól.

Mivel a HTML-t alapvetően emberi fogyasztásra találták ki, sokszor szükséges bizonyos információk megjelenésének megkülönböztetése a többitől. Hiába kapunk újabb és újabb CSS definíciókat, ilyen esetekben mindenképp plusz markupra van szükség, ami ugyanúgy a megjelenítés része, mint maguk a stílusok, de a nyelv jellegéből adódóan nem tudjuk őket száműzni a dokumentumból. Emiatt sosem lesz olyan HTML oldalunk, ahol a kódban pusztán csak az adatok vannak, és minden, a megjelenéssel kapcsolatos dolog teljesen külön van ettől választva. El kell fogadni, hogy a HTML se több, se kevesebb, mint felületleíró nyelv, és ennek megfelelően kell kezelni.

A metaadatok megadásának korlátozott lehetősége

Kezdetekben a <meta> elemekben volt lehetőség az oldal tartalmáról és kulcsszavairól bővebb információkat megadni, ezeket máig használják, de az utóbbiak sokat nem érnek, mert nem lehet megmondani, hogy a kódunknak pontosan melyik szekciójára vonatkoznak. A kétezres évek elején kezdtek el komolyabban foglalkozni a szemantikus webbel a W3C-nél, de sajnos a fejlesztésük, az RDF(a) nem igazán terjedt el az átlagos weboldalakon, többek között korlátozott elemkészlete miatt (nagyon kevés valós objektumot lehet így leírni, valamint nem egy szervezet kezeli az összeset).

Az ezredforduló után kezdett elterjedni az XHTML (eXtensible HTML), ahol a bővíthetőséggel tervezői azt szerették volna elérni, hogy dokumentumainkban lévő adatainkról többletinformációt adhassunk meg. A koncepció többek között azért bukott meg, mert egyrészt nem volt útmutatás a folyamatra vonatkozóan, nem volt egy központi elemtár, amiből válogathatunk, továbbá a bővítéshez szükséges DTD-k létrehozása nem egyszerű feladat, mellyel a HTML elvesztette egyetlen óriási előnyét, azt, hogy egyszerű, a belépési küszöb alacsony. (Persze ez egyben hátrány is, mert a weboldalak túlnyomó többsége a megvalósítás, használhatóság szempontjából rengeteg kívánnivalót hagy maga után az alulképzett szakemberek és az egyre bonyolódó szabvány miatt).

A mikroformátumok ugyancsak hamar megbuktak, itt is amiatt, mert kevés dolgot lehetett velük leírni. A 2011-ben a Microsoft, a Google és a Yahoo által kezdeményezett schema.org már valamennyivel komolyabb, jelenleg körülbelül ötszáz objektummal dolgozhatunk, ami körülbelül egymilliomod része a Google belső használatra készült 570 milliós adatbázisának. Ez utóbbi tény jelzi, hogy milyen fajsúlyú a probléma, amivel szembenállunk, és hogy a keresőóriás mennyire fog elhúzni a mezőnytől, ha ezt a fegyvert beveti: nem lesz versenytársa, minden az övé lesz.

A jelen

A folyamatok megkoronázása a HTML5, mely épp csak a legégetőbb problémákra nem hoz megoldást. Az újonnan bevezetett elemek nagy része nemcsak redundáns (<header> kontra <div role="header">), de visszafele sem kompatibilis, és az adatok szempontjából nincs szemantikus jelentésük, amivel többek vagy jobbak lennének a korábbi megoldásoknál – így megjelenésük valószínűleg pusztán politikai kérdés. A szabványalkotók munkáját „dícséri”, hogy a role attribútumok mindenképp felülírják a szülőelemük jelentését, például az <article role="button"> segítségével gombot hozhatunk létre, azaz így is könnyen írhatunk olyan kódot, amelynek működése első látásra nem egyértelmű.

Az adatok és a viselkedés szétválasztásának céljával ellentétes az elképzelés, amit ugyancsak itt vezettek be, a data-* attribútumok. Ezeknek annyi a szerepe, hogy az alkalmazásunk számára tárolhatunk bennük további információt, és JavaScript segítségével dolgozzuk fel őket – ennyi erővel kerülhetnének (független) szkriptblokkba. Használatuk további hátránya, hogy elérésük lassú, egy natív adattömbből 30-40-szer gyorsabban lehet kikeresni ugyanazt az adatot, de ha ezt a népszerű jQuery rutinkönyvtár segítségével tesszük, a különbség ezerszeres (!) is lehet.

Miért fontos a szemantikus jelölés?

A napról napra növő internetes adatmennyiséget csak és kizárólag gépileg lehet hatékonyan feldolgozni, így elsődleges feladatunk az kéne legyen, hogy ezt maximálisan támogassuk. Jelenleg a minket érdeklő információnak csak egy apró töredékét érhetjük el, egyszerűen azért, mert nincs időnk eleget keresni. Leggyakrabban gyűjtőoldalakat (pl. portálok) használunk a szűrésre, de ez a lehetőség is korlátozott, ráadásul mások válogatják ki számunkra, hogy mit olvassunk. A modern web egyik fontos találmánya a címkék bevezetése, de ezek mindig csak az adott webhelyen belül működnek, és így sem lehet sok helyen egyszerre egynél többre keresni.

Kellemetlen tényekkel szembesülhetünk, ha megnézzük a statisztikákat: 2003 és 2013 között a webhelyek száma nagyjából megtizenhatszorozódott, míg az egyes oldalakra jutó látogatók száma az ötödére csökkent. Ez azt jelenti, hogy a tulajdonosoknak ötször annyi embert kell megszólítani hirdetésekkel, ha ugyanakkora forgalmat szeretnének. Bár az eszközök fejlődésével nyilvánvalóan rövidebb idő elkészíteni egy weboldalt, azaz csökkenhetnek a költségek, de egy webhely teljes életiklusában ez elenyésző kiadást jelent a marketingkiadások mellett. Ebből következik, hogy a lehető legrosszabb döntés volt a fejlesztők kényelmének kiszolgálása (pl. HTML5) a keresés hatékonyságának növelése helyett.

Jelenleg legfeljebb szövegekben található pár szóra tudunk viszonylag hatékonyan keresni, a webhelyek keresőoptimalizálásakor is általában egy-két szóra fókuszálnak. Node mi intézhető el két szóból? A férfiember, ha szoknyákat kergetni indul, nem csak „szőke nő” az elvárása, hanem továbbiakat is fogalmaz meg: például legyen csinos, házias, cserfes és így tovább. Amennyiben az interneten tárolt adatainkat további jelentéssel ruháznánk fel és egységesen jelölnénk meg, lehetővé válna a szűrésük.

Ezen az elven most is kereshetőek weboldalak, magyarul például az ingatlanokra specializálódott ingatlan.com vagy a széles választékkal dolgozó Árukereső vagy Olcsóbbat.hu, de olyan korlátozással, hogy csak az általuk megadott kategóriákból, valamint a saját rendszerükbe felvitt adatokból lehet válogatni.

Milyen előnyökkel jár, ha az adatokat különválasztjuk a megjelenéstől?

HTML-ben – mivel felületleíró nyelv – még a legjobb szándékkal is csak spagettikódot lehet írni, amiben keveredik a szezon a fazonnal. Aki egy kicsivel is továbblépett a kezdő szintről, tudja, hogy az ilyen átláthatatlan, karbantarthatatlan, és már rövid távon is csak bajjal jár. Ahogy a stílusokat is elválasztottuk a HTML-től (ebből lett a CSS), a viselkedésnél is minden szkript külön fájlba kerül, ha továbbvisszük ezt a logikát, bizony az adatok sem tartoznak a végleges kódba.

A HTML alapvetően egy önző formátum, ahol az adatszolgáltató dönti el, adatait milyen formában tekinthetjük meg. Ez egyrészt amiatt hibás felfogás, mert a dizájn mint divat elég gyorsan változik, ami tíz éve még jól nézett ki, ma már szinte biztosan elavultnak hat. Másrészt a kimenetben az adatok a szolgáltató elképzelése szerint vannak csoportosítva, sorrendezve, más van kiemelve, s ezek nem feltétlenül egyeznek meg azzal, amire az adat igénylőjének szüksége van.

A mikroformátumokat úgy találták ki, hogy meglévő HTML kódunkat „díszítsük” fel, és jelöljük meg, hogy melyik adat mit jelent. Ez alapvetően jó is lenne, csak a kivitelezésnél derül ki, hogy igazából hatékonyan csak a gépileg előállított adatokat lehet szemantikusan megjelölni, az ugyanis nem várható el egy folyószöveg (például blogbejegyzés) írójától, hogy a végleges anyag HTML kódján végigmenjen minden szón, és adja meg, hogy mi milyen objektumot takar. Emellett a HTML-ben rengeteg olyan elem van, aminek dokumentumstrukturálási szerepe van (<header>, <aside>, <span>), azaz a feldíszített kódból több munkával jár a szemantikus objektumok összegyűjtése, mintha helyből egy külön adatfájlban, strukturáltan lenne minden adatunk megadva. Amennyiben adatainkat különválasztjuk a HTML-től, rákényszerülünk arra, hogy szemantikusan megjelöljük, mi mit jelent, míg abban az esetben, ha a HTML-nél maradunk, Pató Pál szelleme fog kísérni minket munkánk során.

Ha adatainkat „beleégetjük” a HTML-be, akkor azokat leginkább csak böngészőn keresztül tudják megnézni, pedig a felhasználók részéről egyre növekedik az igény, hogy más platformokon is elérhessék azokat. A mobileszközök hardveres korlátai (teljesítmény, memória, akkumulátorkapacitás) miatt megnőtt az igény a natív alkalmazásokra, így a fejlesztésnél rengeteg időt spórolhatunk meg, ha adatainkat különválasztjuk a megjelenítéstől, hogy bármilyen szoftverkörnyezetből könnyedén elérhessük azokat.

A weben ma már egyre kevésbé a HTML az alapvető kommunikációs forma. Ez persze nem azt jelenti, hogy mindenkinek pusztán csak adatokat kell küldeni, a buta klienseknek – mint például a böngészők – segítséget kell adnunk a megjelenítéshez.

Internet of Things

Sok gyártó nagy terve, hogy (háztartási) eszközeiket rákössék az internetre, amelyek így kommunikálni tudnak velünk és egymással. Ez sok előnnyel járhat, például egy jól koordinált rendszerben jelentős mennyiségű energiát takaríthatunk meg, mert például csak akkor fűtünk, amikor szükséges, hűtőnk nyilvántarthatja, miből mennyi van benne, azok szavatossága mikor jár le, és üzenetben tájékoztathat minket, hogy legközelebb mit vásároljunk a boltban és így tovább. Összességében ezek az okosnak titulált eszközök csökkentik a gondolkodásra szánt időnket, amit így sokkal kellemesebb és kevésbé megerőltető tevékenységekre fordíthatunk, például fogyasztásra, így más iparágak is fellendülhetnek ettől a technikai forradalomtól.

Ami ebből minket, fejlesztőket érint, hogy mivel a weben keresztül folyik a kommunikáció, érdemes lesz egy közös nyelvet találni a feladatra. A HTML többek között a fentebb említett tulajdonsága, az adatok és a megjelenés szét nem választása miatt erre nem a legalkalmasabb. Emellett a kazánomat nem érdeklik a <header> és <footer> elemek, de a hűtőmet sem hozzák lázba a legkörültekintőbben megírt JavaScript kódok. Ezeket a háztartási eszközöket nem cserélik le kétévente, a gyártók így egyszerű, hosszú életű megoldásokra törekednek. A legtöbbjük wifi segítségével, esetleg az elektromos hálózaton keresztül tartja a kapcsolatot, így irányításukhoz elegendő egy tablet vagy egy telefon. Elég, ha pusztán adatokat küldünk és fogadunk tőlük, így visszatértünk az előző fejezet problémájához, hogy azoktól válasszuk külön a megjelenítést.

Ha mindez megvalósul, a weben a forgalom egyre kisebb része lesz az, amit emberek bonyolítanak le böngészőkkel, és egyre többet kommunikálnak egymással a gépek. Emiatt célszerű lenne ezt fejleszteni, a HTML-t pedig lecsupaszítani a szükséges minimumra, hogy a lehető legkevesebbet kelljen vele foglalkoznunk.