ugrás a tartalomhoz

Irányváltás

Hidvégi Gábor · 2015. Jan. 7. (Sze), 13.17

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.

 
1

Sablonozás

Poetro · 2015. Jan. 7. (Sze), 14.17
Azért a HTML5-be bekerült a <template> elem és az ECMAScript 6-ba pedig a Template string. Szóval lassan, de haladunk előre ebben a tekintetben.
2

Sablonozás

Hidvégi Gábor · 2015. Jan. 7. (Sze), 15.10
Egy normális sablonnyelvben vannak ciklusok, értékek automatikus hozzárendelése HTML elemekhez stb. A template elem semmiben sem segít, a sablonozás logikáját ugyanúgy nekünk kell megírni, azaz egy jottányit sem vagyunk előrébb, mint eddig.
3

Logika

Poetro · 2015. Jan. 7. (Sze), 15.23
Szerintem nem várhatjuk el egy leíró nyelvtől hogy összetett logikát tartalmazzon a sablonozáshoz. Azt hagyjuk meg egy programozási nyelvnek.
4

+1 / ♥ /

kuka · 2015. Jan. 7. (Sze), 16.08
+1 / ♥ / lájk
6

Gyakorlatilag minden

Hidvégi Gábor · 2015. Jan. 7. (Sze), 18.03
Gyakorlatilag minden oldalletöltésnél sablonozunk, vagy szerver- vagy pedig kliensoldalon, hisz a statikus dokumentumok ritkák a neten. Emiatt célszerű lenne egy egyszerűen és általánosan használható sablonrendszert használnunk, hogy erre több erőforrást ne kelljen pazarolni. Ez ugyanolyan, mint ahogy a CSS-ben megjelentek a leggyakrabban használt Photoshop effektek, a HTML-be is be lehetne venni ezt a feladatot.
17

+1, szerintem is teljesen

inf3rno · 2015. Jan. 8. (Cs), 14.08
+1, szerintem is teljesen felesleges, arra van a js kliens oldalon és a szerver oldali programozási nyelvek. Vagy dobjuk ki a js-t, és tákoljunk 10-20 év alatt egy teljesen új nyelvet, ami sablonozásból növi ki magát, mint pl a PHP?! (Hát kösz, de nem!)
5

Példa

Pepita · 2015. Jan. 7. (Sze), 16.49
Jórészt igazad van, jó, részletes írás.
Viszont hiányolom a példát, valami egyszerűbb eseten keresztül bemutathatnád: te hogyan csinálod az adatok szétválasztását?

És egy aprócska megjegyzés:
esetleg az elektromos hálózaton keresztül tartja a kapcsolatot
Ez kb. soha nem fog megvalósulni, akkora a zavarszűrési probléma. Olyan lenne nagyjából, mintha minden szállítójármű nélkül szeretnél átvinni a Csendes Óceán egyik partjáról a másikra egy csepp étolajat.. :)
(Annyira nagy nagyságrendben is a hálózat és a net közötti feszültség- és áramerősség-különbség.)
7

Viszont hiányolom a példátÍgy

Hidvégi Gábor · 2015. Jan. 7. (Sze), 18.07
Viszont hiányolom a példát
Így is nagyon hosszú lett az írás, a példa majd egy következő cikkbe fog kerülni.

»esetleg az elektromos hálózaton keresztül tartja a kapcsolatot«
Ez kb. soha nem fog megvalósulni
powerline
8

+1 -1

Pepita · 2015. Jan. 7. (Sze), 20.19
A példát megvárom, a linkelt cikkben arról van szó, hogy wifis eszköz vezérel 230V-ot, nem a háztartási áram vezetékén kommunikál. :)
9

Vonalas telefon

Gixx · 2015. Jan. 8. (Cs), 09.47
A régi vonalas telefon hálózaton tudtommal a készülék ugyanonnan kapta az áramot, amin a kommunikáció is folyt...
10

A linkelt oldal egy

Hidvégi Gábor · 2015. Jan. 8. (Cs), 10.04
A linkelt oldal egy felsorolás a prohardver olyan cikkeiről, amelyek elektromos hálózaton keresztüli ethernet kommunikációt megvalósító eszközökről szólnak.
16

Igaz

Pepita · 2015. Jan. 8. (Cs), 14.03
Bocs, csak az elsőt olvastam..
Hát, van már csónak az óceánhoz mégis, csak még én nem láttam...
Ezek az eszközök elektromos hálózaton keresztül továbbítanak adatot 200 Mbps elvi csúcssebességgel.
Mondjuk az elvi és a (gondolom magyarországi) teszt sebesség közt van nagyságrendi különbség még... Elég combos zavarszűrő lehet.
147

miért?

Szigyártó Mihály · 2015. Feb. 3. (K), 15.51
Érdekel, hogy szerinted miért lenne olyan zajos a kommunikáció? Maga az áram nem sokat zavar, teljesen jól szűrhető a többitől. Az rendben van, hogy nem egy csavart érpár, meg nem is koax kábel, de mondjuk egy wifihez képest nem hinném, hogy több zajjal kéne számolni.
148

Gyorsabb

Poetro · 2015. Feb. 3. (K), 16.06
Egyébként ma már nem csak 200, hanem 500, 600, 1000 sőt 1200Mbps-es powerline adapterek is vannak (ZyXel, TP-Link, Netgear, TRENDnet).
11

elektromos hálózaton egy

szabo.b.gabor · 2015. Jan. 8. (Cs), 11.06
elektromos hálózaton egy háztartáson belül, a mérőóráig. és itt találnak egy routert.
150

ilyen már régóta van

Mikulasche · 2015. Feb. 11. (Sze), 12.51
A televíziós - broadcast - technológiában, már több évtizede gyakorlatban
működik olyan rendszer, ahol 3 szálú vezetéken megy minden.

Nagy stúdiókamerák esetén ez így működik.

A három szál vezetéken megy a tápfesz, a kép, a fülhallgató hangja, a súgógép
képe a ccu vezérlése /optika és írisz mozgatás/

ld. részletesebben frekvencia és ampitúdó moduláció

Tudom, ez programozás-nyelv téma, csak mellesleg jegyzem meg.
151

Nem rosszabb, mint az én

inf3rno · 2015. Feb. 11. (Sze), 19.36
Nem rosszabb, mint az én csobogós projektem, aminek még ennyi köze sincs a témához. :-)
12

Szerintem

szabo.b.gabor · 2015. Jan. 8. (Cs), 11.36
A fejlődés, vagy élet, folyamatok valahogy úgy működnek, hogy a legkisebb ellenállás felé mozdulnak el, aki kevés energiát fektet be, az is tud érvényesülni, aki többet, az is, csak maximum más szintre jut el, vagy nagyobb, keserűbb ajándékot kap a szájába.

az emberek, emberekkel akarnak kereskedni, emberekkel akarják közölni a gondolataikat. ha egy adott eszköz alkalmas erre, használják.

létrehozhatsz szuperobjektumokat, szabványokat a gondolatok leírására. ezek használata komoly tudást igényel, valamint egy-egy dolognak sok nézőpontja lehet ha leírod egy struktúrával, ha valaki más miatt keresi az adott tartalmat, nem fogja megtalálni.

azt sem várhatod el, hogy a kis energiával létrehozott dolgok ne működjenek, működhessenek, ha megfosztod a html-t ettől a tulajdonságától, akkor kialakul helyette egy ugyanilyen.

valamint egy kereső sosem lesz jó, ha csak profin létrehozott tartalmakat tol eléd, mert a 'külcsíny' a pénzzel arányos, nem a tartalommal.

ha van az iparnak egy meghatározott csoportja akik jól megfogható dolgok mentén működnek együtt, akkor alakítsanak ki közös szabványt munkájuk megkönnyebbítésére, ha nem elégedettek az adott folyamat hatékonyságával.

nincs egy jó megoldás, nem rossz a html, csak organikus :)

szerintem.
13

Nem állítom, hogy a HTML per

Hidvégi Gábor · 2015. Jan. 8. (Cs), 11.59
Nem állítom, hogy a HTML per se rossz lenne, csak azt, hogy ma már láthatóan többre (vagy kevesebbre) van szükség, mint amit nyújtani képes. Az adatok egyre többek számára fontosabbak önmagukban, a hozzájuk ragasztott megjelenítés pedig kevésbé.
15

A html, css, js szerintem

szabo.b.gabor · 2015. Jan. 8. (Cs), 13.56
A html, css, js szerintem alkalmas információ megjelenítésére, felhasználói felület készítésére, továbbfejleszthető, optimalizálható, nyílt!

a felhasználókat nem érdekli mi módon jutnak el hozzájuk az adatok, a megrendelők is hoznak döntéseket, vagy tudják hogy miből választanak, vagy nem.

Semmi sem akadályoz meg abban, hogy a szerverről elküldött strukturált adathalmazból állítsd elő a html-ed, pl ahogy tetted azt valamelyik wl sörözés jelentkezésénél. De kit érdekel? :)

Tehát saját magad olyan struktúrát alkalmazol, amilyet akarsz. Adott esetben gazdasági partnereddel szintén olyan struktúrát használsz amilyent akarsz. Miért akarná bárki is ezt beledobni a világba? Vagy mi lenne ezáltal jobb? nem teljesen értem.

Nem látom át, a nagy pozitív hozadékát, nem hiszem hogy nem sérülnének érdekek. No mindegy, bocs nem akarom szétoffolni a cikkedet, kíváncsian várom a folytatást.
18

Nem mindenki HTML-ben várja

Hidvégi Gábor · 2015. Jan. 8. (Cs), 14.20
Nem mindenki HTML-ben várja az adatokat. A felhasználót nem érdekli, mi van a háttérben, de a gyártókat igen.
19

A felhasználót nem érdekli,

inf3rno · 2015. Jan. 8. (Cs), 14.32
A felhasználót nem érdekli, mi van a háttérben, de a gyártókat igen.


Ezt kifejtenéd?
21

Lásd az írás utolsó

Hidvégi Gábor · 2015. Jan. 8. (Cs), 14.39
Lásd az írás utolsó bekezdését.
26

Ohh. Hát be lehet szórni egy

inf3rno · 2015. Jan. 8. (Cs), 15.48
Ohh. Hát be lehet szórni egy javascriptes REST service-t vagy egy nodejs-es websocket-es csodát a kazánba, aztán csókolom. Mindegyik elmegy egy olcsó single board computeren, csak az áram szolgáltatás meg ne szakadjon. ;-)

Egyébként ezekkel már sokan csinálnak automata öntöző rendszert, és hasonlókat. Ha megengedhető a néhány másodperces késés (szóval nem annyira fontos, hogy realtime legyen a vezérlése a dolgoknak), akkor teljesen működőképes és olcsó megoldások.
14

+1

bamegakapa · 2015. Jan. 8. (Cs), 13.26
Nagyon elgondolkodtató mondatok.
20

az emberek, emberekkel

Hidvégi Gábor · 2015. Jan. 8. (Cs), 14.38
az emberek, emberekkel akarnak kereskedni, emberekkel akarják közölni a gondolataikat. ha egy adott eszköz alkalmas erre, használják
Nem véletlenül linkeltem be az ~ aktuális statisztikát a weboldalak és az internethasználók számáról. Ez alapján nyilvánvaló, hogy egyre kevesebb gondolat jut el egyik embertől a másikig, egyre kevesebben találják meg az adott terméket, mert egyre nagyobb a választék. Ha megnézed a google-t, a binget vagy bármelyik keresőt, az egy oldalon lévő összes találat negyede fizetős, tehát ennyivel is csökken a te megrendelőid esélye, hogy eladjanak bármit.

létrehozhatsz szuperobjektumokat, szabványokat a gondolatok leírására. ezek használata komoly tudást igényel, valamint egy-egy dolognak sok nézőpontja lehet ha leírod egy struktúrával, ha valaki más miatt keresi az adott tartalmat, nem fogja megtalálni
Ha adatokban is lehet, az csak kiterjeszti a lehetőségeket, de a szöveges keresés lehetősége megmarad. Tehát csak nyerni lehet vele.

azt sem várhatod el, hogy a kis energiával létrehozott dolgok ne működjenek, működhessenek, ha megfosztod a html-t ettől a tulajdonságától, akkor kialakul helyette egy ugyanilyen
A HTML az adatok megjelenítésének egy médiuma. Erre is szükség van, viszont nem mindenkinek.

ha van az iparnak egy meghatározott csoportja akik jól megfogható dolgok mentén működnek együtt, akkor alakítsanak ki közös szabványt munkájuk megkönnyebbítésére, ha nem elégedettek az adott folyamat hatékonyságával
Nem igazán értem, hogy jön ez ide.
22

Csak az utolsó részre reagálnék

szabo.b.gabor · 2015. Jan. 8. (Cs), 14.58
Nem igazán értem, hogy jön ez ide.


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.


Nincs sehol sem html alapú adattárolás.
A megjelenítéssel nincs gond.

Kevés fejlesztő / döntéshozó foglalkozik ezzel, mert kevés fejlesztőnek / döntéshozónak okoz problémát.

Ha az ipar egy részének gondot okoz az adatcsere, üljenek össze csinálják meg maguknak (pl gagyi példával akár árgép, stb.). vagy ha az állam támogatni szeretne egy területet fektessen le B2B szabványokat (persze fontos hogy csinálja jól, és vonja be a szereplőket).
23

Nincs sehol sem html alapú

Hidvégi Gábor · 2015. Jan. 8. (Cs), 15.33
Nincs sehol sem html alapú adattárolás.
Ha böngészőben lekérsz valamit, akkor 99%-ban HTML-t kapsz vissza, innentől kezdve a weben a HTML egy adattárolási forma.

Kevés fejlesztő / döntéshozó foglalkozik ezzel, mert kevés fejlesztőnek / döntéshozónak okoz problémát.
Ez az írás azért született, hogy felhívja erre a figyelmet. Irányváltás szükséges, mert amíg mi, fejlesztők a saját kényelmünkkel vagyunk elfoglalva, addig konkrét károkat okozunk a megrendelőinknek és a (potenciális) látogatóiknak.
24

Információközlési forma. Az

pythonozok · 2015. Jan. 8. (Cs), 15.40
Információközlési forma. Az adattárolás (szerintem) mást jelent.
És már régebben is említettük páran, ha jól emlékszem: a weblapok üzemeltetőinek egyáltalán nem érdeke a legtöbb esetben, hogy feldolgozható formában adja át az információt, mert abból neki kára származhat.
27

HTML-t is lehet alkalmazni

inf3rno · 2015. Jan. 8. (Cs), 15.50
HTML-t is lehet alkalmazni adattárolásra, csak nagyon alacsony hatékonysággal mondjuk egy JSON-hoz képest. ;-)

(Nyilván pont ezért nem is használják rá, csak adat közlésre, hogy REST-es szószedettel éljek, reprezentációs formátum.)
28

Legalább harmadszor említed a

Hidvégi Gábor · 2015. Jan. 8. (Cs), 16.12
Legalább harmadszor említed a REST-et. A cikk pont erről szól, hogy a HTML egyre kevésbé a web kizárólagos nyelve.
31

Talán azért említem, mert

inf3rno · 2015. Jan. 8. (Cs), 22.41
Talán azért említem, mert releváns. Természetesen a cikk erről szólt, de nem a cikkhez szóltam hozzá, hanem az előző hozzászólásodhoz és pythonozok rá adott válaszához.
29

És akárhányszor leírtad a

Hidvégi Gábor · 2015. Jan. 8. (Cs), 16.13
És akárhányszor leírtad a fenti válaszodat, annyiszor írtam én rá, hogy ha valami kinn van a neten, csak idő kérdése, hogy megfelelő algoritmussal az adatokat kinyerjük a HTML-ből. Tehát azzal nem védesz meg semmit, ha HTML-be "kódolva" adod ki.
30

Megfelelő algoritmussal.

pythonozok · 2015. Jan. 8. (Cs), 16.23
Megfelelő algoritmussal. Kérdés, hogy megéri-e a fáradságot.
Én pl. szívesen leszedném a tévéműsort valahonnan XML formában, ha megbízható forrásból származna, de arra nem vagyok kapható, hogy a port.hu oldalaira parsert írjak.
38

Tapasztalatok

complex857 · 2015. Jan. 9. (P), 12.03
Megfelelő algoritmussal. Kérdés, hogy megéri-e a fáradságot.

Szeretném egy konkrét példával demonstrálni, hogy miképp nézhet ki egy ilyen project: Történt ugyanis, hogy ~2 éve megelégeltem vim-ben található PHP omni-complete adta találatok minőségét főleg, hogy mennyire hiányosak a beépített függvények, osztályok, konstansok listái.

Körülnézve a php.net-en nem találtam adatbázist vagy direkt csak gépi feldolgozásra szánt formában meg ezeket az információkat, az egyetlen teljesnek tekinthető adatforrásnak a letölthető xhtml fileok bizonyultak. Ez összesen ~12 ezer fájlt jelent, pár relatíve szabványos oldal formátumot és rengeteg kis kivételt. Az elkészült feldolgozó csak hozzávetőleges pontossággal és elég sok próbálkozás árán összerakosgatott xpath halomként született meg (pl). A kimenet valami ilyesmi a feldolgozás után, de kód futás közben rendelkezik minden paraméterhez külön adatszerkezetekkel.

Végeredményről elmondható, hogy működik, de xhtml ide vagy oda elég fájdalmas ezekkel dolgozni (bár nem annyira mint amennyire elején féltem tőle) annak ellenére, hogy a fileok legalább részben gépi generáltnak tűnnek (feltételezem extension-ök kódjából) és számomra érdekes részei többnyire mentesek az emberi hibáktól.

U.I.: Érdekes, hogy pont a port.hu-t hoztad fel példaként mert személyesen ismerek olyat aki port.hu-nál dolgozott és folyamatosan arra panaszkodott, hogy mindenki az oldalt crawlolja és felzabálják szervereik erőforrásait (és persze így nem nézik a reklámokat...) Pl.: OSX-es porthu widget. A TV műsorból csinál XML-t egyébként backendje (nem tudom mennyire publikus ez mondjuk, a widget kódjában talátam).
40

Nem tudtam, hogy vannak ilyen

pythonozok · 2015. Jan. 9. (P), 12.36
Nem tudtam, hogy vannak ilyen problémák a port.hu-nál. Ha megszüntetik egyszer a régit, azt hiszem, meg fog szűnni, mivel az új... azt hiszem, a felhasználókat is elüldözi, nem csak az automatákat. :)
(tévedés joga fenntartva)

Ha már most is sok az automatizált "nézelődő", képzeld mi lenne, ha valóban olyan formában jelenne meg, hogy elég egy XML-t lekapni, nem kell utólag kibányászni a sok szemét közül a lényeges adatokat!

Szóval továbbra is ott tartok, hogy feleslegesnek érezném a nyers adatokat publikálni, ha látogatókat akarok az oldalamon és nem automatákat.
45

Ez azt hiszem inkább hibás

inf3rno · 2015. Jan. 9. (P), 15.29
Ez azt hiszem inkább hibás üzletpolitika eredménye. Csinálniuk kéne egy API-t egy crawler példával esetleg egy andoidos alkalmazással és fizetőssé tenni olyan áron, hogy megérje nekik, és a felhasználók se tántorodjanak el tőle, mittomén egy ezres egy év.
32

Ha böngészőben lekérsz

inf3rno · 2015. Jan. 8. (Cs), 22.49
Ha böngészőben lekérsz valamit, akkor 99%-ban HTML-t kapsz vissza, innentől kezdve a weben a HTML egy adattárolási forma.


Nem szeretnék különösebben belemenni ebbe az agyrémbe, de az oldalak nagy részét adatbázisban tárolt adatokból generálják a weben, így a HTML egyáltalán nem adattárolási forma. Maximum adattovábbításra használják, de valamikor még erre sem, pl amikor visszaírják, hogy hiba történt a kérés feldolgozása során, vagy 404, az oldal nem elérhető. Ilyenkor nem a szerver által tárolt adatokat továbbítják, hanem csak állapotot, amibe a kérés feldolgozása során jutott a szerver. (Természetesen a HTML felhasználható adattárolásra is, de mivel pocsék benne, ezért senki nem fogja ilyesmire használni. Nem véletlenül megy annyira nyögve nyelősen a szemantikussá tétele.)
39

Igen, amennyire én tudom, a

bamegakapa · 2015. Jan. 9. (P), 12.08
Igen, amennyire én tudom, a HTML egy Markup Language. Nem vagyok egy CS zseni, ezért javítsatok, de egy markup language tudtommal dokumentumok leírására szolgál. A HTML5 azért jó, mert ezt a feladatot jobban oldja meg, mint az eddigiek. Ha az a cél, hogy adatokat továbbítsunk gépek számára könnyen értelmezhetően és struktúráltan, nem hiszem, hogy a HTML erőszakolása lenne a megfelelő irány, hiszen a HTML dokumentumokat ír le (amelyek alapvetően emberi fogyasztásra vannak szánva, de a dokumentum struktúráját nyilván gépek is értelmezni tudják, ha megfelelően van elkészítve - a dokumentumét, nem a benne felhasznált adatokét!).

Ha az oldal készítője ezt megfelelő iránynak tartja, publikálhatja a HTML dokumentumok elkészítéséhez felhasznált adatokat gépek számára könnyen feldolgozható formátumban is.
46

Pontosan. Egyébként microdata

inf3rno · 2015. Jan. 9. (P), 15.33
Pontosan. Egyébként microdata meg RDFa helyett lehetőség van arra, hogy JSON-LD formában a HTML-be ágyazzuk ezeket az adatokat, pl http://www.seoskeptic.com/json-ld-google-knowledge-graph-schema-org-seo/. Nyilván a google fel van készítve tiszta JSON-LD-re is, amit a schema.org elemeivel annotáltunk fel. Azt nem tudom, hogy a többi linked data szószedetet mennyire támogatja. Amit eddig láttam, abból arra következtetek, hogy egy részüket nagy valószínűséggel igen.
47

Absztrakció

Hidvégi Gábor · 2015. Jan. 9. (P), 15.46
Egy winchesteren sem elektromos formában tárolják a biteket, hanem mágneses elven, de amikor onnan kérsz adatot, akkor mégis egy bitkolbászt kapsz vissza. Teljesen indifferens, hogy a szerveren adatbázisban vagy fájlokban tárolják az adatokat, a lényeg, hogy egy HTML dokumentumot kapsz vissza. Emiatt a web adattárolási nyelve a HTML.
48

Értem, hogy mire akarsz

inf3rno · 2015. Jan. 9. (P), 15.52
Értem, hogy mire akarsz kilyukadni, ha úgy vesszük tekinthetjük a webet egy hatalmas adattárolónak, ami a kéréseinkre adatokat ad vissza HTML formában. Ennek egyik előnye, hogy a végeredmény emberek számára értelmezhető, a hátránya meg, hogy gépileg nehezen feldolgozható. Nem véletlenül terjednek a gépileg könnyen feldolgozható formátumok, ATOM+XML, plain JSON, HAL+JSON, JSON-LD, stb... ha arra van szükség, hogy gépi klienseket szolgáljunk ki.
33

Összességében nagyon

inf3rno · 2015. Jan. 8. (Cs), 22.53
Összességében nagyon egyetértek.
25

Imho. az elmúlt 20 év

inf3rno · 2015. Jan. 8. (Cs), 15.43
Imho. az elmúlt 20 év legnagyobb fejleménye, hogy a HTML fejlesztői végre rájöttek, hogy a nyelv minden komolyabb változtatásnak ellenáll (lásd XFORMS, XSLT, RDFa, és így tovább). Egyszerűen csak statikus dolgok megjelenítésére alkalmas, semmi többre, és ha ha megpróbáljuk másra használni, akkor baromi kényelmetlen dolgokat kapunk a nyelv öröklött tulajdonságai miatt. (Más nyelvekben a string-et külön token-ekkel választjuk le, pl quote, double quote, a HTML-ben viszont minden mást választunk le </>-el a string-ről. Első ránézésre ez inkább a sablonnyelvekre hajaz szerintem, amik nem kimondottan alkalmasak komolyabb programok irására.)
Szerintem nagy előrelépés, hogy végre elfogadták, hogy a HTML az, ami, és a HTML5-ben ilyen téren próbáltak fejleszteni a nyelven, és egyértelműsíteni, hogy melyik tag, mit jelent. Pl a header, video, audio, svg, stb... tag-ek nekem nagyon tetszenek, sokkal egyszerűbb velük dolgozni, mint a HTML4-es megfelelőikkel. Amit sajnálok, hogy a régi berögződéseket, pl az egyes tag-ek önkényes rövidítését p(aragraph), div(ision), b(old), i(talic), s(trike), br(eak), stb... nem sikerült elfelejteni, holott egyik sem hosszabb, mint mondjuk a blockquote, amit csodák csodája, nem bq-val jelölnek. A visszafele kompatibilitást én egyáltalán nem tartom problémának, hiszen 5.0-s verzióról van szó, és aki kicsit is tájékozott ilyen téren, az tudja, hogy a major verzió váltás visszafele nem kompatibilis dolgok bevezetésénél indokolt.

Amit én most trendnek látok, hogy minden js felé tolódik el, mert az egy programozási nyelv, és ténylegesen egyre inkább az a web nyelve, szemben a HTML-el és CSS-el, amiket csak adat megjelenítésre használnak. Js-nél a felsorolt problémákra, mint pl: model-view szétválasztás (backbone, angular, knockout, stb...), metaadatok leírása (JSON-LD - RDF formátum), sablonok (pl mustache), kommunikáció (AJAX, WebSockets), stb... már léteznek jól működő, vagy kiforróban lévő megoldások.

A szemantikus web és a webalkalmazások közötti ellentmondást JSON-LD + Hydra + REST alapon lehet feloldani. Ebből a HTML részt a JSON-LD + Hydra + (egyedi) Hydra kliens, ami helyettesíti. A JSON-LD az adatokat és a metaadatokat tartalmazza. A metaadatokat RDF vocab-okhoz, pl schema.org vagy Hydra vagy más (open) linked data vocab-ok köti, így azok alkalmasak lesznek gépi feldolgozásra feltéve, hogy a feldolgozó program ismeri az adott vocab szókészletét. A Hydra egy RDF vocab, és hamarosan egy W3C szabvány is lesz a REST webalkalmazások leírására. Amiért leginkább szükség van rá az a hyperlinkek (és űrlapok) megjelölése, így a Hydra (REST) kliens tudni fogja, hogy milyen linkeket tud követni. Ez roppant fontos, ha gépi klienseket, pl keresőrobotokat akarunk kiszolgálni. Gyakorlatilag 100%, hogy a google támogatni fogja a Hydra-t is ugyanúgy, mint a JSON-LD-t. Amint a szabványosítás befejeződött, el lehet kezdeni webalkalmazásokat írni ezzel a technológiával, és hozzájuk klienseket. Ezek a kliensek lehetnek hagyományos böngészőben írt AJAX-os kliensek, vagy keresőrobotok, vagy felolvasó programok (akadálymentes web), vagy magasabb absztrakciós szintű webalkalmazások. A szabványosítás szerintem még 1-2 év, utána valószínűleg néhány éven belül már nem nagyon lesz más stílusban írt webalkalmazás, ha a websocket és a hagyományos HTML alapúakat nem számítjuk. A jelenlegi külföldi trendek is olyanok, hogy mindenki REST-ben próbál tákolni (csak sajnos a megfelelő tudás hiányában), viszont ezt a problémát a szabványosítás és tutorialok írása teljes mértékben fel fogja oldani. Hosszú távon (20 év) ez a folyamat valószínűleg elvezet a mesterséges intelligencia megalkotásához, mert az internet ki tudja szolgálni az ahhoz szükséges roppant számításigényt (a REST a teljes webre skálázható), illetve a linked data cloud képes a hozzá szükséges metaadat gráf leírásához. Igazából ez nem is akkora meglepetés, ha azt vesszük, hogy az egész szemantikus web koncepciót mesterséges intelligencia megalkotásához találták ki, és jóval többről szól pusztán a kereshetőségnél.

Így látom én a jelenlegi trendeket.
37

Köszönöm

bamegakapa · 2015. Jan. 9. (P), 11.53
Ez az egy hozzászólásod konstruktívabb, mint Gábor elmúlt években született összes hozzászólása a témában, melyeknek összefoglalója ez a mostani blogbejegyzés. Annyira nem voltak pótolhatatlanok, hogy az is mindenképp olvashassa, aki a fórumban nem botlott bele rendszeresen. Vannak benne érdekes problémafelvetések, mint mindig. Ugyanazok, mint mindig. Szerintem ennyire nem kellenek mindenáron cikkek a Weblaborra.
34

Újdonság?

T.G · 2015. Jan. 9. (P), 09.09
Becsülettel végigolvastam ezt a cikket is, ám szerintem ebben az égvilágon semmi új információ nem volt. Aki csupán felületesen olvasgatja a WL-t, az is ismeri Gábor problémáit a HTML-lel. A bevezetőben említésre került kikeveredésre meg még utalást sem találtam. Az a baj ezekkel a cikkekkel, hogy semmi előremutatást nem ad, a problémák eltúlzottak, megállapításai felületesek, összességében nem többek, mint felesleges hangulatkeltés.

Két és fél évvel ezelőtti cikkben rákérdeztem, hogy tudnánk-e konkrétumokról beszélni, de azóta sem jutottunk el oda. Még ma is ott tartunk, hogy "fel kell hívni a problémára a figyelmet", szerintem ezen már túlléphettünk volna. Ennél még a HTML5-öt is gyorsabban véglegesítették!

Azt gondolnám, hogy mindenki számára teljesen egyértelmű, hogy a HTML megjelenítésre szolgál. Ha majd a hűtőszekrény kijelzőjén lesz alul egy sáv, amely a hőmérsékletet fogja jelezni, és tetszőleges képernyőn fixen ott lesz, akkor azt a footer tag-be tesszük. Nem látom, hogy ezzel mi a gond. Ám, ha nem tetszik a footer tag, akkor ne használd, senki nem fog megszólni miatta.

JQuery a maga egyszerűségének köszönhetően méltán népszerű, de ma már azt gondolnám, hogy mindenkinek egyértelmű, hogyha sebességre érzékeny feladattal szembesül, akkor arra a feladatra nem ezt használja. Számtalan gyorsabb alternatíva létezik, illetve sok kezdeményezés létezik arra, hogy ha lehet, akkor használjuk natív JavaScript-et. Ma már nem mondjuk azt, hogy irányváltás szükséges, mert lassú a JQuery. 4-5 évvel ezelőtt ez még meglepő mondat lehetett, de ma már komolytalan, hogy a JQuery lassúságával indokoljuk az irányváltás szükségességét.

Az is egyértelmű, hogy az adatokat különválasztjuk a megjelenítéstől. Ám ez már húsz évvel ezelőtt is alapértelmezett volt. Itt sem látom, hogy szükséges lenne irányváltás. Engem perpillanat egyáltalán nem zavar, hogy ebből a különválasztásból a látogató semmit sem lát. Egyáltalán nem érzem problémának, hogy a végleges HTML oldalon a felhasználók nem tudják könnyedén szétválasztani az adatokat a megjelenítéstől. Szeretném kihangsúlyozni, hogy ezzel sem a felhasználóknak, sem az ügyfeleknek nem okozok kárt. Teljesen felesleges ilyen nagy szavakkal dobálózni, az még tényleg bosszantó, hogy továbbá lustasággal vádolod azokat a fejlesztőket, akik nem az általad elképzelt módszertanokat használják. Ám ismét megjegyzem, hogy nem is ismert az általad helyesnek elképzelt megoldás, mert állandóan csak az a téma, hogy a jelenleg népszerű trendek miért nem tetszenek neked.

Bár nem először, és valószínűleg nem is az utoljára, ám mégis fontosnak tartom megemlíteni: Sokkal jobb lenne, ha nem arról szólnának a cikkek, hogy mi miért nem jó, mi miért nem használható, hanem arról, hogy mit használjunk, miként használjuk.
35

szerintem ebben az égvilágon

Hidvégi Gábor · 2015. Jan. 9. (P), 10.02
szerintem ebben az égvilágon semmi új információ nem volt. Aki csupán felületesen olvasgatja a WL-t, az is ismeri Gábor problémáit a HTML-lel
Azok szét vannak szórva a fórumban, itt egyben található meg az egész gondolatmenet. Nem kell mindennek újnak lennie.

A bevezetőben említésre került kikeveredésre meg még utalást sem találtam.
A HTML statikus, nem támogatja a sablonozást, az adatok keverednek a megjelenítéssel, és az adatokról nem tudjuk normálisan megadni többletjelentést. Az általam javasolt megoldás, hogy válasszuk külön az adatokat a megjelenítéstől, ezzel egy csapásra leüthetjük az összes legyet, sőt, további előnyöket tapasztalhatunk.

Még ma is ott tartunk, hogy "fel kell hívni a problémára a figyelmet", szerintem ezen már túlléphettünk volna.
Mutass még egy szakmabelit, aki foglalkozik a témával! A weblabor hasábjain legalábbis még nem nagyon találkoztam ilyennel.

Ha majd a hűtőszekrény kijelzőjén lesz alul egy sáv, amely a hőmérsékletet fogja jelezni, és tetszőleges képernyőn fixen ott lesz, akkor azt a footer tag-be tesszük.
Javaslom, szaladj neki még egyszer az utolsó előtti bekezdésnek, ez ugyanis ellentmond az első mondatodban leírtakkal. Ha belegondolsz, egy mondjuk 80x20-as felbontású LCD kijelző meghajtására minek építene be bárki egy komplett HTML+JS értelmezőt?

Az is egyértelmű, hogy az adatokat különválasztjuk a megjelenítéstől. Ám ez már húsz évvel ezelőtt is alapértelmezett volt.
Ha így lenne, akkor nem született volna meg ez az írás. HTML-ben egyben van az egész.

fontosnak tartom megemlíteni: Sokkal jobb lenne, ha nem arról szólnának a cikkek, hogy mi miért nem jó, mi miért nem használható, hanem arról, hogy mit használjunk, miként használjuk
A weblabor várja sok szeretettel az ilyen jellegű irományokat.
36

Mutass még egy szakmabelit...

T.G · 2015. Jan. 9. (P), 11.15
Mutass még egy szakmabelit, aki foglalkozik a témával!

Én egy két és fél évvel ezelőtti témát mutattam! Ugye ezt te sem gondolod, hogy rövid idő lenne? Véleményem szerint a pozitív példát szívesen követnék az emberek, a "ne használjátok, mert nem tetszik és amúgy sem jó" hozzáállást meg nem csodálom, hogy nem követik tömegek.

Bár megjegyzem, hogy ha két és fél év alatt egy embert nem találtál, aki ebben a témában egyetértene veled, akkor érdemes lenne elgondolkodni, hogy jól fogalmazod-e meg a problémákat, illetve helyesen teszed-e fel a kérdéseket?

Az általam javasolt megoldás, hogy ...

Valószínű a megoldás szón nem ugyanazt értjük. Azért ennél konkrétabb és jobban átgondolt kifejtésre lenne szükség ahhoz, hogy arról érdemben lehessen beszélgetni. Ami fent elhangzott az nagyon messze van a megoldástól.

Ha belegondolsz, egy mondjuk 80x20-as felbontású LCD kijelző meghajtására minek építene be bárki egy komplett HTML+JS értelmezőt?

Azért kellene újraalkotni a HTML-t, mert van egy mini eszköz, ahol eddig sem akart senki sem HTML-t megjeleníteni? Na, ezt azért gondoljuk újra! Ez most nekem csupán egy mondvacsinált probléma, emiatt nem kell kidobni a HTML-t, és emiatt ne szidjuk a HTML5 újdonságait!

Ha így lenne, akkor nem született volna meg ez az írás.

Én nem tudom, hogy miért született meg ez az írás.

A weblabor várja sok szeretettel az ilyen jellegű irományokat.

Néhány alkalommal adtam már cikkírásra a fejem, remélem, hogy az általam elvárt kritériumoknak megfeleltem. Ám ha ezek a cikkek a WL-en lennének sem befolyásolná azt a képet, hogy a Te cikkeidből/hozzászólásaidból a negatívumok jönnek. Ám magad írtad le, hogy az elmúlt években senkit nem tudtál rávenni, hogy foglalkozzon a témával, ezért bátorkodom javasolni, hogyha a témában továbbra is hiszel, akkor próbálkozz a megfogalmazás módján javítani, hátha sikeresebb leszel!
41

érdemes lenne elgondolkodni,

Hidvégi Gábor · 2015. Jan. 9. (P), 12.48
érdemes lenne elgondolkodni, hogy jól fogalmazod-e meg a problémákat, illetve helyesen teszed-e fel a kérdéseket
Oké.

Azért ennél konkrétabb és jobban átgondolt kifejtésre lenne szükség ahhoz, hogy arról érdemben lehessen beszélgetni. Ami fent elhangzott az nagyon messze van a megoldástól.
Először mindig az irányt és a végcélt kell megfogalmazni, aztán lehet az implementációs részletekkel foglalkozni.

Azért kellene újraalkotni a HTML-t, mert van egy mini eszköz, ahol eddig sem akart senki sem HTML-t megjeleníteni? Na, ezt azért gondoljuk újra! Ez most nekem csupán egy mondvacsinált probléma, emiatt nem kell kidobni a HTML-t, és emiatt ne szidjuk a HTML5 újdonságait!
Sehol sem mondtam, hogy újra kell alkotni az HTML-t, olvasd el az írás utolsó mondatát, annyit javaslok, hogy a szükséges minimumra csökkentsük le a HTML elemeinek a számát. Sehol nem írtam, hogy ki kell dobni a HTML-t, sőt, a következőt állítom: "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." A böngészők nyelve a HTML, és böngészésre mindenki böngészőt használ. Ezek után miért akarnám kidobni a HTML-t? A HTML5 jogosságát is azért kérdőjelezem meg, mert igazi újdonságot nem hoz, csak idő ment el vele az utóbbi tizenöt évben, és a keresés hatékonyságát viszont nem javítja. Márpedig a megrendelőid, akiből élsz, akkor lesznek elégedettek, ha a potenciális felhasználók megtalálják az általad készített oldalt. Node a website-ok számának ilyen mértékű növekedése mellett ez hogyan lehetséges, ha nincs a kezedben eszköz?

Leírom harmadszorra is szívesen: szerintem az interneten alapvetően adatokat kéne küldeni. A böngészőknek adni kell egy mankót, amivel az adatokat HTML-ben meg tudják jeleníteni, minden más eszköz pedig oldja meg magának úgy, ahogy tetszik.

Mindenesetre a kérdéseid és a felvetéseid ellentétben állnak azzal a kijelentéseddel, hogy becsülettel átolvastad a cikket.
43

Miért magyarul?

T.G · 2015. Jan. 9. (P), 13.34
Nagyon deja-vu érzésem van, ezeket a sorokat már olvastam és azokat a válaszokat is, amelyeket erre írhatnék. Nem találkoztam olyan ügyféllel, aki ezeket a problémákat felvetette volna. Olyannal már igen, hogy le tudjuk-e a jobb klikket tiltani, mert ellopják az adatait. A felvázolt problémák az általam ismert ügyfelek között nem jelentkeztek, és ahogy látom, az itt hozzászólok többségénél is hasonló a helyzet. Volt olyan ingatlan portálhoz szerencsém, ahol a fő bevételi forrás a bannerekből volt, senkit sem érdekelt, hogy mennyire lehet jól keresni az ingatlanok között, ahogy az sem, hogy mennyire jók az ingatlan adatok. A fő szempont az oldalletöltés volt. Számtalan portálnak, szolgáltatásnak nincs ennél jobb üzleti modellje.

Ám egy valamit tényleg nem értek, ezeket a cikkeket miért magyarul és miért egy magyar nyelvű portálra írod? Mert az azért teljesen egyértelmű, hogy azokhoz nem jutnak el az aggályaid, akik befolyásolni tudják, hogy több vagy kevesebb elemű legyen a HTML elemkészlete.
44

A vázolt üzleti modellt

Hidvégi Gábor · 2015. Jan. 9. (P), 14.35
A vázolt üzleti modellt értem. A statisztikákból látszik, hogy nő a weboldalak száma, jobban, mint a látogatóké. Ebből következik, hogy az ügyfeleid oldalait egyre kevesebben fogják megtalálni, a bannerek kattintási aránya és megjelenési száma is csökken. Így előbb-utóbb üzleti modellt kell váltani, és amivel ki lehet tűnni az elején, az a hatékony keresés támogatása.

A website-ok és szolgáltatások számának növekedését szolgálja, hogy egyre több (nyílt forráskódú) kész megoldást lehet kapni, lásd wordpress-alapú oldalak, kész webshop-motorok stb.

Azért magyarul írok, mert a magyar webes szakembergárda ugyanolyan képzett, mint a külföldi (hála a szakma nyíltságának és az angol nyelvű dokumentációknak), és ha bármit sikerül is alkotni, az nemzetközileg is megállja a helyét.
50

Ha az a cél, hogy...

T.G · 2015. Jan. 9. (P), 17.30
Ha az a cél, hogy találjunk ki valami hatékony keresési megoldást, akkor miért arról szólnak a cikkek nagy része, hogy az aktuális trendekkel éppen mi a baj? Szerintem ennek semmi köze egymáshoz. Nem a header tag létén múlik egy keresési megoldás sikere vagy sikertelensége.

Másik, hogy miért gondolod, hogy az új üzleti modellek nagy része a hatékony keresések felé fog elmozdulni? Én nem zárom ki, de nem is látok ráutaló magatartást.

Illetve ismét megkérdezném, hogy miért az aktuális trendeket látod a főgonosznak, miközben a keresés ma egyenlő a Google-lel, ha ő nem talál meg téged, akkor a weboldalad rossz, ha ő jó pozícióba helyez téged, akkor a weboldalad jó. Tökéletesen lényegtelen, hogy van-e header tag vagy sincs, ma a kereshetőségnek Google pozíció a mérőszáma.
51

Ha az a cél, hogy találjunk

Hidvégi Gábor · 2015. Jan. 9. (P), 18.21
Ha az a cél, hogy találjunk ki valami hatékony keresési megoldást, akkor miért arról szólnak a cikkek nagy része, hogy az aktuális trendekkel éppen mi a baj?
"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"

"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."

"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."

Azért a <header> tag meglétén múlik a keresési megoldás sikere, mert amíg az új tag-ekkel bohóckodik a világ webfejlesztőinek 99%-a, addig nem azzal foglalkoznak, hogy metaadatokat adjanak meg az oldalaikon. Ha a <div>-ek átnevezése <section>-né hét évig tartott, akkor egy adatalapú web mennyi ideig fog? Vesztegetjük a saját és a látogatóink idejét.

Másik, hogy miért gondolod, hogy az új üzleti modellek nagy része a hatékony keresések felé fog elmozdulni?
Nem gondolom, de célszerűnek tartom, mert az információ tömege nőni fog, és ezt meg kell tudnunk szűrni.

Tökéletesen lényegtelen, hogy van-e header tag vagy sincs, ma a kereshetőségnek Google pozíció a mérőszáma.
Így van, és a Google csak szöveges tartalomban tud keresni, ezért a modern böngészők mellett ez a cég az internet fejlődésének legnagyobb kerékkötője.

A saját érdekünk, hogy a potenciális látogatók megtalálják az általunk készített oldalakat, mert közvetve belőlük élünk. Ezért feladatunk, hogy a kereshetőséget javítsuk - amivel persze más is foglalkozik, de nem lehet a felelősséget mindig elhárítani.
52

a Google csak szöveges

inf3rno · 2015. Jan. 9. (P), 19.49
a Google csak szöveges tartalomban tud keresni


Ez egyáltalán nem így van, a google RDF-ben is tud keresni, csak ezt baromi kevesen használják ki.
53

Mi ennek a speciális

Hidvégi Gábor · 2015. Jan. 9. (P), 21.05
Mi ennek a speciális keresőnek a címe?
54

Arra gondoltam, hogy a google

inf3rno · 2015. Jan. 9. (P), 21.16
Arra gondoltam, hogy a google crawler RDF-ben is képes keresni, nem arra, hogy mondjuk sparql-t meg lehet adni a google-nek, mint keresőkifejezést. Legközelebb fogalmazz érthetően!

Ha már szóbakerült, megkérdem őket, hogy mikorra tervezik a sparql supportot, hátha lesz...
57

Speciális keresés Írásjelek,

Hidvégi Gábor · 2015. Jan. 10. (Szo), 14.39
Speciális keresés
Írásjelek, szimbólumok és operátorok a keresésben

Akárhogy nézem, csak szövegben tud keresni. Teljesen más tészta, hogy bizonyos tag-eket felismer, és azok tartalmát meg tudja jeleníteni a találatok között, de ezeket az adatokat szűrésre nem lehet használni.
61

Nálam a szöveg, mint

inf3rno · 2015. Jan. 10. (Szo), 15.12
Nálam a szöveg, mint keresőkifejezés alapján történő keresés, és a szövegben keresés teljesen külön fogalmak, ahogy valószínűleg az emberek 99.9%-ánál is.
64

Ebben egyetértünk. Vegyük a

Hidvégi Gábor · 2015. Jan. 10. (Szo), 15.34
Ebben egyetértünk. Vegyük a következő RDFa szeletet (a Wikipédiáról másoltam):
<div xmlns:dc="http://purl.org/dc/elements/1.1/"
  about="http://www.example.com/books/wikinomics">
  <span property="dc:title">Wikinomics</span>
  <span property="dc:creator">Don Tapscott</span>
  <span property="dc:date">2006-10-01</span>
</div>
Tudsz keresni a creator mezőre?
67

Hát először ki kell keresni a

inf3rno · 2015. Jan. 10. (Szo), 18.23
Hát először ki kell keresni a névteret, hogy mi a neve: "http://purl.org/dc/elements/1.1/", utána már lehet használni egy xpath-et, ami keres rá.

Csak, hogy valami építő jellegűt is írjak:


<script type="application/ld+json">
{
"@context": {
  "@vocab": "http://purl.org/vocab/frbr/core#",
  "@language": "en",
  "dc": "http://purl.org/dc/terms/",
},
"@id": "http://books.example.com/works/45U8QJGZSQKDH8N",
"@type": "Work",
"dc:creator": "Wil Wheaton",
"dc:title": "Just a Geek",
"realization": [{
  "@id": "http://books.example.com/products/9780596007683.BOOK",
  "@type": "Expression";
  "dc:type": "http://books.example.com/product-types/BOOK"
}, {
  "@id": "http://books.example.com/products/9780596802189.EBOOK"
  "dc:type": "http://books.example.com/product-types/EBOOK"
}]
}
</script>

Ezt egy mail list-ről másoltam. Egyszerűen ráeresztesz egy json-ld parsert, és rákeresel a http://purl.org/dc/terms/creator-re. A google ha jól tudom mindkettőt csinálja.

Egyébként ha gondot okoz az RDFa vagy microdata parsolása, akkor én a helyedben egy már meglévő parsert keresnék ahelyett, hogy egy újat írnék. Don't reinvent the wheel!
75

?

Hidvégi Gábor · 2015. Jan. 10. (Szo), 19.34
A google-ről volt szó. Tehát a google-ben hogyan lehet a fenti RDFa-ban lévő megjelölt adatokra keresni?
80

Szerintem olvass vissza. Nem

inf3rno · 2015. Jan. 10. (Szo), 21.56
Szerintem olvass vissza. Nem állítottam, hogy lehet ilyet a jelenlegi google-ben. Ha megtámogatják sparql-t, akkor majd lehetséges lesz.
88

Akkor nem értem, minek

Hidvégi Gábor · 2015. Jan. 10. (Szo), 22.35
Akkor nem értem, minek kezdted ezt a szálat az 52-vel. Tudom, hogy a google crawler tud értelmezni bizonyos metaadatokat, de amíg ezekben nem lehet közvetlenül keresni, addig minek hozod ezt fel? Ha felmerül az a kifejezés, hogy "google", abból indultam ki, hogy akkor általában mindenki arra a bizonyos keresőre (vagy általában a keresőkre) gondol, és nem a crawlerre. És ez a kereső csak szöveges dolgokban tud keresni. A cikkben direkt hoztam fel olyan oldalakat (pl. ingatlan.com), ahol adatokban lehet keresni, a google nem ilyen.
89

Most örülünk? :)

T.G · 2015. Jan. 10. (Szo), 23.02
Egy ingatlanportál saját ingatlanjai között tud keresni és ennek örülünk? Ezt már eredménynek tartjuk? :) Annak ellenére, hogy header tag-et is használ? :) Ilyen oldalból szerintem milliónyit lehet találni. Ám, akkor mégsem volt annyira elvesztegetett az elmúlt 10 év? :)
90

Örülünk, Jules

Hidvégi Gábor · 2015. Jan. 10. (Szo), 23.05
Képzeld el, hol tartanánk, ha a webfejlesztők a <header> tag-ekkel való szerencsétlenkedés helyett arra fordították volna az idejüket, hogy az oldalaikon lévő (a példa kedvéért ingatlan)adataikat egységesen adták volna meg, mondjuk <ingatlan><alapterulet>200m2</alapterulet></ingatlan>, vagy valamilyen menő JSON formában. És akkor elég lenne egy központi ingatlankereső, amiben az egész világon lehetne egységesen keresni (és a találatai az egyes ingatlanos site-okra vinnének).
91

Hol?

T.G · 2015. Jan. 10. (Szo), 23.17
Az ingatlan.com -on hol látsz te ilyeneket? Kiemelted valamiért az ingatlan.com -ot, de az nem írtad, hogy miért is jobb ez az oldal, mint bármely másik apró hirdetésekkel foglalkozó portál, ahol a saját adataikban ugyanúgy lehet keresni.
93

Példa

Hidvégi Gábor · 2015. Jan. 11. (V), 10.40
Az ingatlan.com-ot (másik kettő mellett) példaként hoztam fel.

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.

A cikkben direkt hoztam fel olyan oldalakat (pl. ingatlan.com), ahol adatokban lehet keresni


Azért hoztam fel példaként, mert ezt az adatmodellt lehetne kiterjeszteni az internetre, lásd az írás utolsó előtti bekezdését.
96

Azért hoztam fel példaként,

inf3rno · 2015. Jan. 11. (V), 12.47
Azért hoztam fel példaként, mert ezt az adatmodellt lehetne kiterjeszteni az internetre, lásd az írás utolsó előtti bekezdését.


Folyamatban van már baromi sok éve. Nem mondtál vele újat, szemantikus webnek hívják.
95

Szerintem baromira eltúlzod

inf3rno · 2015. Jan. 11. (V), 12.46
Szerintem baromira eltúlzod ezt az egészet. A HTML5-öt úgy tudom, egy zárt körű csoport alkotta meg (ugyanúgy, mint a W3C szabványok többségét, gondolom max 20 ember). A webfejlesztőknek semmi köze nem volt a dologhoz. Ezek után nyilván aki tudja szép lassan implementálja bele az oldalaiba, de mivel a böngészők támogatják még egy jó darabig a HTML4-et, illetve XHTML-t is, ezért egyáltalán nem kell, hogy erőforrásokat kössön le mindez.

RDF vocab-ot bárki gyárthat, akinek kedve van, csak az eredmény általában nem túl fényes, mert sok munkát, tapasztalatot, és átgondolást igényel egy ilyen szókészlet összeállítása. Mivel az ingatlanozás az árukereskedelem mellett alap dolognak számít, ezért gyakorlatilag biztos, hogy létezik már RDF vocab, ami speciálisan ingatlanozáshoz kell. Elég lenne ezt a vocab-ot támogatni a google-nek, illetve ezt a vocab-ot kötni az ingatlanos oldalaknak az adataikhoz. Mivel vagy a menedzsment nem tud erről a lehetőségről (mert a fejlesztők sem tudnak), vagy a menedzsment úgy döntött, hogy valamiért szerintük ez ellentétes az üzleti modeljükkel, vagy szimplán nem érné meg a belefektetett energiát, ezért nem valósult meg.

Amúgy elég sok oldal van már, ami köti az adatait a schema.org vocab-hoz: http://getschema.org/index.php/List_of_websites_using_Schema.org.

Van már pár olyan oldal, ami a hydra-hoz is (ami később lehet, hogy a schema.org része lesz), így akár előfordulhat, hogy a végén meg sem kell látogatni egy webshop-ot, hanem a google-ben is fel lehet adni majd a rendelést.

Imho sosem lesz olyan, hogy pl dc:creator, vagy bármilyen egyéb szemantika szerint lehessen keresni a mai google interface-en. Az embereknek van kitalálva, akiknek a 99.9%-ának fogalma sincs arról, hogy mi az, hogy vocab, vagy dc:creator, vagy hogy mennyire fontos a keresésben, hogy egy szóalakhoz több jelentés is társulhat. Én személy szerint sokszor azzal vagyok bajban, hogy csak a témakört ismerem, meg nagyjából tudom, hogy milyen fogalmat keresek, de nem tudom rá a szakszót. Ebben pl sokat segíthetne, ha fellapoznék egy RDF vocab-ot a témában, és átnyálaznám a szakszavait. Sajnos ilyenre a google jelenleg nem alkalmas, az RDF vocab-ok meg még nem fednek le minden témakört kellő alapossággal, főleg ha tudományos kutatásokról van szó, és nem mindennapi dolgokról. Szóval én személy szerint tudnám használni, de ez már inkább kutatómunka, mint sima keresés.
98

Akkor lehet, hogy itt az

Hidvégi Gábor · 2015. Jan. 11. (V), 12.58
Akkor lehet, hogy itt az ideje egy újfajta keresési felület kialakításának, ami specializált egy témakörre. Sokaknak már sikerült, lásd ingatlan.com és társaik.
99

Hát van már egy sereg árgép

inf3rno · 2015. Jan. 11. (V), 13.00
Hát van már egy sereg árgép vagy liligo, stb... senki nem mondta, hogy a specializált keresők nem működnek. Pont azért van rájuk szükség, mert képtelenek a fejlesztők RDF-re váltani. Vagy mert nem szeretnék a cégek, hogy a felhasználók egy kattintással összehasonlítsák az áraikat azzal, amit a konkurrencia kínál...
101

Ha nem szeretnék a kereskedők

Hidvégi Gábor · 2015. Jan. 11. (V), 13.08
Ha nem szeretnék a kereskedők az összehasonlítást, akkor nem működne az árgép - és ne feledd, az áron kívül sok más tényező is befolyásolja a döntést, hogy hol vásárlunk.

Ha nem lehetne már most is összegyűjteni az adatokat, nem működne a liligo.

Ha nem használják az RDF-et, annak az lehet, az oka, hogy túl bonyolult. Talán egyszerűbb modellt kéne használni.
102

Nem létezik egyszerűbb model

inf3rno · 2015. Jan. 11. (V), 13.11
Nem létezik egyszerűbb model az RDF-nél.

Az adatokat csak akkor nem lehet összegyűjteni keresővel, ha nem jelennek meg az emberek számára sem. Ami kikerül a webre az onnantól már nem titok, és bármikor crawlerrel le lehet nyúlni. Ezt maximum megnehezíteni lehet, amit meg is próbálnak sokan.

Egyébként ha megnézel egy lufthansa oldalt, akkor ott szopás van orrba szájba csak azzal, hogy listázd a találatokat. Nem véletlenül alakították ki ilyenre. Egyáltalán nem egyszerű crawler-t írni rá. Ha érdeke lenne a lufthansa-nak, hogy összehasonlítsák a wizzair-rel az árait, akkor biztosan könnyen hozzáférhetővé tették volna azokat.

Összességében annyit tudok írni a témáról, hogy a kereshetővé tétel növeli a piaci versenyt, lejjebb nyomja az árakat, és ha webshopokról van szó, akkor arra készteti a cégeket, hogy versenyezzenek az olcsóbb, de nem feltétlenül ugyanolyan minőségi szolgáltatást nyújtó cégekkel. Ez ár szempontjából jó lehet a fogyasztónak, de korántsem biztos, hogy egy alacsonyabb minőségű szolgáltatást alacsonyabb áron használva ugyanazt kapja, mint amit elvár. Ez teljesen szolgáltatás és piac függő.
104

Nem létezik egyszerűbb model

Hidvégi Gábor · 2015. Jan. 11. (V), 13.16
Nem létezik egyszerűbb model az RDF-nél.
Vagy csak te nem tudsz róla. Ha meg tényleg így van, akkor készíteni kell egyet. Az RDF egy elég komoly rendszer, de nem vagyok arról meggyőződve, hogy erre lenne mindenkinek szüksége.

A második bekezdésedet sok szeretettel küldöm H.Z. kollegának.
105

Senki nem fog vissza, hogy

inf3rno · 2015. Jan. 11. (V), 13.20
Senki nem fog vissza, hogy előállj egy RDF-nél jobb rendszerrel, és keresztülverd a google-ön, hogy támogassa. (Ami biztos, hogy a sablon XML, amit eddig felvázoltál az egyáltalán nem válik be.)
106

Csakhogy itt - ha jól értem -

pythonozok · 2015. Jan. 11. (V), 15.01
Csakhogy itt - ha jól értem - elsősorban nem adatokról, hanem adatkapcsolatokról _információról_ van szó. Na ennek begyűjtéséhez valamiféle mesterséges intelligencia szükséges, ha nincs megfelelően előkészítve az automaták számára, ez viszont egyelőre nem tűnik elterjedtnek.

Lásd: autó és piros szavak önmagukban semmit sem jelentenek ha piros autót keresel, csak ha valahogy felismered, hogy a piros az autó színe és nem mondjuk a rajta lévő gumiabroncsé.
107

Az írott szöveg olvasására

inf3rno · 2015. Jan. 11. (V), 16.13
Az írott szöveg olvasására szükséges a mesterséges intelligencia, mert a gép sokkal nehezebben teszi kontextusba a szavakat, mint az emberek, és nem szokott visszakérdezni, hogy ugye erre gondolsz?!

Az RDF-et a gépek erőlködés nélkül tudják olvasni, ezért pl a beágyazott JSON-LD egy teljesen jó megoldás. A HTML+RDFa vagy HTML+microdata már kevésbé jó, mert a HTML struktúrája és az adat struktúrája nem minden esetben követi egymást, és valamikor problémás lehet összeegyeztetni a kettőt. Ettől függetlenül valószínűleg az esetek döntő többségében az is használható.

Igen, pont arról beszélünk, hogy nem elterjedt RDF-el vocab-hoz kötni a megjelenített adatot, ezért nehezen kereshetőek a weboldalak.
109

ddg hacks

complex857 · 2015. Jan. 11. (V), 18.37
Akkor lehet, hogy itt az ideje egy újfajta keresési felület kialakításának, ami specializált egy témakörre.

Nem tudom mennyire ismered/ismeritek DuckDuckGo-t de ha "új felület" ötletekből akartok pár élő példát akkor érdemes lehet itt körülnézni. Pl. ha ha rákeresek "orange"-ra akkor a kapok egy sor "meanings"-et, illetve lehet ún. "instant answer" hackeket gyártani amivel tetszőleges szolgáltatásból lehet ehhez hasonló a szokásos találatok felett megjelenő listát generálni (Pl). Jelenleg nem tudok olyan API elemről náluk ami crawlerjük által talált rdfa vocab vagy hasonlók segítségével kigyűjtött metadatában engedne keresni (ha egyáltalán indexelik ezeket a vocabok alapján), de ha van ilyen adatforrásotok ide be lehet drótozni.

Maga a kereső nyelv afaik semmivel sem okosabb mint googlé jelenleg, de ha kereső oldal irányából tenni valamit az ügy érdekében érdemes lehet nyitni itt egy topic-ot (RDFA-ra keresve nem találtam semmit jelenleg).
94

Én továbbra sem értem, hogy

inf3rno · 2015. Jan. 11. (V), 12.25
Én továbbra sem értem, hogy mire akarsz kilyukadni. Eddig arról volt szó, hogy a HTML nem elég jó olyan szempontból, hogy nem kereshető az adat, ami benne van. Kiderült, hogy mégiscsak kereshető, ha RDF-el kötik valamilyen elterjedt vocab-hoz. Továbbra sem értem, hogy egy google vagy bármilyen oldal felhasználói felületének ehhez mi köze?! Nyilván technikailag megoldható, hogy a google-nek szemantikus keresőkifejezést adjunk meg, ahogy az is, hogy egy ingatlanportál vagy akár az amazon kereshető HTML-t generáljon. Nyilván megvan az oka annak, hogy erre nem fordítanak energiát, és ez valószínűleg az esetek döntő többségében ugy gondolom, hogy az, hogy nincs olyan üzleti modeljük, ami ezt előnyösnek tartaná. Ezt azt hiszem már le is írtam párszor. De persze mondhatjuk azt, hogy ez a HTML hibája, mert a szabvány fejlesztői bevezették a headert meg a footert, csak nem tudom, hogy ebben hol a logika...
97

Attól függ, mit szeretnél:

Hidvégi Gábor · 2015. Jan. 11. (V), 12.54
Attól függ, mit szeretnél: nekifutsz még egyszer az írásnak, vagy pedig idézzek neked?

Nyilván megvan az oka annak, hogy erre nem fordítanak energiát, és ez valószínűleg az esetek döntő többségében ugy gondolom, hogy az, hogy nincs olyan üzleti modeljük, ami ezt előnyösnek tartaná.
Valószínűleg így van, de most te a google és az amazon szekerét tolod, vagy a felhasználókét? Ha részvényes vagy, akkor megértem, ha az előbbiek mellett állsz, egyébként nem.

Tegyük fel, hogy valaki meg szeretne vásárolni egy könyvet. Ehhez jelenleg át kell nézni n darab kereskedő oldalát, hogy megtudja, egyáltalán van-e raktáron, az üzlet milyen messze van, mennyibe kerül a csomagszállítás stb. Adatalapú internet esetén ezeket az információkat össze lehetne gyűjteni, és egy helyen össze lehetne őket hasonlítani. Pusztán HTML alapú webnél ezt sokan (lásd az általad felhozott példák) nem teszik meg sokan.
100

Valószínűleg így van, de most

inf3rno · 2015. Jan. 11. (V), 13.08
Valószínűleg így van, de most te a google és az amazon szekerét tolod, vagy a felhasználókét? Ha részvényes vagy, akkor megértem, ha az előbbiek mellett állsz, egyébként nem.


Ez egy érdekes kérdés. Nyilván annak a szekerét tolom, aki fizet. Pl ha az amazontól kapok megrendelést egy fejlesztésre, akkor az övékét. Nyilván van egy piaci rés, amit sokan kitöltenek most már téma specifikus keresőkkel, lásd árgép, oclsobbat.hu, liligo, szallas.hu, és így tovább. Ez nem véletlenül akakult ki. A boltok szeretnék kerülni a versenyt, mert sokan a legolcsóbbnál vásárolnának, ezért nem teszik közkinccsé az adataikat. A keresők meg abból élnek, hogy megírják minden oldalra a crawlereiket, aztán kiraknak egy listát, és így növelik a versenyt. A kicsi boltoknak ez nyilván jó, ők be is regisztrálnak a keresőkhöz. A nagy boltoknak meg rossz, mert a kicsikkel kell versenyezniük online, ahol ugye mások a szabályok, mintha kibérelnek egy nagy hodályt a város szélén, és mindenki hozzájuk jár.
103

A verseny már csak ilyen, nem

Hidvégi Gábor · 2015. Jan. 11. (V), 13.14
A verseny már csak ilyen, nem mindenki fog jól járni. Miért emeljük ki a nagy boltokat, miért legyen nekik jó? Ha egy jelenleg kis üzlet életképesebb modellt választ, és a felhasználók hozzá kezdenek el menni, akkor megérdemli a sikert.

Hiába szeretnék elkerülni a boltok a versenyt, akár a mesterséges intelligencia fejlődésével az árukészletük előbb-utóbb indexelhető lesz, de kézi erővel is lehet írni parsert bármire, à la liligo.

Az adatalapú web megvalósulása csak idő kérdése, és minél előbb vált valaki, minél előbb kezdünk el mi, fejlesztők elmenni ebbe az irányba, annál jobban járunk.
55

Mi történt két és fél év alatt?

T.G · 2015. Jan. 9. (P), 23.18
De most komolyan, mi történt két és fél év alatt? Ez nem elvesztegetett idő volt?
Nem értem, hogy miért várod, hogy más is foglalkozzon az általad fontosnak tartott témákkal, ha magad sem foglalkozol vele. Mert az, hogy a HTML5 hiányosságait sorolod, azzal nem lett a keresés problémája előrébb.

Amennyiben csupán egyetlen egy axiómádat elveszünk az érrendszeredből - hogy nem a keresés a legfontosabb dolog az Interneten - a magyarázataid, illetve a következtetéseid értelmét vesztik, és máris a fejlesztők 99% nem csupán bohóckodik, hanem azon dolgozik, hogy az Internet egyre jobb legyen.

Persze az szép és jó dolog, ha te is ezen dolgozol, és a keresést szeretnéd javítani, de lassan el kellene fogadnod, hogy sokan nem ezt tartják a legfontosabbnak.
56

De most komolyan, mi történt

Hidvégi Gábor · 2015. Jan. 10. (Szo), 14.34
De most komolyan, mi történt két és fél év alatt? Ez nem elvesztegetett idő volt?
Emiatt nem kell aggódnod, majd elrendezem én ezt magamban. Én legalább foglalkozom a problémával.

Amennyiben csupán egyetlen egy axiómádat elveszünk az érrendszeredből - hogy nem a keresés a legfontosabb dolog az Interneten
Leírtam már párszor, hogy az internet egy egyre növekvő adathalmaz, ami ráadásul csak minimálisan struktúrált. Az adatokban keresni szoktunk, nem? Amikor rákattintasz egy linkre, szerinted akkor mi történik? Ezek után miért vennénk ki az érvrendszerből azt, hogy az interneten a keresés a legfontosabb? Nem azért teszik fel az internetre a honlapokat, hogy megtalálják azokat? Mit ér a legszebb javascript/css, ha a felhasználók nem találják meg?

lassan el kellene fogadnod, hogy sokan nem ezt tartják a legfontosabbnak
Pontosan látom, és nem igazán értékelem ezt a cinizmust ("megcsinálom ezt az oldalt, felteszem a netre, a többi az már nem az én problémám, csak legyen minden kényelmes és fizessenek ki"). Továbbra is vallom, hogy nem a megrendelőknek dolgozunk, hanem a (potenciális) látogatóknak, vevőknek, mivel végeredményben ők fizetnek a megrendelőinknek (akik pedig nekünk). A mi felelősségünk is, hogy az általunk készített oldalt vagy alkalmazást megtalálják, és érdekünk is, mert így számíthatunk több munkára.
58

Tudnál mutatni pár olyan

pythonozok · 2015. Jan. 10. (Szo), 14.39
Tudnál mutatni pár olyan oldalt, ahol megvalósultak az elképzeléseid? Elsősorban saját munkáid érdekelnének, másodsorban nagyobb forgalmú, nemzetközi oldalak.
59

Igen

Hidvégi Gábor · 2015. Jan. 10. (Szo), 14.43
Mindent a magam idejében. Nemzetközi oldalt nem csináltam még ilyen módszerrel.
60

Elsősorban saját, másodsorban

pythonozok · 2015. Jan. 10. (Szo), 14.59
Elsősorban saját, másodsorban (tökmindegy kitől származó) nemzetközi.
Ami kimaradt: lehetőleg ne hobbi oldalt, hanem olyat, amiért fizetnek is, az oldal gazdája bevállalja, hogy formázatlan adatokat ad ki a rendszeréből, feldolgozható állapotban.
62

Gyakorlatilag az összes API

inf3rno · 2015. Jan. 10. (Szo), 15.15
Gyakorlatilag az összes API ilyen, pl github API, youtube API, facebook API, és így tovább...
63

Nem, azok API-k. Az szerintem

pythonozok · 2015. Jan. 10. (Szo), 15.31
Nem, azok API-k. Az szerintem más kategória.
Én arra gondolok, hogy mondjuk egy index.hu jellegű portál esetében hol találok olyat, ahol a tényleges tartalmat feldolgozható formában publikálják a nagyközönségnek.
68

Általában RSS feed, vagy

inf3rno · 2015. Jan. 10. (Szo), 18.26
Általában RSS feed, vagy APIk, amiken keresztül publikálni szokták. Mivel az index-nek (gondolom) nem az az üzleti modelje, hogy ilyet elérhetővé tesz, ezért sehol. Nem értem, hogy ez miért releváns, eleve ezek a dolgok magyar piacra talán ha 5 év múlva fognak bejönni, szóval nem kellene alapul venni, hogy az itthoni szennyoldalak, mint pl az index mit csinál.
70

Csak példaként hoztam az

pythonozok · 2015. Jan. 10. (Szo), 18.37
Csak példaként hoztam az indexet, hogy ilyen jellegű, leginkább reklámokből élő oldalak esetében hol találni effajta megoldásokat.
Nem az a kérdés, hogy az index mit csinál, hanem, hogy hol van hasonló jellegű lap, ami Gábor elvárásainak megfelelő struktúrában működik?
Nem API, nem RSS stb., hanem webre szánt oldal, komoly tartalommal.
Egyszerűen látni szeretnék egy ilyet.
77

Nincsenek elvárásaim a

Hidvégi Gábor · 2015. Jan. 10. (Szo), 19.47
Nincsenek elvárásaim a struktúrával kapcsolatban. Ez az írásom nem szólt többről, csak annyiról, hogy HTML alapú web helyett menjünk el az adatalapú web irányába (aminek paradox módon részhalmaza a HTML alapú web). Természetesen van megoldási javaslatom, de ez a cikk csak vitaindító, nem technológiai bemutató.
78

Évek óta csak az előételt

bamegakapa · 2015. Jan. 10. (Szo), 21.25
Évek óta csak az előételt ízlelgetjük, most már lassan szervírozhatnád a lényeget :).
79

O.K., de látni szeretnék egy

pythonozok · 2015. Jan. 10. (Szo), 21.31
O.K., de látni szeretnék egy oldalt, ami így működik. Ennyi, nem több.
Ha nincs ilyen... akkor miért nincs egy sem?
Elég régi téma, nemzetközi fórumokon is találkoztam hasonló felvetéssel, de működő oldalt még nem láttam, ami ilyen elvek szerint működne.
De ahogy elnézem, még a http://www.semanticweb.org és a http://www.semanticarts.com/ sem felel meg ezeknek, sima HTML+javascript mindkettő.
65

Az, hogy van lehetőség az

Hidvégi Gábor · 2015. Jan. 10. (Szo), 16.05
Az, hogy van lehetőség az adatokat közvetlenül kitenni a webre, jelenti-e azt, hogy ezzel kötelező élni?
66

Amit eddig tőled láttam,

pythonozok · 2015. Jan. 10. (Szo), 17.19
Amit eddig tőled láttam, abból az jön le: valami XML jellegű adathalmazt + formázáshoz egy sablont vársz kimenetként a weboldalaktól. Ezt másképp hogy lehetne?
69

Pl az adatokat bele lehet

inf3rno · 2015. Jan. 10. (Szo), 18.30
Pl az adatokat bele lehet szórni egy külön tag-be az automatizált rendszernek könnyen feldolgozható formában. Ez lehet XML, JSONLD, bármi, ami tetszik. Az RDF mindenképp jobb ilyen szempontból, mert jelentést is rendel a mezőkhöz, adatokhoz. A HTML-hez van microdata, RDFa, de egyik sem igazán jó. Szóval úgy általánosságban, ha HTML-be ágyazva kell ilyet küldeni, akkor jobb másolni az adatokat. Volt még azt hiszem XFORMS, ami a HTML-t az adatok alapján generálta le, de azt csak firefox támogatta. Ugyanezt javascripttel is meg lehet csinálni, csak még elég sokan ragaszkodnak ahhoz a tévhithez, hogy a HTML+RDFa jobban kereshető, mintha a fenti JSON-LD-t parsolja be a rendszer, és abból generálja amit megjelenít a felhasználónak. Talán annyi vesztesége lehet a dolognak, hogy valamivel nagyobb a betöltési idő. Én úgy gondolom, hogy nem szükséges tovább tákolni a kereshetőség terén a HTML-t, az RDFa, microdata pont elég. Ha meg erre külön igény van, akkor úgyis el fognak menni a beágyazott RDF, pl JSON-LD irányába, amivel struktúrált formában le lehet írni, hogy mi található az oldalon, nem csak úgy félig-meddig ömlesztve, mint HTML-ben.
71

Én elvileg kérdezem, hogy

pythonozok · 2015. Jan. 10. (Szo), 18.39
Én elvileg kérdezem, hogy hogy lehet másképp, te meg egy elviekben hasonló, csak gyakorlatban eltérő választ adtál.
72

Hát szerintem nem lehet

inf3rno · 2015. Jan. 10. (Szo), 18.45
Hát szerintem nem lehet másképp, de majd Gábor úgyis feltalálja. :-) Nem értem miért nem jó neki, ami van, mindegy.
73

Mielőtt félreértenél: nem

pythonozok · 2015. Jan. 10. (Szo), 18.59
Mielőtt félreértenél: nem kötekedni akarok, tényleg érdekelne, hogy van-e valahol olyan oldal, amit úgy készítettek el, ahogy Gábor szeretné. Illetve ha nincs ilyen, akkor miért nincs?
Úgy emlékszem, amikor egy-két éve ugyanezt körbejártuk, akkor sem sikerült a kritériumoknak megfelelő lapot találni.
74

Természetesen van ilyen. :)

T.G · 2015. Jan. 10. (Szo), 19.03
Természetesen van, illetve két éve még volt, csak titkos. (Bocs, de nem tudtam kihagyni.:)
81

:D

inf3rno · 2015. Jan. 10. (Szo), 21.57
:D
82

Azt hiszem erre Gábor tudna

inf3rno · 2015. Jan. 10. (Szo), 22.19
Azt hiszem erre Gábor tudna válaszolni. Én nem igazán értem, hogy mit szeretne többet, ami előremutatóbb a jelenlegi szabványoknál.

Egyelőre az jött le, hogy az a kínja, hogy a google-ben nem lehet szemantika szerint keresni, amiben végülis egyet tudok érteni vele. Van olyan crawlere a google-nek, ami nézi az RDF-es tartalmakat, szóval igazából csak a user interface-t kellene kicserélni, olyanra, amit programok is tudnak használni mondjuk sparql query küldésével, és bumm. Esetleg meg lehetne kérdezni a felhasználót minden egyes bevitt szónál, hogy a szó melyik jelentésére gondolt. És így tovább. Ilyen szempontból, ha a google nem lép 5-10 éven belül, akkor át fogják venni a helyét más keresők, amikben nem csak szavakat, hanem jelentést is meg lehet majd adni, mert ez a jövője a dolgoknak. Valószínűleg maga a probléma ennél azért sokkal bonyolultabb lehet, mert a feltérképezett weboldalak jelentős részéhez valahogy jelentést kellene rendelni, nem csak szavak szerint indexelni őket. A google-nek ehhez valami mesterséges intelligencián kellene áttolni ezeket az oldalakat, hogy kiköpje miről szól az oldal. Alternatív megoldás, hogy a webfejlesztők elkezdik használni az RDFa, microdata-t, JSON-LD beágyazást, stb... Ezen kívül még gond lehet a keresőkifejezés bevitelével. Mert a sparql-t csak programozók tudják összerakni, más szemantika szerinti keresést megtámogató GUI-t meg még senki nem rakott össze. Jelenleg ők azon dolgoznak, hogy a szövegesen, kérdés formában megadott dolgokat értelmezzék szemantikailag, illetve figyelik az előző keresést is, amiből tudnak nagyjából a kontextusra következtetni. Az átlag felhasználónak lövése sincsen arról, hogy a szó és a jelentése két külön dolog, és nem igazán értenék, hogy maga az RDF miről szól, szóval egyszerűen nincs rá igénye az emberek túlnyomó többségének (99%<) arra, hogy mondjuk egy SPARQL-t össze tudjanak állítani, és beküldeni google-be. A maradékra (<1%) energiákat fordítani meg nem igazán éri meg a cégnek. Na legalábbis én így gondolom, hogy ezért nem tudunk szemantika szerint keresni a google-ben.

Valószínűleg ha jobban elterjednek az igazi REST service-ek, amik RDF-et szolgálnak ki, akkor lesz rájuk külön kereső, amiben meg lehet adni SPARQL-ben (vagy más szemantikus lekérdező nyelven), hogy milyen szolgáltatást keresel, és kidobja majd a service-ek listáját, amik azt a bizonyos szolgáltatást meg tudják neked csinálni, aztán választhatsz közülük, befizethetsz egy hónapra, összekattinthatsz hozzá egy automatizált klienst, vagy végigkattinthatod kézzel manuálisan is, hogy mit szeretnél egy erre specializált böngészővel, ami a HTML-t nem feltétlenül fogja ismerni, csak azt, hogy bizonyos RDF vocab-okhoz kötött adatot hogyan jelenítsen meg. De ez a része szerintem még sok év. Jelenleg az van, hogyha szolgáltatást keresel, akkor felmész google-re, beírod a szolgáltatás leírását meg hogy API, kapsz egy HTML-t, aztán próbálod a találatokból kikeresni, ami neked talán jó lenne, utána elnavigálsz az oldalára, betanulod, hogy milyen plain JSON-t vagy XML-t vár, és megírod hozzá az egyedi klienst.
84

Ilyen szempontból, ha a

Hidvégi Gábor · 2015. Jan. 10. (Szo), 22.28
Ilyen szempontból, ha a google nem lép 5-10 éven belül, akkor át fogják venni a helyét más keresők, amikben nem csak szavakat, hanem jelentést is meg lehet majd adni, mert ez a jövője a dolgoknak.
Ezzel egyetértek, és személy szerint örülnék, ha belépne a keresőpiacra a konkurencia.
76

Arra próbáltam célozni, hogy

Hidvégi Gábor · 2015. Jan. 10. (Szo), 19.40
Arra próbáltam célozni, hogy nem muszáj használni egy ilyen technológiát, aki szerint a HTML megvédi az adatait, lelke rajta. De vannak, akik mindenképp jobban járnak, ha minél több adatot megosztanak, például a kereskedők.
83

Maximum egy kicsit nagyobb

inf3rno · 2015. Jan. 10. (Szo), 22.22
Maximum egy kicsit nagyobb idő/pénz ráfordítás HTML-ben összegányolni egy egyedi parser-t, de attól még egyáltalán nem védi meg az adatokat. Én is úgy látom, hogy az lenne a piac érdeke, ha az adatok hozzáférhetők lennének mindenkinek, viszont a megfelelő üzleti model nélkül ez néhány szolgáltatónak biztos bukást jelentene...
86

Biztos, hogy sokan fognak

Hidvégi Gábor · 2015. Jan. 10. (Szo), 22.30
Biztos, hogy sokan fognak bukni a jelenlegi modellel. Az írásom célja az is volt, hogy felhívjam erre a figyelmet, és hogy idejében el tudják kezdeni a fejlesztéseket.
85

De vannak, akik mindenképp

inf3rno · 2015. Jan. 10. (Szo), 22.28
De vannak, akik mindenképp jobban járnak, ha minél több adatot megosztanak, például a kereskedők.


Ez teljes mértékben üzleti model függő lehet. Pl ha megnézed az amazont, náluk sincsen szemantika hozzácsapva a tartalomhoz, ergo nem kereshető. Ugyanígy nincs APIjuk sem, amin keresztül programozottan lehetne rendelni tőlük bármit is. Ha annyira jövedelmező lenne mindent kereshetővé tenni, akkor valószínűleg már léptek volna ez ügyben. És ez csak egy nagy cég, a többit is érdemes lenne átvizslatni, ha van rá időd.
87

Kisebb cégeknek mindenképp

Hidvégi Gábor · 2015. Jan. 10. (Szo), 22.34
Kisebb cégeknek mindenképp megérheti, mert a termékeik megjelennek az általános keresőkben is. De az igazi nyertesei a folyamatnak a felhasználók - akikből mindenki él.
42

Köszönet!

c_p_ · 2015. Jan. 9. (P), 13.21
Nagyon tetszett, hasznos gondolatokkal, jó vitaindítónak találom egy cégen belüli beszélgetéshez!
49

gyakori kérdés sok fejlesztésnél, itt is

EL Tebe · 2015. Jan. 9. (P), 15.59
Én a html(ek)re - az eredeti koncepciót is figyelembe véve - úgy tekintek, mint egy, "átjárható" - legjellemzőbben online fellelhető, tartalomjegyzékre, plussz a hozzá kapcsolódó rövidebb-hosszabb publikálandó, emberek számára könnyen olvasható dokumentumra. Aztán jött a pillanat, hogy ezeket a tartalmakat szebben, egyedibben akartuk már látni (és persze könnyebben kezelhetővé, kereshetővé tenni). Részben a "csicsázás" egyik következménye lett az elképesztő (anyagi-gazdasági) lehetőség felismerése. Az ehhez szükséges technikai bővítések "ipari ráerőszakolása" máris megjelent. (nem újdonság, hogy minden "gyártó" csinált valamit, a fejlesztők meg oldják meg, úgy hogy az mindenkinél jó legyen)

A képek és az egyediség mellett, máris jöttek a reklámok, később videótartalom, keresést megkönnyítő tartalmak, "legfrissebb, leggyakoribb és hasonló többlettartalmak", meg ami kellett ahhoz, hogy a dokumentum - megintcsak üzleti célzattal - szélesebb tömegeket érjen el, több látogatót vonzzon, nagyobb bevételt és jobb statisztikákat produkáljon.

Nem csoda, ha ezek után felmerül az igény arra, hogy az egyik blokk és tartalma más súlyú legyen, mint a másik, ahogy azt eredetileg ügyesen kitalálták a címeket tartalmazó <hX> tag-ek esetén. A tartalmak más oldalakhoz képest lehetőleg egyedibbek legyenek, többet, több szolgáltatást és lehetőséget nyújsanak (mint a másik weblapja).

A sok bővítés már mind egy-egy dokumentum szerves részét képzi és a konkrét tartalom, amiről az egész szól sokszor elvész ezekben és esetenként kb. mindegy is hogy mi az (lásd ilyen jellegű hírérték nélküli, likegyűjtő, stb. weblapok tömkellege).
És a többi vonzat persze: videókiszolgálás, hálózati forgalom, böngészők felkészítése, biztonsági kérdések, elterjedség-kompatibilitás, jogi kérdések, stb.stb.

Szerintem az újabb html verziók célja részben, hogy ezeket próbálják tisztázni és valamilyen érthetőbb, használhatóbb keretbe foglalni, bonyolultabb szerkezeteket egyszerűsíteni, könnyebben megvalósíthatóbbá és átláthatóbbá tenni, de az alapelvet megtartják - fő verzióváltás ide-vagy oda.

--

Feltétlen újra kellene-e gondolni a html-t? Például "beépített" funkciója legyen egy html dokumentumnak mondjuk egy 3D-s megjelenítés? Hatékony-e ez, kényelmes a fejlesztőknek, a felhasználóknak? Vagy céleszközöket gyártani adott problémára (mint pl egy-egy erre kiélezett speciális alkalmazás, ami mondjuk nem egy böngészőre épül).

Ugyanez a bajom az e-mailekkel is, ami az eredeti célját tekintve nagyon jó dolog, egyszerű, de a mai követelményeknek már a sok hekmány mellett sem feltétlen felel meg.
Ezekre a módosításokra, ahány cég, annyi féle megoldás és ki az aki szívni fog vele? A fejlesztő és a felhasználó. Is-is.

Az ilyen utólagos és nem kismértékű változások eredménye ez az érzés, ami gondolom a cikk íróját is ihlette: Belesűrítünk minden lehetőséget egy olyan "keretbe", amit nem erre találtak ki. Vagy csak megpróbáljuk azt valamilyen - a tech.fejlődést előre nem megjósolható módon - meghatározatlan mértékig bővíteni. Vagy a jelenlegi tapasztalatok alapján nyitunk egy új fejezetet és eltérünk a megszokottaktól?

Szerintem ezt úgyis az fogja meghatározni, hogy mire van igény és milyen áron.
És biztos, hogy nem csak egy irányt fog venni ez a dolog, főleg egy ennyire elterjedt technológia esetén, tehát a különböző megoldások nem feltétlen zárják ki egymást.
92

pártatlan. :)

Pepita · 2015. Jan. 10. (Szo), 23.22
Azért azt mindenképpen el kell ismerni, hogy Gábor megmozgatja a wl -t.

Szoktatok bármiről ennyit vitatkozni? :)

Amellett, hogy én inkább szeretnék pártatlan maradni a témában, meg kell jegyeznem, hogy az ellentábor is igen aktív. Ez azt is jelenti, hogy nem érzik biztosan az igazukat.

Mindezt jónak tartom, amíg nem személyes, addig jó vita.
108

Nem értem itt mik a problémák

MadBence · 2015. Jan. 11. (V), 18.18
Nem értem itt mik a problémák (vagy mi lenne a megoldás). Az, hogy az adat + megjelenítendő struktúra milyen kombinációban érkezik meg a klienshez, szerintem teljesen mindegy, ha fontos, hogy a Google is lássa a tartalmat, akkor léteznek megoldások. Egyébként meg nem valószínű, hogy a HTML+CSS+JS-t leváltaná valami a közeljövőben (és nem is kell!). Ha neked ez nem tetszik, használj valamit, ami elrejti ezeket a technológiákat (pl. Jade+Stylus+PureScript), választhatsz a csilliárd variáció közül (vagy valamit, amit helyetted már összeraktak)

A szemantikus web tényleg jó lenne, de a helyzet most elég reménytelen. Egyébként a Google ettől függetlenül szerintem elég jó munkát végez, nagyjából megérti a kereséseket. Ha neked struktúrált formában kellenek adatok, a legjobb esélyed a különböző API-k használata. Ha az API szolgáltatónak megéri, hogy publikus az API-ja, akkor hajrá, használd.
110

Sokmindent meg lehet

Hidvégi Gábor · 2015. Jan. 12. (H), 13.10
Sokmindent meg lehet valósítani a HTML alapú weben is, de ha elolvasod a cikket, kiderülhet, hogy nyomós érvek vannak az adatalapú web mellett (amelynek részhalmaza a HTML), ráadásul ezekből további előnyök következnek, ami egy következő írás témája.
111

Nekem tetszett a

tisch.david · 2015. Jan. 13. (K), 10.30
Nekem tetszett a problémafelvetés provokatív, vitára invitáló jellege és a téma is, ha a végkövetkeztetéssel nem is értek egyet. Köszi az írást!

Ha már irányváltás a téma: azt meg tudnátok mondani nekem, hogy abba az irányba miért nem fejlődnek (jobban?) a dolgok, hogy megszüntethessük a szerver és a kliens oldal közötti technológiai különbségeket? Nekem ugyanis a legnagyobb problémám az, hogy miért kell egy csomó mindent (pl. adatellenőrzések) kétszer lekódolni, egyszer egy szerver oldali nyelven egyszer meg JavaScriptben? Miért nem lehet mindent megírni egy szerver oldali nyelven, és bizonyos kódrészleteket egyszerűen delegálni a kliensre, aki azt ott hajtaná végre? Szerintem ez nagyon vagány lenne és nagyban megkönnyítené a munkánkat.

Üdv:

Dávid
112

a legnagyobb problémám az,

Hidvégi Gábor · 2015. Jan. 13. (K), 10.43
a legnagyobb problémám az, hogy miért kell egy csomó mindent (pl. adatellenőrzések) kétszer lekódolni
Miért kéne? Bőven elég a szerveroldalon ellenőrizni, hisz ott mindenképp kell. A POST kérések legtöbbször pártízbájtos nagyságrendűek, senkit nem vág földhöz, még a mobilneteseket sem, ha ilyeneket küldözgetsz. A válasz ráadásul hamar megérkezik, így a felhasználó csak extrém esetekben fogja észrevenni, hogy ha lassú a hálózat.

Emellett egyszerűsödik a kliensoldali kód, de a szerveroldali is, hisz az ellenőrzéseket nem kell két csoportra osztani aszerint, hogy ez le tud-e futni a kliensen vagy sem.
113

:D

szabo.b.gabor · 2015. Jan. 13. (K), 11.12
Több-e a semminél a valami? Ez itt a kérdés.

Sokszor elmondtuk már, hogy miért kell.
114

A semmi nem van, hanem nincs

Hidvégi Gábor · 2015. Jan. 13. (K), 11.51
Milyen semmiről beszélsz? Az ellenőrzés mindenképp lefut.

Lehet, hogy nem volt elég meggyőző az érvelésetek? Nagyjából abba az optimalizálási kategóriába sorolom a JS ellenőrzést, mint amikor az oldal CSS-ét két részre szedik, az elején egy kis stíluslapot töltenek be, ami a kezdőlap megjelenítéséhez szükséges, a végén pedig a többit. Lehet, hogy nyernek egy ezredmásodpercet a renderelésnél, cserébe bonyolódik a karbantartás. Egy jQuery használatával több időt vesztegetsz, mint pár feleslegesnek ítélt kéréssel.
115

Erről lemaradtam. Hol találok

pythonozok · 2015. Jan. 13. (K), 12.21
Erről lemaradtam. Hol találok valamit arról, hogy miért _kell_?
Hogy célszerű, kliens oldalon is ellenőrizni, az tiszta, de hogy kell/szükséges... ?
116

UX

szabo.b.gabor · 2015. Jan. 13. (K), 12.29
UX
117

Hol lehet találni arra

Hidvégi Gábor · 2015. Jan. 13. (K), 12.39
Hol lehet találni arra vonatkozólag számokat, hogy milyen input lagnál tartják a felhasználónak lassúnak az oldalt?
118

Nem feltétlenül a idő a baj.

MadBence · 2015. Jan. 13. (K), 13.13
Nem feltétlenül a idő a baj. Példa: jelszókritérium, legalább 8 karakter, 3 karakterosztály. Beírom, kétszer. Kitöltöm a többi dolgot, felküldöm szerverre (mondjuk pár másodperc meg is jön a válasz), jön a hibaüzenet, megint kitöltöm (kétszer), megint hibaüzenet (mert megint elrontottam). Oké, megint kitöltöm (kétszer), most meg az a baja, hogy a két beírt jelszó nem egyezik. Instant feedbacknél el sem tudom küldeni addig az űrlapot, amíg formailag hibás adatokat akarok küldeni, rögtön tudom javítani a hibákat.

Egyébként kb 1 mp az a határ, ami után a user úgy érzi, hogy valami dolgozik a háttérben, valamire várni kell.
120

Erőltetett példa

Hidvégi Gábor · 2015. Jan. 13. (K), 13.23
A fenti szcenárióban ki akadályoz meg abban, hogy
1, kiírd előre, hogy mik az adott mező kritériumai
2, a háttérben AJAX-szal küldözgesd az adatokat ellenőrzésre?

Ha már felhasználói élményről beszélünk.

Az egy másodpercet alátámasztja ez a két link. Tegyük hozzá, egy másodperc alatt sokminden történhet, akár megabájtos adatforgalom is lehet a háttérben. Tehát én nem aggódnék amiatt, hogy lassú lesz az az ellenőrzés.
121

Tulajdonképpen miért is kell

MadBence · 2015. Jan. 13. (K), 13.36
Tulajdonképpen miért is kell bonyolult (ajaxos) kliens oldali logikát, és szerver oldalit (mező validálása) megírni, amikor meg lehet oldani egyszerűen is?
Miben segít nekem a helyes kitöltésben az, hogy oda vannak írva a szabályok? (azon kívül hogy valószínűleg el sem olvasom, ha meg mégis, akkor sem garantálja, hogy helyes adatokat adok meg)
122

Tulajdonképpen miért is kell

Hidvégi Gábor · 2015. Jan. 13. (K), 14.11
Tulajdonképpen miért is kell bonyolult (ajaxos) kliens oldali logikát, és szerver oldalit (mező validálása) megírni, amikor meg lehet oldani egyszerűen is?
Mitől bonyolult az AJAX-os technika? Minden mező onchange eseményére ráteszed, hogy küldje el a tartalmát a szervernek.

A szerveroldali ellenőrzést mindenképp meg kell írni, azt nem tudod megspórolni, viszont a kliensoldalon a teljes ellenőrzési listának csak egy részhalmazát tudod csekkolni (~ formai követelmények). Miben egyszerűbb az, ha változik az űrlapod, akkor a kliensoldali kódot is frissíteni kell?

Miben segít nekem a helyes kitöltésben az, hogy oda vannak írva a szabályok?
Ha vesszük a fenti példádat (nyolc karakter, három karakterosztály), akkor ha nem írod ki ezt a szabályt, a felhasználóknak gyakorlatilag 99%-a elsőre biztosan el fogja rontani. Ezek után pontosan milyen felhasználói élményről beszélsz?
123

Nyilván jelezni kell, mik a

MadBence · 2015. Jan. 13. (K), 14.29
Nyilván jelezni kell, mik a formai követelmények. Viszont mindenképpen kell valami szerver oldali logikát is pluszban írnod az AJAX-os ellenőrzéshez. És különben is, minek egy plusz kör a szerver felé egy olyan művelethez, amit kliens oldalon is el lehet végezni?
125

Ellentmondasz magadnak:

Hidvégi Gábor · 2015. Jan. 13. (K), 14.50
Ellentmondasz magadnak: "Miben segít nekem a helyes kitöltésben az, hogy oda vannak írva a szabályok?" versus "Nyilván jelezni kell, mik a formai követelmények."

Viszont mindenképpen kell valami szerver oldali logikát is pluszban írnod az AJAX-os ellenőrzéshez.
Eleve van egy szerveroldali logikád a teljes űrlap ellenőrzéséhez. Mennyiből tart egy plusz feltételt beleírni, hogy például AJAX-os kérés esetén csak azon az egy mezőn dolgozzon?

És különben is, minek egy plusz kör a szerver felé egy olyan művelethez, amit kliens oldalon is el lehet végezni?
Mivel alapból a kliens megbízhatatlan, ezért az adatot mindenképp el kell küldeni a szervernek ellenőrzésre. Mint fentebb írtam, pár tíz bájtos a POST kérés, fejlécekkel mondjuk száz, az adatmennyiség kicsi, a válasz is, 1-2 tizedmásodperc alatt megvan, és akkor már nagyon lassúnak kell lennie a hálózatnak. Egytized másodperc az érzékelési határ, lásd fentebbi link, tehát a felhasználó nem fogja tudni megmondani, hogy hol történt a művelet. Még akkor sem, ha ötször rontja el, és ötször kell szerveroldalon ellenőrizni.

Ezek alapján a két megközelítés felhasználói élménye megegyezik, de a kód egyszerűbb abban az esetben, ha csak szerveroldalon ellenőrzünk.
126

Ellentmondasz magadnak:

MadBence · 2015. Jan. 13. (K), 15.16
Ellentmondasz magadnak: "Miben segít nekem a helyes kitöltésben az, hogy oda vannak írva a szabályok?" versus "Nyilván jelezni kell, mik a formai követelmények."

Mint már az előbb is írtam, semmi nem garantálja, hogy helyesen töltöm ki, hiába van odaírva.
Mivel alapból a kliens megbízhatatlan, ezért az adatot mindenképp el kell küldeni a szervernek ellenőrzésre.

Igen, ez megtörténik az űrlap tényleges elküldésekor.
Eleve van egy szerveroldali logikád a teljes űrlap ellenőrzéséhez. Mennyiből tart egy plusz feltételt beleírni, hogy például AJAX-os kérés esetén csak azon az egy mezőn dolgozzon?

Eleve van kliensoldali logikád (hiszen felküldöd a szerverre, hogy formailag oké-e). Mennyiből tart egy ajax helyett helyben ellenőrizni?
Mint fentebb írtam, pár tíz bájtos a POST kérés, fejlécekkel mondjuk száz, az adatmennyiség kicsi, a válasz is, 1-2 tizedmásodperc alatt megvan, és akkor már nagyon lassúnak kell lennie a hálózatnak.

Szoktál használni mobilt netezésre? Ott a gyors internet/megbízható hálózat elég ritka.
Ezek alapján a két megközelítés felhasználói élménye megegyezik, de a kód egyszerűbb abban az esetben, ha csak szerveroldalon ellenőrzünk.

Az mondat első felével nagyjából egyetértek (bár lassabb lesz a te megoldásod), a másodikkal nem.
  • A te megoldásodhoz bele kell nyúlni a szerver kódjába, és a kliensoldali részbe is.
  • Az enyémben elég kliensoldalon módosítani a kódot. A hátrány, hogy a feltételek több helyen is szerepelnek a kódban (kliens és szerveroldalon). Ha gyakran változnak a követelmények, akkor úgyis valamilyen konfigurációs állományban vannak benne a szabályok, amit a kliens is ismerhet, ilyenkor ezzel sem lehet probléma.
127

Mint már az előbb is írtam,

Hidvégi Gábor · 2015. Jan. 13. (K), 17.14
Mint már az előbb is írtam, semmi nem garantálja, hogy helyesen töltöm ki, hiába van odaírva.
Ha viszont nem írod oda, akkor csorbul a felhasználói élmény (hisz több lépésből tudja csak kitölteni a mezőt, ha elsőre nem áll a rendelkezésére elegendő információ). Azzal viszont nem lehet mit kezdeni, ha a felhasználó figyelmetlen.

»Mivel alapból a kliens megbízhatatlan, ezért az adatot mindenképp el kell küldeni a szervernek ellenőrzésre.«

Igen, ez megtörténik az űrlap tényleges elküldésekor.
Kliensoldalon jórészt csak formai dolgokat tudsz ellenőrizni, például hogy megfelel-e egy adott reguláris kifejezésnek a string. Ha előbb kliensoldalon ellenőrzöl csak, akkor csorbulhat a felhasználói élmény, hisz lehet, hogy csak az űrlap elküldése után derül ki, hogy az adott azonosítóval már regisztráltak, azaz össze-vissza kell ugrálni a mezők között. Pusztán szerveroldali ellenőrzésnél egy menetben ki tudsz írni minden hibaüzenetet a mező elhagyása után.

Eleve van kliensoldali logikád (hiszen felküldöd a szerverre, hogy formailag oké-e). Mennyiből tart egy ajax helyett helyben ellenőrizni?
Attól függ. Ha például a két oldalon nem egyezik meg a reguláris kifejezések szintaktikája, máris hátrányban vagy. Ha nem node.js-t használsz, akkor az ellenőrző függvényeket mindkét helyen meg kell írnod, ami növeli a hibázási lehetőséget.

Szoktál használni mobilt netezésre? Ott a gyors internet/megbízható hálózat elég ritka.
19 éve kezdtem netezni, 14 kilobites modemünk volt akkor, ami 1,7 kilobájtos letöltési sebességet jelent másodpercenként. Egy 400 bájtos (sok adat, fejléccel) kérdés-válasz azon is megvolt 0,25 másodperc alatt, ami bőven belül van az egy másodperces határon, feltételezem, hogy ennél többet tudnak ma a mobilhálózatok.

A te megoldásodhoz bele kell nyúlni a szerver kódjába, és a kliensoldali részbe is.
Az enyémben elég kliensoldalon módosítani a kódot.
Szimpla matek, nézzük az eseteket:

1, egyszerű űrlapküldés JS nélkül
- elküldés után minden mezőről megjelenik a hibainformáció

2, egyszerű űrlapküldés AJAX nélkül, plusz kliensoldali ellenőrzés
- minden ellenőrizhető mezőre teszünk egy kliensoldali ellenőrzést (formai)
- kliens- és szerveroldalon is meg kell valósítani a formai ellenőrzést

3, AJAX-os űrlapküldés, plusz kliensoldali ellenőrzés
- minden mezőre teszük egy AJAX kérést
- minden ellenőrizhető mezőre teszünk egy kliensoldali ellenőrzést (formai)
- kliens- és szerveroldalon is meg kell valósítani a formai ellenőrzést

4, AJAX-os űrlapküldés, csak szerveroldali ellenőrzés
- minden mezőre teszünk egy AJAX kérést

Legkevesebb munkával az 1-es és a 4-es jár, míg legtöbbel a 2-es és a 3-as. Több munka = több tévedési lehetőség.


A fentiek alapján egyértelmű, hogy a kliensoldali + szerveroldali ellenőrzés hátrányokkal jár a csak szerveroldali ellenőrzéshez képest:
  • bonyolultabb, duplikált kód, több hibázási lehetőség, ami növeli a fejlesztési és a karbantartási időt
  • A felhasználói élmény csorbulhat (a 2-es esetben).
A pusztán szerveroldali ellenőrzés akkor hátrányos, ha nagy adatmennyiséget küldünk vagy nagyon lassú a hálózat.

Tehát felhasználói élmény és a fejlesztés szempontjából mindenképp célszerűbb a csak szerveroldali ellenőrzést választani.
128

Ha viszont nem írod oda,

MadBence · 2015. Jan. 13. (K), 17.54
Ha viszont nem írod oda, akkor csorbul a felhasználói élmény
Szerintem ebben már megegyeztünk, hogy oda kell írni.
Ha előbb kliensoldalon ellenőrzöl csak, akkor csorbulhat a felhasználói élmény, hisz lehet, hogy csak az űrlap elküldése után derül ki, hogy az adott azonosítóval már regisztráltak, azaz össze-vissza kell ugrálni a mezők között.
Erre lehet jó az általad is javasolt AJAX-os megoldás.
Attól függ. Ha például a két oldalon nem egyezik meg a reguláris kifejezések szintaktikája, máris hátrányban vagy.
Azért ezt nem olyan nehéz lekövetni :).
Szimpla matek, nézzük az eseteket:
Én nem állítottam, hogy az én megoldásom a legegyszerűbb. Az teljesen tiszta, hogy a statikus html + dinamikus backend a legegyszerűbb. Ez UX szempontból borzalmas (az ellenkezőjéről eddig nem tudtál meggyőzni). UX szempontból a legjobb az azonnali visszajelzés, újratöltés nélküli flow (aka single page app). Ez nyilván nem a legegyszerűbb, de kellő körültekintéssel simán megoldhatók az általad említett problémák.
129

UX szempontból a legjobb az

Hidvégi Gábor · 2015. Jan. 13. (K), 18.08
UX szempontból a legjobb az azonnali visszajelzés, újratöltés nélküli flow
Ez csak elmélet, a legjobb lenne, ha számok is állnának mögötte. Jacob Nielsen szerint is egy másodpercnél van a határ, márpedig olyan válaszidőkhöz elég sok csillagnak kell rosszul állnia.

Egy szoftver szempontjából hosszú távon az egyszerűség is nagyon fontos, mind fejlesztés, mind pedig karbantartás szempontjából is.
135

Kipróbáltam a telefonomon, a

MadBence · 2015. Jan. 13. (K), 22.58
Kipróbáltam a telefonomon, a weblabor 12 mp alatt töltődött be úgy, hogy használható lett (lehet scrollozni, látszik a tartalom). Oké, írjuk az üres cache számlájára. Rámentem a friss menüpontra, újabb 5 mp volt a várakozási idő. Persze lehet, hogy ez csak egy szerencsétlen véletlen volt.
138

Szimpla matek

Hidvégi Gábor · 2015. Jan. 14. (Sze), 01.25
Töröltem a gyorstárat, így a kezdőlapot újratöltve 344 kilobájt tartalmat számolok, ami 12 másodperc alatt neked így 28k/sec sebességgel jött le. 400 bájt letöltése ekkor 0,014 másodpercet vesz igénybe, ami pont az észlelési határon billeg.
139

Desktopon nálam 200ms a

MadBence · 2015. Jan. 14. (Sze), 01.39
Desktopon nálam 200ms a válaszidő (a további kéréseket nem számolva), a DOMContentLoaded esemény 1000ms körül érkezik meg, azaz kb ennyi idő után használható az oldal. Ez még mindig elég messze van az instant feedbacktől. Gondolom egy olyan műveletnél, aminél valami dolga is van a szervernek, ott tovább romlik a válaszidő.
119

Célszerű (UX) vs. kell (??)

pythonozok · 2015. Jan. 13. (K), 13.22
Célszerű (UX) vs. kell (??)
124

Lovagolhatsz egy szavon, jó

szabo.b.gabor · 2015. Jan. 13. (K), 14.43
Lovagolhatsz egy szavon, jó nem kell. Győztél. Bszknr :D
131

Mert tehermentesíti a

inf3rno · 2015. Jan. 13. (K), 19.20
Mert tehermentesíti a szervert. Persze napi 1 felhasználós oldalaknál nem kell, mert minek...
137

Premature optimization

Hidvégi Gábor · 2015. Jan. 14. (Sze), 00.51
Sebesség problémájával akkor kell foglalkozni, ha felmerül. Hiába villámgyors az oldalad, ha ugyanaz történik, mint az ismeretségi körömben nemrég két céggel, hogy elfelejtettek marketingre költeni, aztán nem jöttek az ügyfelek, és kénytelenek voltak a weboldalt bezárni meg programozókat elküldeni.
140

Ugyanezt írtam.

inf3rno · 2015. Jan. 14. (Sze), 05.07
Ugyanezt írtam.
130

Léteznek ilyenek nodejs-ben

inf3rno · 2015. Jan. 13. (K), 19.20
Léteznek ilyenek nodejs-ben és javascripttel, de bármikor tudsz írni PHP-ban is olyan kódot, ami kliens oldalra generál a validációt konfigod alapján javascript kódot. Nem értem, hogy min akadtál fenn...
132

Nyilván bármit meg lehet

Hidvégi Gábor · 2015. Jan. 13. (K), 19.40
Nyilván bármit meg lehet oldani, de ne felejtkezz el az árról, amit fizetsz érte: a programod bonyolultabb lesz, több hibázási lehetőséggel, új kollega betanítása hosszabb lesz stb. Mindezt egy olyan előnyért (kicsivel gyorsabb válaszidő), amit a felhasználók 99%-a nem fog észrevenni.
133

És ezért a kicsivel gyorsabb

szabo.b.gabor · 2015. Jan. 13. (K), 21.33
És ezért a kicsivel gyorsabb válaszidőért képes a google akár szabványt megerőszakolni, új szabványokat létrehozni, szerverparkokat telepíteni a világ minden pontjára.

Elfogadom, hogy nem érdekel téged és neked kényelmesebb, de ne mondd egy szakmai oldalon, hogy nem számít, mert nem igaz.
145

Gondolom, hogy az SPDY-re

Hidvégi Gábor · 2015. Jan. 14. (Sze), 10.24
Gondolom, hogy az SPDY-re célzol. A Wikipédia oldala szerint az indikálta a fejlesztését, hogy sok weboldal egyszerre akár 60 lekérést is indít, lásd WordPress, de például a weblabor is elég sok css-sel és js-sel dolgozik. A HTTP-t eredetileg egy fájl kiszolgálására tervezték, amikor még jóval alacsonyabb volt a sávszélesség. Ma már jóval gyorsabb a net, ezért a protokollt is meg kell változtatni, ami teljesen nyilvánvaló probléma, én is tettem rá anno javaslatot. Tehát ebben az esetben a sebesség igenis számít.

A mostani szál is a sebességről szól, de a felhasználói élmény szempontjából, szóval az almát a körtével való hasonlítás esete. A fentiekben azt bizonyítottam, hogy egy átlagos kérést (aminél kérjük, hogy a szerver ellenőrizze az inputot), ami jellemzően kicsi (párszáz bájt utazik), 2-300ms alatt megkapunk, amit a felhasználó nem fog észrevenni, mert az észlelési határ közelében van. Ebben az esetben a sebesség (és az, hogy közben hálózati elérés és szerverterhelés van) nem igazán számít. Ha pedig eleve lassú az illető nete, akkor nem is biztos, hogy fogja használni.
146

Nyilvánvaló

pp · 2015. Jan. 14. (Sze), 11.47
Tehát akkor, összefoglalva:

A felhasználói élményt nem rontja a szerver oldalon történő ellenőrzés, mert gyorsan megkapjuk a szervertől a választ.

Ha mégse kapnánk meg elég gyorsan, akkor úgy leromlik a felhasználói élmény, hogy nem lesz felhasználó, tehát végül is nem romlik a felhasználói élmény, mert ugye "nemfelhasználónak" nincs felhasználói élménye, mert ő nem felhasználó.

Logikus és nyilvánvaló!
Hogy erre én nem gondoltam!

pp
142

Ez így nem igaz. Pl egyik

inf3rno · 2015. Jan. 14. (Sze), 05.21
Ez így nem igaz. Pl egyik ismerősöm java projektnél a teljes weboldalt, mindent egy java libbel generáltatott úgy, hogy egy deka HTML-t sem írtak le, igazából szerintem azt se tudják, hogy mi az. :D Baromi lassú lett, de működik. Szóval a fejlesztési idő lerövidült, mert magasabb absztrakciós szintre emelték a dolgot, és nem foglalkoztak ilyen apróságokkal, mint a HTML+javascript megírása vagy a kommunikáció, amit a keretrendszer legenerált helyettük.

Ezek olyan dolgok, hogy elég csak egyszer megírni, utána nagyjából automatizáltan megy az egész.
144

Túl van ez lihegve

bamegakapa · 2015. Jan. 14. (Sze), 10.19
Ez tipikusan nem az a feladat, ami bonyolítaná a kódot. Mivel a validátor konfigját a szerveren is tárolod valamilyen formában (hacsak nem kézzel írod minden mezőre, amit kétlek), nincs más dolgod, mint ezt átadni valamilyen módon a kliensnek (mondjuk egy JSON-ban). Ott implementálod a validátorfüggvényeket, amiket jónak látsz. Ami nincs implementálva, azt úgyis elkapja majd a szerver oldali validálás, vagy az általad javasolt módszert használja fallbacknak. Az alap validációk tipikusan nagyon könnyen tesztelhetőek, tehát a hibázási lehetőség lecsökken. Vagy használsz valamilyen kész eszközt (a Laravel validátor szabályaihoz pl. van több is, nemrég néztem). Újrafelhasználható, tehát egyszer írod meg, független, tehát nem bonyolít. Egyszerű, mint a faék, tehát betanításnál ha probléma lesz, nem ezzel lesz. Az alapvalidációk (pattern, number, min, max, stb.) általában lefedik az esetek több, mint 95%-át, ez jelentős spórolás a szerver baszogatásában, nagyon kicsi energiabefektetéssel.
134

+1

szabo.b.gabor · 2015. Jan. 13. (K), 21.36
+1
136

Nem akadtam fent, csak egy

tisch.david · 2015. Jan. 13. (K), 23.57
Nem akadtam fent, csak egy kicsit elengedtem a fantáziámat. :) A Node.js + javascript kombóval még nem próbálkoztam, ez a másik, Általad említett "megoldás" viszont nem pont az, amit én felvetettem.

Én láttam már olyan eszközt, amit jól el tudnék képzelni a webre kiterjesztve is, hogy van egy egységes szerver oldali kód, amiben bizonyos kódblokkok (ad absurdum egy-egy sor is akár) meg vannak jelölve, mint kliensen futtatandó logika, és ezek "folytatólagosan" futnak le, csak hol a szerveren, hol a kliensen. Ettől eltekintve egy munkamenetet alkotnak. Természetesen valamennyire eltér a szerver és a kliens eszközkészlete, de van egy nagy metszet, ami mindenhol használható, és nem kell kézzel AJAX-ozni, mert a háttérben ez az egész le van kezelve. A kliensről lehet pl. "közvetlenül" adatbázis lekéréseket is hívni, logikai tranzakcióba zárva, stb.

Egy ilyen megoldás szerintem forradalmasíthatná a webfejlesztést. Vagy nem. :) Engem mindenesetre felcsigázna.
141

Szerintem baromi nehéz lehet

inf3rno · 2015. Jan. 14. (Sze), 05.13
Szerintem baromi nehéz lehet követni egy ilyen rendszerben, hogy mi hol fut. Ha erre nincs szükség, mert nem akarsz egyedi komponenseket, hanem a lib automatizált megoldásai elegek neked, akkor műküdhet a dolog. Azt hiszem meteor ilyen: https://www.meteor.com/ izomorf megoldás. Egyelőre még én sem nagyon folytam bele a témába, de van több ilyen js lib is. Valahogy idegenkedek attól, hogy a programra bízzam mit hol futtat, de próbáld ki, hátha neked bejön, aztán írj cikket a tapasztalatokról! :-)
143

Nem tudom, hogy weben működő

tisch.david · 2015. Jan. 14. (Sze), 09.48
Nem tudom, hogy weben működő képes lenne-e a dolog, mert nagyon sokat feltételez a kliens oldali futtató környezetről. Azzal a termékkel, amit én láttam/használtam, kliens-szerver architektúrában működő, multi platformos mobil alkalmazásokat lehetett fejleszteni, és ott működött a dolog. Viszont ott sem a program döntötte el, hogy az adott sor a szerveren vagy a kliensen fusson-e, hanem a fejlesztő. A kódot egybeszerkesztve lehetett írni, és az editorban lehetett megadni, hogy mi hol fusson.

Én csak játszottam vele, de vannak fejlesztő kollégáim, akik üzleti alkalmazásokat is írtak ezzel. Szóval csak ezen merengtem el, hogy ez jópofa lenne webre is.
149

M2M

Hidvégi Gábor · 2015. Feb. 4. (Sze), 16.18