ugrás a tartalomhoz

Az AJAX kihívásai

Hidvégi Gábor · 2013. Már. 18. (H), 20.33

A fórumban kérdés merült fel egy AJAX-szal foglalkozó könyvvel kapcsolatban, ennek apropóján szeretném megosztani a véleményemet és a tapasztalataimat a témában. Bár egyre több helyen használják a technológiát, de a felmerülő gondokkal kevés írás foglalkozik.

Jó AJAX-ot használó weboldalt/alkalmazást nehéz készíteni. Ez részben annak köszönhető, hogy az internet technológiailag rossz alapokra építkezik, valamint sokan nem fordítanak elég figyelmet a dinamikus adatcserével járó problémákra. A leggyakrabban elkövetett hibák, amelyekkel eddig találkoztam:

1. Pusztán JavaScripttel állítanak elő bizonyos tartalmakat: jó példák erre az Origó galériái. Ha magát a markupot kliensoldalon, DOM műveletekkel generálják, az egyrészt lassú, másrészt, mivel a képek nevét és elérési útvonalát ígyis-úgyis valamilyen módon (statikusan vagy dinamikusan) bele kell írni a dokumentumba, ennyi erővel helyből szerveroldalon is el lehetne készíteni a kódot, hogy a keresők, valamint a kikapcsolt JavaScripttel böngészők is meg tudják nézni az oldalt. Ez utóbbi esetben a kész markupot a megfelelő helyre innerHTML segítségével szúrják be, de ez is ellentmondásos: ha ígyis-úgyis a szerveren készül a kód, akkor pontosan mit is nyerünk az AJAX-szal? Valamennyivel kevesebb adatot kell küldeni, tehát picivel gyorsabb lesz, de ugyanezt az élményt elérhetjük cache-eléssel is (Etag, Expires fejlécek), amire amúgy is szükség van. Így inkább csak bonyolultabb kód lesz a végeredmény, mert a plusz JavaScript újabb hibázási lehetőséget hoz magával.

2. Bizonyos tartalmat csak AJAX kéréssel kapunk meg: például a HWSW cikkei alatti fórumhozzászólások. Ehhez mindegyiknél külön kéréssel fordulnak a szerver felé, ahelyett, hogy amit lehetett volna, már az elején kitették volna a HTML-be. A sávszélesség a legtöbb esetben a szűk keresztmetszet, ráadásul komolyabb rendszerek esetén sok kódnak le kell futnia addig, amíg elő tudja állítani a kimenetet (például több osztályt kell létrehozni a lekérdezéshez, amik az eredeti HTML készítésekor már eleve rendelkezésre állhattak). Ez egy minden szempontból erőforráspazarló elgondolás, zéró gyakorlati haszonnal.

3. Túl sok tartalmat generálnak AJAX segítségével:például az eRepublik adatlapjai (regisztráció szükséges). Amint leérkezett az oldal váza, a $(document).ready()-ben rögtön indítanak pár kérést, hogy néhány további szekciót feltöltsenek. Ez ugye ennyi kérés, lassúak, mint azt az előző pontban kifejtettem, ráadásul sokszor JS-sel állítják elő a markupot. Ha harmadik fél szerveréhez is fordulnak (oldalletöltések számlálása, reklámok) vagy lassú a hálózat, akkor a $(document).ready() elég későn futhat le, és az így előállított kód később villanhat be. A fentiek miatt az oldal betöltődése után rövidesen a böngésző több másodpercre „lefagy”, még görgetni sem lehet (mindezt modern browseren, pluginek nélkül).

4. Használhatósági gondok: többek között a Randivonal oldalain (regisztráció szükséges) találkoztam olyannal, hogy az AJAX-szal betöltött tartalom bizonyos paramétereit (például hol állok a listában) nem az URL-ben, hanem a munkamenetben tárolják. Így, ha egy másik fülön megnyitottam ugyanazt az oldalt, és visszaléptem az elsőre, a lista alaphelyzetbe állt. Ezek mellett sok helyen az előre-vissza gombok működése is problémát okoz, vagy frissítéskor sem azt kapom, amit várok. Vagy egy másik anomália, hogy egy cikk alatt AJAX-szal jelenítik meg a hozzászólásokat, és ha azok között ellépek az n-edik oldalra, majd megnyomom a böngésző vissza gombját, akkor mit töltsünk be: az előző hozzászólásokat vagy az előző lapot?

5. A tartalom betöltését jelző animáció: ha elég gyors a hálózat és/vagy kevés adatot kapunk, nem hordoz információt a megjelenése, így az esetek túlnyomó többségében zavaró a bevillanása. Akkor van csak jelentősége, ha nem ilyen szerencsések a körülmények, ezért én általában 1,5-2 másodperc után szoktam kitenni, hogy a felhasználó lássa, a program dolgozik. Ugyanez igaz a Flash objektumoknál is, főleg akkor, ha a betöltendő SWF már a memóriában van. Visszatérve a HTML-re, nem túl szép megoldás az sem, amikor nem adják meg a képek méreteit (még akkor sem, ha azok fixek), így egy újabb adag kép betöltésekor a tartalmi szekció „ugrál”.

Kérdések

Mielőtt AJAX-ot használó fejlesztésbe vágnánk, érdemes feltenni pár kérdést.

  • Segíthet-e ez a technológia, és ha igen, miben?
  • Mennyit nyerhetünk vele?
  • Mennyit veszthetünk vele (pl. bonyolultabb kód, nehezebb karbantartás)?
  • Mik az alternatívák? (Például fix méretű tartalom esetén egy <iframe> használatával egy plusz sort sem kell kliensoldalon írnunk)
  • Milyen használhatósági (usability) problémák merülhetnek fel?
  • Meg tudom-e oldani a feladatot a célközönség által használt minden böngészőverzióban?

Ezek mellett nem szabad elfelejtkezni két kisebb csoportról: ha fogyatékkal élő látogatja meg oldalunkat, ő is tudja majd használni? Ő is be tud regisztrálni, be tud jelentkezni? Ha dinamikusan frissítem a tartalmat, miből fogja tudni, mi az, ami változott? A másik csoportba azok az emberek tartoznak, akik biztonsági okokból kikapcsolják a JavaScriptet, mert tudják, hogy a legtöbb támadást ennek a segítségével indítják.

Arról sem szabad elfelejtkezni, hogy a fejlesztők többsége nagytudású, sokszor Java alapú IDE-t használ, amelyek nem a gyorsaságukról híresek, emiatt kénytelenek az átlagnál erősebb hardveren dolgozni. Ez a tény, valamint az, hogy helyi hálózaton tesztelnek, elfeledtetheti velük azt, hogy az átlagfelhasználó messze nem rendelkezik ilyen feltételekkel. Nem ritka, hogy tíz-tizenöt szkriptet is betöltenek, biztos, hogy erre mind szükség van?

Mivel a gazdasági válságból még messze nem keveredtünk ki, ami ráadásul hazánkat még jobban érintette kiszolgáltatott helyzete miatt, technológiailag a konzervitizmus kifizetődőbb lehet. Ez különösen igaz olyan oldalaknál, amelyekből a megrendelőnek közvetlen vagy közvetett haszna van, s most különösen fontos, hogy mindenkit megfogjunk. Ne felejtsük: a weben a belépési és az elhagyási küszöb alacsony, azaz, ha valami nem úgy működik, nem azt kapják az emberek, amit elvárnának, nagyon könnyen továbbmehetnek a konkurenciához. Egy százaléknyi látogató elvesztése az internetről generált bevételt ugyanilyen mértékben csökkenti, így a sitebuildernek célszerű kétszer is meggondolni, milyen újítást szabad bevezetni, mert ez a kiesés az ő felelőssége. A cél nem feltétlenül az, hogy oldalunk látványos legyen, hanem hogy lehetőleg mindenkinél jól jelenjen meg, és jól működjön.

Kell-e?

Nem tudom, létezik-e, létezhet-e olyan weboldal vagy webes alkalmazás, ahol egyáltalán meg lehet oldani a teljesen dinamikus adatfrissítést, azaz azt, hogy ha megváltozik bármilyen állapot, mint az 4-es példában, vagy mondjuk az adatbázis bizonyos táblái módosulnak, akkor a kapcsolódó klienseknél, ahol ez szükséges, automatikusan frissítsük a megfelelő részeket (akár több megnyitott fülön). Ehhez rengeteg információt el kell tárolni a szerveren, ami eddig az URL-ben volt, vagy integrálni kell az alkalmazást az adatbázis motorjába, hogy értesüljünk a minket érintő eseményekről.

Mivel sem szabvány-, sem pedig böngészőoldalról nincs támogatása a dinamikusan frissülő tartalmaknak, jelenleg AJAX-ot használni weblapon nem tanácsolnám senkinek, mert annyit nem nyerünk vele, valamint egyszerűen annyi hibázási lehetőség van, ráadásul a technológiát használó oldalak és segédletek is szinte csak rossz példákat tudnak hozni. Egy webes alkalmazás már más tészta, de saját tapasztalatból tudom, hogy ott is óriási kihívás olyan backendet készíteni, amivel normális felhasználói élményt adhatunk a kliensen, hacsak nem lehetetlen.

 
1

Nem értek teljesen egyet

tihi · 2013. Már. 18. (H), 22.12
Nem értek teljesen egyet azzal, amit írsz. Én szeretek új technológiákat megismerni, új dolgokat kipróbálni, kísérletezni. Az AJAX jó! Ha egy tanulni vágyó olvassa amit írsz, biztosan elmegy a kedve az AJAX –tól.

Azt írod, hogy a javascript lassú. Az utóbbi időben elég sokat fejlődtek a javascript motorok. 3D –s animációk egész jó sebességgel futnak a böngészőben. Ennek fényében nem gondolnám, hogy DOM manipulációk problémát okoznának. Még kis terhelést le is vehetnek szerver oldalról.

Azzal egyetértek, hogy késői ajax betöltés a felhasználó számára idegesítő lehet, és akár még vissza is fog fordulni, de ez nem a technológia hibája.

Említed a visszalépés ( history.back ) problémát. Erre ott a pushstate. A modern böngészők mind támogatják. A példákat amiket említesz, nem technológiai problémák, sokkal inkább kivitelezési.

Kell-e? Igen! Nagyon interaktív jó dolgokat lehet vele művelni.
4

Kell-e? Igen! Nagyon

Joó Ádám · 2013. Már. 18. (H), 22.36
Kell-e? Igen! Nagyon interaktív jó dolgokat lehet vele művelni.


Fenntartva azt, hogy az aszinkron kérés jó dolog, és szinte minden oldalon meg lehet találni az alkalmazási területét, én is úgy vélem, hogy nagyon sok esetben teljesen indokolatlan a használata, főleg a hátrányai tükrében.

Gyors szerveroldali alkalmazásokkal is nagyon interaktív dolgokat lehet művelni.
7

Persze nem arra gondolok,

tihi · 2013. Már. 18. (H), 22.58
Persze nem arra gondolok, hogy ok nélkül mindent ajax-szal töltsünk be, viszont sok helyen nagyon is helye van.
Épp most találkoztam egy jó példával: Videomegosztó portál, kommentek lapozása. Nem lenne jó ha a videó nézése közben az oldal újratöltődésével, megszakadna a videó lejátszása.
Abban is biztos vagyok, hogy server oldali terhelés tekintetében is kevesebb erőforrás 5 komment leküldés, mint az egész oldalt újra generálni.
8

Erre tökéletes, csak nem

Hidvégi Gábor · 2013. Már. 18. (H), 23.07
Erre tökéletes, csak nem mindegy, hogyan oldod meg a feladatot. Lehet jól és rosszul, de ez nem mindenki számára egyértelmű.

(Off - Most akkor a videót nézed vagy a kommenteket? : )
10

Off-ra reagálva. Jogos a

tihi · 2013. Már. 18. (H), 23.42
Off-ra reagálva. Jogos a felvetés! Életszerű, hogy a kép kevésbé köti le a figyelmet, mint a videó hangja (Pl. zenéknél). Mondjuk írhattam volna a kedvencekhez hozzáadás példáját is, az talán kevésbé támadható logikailag. :D
6

A saját oldalodon azt

Hidvégi Gábor · 2013. Már. 18. (H), 22.52
A saját oldalodon azt csinálsz, amit akarsz. Az írás lényege, hogy ha pénzről van szó, a mai helyzetben érdemes előbb gondolkodni.
9

Én sem szeretem ha

tihi · 2013. Már. 18. (H), 23.26
Én sem szeretem ha indokolatlanul, és/vagy rosszul használják az ajax-ot. Ebben teljesen igazad van!
Arra gondolok, hogy inkább a felhasználás módján kellene változtatni, mintsem hogy kell -e használni vagy sem.

Gondolkodtam az elmúlt projekteken. Vajon több idő volt-e mondjuk egy form mentést ajax-szal megoldani, mint post-tal... Nem lehet időben szignifikáns a különbség, viszont a felhasználói élményben már igen.
2

Jaj!

T.G · 2013. Már. 18. (H), 22.25
Tényleg szükségesek az ilyen blogbejegyzések a Weblabor-ra?

Ezeket a vitákat azt gondoltam volna, hogy valamikor 2005-2006-2007 környékén már lezártuk...
3

A bejegyzések a szerzőik

Joó Ádám · 2013. Már. 18. (H), 22.32
A bejegyzések a szerzőik véleményét tükrözik, nem feltétlenül a szerkesztőség által mérvadónak tartott álláspontot. Aki nem ért egyet, azt biztatjuk, hogy szálljon vitába.
5

Hát akkor nem jól lettek

Hidvégi Gábor · 2013. Már. 18. (H), 22.49
Hát akkor nem jól lettek lezárva azok a viták. A hozott példák profi, internetből élő cégek weboldalairól származnak, ha ők nem tudnak jól használhatót alkotni, ahol van rá keret, akkor mások hogyan fognak? A bevezetőben hivatkozott könyv is elköveti az összes hibát, amit csak lehet.
11

Rossz a kérdés.

T.G · 2013. Már. 19. (K), 09.13
Alapvetően rossz a kérdés felvetés. Ha az a kérdés, hogy az Ajax-szal meg lehet-e oldani olyan problémákat, amiket Ajax nélkül nem lehet, akkor a válasz egyértelműen igen. (és innentől kezdve szerintem megkérdőjelezhető az egész fenti felvetés)

Viszont, ha az a kérdés, hogy használható-e hibásan/rosszul az Ajax, akkor természetesen az a válasz, hogy igen. De ezért nem a technikát kell megkérdőjelezni.

Előbb belinkeltem az alábbi videót, de ide is nagyon ideillik: http://www.youtube.com/watch?v=CvX241gK6gc
13

Alapvetően rossz a kérdés

Hidvégi Gábor · 2013. Már. 19. (K), 09.39
Alapvetően rossz a kérdés felvetés.
Melyik? Az, hogy az AJAX-os oldalak megvalósításakor vannak-e kihívások?
Ha az a kérdés, hogy az Ajax-szal meg lehet-e oldani olyan problémákat, amiket Ajax nélkül nem lehet, akkor a válasz egyértelműen igen. (és innentől kezdve szerintem megkérdőjelezhető az egész fenti felvetés)
Ezt te vetetted fel, és mindjárt meg is kérdőjelezed?
... használható-e hibásan/rosszul az Ajax ...De ezért nem a technikát kell megkérdőjelezni.
Ha van alternatíva, ami biztonsággal és egyszerűbben használható, akkor melyiket érdemes választani?
Előbb belinkeltem az alábbi videót, de ide is nagyon ideillik
Az utolsó bekezdést ajánlom a figyelmedbe. Egy webes alkalmazásnál megmondhatod, hogy mit használjanak, egy weboldalnál nem.
14

Elírtam. :)

T.G · 2013. Már. 19. (K), 09.52
A kérdés, amit feltettél, hogy "Kell-e?" (elég jól ki van emelve:)

Na jó, elírtam az én kérdésemet, tehát van-e olyan probléma, amit Ajax-szal meg lehet oldani, de Ajax nélkül nem. :) És erre lásd a belinkelt videót.

Autóvezetésben is sokan meghalnak, mégis feleslegesnek érzem azt hangoztatni, hogy ne használják, pedig az valóban sokkal veszélyesebb, mint az Ajax. :)
12

Modern Javascript technologiak

sandornemeth · 2013. Már. 19. (K), 09.37
Egyaltalan nem ertek veled egyet, sot! De lassuk kb pontokban megvalaszolva:

1.-2. Segithet-e ez a technologia? Mennyit nyerhetunk vele?
Igen, segithet, nem is keveset. Megpedig azert, mert sokkal dinamikusabb, interaktivabb oldalt (alkalmazast) lehet keszinteni ezzel a modszerrel. Es itt valoban alkalmazasokrol beszelunk. Egyre inkabb afele megy a web, hogy alkalmazasok osszessege legyen, nem pedig egyszeru weboldalakrol van szo. (ez a netes media oldalakra is igaz, lasd pl: http://www.theverge.com/)

3. Mennyit veszithetunk vele? (karbantartas)
Ha normalis modon irunk javascriptet, nem pedig script kiddie-kent, akkor semmit (javascriptben is leteszik TDD, MVVP framework, etc, hadd ne soroljam, redirect a google-hoz)

4. Alternativak? Iframe?
Iframe? - Azt hiszem ezt nem is kommentelem, nincs ertelme.

5. Milyen használhatósági (usability) problémák merülhetnek fel?
A W3C WAI-ARIA recommendation. JS dialogot, focusvaltast, etc-t is meg lehet benne csinalni. Van valahol egy Google I/O video a youtube-on errol, erdemes megnezni. Nem korlatoz a jol mukodo weboldalak es webalkalmazasok elkesziteseben.

6. Kikapcsolt JavaScript
Amennyiben ok valoban celkozonseg, ebben az esetben lehet erre optimalizalni, egyebkent nem erdemes.

7. "Nem tudom, létezik-e, létezhet-e olyan weboldal vagy webes alkalmazás, ahol egyáltalán meg lehet oldani a teljesen dinamikus adatfrissítést"
HTML5 Web Socket (StackOverflow), illetve a megfelelo fallbackek hasznalataval kenyelmesen lehet ilyet csinalni.

8. Nem ritka, hogy tíz-tizenöt szkriptet is betöltenek, biztos, hogy erre mind szükség van?
Erre megint csak egy link a valaszom: RequireJS r.js optimalizacio


9. Mivel sem szabvány-, sem pedig böngészőoldalról nincs támogatása a dinamikusan frissülő tartalmaknak

A facebook, a twitter (es a tobbi aprocska alkalmazas, amit emberek 10millioi hasznalnak naponta) sem mukodnek dinamikusan.


Szerintem ennek a bejegyzesnek cca 5 evvel ezelott lett volna letjogosultsaga...
15

Köszönöm a válaszokat! 1, A

Hidvégi Gábor · 2013. Már. 19. (K), 10.00
Köszönöm a válaszokat!

1, A "vadonban" nem te mondod meg, ki milyen böngészővel használhatja az oldaladat. Tudod-e biztosítani, hogy mindenki, aki az oldalra érkezik, megkapja azt, amiért jött? A megszokott eszközök használata ugyanúgy működik (frissítés, oda-vissza gombok, lapozás), mint ahogy megszokták? Ha új használati elemeket találsz ki, a felhasználót segíted a tanulásukban?

3, Ha az a ha ott ne lett volna! A bevezetőben hivatkozott könyv és a példák alapján sokaknak nem sikerült "normális módon" megoldani a feladatot.

4, Mi a baj az iframe-mel? Az, hogy sok helyen lehúzzák, mert nem tudják, hogyan kell használni? A legáltalánosabb példa: van egy fix méretű dobozod (például galéria), amiben lapozhatsz és/vagy a tartalma időnként váltakozik. Ezt megoldhatod AJAX-szal, de nem egyszerűbb egy iframe? A bemenet hasonló lesz (egy fájl, amiben tartalom van, jelen esetben HTML, amit a keresők is tudnak értelmezni), és egy sor scriptet nem kell hozzá, hogy működjön.

5, "JS dialogot, focusvaltast, etc-t is meg lehet benne csinalni." - Megcsinálta a programozó? Gondolt mindenre? Volt rá keret/idő?

6, A bejegyzés írásakor utánanéztem, világszinten 0,5-3,5% között van a kikapcsolt JS aránya, az EU-ban 2%. Ha van egy kereskedelmi oldalad, amelynek évi tízmillió forint bevétele van, ha abból 2% nem tudja használni, mert erre a csoportra nem gondolt a fejlesztő, oda fog-e menni a megrendelőjéhez, hogy: "Tisztelt megrendelő, itt van kétszázezer forint, hogy kompenzáljam a hiányosan elvégzett munkám miatt kieső bevételeit."?

7, Itt fontos továbbolvasni a bekezdést. Nem a kliensoldal frissítésével van gond, hanem azzal, hogy ha a szerveren megváltoztatsz egy adatbázisbejegyzést, akkor a klienseken, ahol az éppen meg volt jelenítve, kérdés nélkül frissüljön mindenhol.

8, Köszönöm a példát, látod, erről sem tudnak sokan.

9, Ezt nem igazán értem.
16

1. Mindenki =/= Celkozonseg.

sandornemeth · 2013. Már. 19. (K), 10.33
1. Mindenki =/= Celkozonseg. A celkozonsegre optimalizalsz, es elosegited, hogy mindenki tudja hasznalni a weboldaladat. Ez azt jelenti, hogy ha a celkozonseged IE8/FF18/Chrome25-t hasznal, akkor arra fogsz optimalizalni. Ha fokent mobil platformot hasznalnak, es mobilrol erik el az oldalt, akkor mobilra fogsz optimalizalni. Egyebkent pedig mindenkinek megjelenik az oldal. Mindent lehet ugy implementalni (pl. push state, bookmarkable url-ek akar single-page alkalmazasokban is!), hogy ezek a funkciok mukodjenek.

3. Konyv? LoL. Internet. Ott kurrens tudas van, ami folyamatosan fejlodik. Nezz utana, kerlek, de egy par link es eszkoz, csak igy bevezetonek: BackboneJS, AngularJS, QUnit, Yeoman, RequireJS (mar linkeltem), de meg szamtalan ilyen van. Tenyleg nem mennek ebbe bele, google pls.

4. IFrame: mert letezik ra jobb megoldas. Mert a keresok nem indexelik. Mert sokkal egyszerubben meg lehet hekkelni man-in-the-middle attackkal (elvegre eleg csak az iframe src-t atirni), mint egy javascriptes appot, vagy egy ajax lekerdezest, ami csak JSON-t var, es azt dolgozza fel utana.

5. A van-e penz/ido kerdese az egyetlen dologra vonatkozik: igenye van-e a megrendelonek, illetve celkozonseg-e. Ha igen, akkor lesz ra ido es penz. Ha nem, akkor nem. Ennek semmi, de semmi koze az AJAX-hoz magahoz.

6. Lasd 1. pont. Ha Celkozonseg, akkor erre ki lesz optimalizalva az oldal. Ha nem, akkor nem.

7. Ezek szerint fogalmad sincs, hogy mirol szol a web socket. Olvasd el legalabb ezt.

8. Szivesen :)

9. Arra probaltam celozni, hogy amit irtal ezzel a mondattal, az egy netto baromsag. Elnezest kerek a serto kifejezesert, de tenyleg az, mert amit te most itt lehuzol, arra epulnek az olyan egyszeru, es keves (par 10millio) felhasznalot egyidoben kiszolgalo alkalmazasok, mint a Facebook, a Twitter, a Google.

Udv,
Sanyi
17

Ha fokent mobil platformot

Poetro · 2013. Már. 19. (K), 10.45
Ha fokent mobil platformot hasznalnak, es mobilrol erik el az oldalt, akkor mobilra fogsz optimalizalni.

Ha nem használható az oldalad mobilról, akkor nem fogják használni. Ugyanez igaz minden más platformra, böngészőre. És nem tudod, ezzel mekkora piactól esel el.
18

Ez igenyfuggo. Elkepzelheto,

sandornemeth · 2013. Már. 19. (K), 11.13
Ez igenyfuggo. Elkepzelheto, hogy a nativ appnak nagyobb letjogosultsaga van, mint a mobilra optimalizalt verzionak (de ez mar fokent alkalmazasokra igaz, nem altalanos hiroldalakra).
19

1, A bankok úgy adnak hitelt

Hidvégi Gábor · 2013. Már. 19. (K), 11.28
1, A bankok úgy adnak hitelt a megrendelődnek szerinted, hogy "Számunkra a Chrome 24-es felhasználók pénze büdös, az oldalatok közelébe ne engedjétek!"?

3, A weblaboron is fel szokott merülni többeknél, hogy könyvből tanulnának szívesen.

4, Ha már benn vannak az oldaladon a támadók, teljesen mindegy, hogy iframe-et vagy ajax kérést hamisítanak.

7, Ismétlem: nem az adatok frissítésének technológiai problémája, ami nehezen megoldható. Egy egyszerűsített példa: van egy felhasználód, akinél az AJAX-os alkalmazásodban nyitva van egy termék, aminek az ára 70 000 forint, amit meg szeretne rendelni. Az illető kimegy WC-re, közben az adminisztrátor módosítja 75 000-re. Ha tökéletes kiszolgálást szeretnél nyújtani, nyilvántartanád, hogy melyik felhasználódnál jelenik meg bármilyen formában ez a termék, és abban a pillanatban frissítenéd, ahogy nálad, az adatbázisban változik. De ez nem egyszerű, mert lehet, hogy egy hosszú lista közepén van ott (tegyük fel, rászűrt a 68 - 72 000 forintos termékekre), amiből elvileg azonnal ki kéne esnie, amint változott az ára.

9, Mint írtam a bejegyzésben, Magyarországon vagyunk magyar körülmények között. A bankok nem adnak hitelt, vagy csak nehezen és keveset, ebből kell kihozni a legjobbat, és én úgy vélem, jelen helyzetben a konzervatív hozzáállás több pénzt hozhat a megrendelő konyhájára.
20

1. Pont a leirtak miatt

sandornemeth · 2013. Már. 19. (K), 11.46
1. Pont a leirtak miatt fontos a celkozonseg :) Arra kell optimalizalni.

3. Igen, felmerult mar, ellenben sajnos - es ezt mindenki kenytelen lesz belatni -, a legfrissebb eszkozok, az up-to-date tutorialok blogokban, a kerdesekre adott valaszok stackoverflow-n vannak. Egyesekre van konyv, de leginkabb angolul (pl a BackboneJS-re van itt, early release).

4. Nem az oldalamon vannak bent :) Es JS-ben meg kliens oldalon is tudom hitelesiteni az adatokat (ne adj' isten, ha nagyon secure akarok lenni, akkor crypto librarykkel encodeolni es decodeolni az adatokat - bar ez mar erosen elviszi a teljesitmenyt), es az esetleges fals adatokat kezelni, nem pedig nativ HTML-t tolok a user bongeszojebe, mint iframe-en keresztul.

7. Meg mindig meg lehet oldani :) Termeszetesen egy ilyen megoldast implementalni kell (pl ugy, hogy websocketen keresztul kipusholod, hogy megvaltozott egy termek ara, es JS-bol ujrafuttatod a szurest).

9. Nem ertek egyet. A megrendelo szamara az fogja a legtobb penzt hozni, hogyha jo minosegu, es az elvart kovetelmenyeknek megfeleloen alakitod ki az alkalmazast (btw egyebkent a server side-rol lehet vitatkozni, de nem hiszem, hogy terhelesbirasban akarmilyen server-side rendereles allna a sarat egy olyan szerveroldali app-pal, ami csak REST adatokat fogad es kuld, mert nincs rajta rendering terheles -> csokkeno uzemeltetesi koltsegek... a felhasznaloi elmeny fokozasaval).

Termeszetesen lehet 2005-os weboldalakat is fejleszteni, csak az valoszinuleg nem all osszhangban a megrendelo igenyeivel. Ha pedig nem ismered az eszkozoket (lasd elozo postokban linkelt eszkozok pl), akkor nyilvan nem is tudsz koltseghatekonyan fejleszteni, ami a megrendelonek is megerne, de ez ne legyen mar a technologia hibaja. Az pedig igenis a fejleszto felelossege(!), hogy megfeleloen tovabbkepezze magat (es ez a webes dolgokra gyakorlatilag napi szinten igaz - es a napi szinten meglevo up-to-date tudast nem lehet megszerezni konyvekbol), es igy a megrendelonek magas szinvonalu szolgaltatast tudjon nyujtani.
24

Ez a 7-es példa azért sántít,

nova76 · 2013. Már. 19. (K), 18.28
Ez a 7-es példa azért sántít, mert amikor bemegyek a közértbe egy újsággal a kezemben ami a múlt heti akciókat írja, akkor sem kapom meg azon az áron a terméket, ha amúgy a polcon van. De azért jellemzően a webshop árak nem változnak 2 percenként.
Egyébként nagyon nehéz az ajax pont egy terméklistánál. Hiszen ha veszek egy terméket, amivel pont elfogy a raktárról, akkor egy rossz logikával én csak a kosár tartalmát frissítem, és a termék meg ott marad a listában. Abban a listában, amiben a esetleg csak a raktáron lévő és rendelhető termékeket kéne látnom.
26

7: Megoldható az azonnal

inf3rno · 2013. Már. 19. (K), 18.40
7: Megoldható az azonnal frissítés, és ahogy fentebb is írták nem kell hozzá nagy mennyiségű adatot tárolni szerver oldalon. Lehet pusholni a változtatást websocket-en, de akár comet-tel is le lehet kérni bizonyos időközönként, hogy változott e valami az előző lekérdezés óta. Egyébként egyáltalán nem értem, hogy ez hogy jött a témába, egy sima html-t generáló webalkalmazás közelében sincs ennek a szintnek...

9: Elég furcsa azzal indokolni, hogy rossz az ajax, hogy a bankok nem adnak hitelt full ajax-os oldalak fejlesztéséhez. Jót mosolyogtam rajta... :-)
27

9: Elég furcsa azzal

Hidvégi Gábor · 2013. Már. 19. (K), 18.45
9: Elég furcsa azzal indokolni, hogy rossz az ajax, hogy a bankok nem adnak hitelt full ajax-os oldalak fejlesztéséhez. Jót mosolyogtam rajta... :-)
Nem tudom, ezt hol olvastad.
32

Jó, egy kicsit kiforgattam,

inf3rno · 2013. Már. 19. (K), 19.30
Jó, egy kicsit kiforgattam, amit írtál :D
33

:)

Pepita · 2013. Már. 19. (K), 19.55
Különben nekem nagyon tetszett, csak sejtettem, hogy Gábor "haragudni" fog érte, ezért nem mertem +olni. :)
34

Megbocsájtok neki, mert ő

Hidvégi Gábor · 2013. Már. 19. (K), 19.56
Megbocsájtok neki, mert ő alapból rendes ember : )
35

Haha :-)

inf3rno · 2013. Már. 19. (K), 20.10
Haha :-)
36

Kár

Pepita · 2013. Már. 19. (K), 20.26
Már kezdtem remélni egy kis lövöldözést, ilyesmit...
37

7. pont

szabo.b.gabor · 2013. Már. 19. (K), 21.51
Most én csak annyit kérdeznék, hogy sima HTML oldalnál ez hogy is van?
38

Irreleváns

Hidvégi Gábor · 2013. Már. 19. (K), 22.09
Egy sima HTML oldalnál tudod, hogy statikus tartalmat látsz, a kérdés pillanatában élő snapshot az adatokról, és manuálisan kell frissítened, hogy a legújabbakat kapd meg.

Egy dinamikus alkalmazásnál azt mondja a fejlesztő, hogy a frissítés problémáját átvállalja magára, és akkor, ha szerencséd van, gondolt mindenre, de bizonyos kompromisszumokat mindenképp kötnie kell, mint például a 7-es pontban leírt problémánál. És akkor ez az igazából nem más, mint fegyvernek látszó tárgy.
39

Ennyi erővel odateszek a

inf3rno · 2013. Már. 19. (K), 22.13
Ennyi erővel odateszek a lista elejére vagy végére egy szöveget, hogy a lista x dátumra vonatkozó adatokat közöl...

A felhasználók többsége nincsen tisztában azzal, hogy ajaxos oldalt lát, ha mondjuk beteszel egy pushstate-et, akkor semmi nem jelzi nekik... Nem is igazán értik a különbséget, szóval ez a probléma fel se merül bennük, max ha egy sima html-es oldaltól is azt várják, hogy az aktuális állapotot közvetítse, ne a letöltéskorit...
40

+1

szabo.b.gabor · 2013. Már. 19. (K), 22.32
+1
23

Mindenki =/= Celkozonseg. A

Hidvégi Gábor · 2013. Már. 19. (K), 18.25
Mindenki =/= Celkozonseg. A celkozonsegre optimalizalsz, es elosegited, hogy mindenki tudja hasznalni a weboldaladat. Ez azt jelenti, hogy ha a celkozonseged IE8/FF18/Chrome25-t hasznal, akkor arra fogsz optimalizalni.
Én úgy fejlesztek, hogy első körben működjön mindenkinél, és ha fel lehet dísziteni addícionális dolgokkal, akkor azokkal kiegészítem.
30

IE 5.5

sandornemeth · 2013. Már. 19. (K), 18.59
Ezek szerint te meg a mai napig foglalkozol IE 5.5 kompatibilitassal? IE6? :)

Jo ez mar tenyleg csak kotozkodes, de ketlem, hogy IE 5.5 kompatibilitast el tudnal adni a megrendelonek (foleg ha ez mondjuk +2 het meloval es 0.05% novekedessel jar). De ez az en velemenyem.
56

Ez olyan, mint ha azért

prom3theus · 2013. Már. 24. (V), 18.47
Ez olyan, mint ha azért építenél először felhőkarcolót, hogy utána abból takaros kis weekend ház legyen dömbtetőn.

Nem lehet, hogy a célközönséget azért így nevezik, mert ők a cél, az összes többi pedig másod-, harmad-, sokadlagos szempont?

Csak kérdezem, mert lehet, hogy az én fogalmaimmal van probléma.
57

Célközönség

Hidvégi Gábor · 2013. Már. 24. (V), 18.57
Ez olyan, mint ha azért építenél először felhőkarcolót, hogy utána abból takaros kis weekend ház legyen dömbtetőn.
Nem. Ez azt jelenti, hogy az időseket és a kismamákat figyelembe véve tervezed meg az épületet, azaz nem csak lépcsőn lehet felmenni.

Sosem tudod pontosan meghatározni a célközönséget. Tegyük fel, hogy a nagymama szeretné az unokáját meglepni egy csodálatos kütyüvel. Ő a célközönség? Nem. Az oldalnak fiatalosnak kell lennie? Igen, mert a legtöbben valószínűleg az unoka korosztályából nézik meg. Kell tudnia használnia a nagymamának az ősöreg böngészőjében az oldalt? Igen, mert ő is potenciális vásárló. Hány nagymama nézi meg az oldalt? Nem tudod.
63

Dehogynem

Pepita · 2013. Már. 24. (V), 22.10
Sosem tudod pontosan meghatározni a célközönséget.
De, muszáj a lehető legpontosabban meghatároznod, különben csak káoszt növelsz, nem webet építesz. Persze kezelni kell (valamennyire) a nem célközönséghez tartozó látogatókat is, de ettől ők még nem célközönség.

(Azért ne csak a nagyiról feltételezzük, hogy a böngészője (is) öreg! :))
76

Értem. Tehát szerinted az a

prom3theus · 2013. Már. 25. (H), 16.37
Értem. Tehát szerinted az a helyes tervezési-kivitelezési szemlélet, ha mondjuk egy uszoda köré salakos futó körpályát is építenek, mert hátha futók is fognak jönni az uszodába (hiszen ki tudja: aki futni tud, lehet hogy úszni is!)? o.O

Ezt a kifordított logikát képtelen vagyok asszimilálni egyszerűen. Kiveti magából az elmém. Az általad a profitmaximalizálás jelszava alatt álcázott durva kereskedelmi és logikai bukfenc alapját tehát az mozgatja, hogy csináljunk oldalt 100-ból 2 embernek azért, mert habár a 98 másik a célközönség, mégis az a 2 is HÁTHA, MAJD, VALAMIKOR, ESETLEG ott hagy az oldalon 3 fillért. A fejlesztési költségek pedig a kereskedelmi szempontból marginálisnak számító közönség kivételkezelése végett szökjenek az egekbe! Én nem állítom azt, hogy ez a cél - azt állítom, hogy ez a végeredmény!

Nem gondolod úgy, hogy ez több, mint furcsa?
77

szerintem

zzrek · 2013. Már. 25. (H), 16.58
Szerintem a lényege az, hogyha kétféleképp is építhetjük a medencét, melynek során az egyiknél szinte ugyanolyan költség mellett még egy futópálya is létrejön, akkor azt a módszert célszerű választani; márpedig a megrendelő nem ismerheti a módszereket, mert nem szakember, ezért a célt és ezzel a célcsoportot sem képes pontosan meghatározni. Ilyenkor vagy a megrendelőt eleve erről tájékoztatva, vagy anélkül (a megrendelő tudta nélkül) a jobb módszert kell választani, amivel akár a célcsoporton felül is optimálisan kiszolgálhatók az igények, ezzel a megrendelőnek is hozzáadott értéket hozunk létre. Mivel mi vagyunk a szakemberek, mi tudjuk mérlegelni, hogy mit tegyünk: tájékoztassuk a megrendelőt a lehetőségekről (mert úgy gondoljuk hogy képes felfogni és döntést hozni) vagy simán a saját minőségpolitikánk figyelembe vételével automatikusan a jobb minőségű eredményt biztosító módszer szerint valósítjuk meg a feladatot (azt feltételezve, hogy pont ez az elvárás: a szakterületünkön a felelősségteljes önálló szakmai döntéshozás)
79

Köszönöm

Hidvégi Gábor · 2013. Már. 25. (H), 17.01
Nem tudtam volna ilyen szépen megfogalmazni, van még hova fejlődnöm : )
80

márpedig a megrendelő nem

prom3theus · 2013. Már. 25. (H), 17.56
márpedig a megrendelő nem ismerheti a módszereket, mert nem szakember,

vs. (egyből ezután)
ezért a célt és ezzel a célcsoportot sem képes pontosan meghatározni

Kérlek, meg tudnád magyarázni azt, hogy a két mondatrészben szereplő állításod logikailag hogyan kapcsolódik egymáshoz, hogyan következik az elsőből a második? Az első egy kijelentésbe burkolt feltételezés (hiszen nem tudhatod, hogy ismerheti-e a módszereket), a második pedig vagy az ügyfeleid (ügyfeleink) általános nyílt ledegradálása, vagy egy általános sallang. De ha ezektől el is tekintek, semmilyen kapcsolatot nem találok a két állítás között.

Elég sok és sokféle ügyféllel volt már dolgom - informatikailag képzettel és technológiai analfabétával egyaránt - amióta (17 éve) a szakmában vagyok. A bizonytalankodásaik sora valóban felér anyaföldünktől a csillagos égig, de olyannal még nem találkoztam, aki ne tudta volna legalább azt megmondani, hogy mi a terméke és/vagy szolgáltatása célcsoportja. Onnantól pedig, hogy a célcsoport elhangzott és adott a termék/szolgáltatás, a fejlesztő/kivitelező (jelen esetben mi, jóbitmunkásemberek) dolga ezt elfogadni és ennek megfelelően megtervezni, megvalósítani a megrendelő számára az eszközt.
Időnként persze kérdezni kell ügyféltől - van hogy gyakran - de ezt megtanulni sokkal egyszerűbb és ésszerűbb, sőt költséghatékonyabb is mint az általatok vázolt úton magabiztos lendülettel belegyalogolni abba a tipikus fejlesztői hibába, hogy "mi mindent legalább 3x jobban tudunk az ügyfél vállalkozásáról, mint ő" és aztán jönnek az "ágyúval verébre"-típusú megoldások (amik többnyire vagy nem készülnek el és átadva se lesznek, vagy félkészen kerülnek átadásra, vagy 3x annyi idő alatt készülnek el és a végén tetemes kötbérrel kerülnek átadásra).

Eléggé veszélyes dolog ez a felsőbbrendű logika, kérem.

Persze, mindenki maga választja meg azt, hogy élete során hogyan nehezíti meg a saját dolgát, de ezt még hirdetni is - főleg egy szakmai oldalon - véleményem szerint nagyon súlyos probléma.

Ennek nagy kár lenne közönséget toborozni, mert sajnos így is túl széles a tábora.

Ügyfél az esetek legalább 95%-ában tisztában van azzal, hogy mit akar áruba bocsátani és kiknek szándékszik. Az, ha ezt a szándékot a fejlesztő nem érti, nem az ügyfél hibája. Kérdezni kell és a dolgok világossá válnak. Nem szégyen kérdezni. A feltételezések, amikbe bocsátkoztok egy-egy ilyen gondolatmenet alatt ugyanis - valódi mindent tudás hiányában - sokszor nem fognak egyezni az ügyfél realitásaival.
81

"mi mindent legalább 3x

Hidvégi Gábor · 2013. Már. 25. (H), 18.27
"mi mindent legalább 3x jobban tudunk az ügyfél vállalkozásáról, mint ő" - ezt senki sem állította. Az ügyfél ismeri a saját vállalkozását, a webes szakember meg a webet. Az ügyfél feladata, hogy minden információt megadjon a webes szakembernek, hogy az a munkáját elvégezhesse.

"ágyúval verébre" - pont az ellenkezőjét mondjuk, erre egyáltalán nincs szükség.

Egyébként nem igazán értem, miért ragaszkodsz annyira a célközönséghez. Annyit tudunk róluk, hogy böngészőt használnak. A grafikus felteszi a látványtervre a termékre jellemző képeket, esetleg keres képgyűjteményben (nem jut eszembe a pontos megnevezésük) olyan képeket, amivel a célcsoport azonosulni tud, ennyi. A kivitelezés már a fejlesztő dolga, és nem értem, miért baj, ha arra törekszünk, hogy a lehető legtöbb látogató számára legyen elérhető az oldal.
84

Meddő vita. Most pont azt

prom3theus · 2013. Már. 26. (K), 12.18
Meddő vita. Most pont azt állítod, hogy nem arról beszélsz, amiről beszélsz lényegében. Ezen a ponton úgy érzem, teljesen felesleges folytatnunk a vitát.
Ahogy a hozzászólások számát és tartalmát elnézem, egyébként sem érzem magamat egyedül azzal a legalapvetőbb problémával, hogy a bejegyzést nem sikerült megértetni, megfelelően átadni annak lényegét - ha sikerült volna, akkor nem tartanánk 80 hozzászólás fölött kb 3 nap alatt. Teljes a káosz, meg a félreértés, a félremagyarázás. Ha másból nem, ebből én biztosan arra következtetnék, hogy lenne pár dolog a gondolatmenetemben, amit érdemes lenne felülvizsgálnom, hátha valami nem stimmel benne - vagy abban, ahogyan előadtam.
82

Mielőtt magyaráznék

zzrek · 2013. Már. 25. (H), 19.07
Mielőtt magyaráznék, kérlek, hogy a mondanivalóm lényegét próbáld meg megérteni, ne pedig a hibát keresd benne. Nem tudok mindig teljesen pontosan fogalmazni, úgy pedig főleg nem, hogy aki szándékosan akar, az ne tudjon belekötni.

A lényeget tehát kiemelve, az összefüggés a két idézett részlet közt: a megrendelő nem szakember=>mi vagyunk a szakember=> a megrendelő nem is tudhat arról, hogy van egy része az internetnek/projektnek, amit ígyvagyúgy még figyelembe vehet, elérhet=> mi pontosíthatjuk a célcsoport fogalmát, és ha mégsem, az nem probléma, ha a célcsoporton felül más potenciális ügyfél elégedett a termékkel.

Persze, ha úgy értelmezed, hogy a szakmai tudásunk által a projekthez adott érték felsőbbrendűséget fémjelez, akkor így is kezelheted.

Ebből a szempontból az előző hozzászólásomból a "felelősségteljes önálló szakmai döntéshozás" részt szeretném kiemelni, de csak azért, hogy lásd, szerintem ezen a ponton egyezik a véleményünk (a "...3x jobban..." részre gondoltam, egyetértünk)

Tulajdonképp már nem is értem, hogy miben nem értünk egyet, a lényegben ugyanúgy gondolkozunk (a felelősségteljes, körültekintő munka, a megrendelő kéréseinek figyelembe vétele stb), talán az a különbség, hogy a "felhasználónak dolgozunk" szemlélet pozitív oldalát vagy a negatív oldalát hangsúlyozzuk-e ki :-)
Szerintem te is úgy gondolod, hogy azzal, hogy egy "nem robot" fejlesztőt kér meg a megrendelő, azzal a számára is hozzáadott érték keletkezhet, új aspektus merülhet fel (amit vagy önállóan bedolgozunk a projektbe, vagy megbeszéljük a megrendelővel -- ez is a mi szakmai felelősségünk)
A 74. hozzászólásban írtam még erről, talán abból is látszik, hogy mire gondoltam.
Szerintem ezen a ponton már szőrszálhasogatás folyik, amit akartunk, azt elmondtuk :-)
86

De itt igen

Pepita · 2013. Már. 26. (K), 21.17
Nem tudok mindig teljesen pontosan fogalmazni,...
De itt (fentebb) nagyon is pontosan megfogalmaztad, aki nem akarja - nem érti. Részemről is +1.
21

Kisebbség

Pepita · 2013. Már. 19. (K), 18.04
A többséggel ellentétben, írásod "többségével" egyetértek.
Ha egy kicsit kevésbé veted el a sulykot, nem szidod magát a technológiát (talán nem is egyértelműen szidtad, de mindegy), illetve jobban kiemeled azt az egy-két helyzetet, amikor jobb ajax-ot használni, mint mást - nos akkor erősen javasoltam volna a cikkajánlódba is, olvasgassák csak minél többen (főleg kezdők, akiknek "menő" az "ajax-os oldal").

Így viszont kissé túlzásnak érzem, bár a helytelen használat tényleg nagy divat.
25

A technológiával nincs baj,

Hidvégi Gábor · 2013. Már. 19. (K), 18.32
A technológiával nincs baj, én magam is kb. hat éve egy full AJAX alkalmazáson dolgozom. A gond ott kezdődik, hogy nehéz találni olyan leírást, amiben a fejlesztőt figyelmeztetik mindenre, ami szükséges. Nincs egy általános tananyag, amin végigmehet az illető, nincs szamárlétra. Ha megnézed a weblaboron a témába vágó fórumbejegyzéseket, mindegyiknél nyilvánvaló, hogy a kérdező kihagyott pár lépcsőfokot, talált a neten egy AJAX tutorialt, letöltötte a jQuery-t, átírta a stringeket a megfelelő helyen, aztán csodálkozik, ha a cserélt tartalomban nem működnek az eseményvezérlők.
29

Kezd egy kicsit zavarossa valni a dolog

sandornemeth · 2013. Már. 19. (K), 18.57
Szia,

az en reszemrol kezd egy kicsit zavarossa valni a dolog. 6 eve dolgozol valamivel, amit a vitaindito irasban huztal le a foldig gyakorlatilag. Nyilvan vannak hibai, es lehet hibasan is hasznalni (ahogy lehet csavarhuzoval falat bontani, csak problemas - es ettol nem a csavarhuzo lesz a szar).

Ha megnézed a weblaboron a témába vágó fórumbejegyzéseket, mindegyiknél nyilvánvaló, hogy a kérdező kihagyott pár lépcsőfokot, talált a neten egy AJAX tutorialt, letöltötte a jQuery-t, átírta a stringeket


Ez pedig nyilvanvaloan az ott kerdezo hibaja. Vagy esetleg kezdo, es nem olvasott el minden idevago anyagot, hanem inkabb kerdezett. Vagy nem is erdekli a megoldas melye annyira, hogy belemeruljon a temaba.

Ha ugy gondolod, hogy kellene egy ilyen anyag - esetleg konyv - es van affinitasod megirni, akkor tessek, elotted a lehetoseg :) Egyebkent ha kesz vagy, es publikaltad, akkor utana fogsz rajonni, hogy mindig lesznek ilyenek, akik a legegyszerubb problemat is felteszik valamelyik forumba (itthon weblabor.hu, prog.hu, kint nem tudom, stack overflown egesz jo kerdesek szoktak lenni). Ezt nem szabad zokon venni. Vagy segitesz nekik, vagy egyszeruen figyelmen kivul hagyod.

Velemenyem szerint az ilyen forumokon mindig felulreprezentaltak lesznek a kerdezok kozott a kezdo - vagy hozza nem erto - userek, egeszen egyszeruen azert, mert egy ido utan az ember megtanul utana menni a dolgoknak, es rajon, hogy az mennyivel jobb. Illetve kesobb mar megtanul StackOverflow-n kerdezni (tudom, hogy sokat emlegetem, de jelenleg az a de facto Q&A site), azaz mar joval kevesbe fog ide lecsapodni a dolog.
22

Én úgy gondolom, hogy

inf3rno · 2013. Már. 19. (K), 18.22
Én úgy gondolom, hogy bizonyos helyzetekben előnyös az ajax használata, bizonyos helyzetekben meg nem. Minden attól függ, hogy számít e egyes oldalak megtalálhatósága, számít e, ha kiesik a felhasználók egy bizonyos része, stb... Ezeket már egy projekt elején meg lehet mondani, és ezek alapján el lehet dönteni, hogy szükség van e ajax-ra, vagy sem az oldal bizonyos részein.
Például az admin oldalakat legtöbb esetben csak egy szűk kör használja, akiknél meg lehet nézni, hogy van e közöttük fogyatékkal élő, ill. meg lehet beszélni velük, hogy szükség lesz javascriptre a böngészőben. A nagyközönség által látogatott oldalakat ezzel szemben fel kell készíteni arra, hogy lesz, aki javascript nélkül használja őket.

A cikkben felsorolt hibák túlnyomó többségét el lehetett volna kerülni, ha egy kicsit jobban átgondolják, hogy ki lesz a célközönség.

Az átláthatóságról annyit, hogy egy javascript kliens egy rest service-el nekem sokkal átláthatóbb, mintha html-t használok, a kliens kódját pedig vegyítem a szerver oldali kóddal.
28

Egyetertek

sandornemeth · 2013. Már. 19. (K), 18.48
Az átláthatóságról annyit, hogy egy javascript kliens egy rest service-el nekem sokkal átláthatóbb, mintha html-t használok, a kliens kódját pedig vegyítem a szerver oldali kóddal.
31

Nagyon sok hasznos dolog

virág · 2013. Már. 19. (K), 19.09
Nagyon sok hasznos dolog összegyűlt a hozzászólásokban, jó volt végigolvasni, nem is nagyon maradt mit hozzáfűzni. Két dolog jutott eszembe, az egyik az, hogy sokan egy kicsit talán félreértették Hidvégi Gábor hozzászólását, sokan a JavaScript elleni támadásként élték meg, vagy egyenesen a "kőkorszakba" való visszalépésnek. Szerintem egyikről sincs szó a hozzászólásban, inkább tapasztalatok megosztásáról. A másik, hogy igenis van létjogosultsága a kritikus szemléletmódnak az ész nélküli újításokkal szemben, elég ha péládul felmész az index.hu-ra mondjuk Windows-os mobilról, az egész oldal használhatatlan, köszönhetően az új "fejlesztéseknek" - ami szerintem prototípusa a hozzá nem értésnek és egy igazi jó példa arra, hogy hogyan nem szabad újítani. Persze jó példákból is akad épp elég. Szerintem az Ajax önmagában jó és azokkal értek egyet, akik kihangsúlyozták, hogy egy eszköz nem lehet hibás azért, ha rosszul használják...szerintem ez a lényege az egész történetnek.
41

Hogy mire jó?

Gixx · 2013. Már. 20. (Sze), 12.41
Szerintem sok mindenre jó az AJAX. Nem olvastam el az összes hozzászólást, nézzétek el nekem, ha duplikálnék.

- Az weblaphoz tartozó, de az aktuális tartalomtól kvázi független (és nem létfontosságú) tartalmak betöltése, pl itt a Friss csiripek oldalt. És ha sok ilyen van, simán berakható JSON objektumba a különböző helyre rakandó DOM. Egyéb iránt a DOM-ot mindig a szerver oldalon generálom, sose a kliens oldalon. Utóbbi csak InnerHTML-ezhet. Ha nincs JS, max ezek a tartalmak nem jelennek meg.

- Formokat is jobban szeretek AJAX-szal POST-olni, mert így könnyebben megoldható a sikeres POST vagy a hiba visszajelzés és F5-re, illetve navigáláskor nem jön fel az "Újra küldés" figyelmeztető sem. Igaz ezt ki lehet védeni a szerver oldalon egy redirecttel, de az sok esetben macerásabb. Kliens oldalon nem túl bonyolult írni egy osztályt, ami ráül az onsubmitra és összegyűjti a megfelelő form elemeit, értékeit és úgy küldi el, ahogy azt kell. (Fájl feltöltés macerásabb, de arra is vannak megoldások, lásd pl Gmail). Ha nincs JS, a form úgy működik, ahogy amúgy is működne.

- Állapot változások lekérdezése, pl. itt a Friss csiripek. Adott időközönként bekérdez a szerverre új tartalomért. Bár most, hogy kezd terjedni a websocket support az még jobb erre, mert csak egy kapcsolat nyitás történik és onnantól a szerver szól, ha van valami.
42

pl itt a Friss csiripek

Joó Ádám · 2013. Már. 20. (Sze), 17.08
pl itt a Friss csiripek oldalt


Jól le is lessítja az oldalbetöltést.
43

Mire gondolsz lassú oldaltöltés alatt?

Gixx · 2013. Már. 21. (Cs), 09.36
Mire mondod hogy lassú? Arra, hogy várni kell, hogy betöltődjönek a tweetek?
Most képzeld el, ha ez nem AJAX-szal jönne, hanem a tartalommal együtt, akkor az egész oldal egy nagy fehér paca lenne hosszú pillanatokig a twitter api válaszideje miatt. Így legalább a lényeget látod egyből, mert helyi tartalom. Én speciel a Friss blogmarkokat szoktam átnézni elsőként.

Ha viszont neked a tweetek a legfontosabbak, akkor szerintem próbáld ki, hogy a twitter.com-on is megnézed, hogy ott gyorsabban jön-e a tartalom a #weblabor-ra szűrve (nem sokkal egyébként)...

A magam részéről továbbra is kitartok amellett, hogy a Friss Csiripek blokk kifejezetten jó, hogy AJAX-szal töltődik be.
44

Tipikusan a reklámok

Gixx · 2013. Már. 21. (Cs), 09.42
Egyébiránt az sokkal idegesítőbb, ha minden egyszerre töltődik be. Tipikusan a reklámokkal teletűzdelt oldalaknál jön ez elő, mert amíg be nem jön az összes nyomorék banner, addig sok esetben még scrollozni se tudok a böngészőben (FF is, Chrome is), annyira megfogják. És a reklámok tipikusan nem lokális tartalmak.
45

A magam részéről továbbra is

Hidvégi Gábor · 2013. Már. 21. (Cs), 12.47
A magam részéről továbbra is kitartok amellett, hogy a Friss Csiripek blokk kifejezetten jó, hogy AJAX-szal töltődik be.
Egyetértek, és szerintem egyébként nem is lassít.
48

Ha lassít, akkor még mindig

inf3rno · 2013. Már. 21. (Cs), 20.46
Ha lassít, akkor még mindig le lehet rántani curl-el, és kesselni a szerveren...
46

Form

Hidvégi Gábor · 2013. Már. 21. (Cs), 12.51
Az AJAX-os formok HTML-jét is minden esetben szerveroldalon generálod?
50

Függ az összetettségétől

Gixx · 2013. Már. 22. (P), 11.07
Alapjában véve igen, mert akkor JS nélkül is ugyanúgy tud működni, nem kell külön feldolgozót írni, és csak annyit kell megmondani, hogy ha AJAX-szal jött a POST, akkor ne legyen layout csak content, vagy mi több csak egy Block-ot generáljon le az egészből.

Amúgy egy egyszerű login esetén, ahol rendszerint két mező és egy gomb van, lehet, hogy egyszerűbb eleve az egész HTML-t visszaadni (mármint a form blokkját), mint egy eredmény JSON-t a hibaüzenetekkel. Ha meg mondjuk X db hibás próbálkozás után egy Catptcha elem is bekerül extraként, akkor meg pláne jobb, ha a biztonságot szolgáló elemet nem JS-sel generáljuk az űrlapba.

Viszont vannak olyan űrlapok (pl.: sok mezős, több lépcsős regisztrációs formok), ahol érdemes mérlegelni, hogy mi a jobb megoldás.
51

Sablonozással megoldható a

inf3rno · 2013. Már. 22. (P), 11.13
Sablonozással megoldható a html generálás is js oldalon, és a php-vel is ugyanúgy fel tudod használni ugyanazokat a sablonokat, ha ez szempont... Felesleges emiatt a szervert terhelni... Másik megoldás, hogy a szerver oldali nyelv is js. Mondjuk a harmadik meg, amit te írsz, hogy a szerveren generáltatsz mindent.
47

észrevétel

mikihetty · 2013. Már. 21. (Cs), 18.05
Nos olvasgattam a hozzászólásokat és persze azt kel mondjam mindkét félnek igaza van!
én sokszor és sok esetben használok ajaxot de csak ha annak helye van, vagy másként nem lehetne nagyon egyszerűen megoldani!

az alábbi szempontokkal szoktam főként foglalkozni:
-karbantartás mennyire nehézkes, vagy nehézkesebb
-mit akar a megrendelő
-az oldalnál min lesz a főú hangsúly az effekteken és dinamizmuson vagy a biztonságos és stabil működésen

én általában egy js framework ajax apiját szoktam használni, méghozzá azét amelyiket alapból használom már az oldalnál, hogy az ajax miatt külön ne húzzak be frameworkot, bár a js-eket általában szerveroldalon php-val összegyúrom és azt töltöm be mert úgy vettem észre ez javít elég sokat ha 2 frameworko-t használsz és 8-10 plugint kell a megrendelő igényei(mert ugye idő nincs sajátot fejleszteni a problémára ami az adott oldalon az adott funkcióhoz lenne maximálisan optimalizálva) miatt használni!

amire főként szoktam az ajaxot használni:
-pl az oldalon szereplő keresőnél ajaxal lekérem azokat amikre kereshet, az ügyfél általában örül az ilyen automatikus kiegészítéseknek!
-fomroknál ha a formon belül van ismétlődő szekció pl megrendelő formnál akkor egy add product gomb pl simán ajaxxal működik, ha le van kapcsolva a js akkor az add product semmilyen módon nem működhet az oldal teljes ujratöltése nélkül ami viszont rengeteg munkát róna a szerverre mert mindig az eddigieket vissza kellene tölteni, de js-el vagy createlement-ekkel összerakom amire szükségem van(ez azárt kicsit kellemetlen), vagy jquerye vel egyszerűen appanedelek egy html kódot de ugye minek égetném bele, egyszerűen az ismétlődő részt külön fájlba kiteszem és az add product-al mindig lekérem és appendelek, egyszerű megoldás, kikapcsolt js-el egyszerre 1 terméket rendel vagy egy ajánlatot kér....(az ilyen leginkább persze az ajánlatkéréseknél van ha nem kosaras rendszerrel működik valami)!
az oldalak admin felületén szoktam még ajaxot használni mert a megbízók szeretnek ajaxos admin felületen dolgozni hiszen az oldal nem töltődik újra nekik csak a megfelelő mezőben módosítanak egy értéket és azt már küldtem is a szervernek ajax-al,mojd csak közlöm vele a siker vagy sikertelenség tényét,ha ez kell nekik és tetszik nekik akkor ezt csinálom!
-az ellenőrzések szintén szoktam ajaxot használni, pl az űrlapon természetes hogy js-el is végzek ellenőrzést formai dolgokra, de előfordulhat hogy van olyan adat aminek a hitelességét csak szerveroldalon tudom ellenőrízni igy azt lekérhetem ajax-al igy tudom előre tájékoztatni hogy elrontotta, de ettől függetlenül a z úrlap szerveroldali feldogozása még ugyanugy ellenőrzi az egészet ezáltal a kikapcsolt js nincs különösebb hatással a müködésre főként csak a kényelemre!

amire soha meg sem fordult a fejemben az ajax: űrlapok feldogozása, oldal egyes részeinek utólagos betöltése galériák utólagos letöltése és megjelíntése mert ez mind sokkal egyszerűbb eleve kigenerálni és csak láthatóvá tenni,
én nem tartom be azt hogy js nélkül ugyanugy működjön egy weboldal mint vele mert nem tartom fontosank, de azt betartom mert fontos hogy js nélkül is használhatóü legyen az oldal minden funkciója mégha a kényelmi funkciók épp nem is érhetőek el
49

Hasogassunk szőrszálat, js

inf3rno · 2013. Már. 21. (Cs), 20.49
Hasogassunk szőrszálat, js nélkül is ugyanúgy elérhető minden funkció, ha valaki curl-el a megfelelő json-t elküldni a rest service-nek :D Amúgy igazad van :D
52

Mivel sem szabvány-, sem

tgr · 2013. Már. 24. (V), 15.09
Mivel sem szabvány-, sem pedig böngészőoldalról nincs támogatása a dinamikusan frissülő tartalmaknak, jelenleg AJAX-ot használni weblapon nem tanácsolnám senkinek, mert annyit nem nyerünk vele, valamint egyszerűen annyi hibázási lehetőség van, ráadásul a technológiát használó oldalak és segédletek is szinte csak rossz példákat tudnak hozni.

Ezen a ponton meg kell, hogy kérdezzem: a cikk szerzője készített az elmúlt öt évben bármilyen weblapot megbízásból, vagy tisztán ideológiai alapokról osztja az eszet? Mert a cikk eleje egyszerűen csak zagyvaság, de a végére olyan mértékben eltávolodik a valóságtól, hogy azzal nehéz mit kezdeni. Bármilyen kicsit is interaktív weboldal tele van olyan elemekkel, aminél egy professzionális fejlesztővel szemben (jogos) elvárás, hogy ajaxban oldja meg; tipikusan ilyen az adatbázist is igénylő form validáció (foglalt-e a felhasználónév?), a nem központi jelentőségű adatküldés (egy regisztrációs űrlapnál még elfogadható, ha az elküldése lapújratöltéssel jár, egy termékértékelő csillagos bigyónál vagy egy komment upvote/downvote-nál nem), a search suggestion, a chat integráció (nem feltétlenül ajax, de valami hasonló), a folyamatosan frissülő információk (mondjuk egy újságnál a percről-percre friss hírek), a galériák. És hát persze van egy csomó minden, ami külső szolgáltatást használ, ami feleslegesen lassítaná az oldal betöltődését, ha várni kéne rá. Twitter feed, ajánlórendszer, ami éppen.
53

Köszönöm a hozzászólást! a

Hidvégi Gábor · 2013. Már. 24. (V), 16.19
Köszönöm a hozzászólást!

a cikk eleje egyszerűen csak zagyvaság
Mi nem tiszta? A példák leírása? Lehet kérdezni.
Az említett hibák konkrét, professzionális fejlesztők által készített oldalakon léteznek.

egy regisztrációs űrlapnál még elfogadható, ha az elküldése lapújratöltéssel jár, egy termékértékelő csillagos bigyónál vagy egy komment upvote/downvote-nál nem
Miért nem?

a folyamatosan frissülő információk (mondjuk egy újságnál a percről-percre friss hírek), a galériák
Egy oldal újratöltésénél a reklámok is frissülnek, gondolt-e erre a fejlesztő?

És hát persze van egy csomó minden, ami külső szolgáltatást használ, ami feleslegesen lassítaná az oldal betöltődését, ha várni kéne rá.
A cron-t és a szerveroldali cache-elést biztosan nem kell bemutatnom, ráadásul ha van egy nagyforgalmú site-unk, miért terhelje tízezer felhasználó a twitter szerverét feleslegesen, ha ezt mitőlünk elég egyszer megtenni?

A dinamikus tartalomcsere bevezetésével túl sok a buktató, amibe beleszaladhatunk, ezek egy részét felsoroltam az írásban, egy része a kommentekben derült ki. Ezek túlnyomó többsége egy statikus oldalon nem létezik, tehát ennyivel egyszerűbb lesz a kód, a karbantartás. A legfontosabb megállapítás, hogy a konzervatív szemlélet több látogató számára teszi elérhetővé ugyanazt a tartalmat – ez az érdeke a látogatóknak és a megrendelőknek is. Az AJAX-os megoldások hoznak-e új látogatókat?

A legfontosabb kérdést pedig a végére hagytam:
Bármilyen kicsit is interaktív weboldal tele van olyan elemekkel, aminél egy professzionális fejlesztővel szemben (jogos) elvárás, hogy ajaxban oldja meg
Ez kinek az elvárása?
54

Mi nem tiszta? A példák

tgr · 2013. Már. 24. (V), 18.01
Mi nem tiszta? A példák leírása? Lehet kérdezni.
Az említett hibák konkrét, professzionális fejlesztők által készített oldalakon léteznek.

Nem annyira "nem tiszta", mint inkább nagyrészt hülyeség. Mennyivel lassabb például kliensoldalon összerakni egy pár tíz elemből álló DOM fát, mint szerveroldalon? Vagy honnan vetted azt a marhaságot, hogy a sávszélesség a szűk keresztmetszet? Szinte mindig az adatbázis a szűk keresztmetszet, másodsorban meg a szerveroldali kód - amin azzal lehet segíteni, ha cache-eled az oldalt, mondjuk egy reverz proxyn, és a dinamikus részt külön AJAX requesttel töltöd be. (A példának hozott HWSW nálam - külföldről, tehát sávszél szempontjából extrán hátrányos helyzetben - 4860 ms alatt jeleníti meg az oldalt, ebből 89ms, azaz kicsit kevesebb, mint 2% a kommentek betöltése.) Stb, majd minden pontodra jut valami súlyos tévedés.

egy regisztrációs űrlapnál még elfogadható, ha az elküldése lapújratöltéssel jár, egy termékértékelő csillagos bigyónál vagy egy komment upvote/downvote-nál nem

Miért nem?

Túl lassú, megtöri az oldal böngészésének folyamatát, nem fogja használni senki.

a folyamatosan frissülő információk (mondjuk egy újságnál a percről-percre friss hírek), a galériák

Egy oldal újratöltésénél a reklámok is frissülnek, gondolt-e erre a fejlesztő?

Ha mind a három felhasználód, aki hajlandó folyamatosan kézzel frissítgetni az oldalt, hogy megkapja az új híreket, új reklámot kap minden frissítésnél, az nem valószínű, hogy pótolja a többi felhasználó elvesztésével kieső bevételt. (Arról nem beszélve, hogy a weben szinte kizárólag átkattintásért fizetnek, úgyhogy sok reklámot mutatni nem feltétlenül jövedelmező.)

Ezzel együtt van nagy magyar híroldal, ami nem tudta ezt okosabban megoldani, minthogy időnként frissíti az oldalt, de az ilyet büntetni kéne, nem jó példaként bemutatni. (Háttérben is eszi a procit, nem lehet offline használni...)

És hát persze van egy csomó minden, ami külső szolgáltatást használ, ami feleslegesen lassítaná az oldal betöltődését, ha várni kéne rá.

A cron-t és a szerveroldali cache-elést biztosan nem kell bemutatnom, ráadásul ha van egy nagyforgalmú site-unk, miért terhelje tízezer felhasználó a twitter szerverét feleslegesen, ha ezt mitőlünk elég egyszer megtenni?

Ha nagy forgalmú a site, akkor valószínűleg reverse proxy mögött van, amit nem akarsz invalidálni minden alkalommal, ha valaki eltwitteli magát. (Ha kis forgalmú, akkor meg igyekszel spórolni a karbantartásán, és szerveroldalon tárolni a tweeteket felesleges komplexitás.) A Twittert meg nem valószínű, hogy meghatja, hogy százezer requestet kap másodpercenként, vagy százezertizet.

A dinamikus tartalomcsere bevezetésével túl sok a buktató, amibe beleszaladhatunk, ezek egy részét felsoroltam az írásban, egy része a kommentekben derült ki. Ezek túlnyomó többsége egy statikus oldalon nem létezik, tehát ennyivel egyszerűbb lesz a kód, a karbantartás.


Ha csupa html fájlból áll az oldalad, azt még egyszerűbb karbantartani... nem igazán ez az elsődleges szempont egy fejlesztésnél.

A legfontosabb megállapítás, hogy a konzervatív szemlélet több látogató számára teszi elérhetővé ugyanazt a tartalmat – ez az érdeke a látogatóknak és a megrendelőknek is.


Tizedszázalék nagyságrendű látogatóról van szó tipikusan, azokkal összemérhető, akik nem tudják használni IE7 alatt az oldalt, mert szétesik a dizájn. Pluszmunkával meg lehet oldani, ahogy az ajax mögé is lehet pluszmunkával graceful degradationt tenni; a pluszmunka általában többe kerül, mint amennyi hasznot hoznának az extra látogatók, úgyhogy a cégek nem foglalkoznak vele.

Bármilyen kicsit is interaktív weboldal tele van olyan elemekkel, aminél egy professzionális fejlesztővel szemben (jogos) elvárás, hogy ajaxban oldja meg

Ez kinek az elvárása?


Azé, aki fizet a fejlesztésért, és cserébe minél több látogatót szeretne, akiknek nem okoz fájdalmat az oldal használata. Ezért érdeklődtem, hogy volt-e dolgod mostanában ilyen úriemberekhez, mert komolyan meglepődnék, ha valami komolyabb webes műhelyben dolgoznál, és ott lenyelnék ezeket az elméleteidet.
55

Mennyivel lassabb például

Hidvégi Gábor · 2013. Már. 24. (V), 18.40
Mennyivel lassabb például kliensoldalon összerakni egy pár tíz elemből álló DOM fát, mint szerveroldalon?
Annyival, hogy ha gyors HTML-t szeretnél, akkor nem DOM fát kezdesz el építgetni, hanem innerHTML-lel szúrod be a kész kódot, mert sokszoros a sebességkülönbség.

Vagy honnan vetted azt a marhaságot, hogy a sávszélesség a szűk keresztmetszet?
A mobilnetem inspirálta, amit, ugye, egyre többen használnak.

Stb, majd minden pontodra jut valami súlyos tévedés.
Kifejtenéd?

Túl lassú, megtöri az oldal böngészésének folyamatát, nem fogja használni senki.
Ez valami megérzés? Az AJAX elterjedése előtt is működtek ilyenek.

az nem valószínű, hogy pótolja a többi felhasználó elvesztésével kieső bevételt
Milyen többi felhasználó elvesztéséről beszélsz?

nem akarsz invalidálni minden alkalommal, ha valaki eltwitteli magát
Ki mondta, hogy percenként kell frissíteni?

Ha csupa html fájlból áll az oldalad, azt még egyszerűbb karbantartani... nem igazán ez az elsődleges szempont egy fejlesztésnél.
Akkor micsoda?

Tizedszázalék nagyságrendű látogatóról van szó tipikusan
Európában átlagosan 1-1,5%, USÁ-ban 2% között vannak látogatók kikapcsolt JS-sel. Egy tízmilliós bevételű oldalnál ez évi 100 000 forint kiesést jelent, ami a fejlesztő felelőssége, ha JS-től vagy AJAX-tól tette függővé a vásárlást (aminek a része a regisztráció is).

A site-ok túlnyomó többsége jQuery-t használ a dinamikus adatfrissítésre, aminek az 1.9-es verziójától már nincs rendes támogatás a régi IE-kre, máris nem csak 1-2%-ról beszélünk.

Pluszmunkával meg lehet oldani, ahogy az ajax mögé is lehet pluszmunkával graceful degradationt tenni
Mi a pluszmunka? Nem célszerűbb eleve statikusra megcsinálni, és kiegészíteni AJAX-szal?

Azé, aki fizet a fejlesztésért, és cserébe minél több látogatót szeretne
Te a megrendelőnek készíted az oldalt?
58

jQuery 1.9

complex857 · 2013. Már. 24. (V), 19.24
Egy apró tárgyi tévedés:
A site-ok túlnyomó többsége jQuery-t használ a dinamikus adatfrissítésre, aminek az 1.9-es verziójától már nincs rendes támogatás a régi IE-kre, máris nem csak 1-2%-ról beszélünk.

jQueryből a 2.x széria az ami dobja old IE supportot (az általad linkelt oldalról, kiemelés tőlem):
jQuery 1.9 (early 2013): We’ll remove many of the interfaces already deprecated in version 1.8; some of them will be available as plugins or alternative APIs supported by the jQuery project. IE 6/7/8 will be supported as today.
59

Mennyivel lassabb például

tgr · 2013. Már. 24. (V), 19.32
Mennyivel lassabb például kliensoldalon összerakni egy pár tíz elemből álló DOM fát, mint szerveroldalon?

Annyival, hogy ha gyors HTML-t szeretnél, akkor nem DOM fát kezdesz el építgetni, hanem innerHTML-lel szúrod be a kész kódot, mert sokszoros a sebességkülönbség.

Az egy teljesen akadémikus szempont, hányszoros a sebességkülönbség (vö. egy vagy két idézőjelet használjunk PHP-ben és hasonló marhaságok), a lényeg az, nyersz-e a teljes oldalmegjelenítéshez viszonyítva számottevő időt. Ha nem (és nem), akkor nem kell foglalkozni vele.

Vagy honnan vetted azt a marhaságot, hogy a sávszélesség a szűk keresztmetszet?

A mobilnetem inspirálta, amit, ugye, egyre többen használnak.

Mobilra külön oldalt szokás csinálni, a HWSW-nek is van. Ott nem AJAX-szal töltődnek a kommentek.

Túl lassú, megtöri az oldal böngészésének folyamatát, nem fogja használni senki.

Ez valami megérzés? Az AJAX elterjedése előtt is működtek ilyenek.

Meg a WWW elterjedése előtt is lehetett internetezni gopherrel. So what? A mai oldalakkal vagy versenyben, nem a tíz évvel ezelőttiekkel, a ma elvárt szintet kell hoznod, ha azt akarod, hogy látogatóid is legyenek.

Ha csupa html fájlból áll az oldalad, azt még egyszerűbb karbantartani... nem igazán ez az elsődleges szempont egy fejlesztésnél.

Akkor micsoda?

Hogy a fejlesztés árának és a fejlesztés által generált profitnak a különbsége maximális legyen. Ha nem fejlesztesz semmit, vagy mondjuk egy darab under construction gif az oldalad, azt például roppant egyszerű karbantartani, mégsem egy nyerő üzleti stratégia.

Tizedszázalék nagyságrendű látogatóról van szó tipikusan

Európában átlagosan 1-1,5%, USÁ-ban 2% között vannak látogatók kikapcsolt JS-sel. Egy tízmilliós bevételű oldalnál ez évi 100 000 forint kiesést jelent, ami a fejlesztő felelőssége, ha JS-től vagy AJAX-tól tette függővé a vásárlást (aminek a része a regisztráció is).

Szerintem a YDN felhasználótábora nem éppen tipikus ilyen szempontból. Nem tudok más adatot (ahogy elnézem, nem is nagyon van más kimutatás), nekem egy nagyságrenddel kisebb számok rémlenek az utolsó munkahelyről, ahol láttam ilyeneket. Talán más tud pontosabb számokat.

Mindenesetre viszonyításként, 100.000 forint durván egy fejlesztő háromnapi munkájának a költsége, ha ennél több munka a teljes oldalhoz javascript-mentes fallbacket csinálni (ugye nem az AJAX az egyetlen, ami ilyenkor kiesik), akkor már negatívban vagy. Az én tapasztalatom, több különböző piacvezető e-commerce cégnél, az, hogy nem bajlódnak vele.

Mi a pluszmunka? Nem célszerűbb eleve statikusra megcsinálni, és kiegészíteni AJAX-szal?


Az a pluszmunka. Általában egyáltalán nem csinálod meg statikusan, más HTML elemeket igényelne, külön dizájnt, külön logikát, kétszer kell tesztelni...

Te a megrendelőnek készíted az oldalt?


Itt akkor megállok, és harmadszor is megkérdezem, hogy dolgoztál-e már komolyabb cég weboldalán? :-)
60

a lényeg az, nyersz-e a

Hidvégi Gábor · 2013. Már. 24. (V), 20.19
a lényeg az, nyersz-e a teljes oldalmegjelenítéshez viszonyítva számottevő időt
Én is hoztam példát, és a kommentelők is jelezték, hogy a jelenség létezik (amikor megakad a böngésző akár másodpercekre), tehát szempont.

Mobilra külön oldalt szokás csinálni
Ha belefér a keretbe.

»Ha csupa html fájlból áll az oldalad, azt még egyszerűbb karbantartani... nem igazán ez az elsődleges szempont egy fejlesztésnél.

Akkor micsoda?«

Hogy a fejlesztés árának és a fejlesztés által generált profitnak a különbsége maximális legyen.
ha százalékokat vesztesz egy hanyagul kivitelezett AJAX-os oldallal, az a profitmaximalizálást segíti?

ha ennél több munka a teljes oldalhoz javascript-mentes fallbacket csinálni
De miért butításban kell gondolkodni?

Általában egyáltalán nem csinálod meg statikusan, más HTML elemeket igényelne, külön dizájnt, külön logikát, kétszer kell tesztelni...
Feladata válogatja, elég sokmindent meg lehet oldani CSS-sel, grafikusan, de úgy, hogy közben minden megvan szövegesen is.
70

Te a megrendelőnek készíted

sandornemeth · 2013. Már. 25. (H), 11.00
Te a megrendelőnek készíted az oldalt?


Te nem? :)
71

Nyilvánvaló

Hidvégi Gábor · 2013. Már. 25. (H), 11.27
Nem.
72

Nagyon irigykedem rad :)

sandornemeth · 2013. Már. 25. (H), 11.50
Nagyon irigykedem rad :)
73

Van is miért : )

Hidvégi Gábor · 2013. Már. 25. (H), 12.17
Van is miért : )
61

Fejlesztői felelősség

Hidvégi Gábor · 2013. Már. 24. (V), 21.27
Egy rendkívül fontos témáról valahogy mindig elfelejtünk beszélni. Bár a weblaboron alapvetően technológiával foglalkozunk, úgy vélem, egy fejlesztőnek más szempontok alapján is kell döntéseket hoznia, hogy jó munkát adhasson ki a kezéből.

Idézem egy feljebb zajló vita egy szálát, ami egy jó példa. A név lényegtelen, mert ez bárkivel így alakult volna:
fejlesztő: "Bármilyen kicsit is interaktív weboldal tele van olyan elemekkel, aminél egy professzionális fejlesztővel szemben (jogos) elvárás, hogy ajaxban oldja meg"
én: "Ez kinek az elvárása?"
fejlesztő: "Azé, aki fizet a fejlesztésért, és cserébe minél több látogatót szeretne, akiknek nem okoz fájdalmat az oldal használata."
én: "Te a megrendelőnek készíted az oldalt?"

A kérdést nem véletlenül tettem fel: valóban a megrendelőnek készítjük az oldalt? Valóban az ő elvárása szerint kell annak működnie?

Nem.

Ha nekem a dobostorta a kedvencem, és elmegyek pecálni, akkor a horogra a tortát fogom feltűzni?

Az oldalak a felhasználók számára készülnek. És én azt hiányolom, hogy senki sem beszél arról, hogy nekik mi az érdekük, ők mit szeretnének. Miért nem? A megrendelő belőlük él, így közvetetten mi is belőlük élünk.

A témánál maradva: a felhasználónak AJAX-ra van szüksége? A felhasználónak reszponzív oldalra van szüksége? Ezek nem véletlenül a fejlesztő kívánságai?

Mit szeretne a felhasználó? Lehet, hogy csak egy üdítőt szeretne venni, és egyáltalán nem érdekli, hogy milyen technológiával kapja meg. Engem sem érdekel, hogy ADSL-en vagy kábelen jön a net, csak jöjjön.

A megrendelőnek milyen jogon vannak technológiai elvárásai? Én megmondom a fogorvosnak, hogyan fúrjon, vagy a péknek, hogy milyen formájú kenyeret süssön? Nem, hanem választok amalgám vagy fogszínű tömés közül, de a többi a szakember dolga. De a szakmánkban ki a szakember? A fejlesztő döntsön ilyen ügyekben, aki jellemzően technológiai oldalról közelít?

Hol vannak a tanulmányok, hogy a felhasználóknak mire van szüksége? Erről miért nem beszélünk? Ez lényegtelen lenne?

Vagy egy másik, jellemző felvetés a technológiai témakörben:
"A mai oldalakkal vagy versenyben, nem a tíz évvel ezelőttiekkel, a ma elvárt szintet kell hoznod, ha azt akarod, hogy látogatóid is legyenek."

Miért? A felhasználók többsége technológiai vagy pénzügyi szempontok alapján vásárol?

Még egy szempont, újra a fentebbi idézet:
én: "Ez kinek az elvárása?"
fejlesztő: "Azé, aki fizet a fejlesztésért"

Mert a fejlesztőnek a megrendelőnek bármit meg kell tennie? Ez pont ugyanaz, mint amikor a tömegmészárlás után a katonák azt mondják, hogy parancsra cselekedtek. Ilyen hozzáállással hogy lehet jól dolgozni?

Miért nem látok sohasem ezen a fórumon komoly fejlesztőktől kérdéseket? Mindeki csak kijelent, kijelent, kijelent.

(Fontosnak tartom még egyszer megjegyezni, hogy ezzel nem egy bizonyos személyt szeretnék kritizálni, hanem általában ezt a hozzáállást tapasztalom.)
62

Ezzel nem tudok

H.Z. · 2013. Már. 24. (V), 21.43
Ezzel nem tudok egyetérteni.
Sajnos(?) olyan világban élünk, amikor elsősorban a megrendelő igényeit kell kiszolgálni.
1. Nem teszel bele többet, mint amit megrendelt, különben nem férsz bele a határidőbe
2. Nem teszel bele kevesebbet, mert morcos lesz a munkaadód.
Hogy a felhasználónak mi a jó, azt rá kell bízni a megrendelőre. Szerintem.

Lehet javaslatot tenni a megbízónak, hogy másképp kellene ezt-azt, de önkényesen eltérni tőle, mert szerinted a felhasználónak úgy jó... (mert abból amit írtál, nekem ez jött le) Hát izé... elég rossz ötletnek tartom.
---------------------
Komoly fejlesztőket általában nem találsz a fórumok kérdezői között, ahogy elnéztem. Van egy középhaladó réteg, ők kérdeznek és válaszolnak is, a többiek vagy kérdeznek vagy válaszolnak vagy hallgatnak. :)
(ezt leginkább a stackoverflow lapcsaládon tapasztaltam)
Hogy miért? Ha valamiben profinak tartom magam, akkor nagyon ritka eset, hogy olyasmibe kezdek, amiben szükségem van mások véleményére, többnyire bízom a saját ismereteimben. Ha meg valami nem tudok, akkor megkeresem a neten. Kicsi a valószínűsége, hogy valaki másnak ne okozott volna problémát. (szintén tapasztalat: ha valamire nem találok választ, akkor én keféltem el valamit, ill. úgy öt százalék eséllyel valami olyanba futottam, amire még soha, senkinek nem volt szüksége - erre van konkrét példám :D)
64

Részben igazad van

Pepita · 2013. Már. 24. (V), 22.45
valóban a megrendelőnek készítjük az oldalt? Valóban az ő elvárása szerint kell annak működnie?
Sajnos igen, ebben a dologban nincs igazad. Te is feltűzheted a dobostortát, majd a saját károdon megtanulod, hogy "azok a hülye halak" ezt nem értékelik. Annyit tehetsz ilyenkor, hogy elmondod az érveidet, stb., ha nem tudod meggyőzni, akkor esetleg emelsz egy kis árat, mondván: ez szakmailag helytelen, nem tudom referenciaként felhasználni, emiatt engem ennyi kár ér. (Asszem ezt Virág fejtette ki nemrég és elég jól.) Végső soron a Megrendelő befektetése, övé lesz a veszteség is (ha rossz ötlete volt).

Az viszont nagyon is igaz, hogy mindent ne akarjon megmondani a Megrendelő, főleg technológiai dolgokat (megj.: én még nem találkoztam olyan megrendelővel, aki tudta volna, mi az ajax. Az is ritka, aki sejti, hogy "a kliens-szerver nem varázslat".) Mindenkinek magának kell eldönteni, hogy hol ez a határ, mi az, ami helyett már inkább éhenhal.

Miért nem látok sohasem ezen a fórumon komoly fejlesztőktől kérdéseket?
(Azért vannak kivételek! :))
Pont azért, mert valójában (majdnem) mindenki megmondja - a Megrendelőnek is! - a tuttit, mert képvisel egy irányvonalat, és - nem utolsó sorban - pont az ilyen "új technológiákkal" győzi meg a Megrendelőt saját tudásáról, árairól, stb.
Namost, ha valaki már kellően begyakorolta ezt az észosztást (sajnos sok ilyen van), akkor jobban fél egy (saját) kérdéstől, mint a tűztől, mert tudja, hogy lényegesen kisebb a tudása, mint amit igyekszik elhitetni magáról.

Ez a mai világ, megszokod vagy megszöksz. Szándékosan nem írtam egy nevet sem, akinek nem inge, ne vegye magára.
65

Úgy látszik, nem fogalmaztam

Hidvégi Gábor · 2013. Már. 24. (V), 23.18
Úgy látszik, nem fogalmaztam egyértelműen, természetesen a technológiai kérdésekre gondoltam, és nem úgy általában a megrendelők kompetenciáját kérdőjelezem meg. Világos, hogy ha a Niveának dolgozom, akkor az alapszín a kék, még akkor is, ha az emberek a pirosat kedvelik inkább.
66

Ezt most én nem értem :)

Pepita · 2013. Már. 24. (V), 23.36
Szerintem (előzőleg) egyértelműen fogalmaztál, inkább itt utóbb lehet félreértés. Annyiban nem értek egyet veled, hogy igenis, a Megrendelőnek csinálod az oldalt. Akkor is, ha sz...t kell csinálj, mert ő fizet érte és az ő vesztesége lesz. Persze nem kötelező neki dolgozni, ha szerinted túlságosan megmondja a foghúzás mikéntjét.

A válaszom (előbbi) két külön téma, az idézetek szerint. Lehet, hogy az nem egyértelmű? Valahogy nekem ez a reakciód (65) "nem stimmol", csak nem tudom, miért.
68

"A kérdést nem véletlenül

pp · 2013. Már. 25. (H), 08.39
"A kérdést nem véletlenül tettem fel: valóban a megrendelőnek készítjük az oldalt? Valóban az ő elvárása szerint kell annak működnie?"

Igen.

A megrendelő azért bízott meg téged, hogy segíts neki megvalósítani a célját. Nagyon sokszor már kész megoldásokkal jön. Neked mint szakembernek segíteni kell őt abban, hogy a céljait elérje. Ha nem jó megoldást választott, javasolni kell helyette egy másikat, ami ugyan azt a célt eléri.

De a célt ő fogalmazza meg, te ezt önkényesen(szakmai szempontok miatt) nem írhatod felül. A célcsoportját, a látogatóit, ő ismeri a legjobban, nem Te.

El kell fogadnod, hogy a döntést is ő hozza. Ráadásul úgy hozza, hogy ismeri a teljes üzleti domain-t.

Ezért gondolom, hogy egy - az üzleti domain ismerete nélkül hozott - általánosító kijelentés, nem fog jó üzleti döntésre vezetni.

pp
74

de azt nem tudja

zzrek · 2013. Már. 25. (H), 14.31
De azt a megrendelő nem tudja, hogy:
1: hogyan célszerű felépíteni az oldalt, hogy (akár) a célcsoporton felül több látogató elégedett legyen vele (és itt most lehet beszélni a válaszidőtől a reszponzivitáson és a régi böngészők támogatásán át a fogyatékkal élők figyelembe vételéig), (akár) minimális vagy semennyi többletmunkával,
2: hogyan alakul az internetes társadalom, hogyan érhető el a célcsoport, mik a trendek (technológiai és egyéb szempontokból),
3: mi a fejlesztő egyedi eszköztára, (technikai és mentális) ami mentén hatékonyan tudja elvégezni a munkáját
4: stb...

Vagyis egyetértek a Gáborral, hogy mindig célszerű úgy gondolkozni, hogy a felhasználóknak és nem a megrendelőnek készül a fejlesztés -- mintha a saját projektünk lenne. Ezt lehet és célszerű is menedzselni a megrendelő felé, és a tapasztalatom szerint az ilyen törekvések a megrendelő szemében is érezhető hozzáadott értéket képviselnek.

A megrendelő a legtöbb esetben csak azt hiszi, hogy tudja, hogy mi a cél. Ráadásul nagyon sok esetben nem jól, hiányosan fogalmazza meg -- ez természetes, hiszen a technikai részéhez nem ért, és nincs tisztában az optimális megvalósítással, sem a lehetőségekkel.

Sőt, sok esetben nem is kell az egyes alkalmazott technológiai megoldásokat a megrendelő orrára kötni, egyes döntéseket mi magunk hozunk meg: ha az lebeg a szemünk előtt, hogy a felhasználó számára dolgozunk, akkor az eredmény jobb minőségű lesz, mintha csak a specifikációban leírtaknak kívánunk megfelelni. Ha az ilyen, a mi kompetenciánkba tartozó döntéseket megtartjuk magunknak, akkor még az egyeztetéssel kapcsolatos felesleges köröket is megúszhatjuk (bele se íratjuk a specifikációba, esetleg csak általánosságban utalunk az ilyesmire), ezzel is időt spórolhatunk meg (minek is kössük az orrára, amikor úgysem tud objektíven dönteni kompetencia, tapasztalat hiányában?)

Mondok egy példát: a megrendelő egy szállodában velünk szeretné kialakíttatni a vizesblokkot: megbeszéljük vele, hogy milyen legyen a csempe (stb) de azt nem, hogy hol menjenek a vezetékek (stb).

Nekem nem tetszik az a stílus, hogy a specifikációt megír(at)juk és elfogadtatjuk pusztán abból a célból, hogy a munka végeztével lobogtathassuk a bérünket kérve (tessék, ezt akarta a megrendelő, kész van, mostmár fizessen!), és az utólagosan kiderült (számunkra már az elején nyilvánvaló) hozzáadandó fejlesztéseket pluszmunkaként kérhessük le.

Szóval szerintem is akkor végezzük a legértékesebb munkát, ha a projektet olyan szinten magunkévá tesszük (megismerjük és alakítjuk), hogy a megrendelő fejével (együtt és helyett) a felhasználók számára készítsük el a terméket.
75

Pontosan

Hidvégi Gábor · 2013. Már. 25. (H), 15.14
Ha a felhasználónak jó -> a megrendelőm gazdagszik -> én is jól járok = mindenki boldog. Ezért közvetlenül soha nem a megrendelőm érdekeit kell néznem, hanem azét, aki a pénzt hozza neki.

Az első cégemnél például volt egy sitebuilder "kódex", amit egy kollegám kezdett el csinálni, és én vittem tovább, sokszor a szabadidőmből áldozva azért, hogy elkészüljön, és jól lefedjen minden fázist. De megérte, mert a munkánk könnyen ellenőrizhető volt, volt támaszpont a többiek részére, hogy mit és hogyan kell elkészíteni, ezáltal hatékonyabban dolgozott mindenki. Ezt a plusz munkát a cég a következő éves elbeszélgetéskor szép fizetésemeléssel ismerte el.
67

Ha én felhasználóként egy

MadBence · 2013. Már. 25. (H), 00.09
Ha én felhasználóként egy oldalt böngészek, akkor egy dolog érdekel: a felhasználói élmény. Ha kattintásaim eredménye csak egy homokóra, ami nem tudom meddig fog ott táncolni, frusztrált leszek, és egy másik oldalra megyek. Ha a böngészési élményem megszakad, mert a fejlesztő szerint márpedig jó az az újratöltés, akkor frusztrált leszek, és egy másik oldalra megyek. Ha nem kapok azonnali reakciót valamire (csak annyit látok, hogy "tölt"), frusztrált leszek, és egy másik oldalra megyek.
Ezek az én (átlagos felhasználó) igényeim. A fejlesztő(k) felelőssége, hogy ezeket az igényeket kielégítsék, és az engem különösebben nem érdekel, hogy milyen technológiával. Az ilyen jellegű interakciókat tudja az AJAX hatékonyan megoldani.
69

Azért jó

Gixx · 2013. Már. 25. (H), 09.38
Azért jó az AJAX, mert van belőle focicsapat és tisztító szer is. Ennyi.

Hagyjuk már ezt a személyeskedő ócsárolgatás-sorozatot, kérlek... szerintem ez már nem vitázás, hanem vitatkozás.
78

Módjával, de azért használjuk!

Cooty13 · 2013. Már. 25. (H), 16.59
Sok mindenben egyetértek a cikk szerzőjével - főleg a "technológiai konzervativizmust" illető bekezdéssel - de azzal a végkövetkeztetéssel nem, hogy de facto nem javasolja az AJAX használatát.
1) Való igaz, hogy az AJAX és a SEO nem jó barátok, nem túl okos dolog a felhasználó/keresőbot számára legértékesebb tartalmat JS-el betölteni, azonban nem minden tartalom értékes SEO szempontból - pl az szerintem nagyon is helyénvaló, hogy egy komment threadet vagy egy "súgó" tooltip tartalmát AJAX-al töltsünk csak be és csak akkor ha arra a felhasználónak szüksége van. Pl kommenteknél ha legörget odáig.
(btw az ajax-os betöltési tartalmakat is lehet keresőoptimalizálni: https://developers.google.com/webmasters/ajax-crawling/)

2) Pl egy egyszerű kapcsolati form vagy hírlevél feliratkozás kitöltésnél én utálom, ha az egész oldalt be kell újra töltenem (főleg, ha mobilról nézem, amin lassú a net), - miért nem küldhetem el csak annak a pár mezőnek az értékét (igen tudom ez megoldható rejtett iFrame-el is, erről volt is egy szép cikk it a WL-en valamikor)

3) Két általam igen kedvelt buzzwordöt hoznék fel a témával kapcsolatban Unobtrusive JavaScript és progressive enhancement
Hogy az első példából induljak ki, az AJAX-os formokat én midig úgy szoktam megcsinálni, hogy JS nélkül is tökéletesen működjenek (max nem kap a user egy olyan szép "dizájnos" animált visszaigazoló panelt, mint amit a JS-es verzióban kapna, de a lényegi funkció működik), vagy ha pl megnézed a Kirowski Isobar oldalán az "Emberek" oldalt először bekapcsolt JavaScripttel majd kikapcsolt JavaScripttel... Mindenhogy tökéletesen működik, csak JS nélkül kevésbé látványos (bár avatatlan szem észre se venné a különbséget).

Szóval szerintem nagyon is jogos ennek a technológiának a használat, és ha jól csinálod akkor komoly usability előnyre tehetsz szert, de tényleg nagyon át kell gondolni mit hogyan, ha nem akarjuk pont az ellenkezőjét elérni.
83

Kicsit sajnálom ezt a dolgot,

bamegakapa · 2013. Már. 26. (K), 02.30
Kicsit sajnálom ezt a dolgot, mert ha lecsupaszítja az embert ezt az írást, és a lényegét veszi belőle, azaz hogy ne használjunk Ajaxot ész nélkül, akkor ezzel azt hiszem, kevesen vitatkoznánk, és mindenki szívesen osztaná meg tapasztalatait, hogy mire érdemes figyelni.

Sok hasznos dolog van a bejegyzésben, csak túl nagy a zaj, így nekem többször újra kellett olvasnom, hogy ne a (lehet hogy provokációnak szánt?) "mérges" részek maradjanak meg. Egy személyes blogon amolyan rantnek még elmenne a dolog. Szakmai vitát ugyan lehet erős érzelmi töltettel is folytatni, de az onnan kérdéses, hogy szakmai vita-e.
85

Én is kb. erre gondoltam

Cooty13 · 2013. Már. 26. (K), 18.39
Igen, kb. én is ezt akartam hozzátenni lényegében, mert alapból jó a cikk és kell néha az ilyen, ahogy te is fogalmazod "rant", ami felkavarja az indulatokat, szembemegy a trendekkel és a többségileg elfogadott véleménnyel. De ahogy átfutottam a kommenteket, valahogy nekem az tűnt fel, hogy a legtöbben ezt nem teljesen így értették!
87

Igen, csak sajnos

Pepita · 2013. Már. 26. (K), 21.25
a többségnek "kimaradt" a lényeg:
hogy ne használjunk Ajaxot ész nélkül
Ezért - szerintem is - lehetett volna kicsit finomabb az írás, de kérdés, hogy akkor hányan reagáltak volna rá.
Én ezzel együtt - mint korábbi kommentjeimből is kitűnik - képes voltam a mondanivalójára figyelni, ilyenkor (nekünk többieknek is) képesnek kell(ene) lennünk érzelmi töltések nélkül mérlegelni.
88

Még egyszer átolvastam a

Hidvégi Gábor · 2013. Már. 26. (K), 21.58
Még egyszer átolvastam a cikket, de igazából az utolsó bekezdés első mondatába lehet belekötni, de ott is úgy fogalmazok: "jelenleg AJAX-ot használni weblapon nem tanácsolnám senkinek". Nem azt mondom, hogy ne csinálja senki!
89

Mégis sokan úgy értették

Pepita · 2013. Már. 26. (K), 22.09
Én inkább a kommentek alapján mondom (így utólag ugye könnyű...), hogy lehetett volna finomabban. A negatívan reagálók több ilyesfajta állásfoglalásodat vélték felfedezni, én - mint korábban is írtam - legnagyobb részben egyetértek.
90

Pont ez az, a zaj miatt nem

bamegakapa · 2013. Már. 26. (K), 23.39
Pont ez az, a zaj miatt nem jött át a fontos tanulság. A kommentek mennyisége meg elég gyakran nincs összhangban a mennyiséggel, szóval azt ne vegyük jó pontnak, hogy sokan hozzászóltak.

Zárójeles, félkomoly móka: ha már arról beszélünk, hogy minden látogató fontos és mindenkinél működnie kell az oldalnak szépen jól, akkor ne fogjuk a felhasználókra (olvasókra), hogy nem sikerült megérteni a cikk lényegi mondanivalóját :).
91

Azért, hogy leírjuk "ne

pp · 2013. Már. 27. (Sze), 10.29
Azért, hogy leírjuk "ne használjunk Ajaxot ész nélkül" teljesen felesleges ide bejegyzést írni, hisz "itt mindenki szakember" ( :) ), aki nem használ semmit se ész nélkül.

A vita itt akörül zajlott, hogy vajon a felhozott példák fejlesztői ész nélkül használják-e az Ajaxot, vagy esetleg olyan egyéb okok miatt döntöttek az adott megoldás mellett amiről nincs tudomásunk.

Sajnos ez nem megy át.
92

Mindig élvezettel olvasom az

Hidvégi Gábor · 2013. Már. 27. (Sze), 10.41
Mindig élvezettel olvasom az írásaidat.
93

Imho a felhozott példák

inf3rno · 2013. Már. 27. (Sze), 10.59
Imho a felhozott példák fejlesztői úgy gondolták, hogy az az 1-2%, akinek nem jelenik meg rendesen, az nem éri meg a befektetett munkát... Szerintem inkább legyen ajax, mint az origonál az 5 percenkénti újratöltése az oldalnak. Attól kaparom a falat...
94

Az, hogy kinél nem jelenik

Hidvégi Gábor · 2013. Már. 27. (Sze), 11.07
Az, hogy kinél nem jelenik meg az AJAX-os tartalom, nem annyira lényeges szempont. Az 1,-es, 3-as és 4-es példában használhatósági buktatókra mutatok rá (lassú lesz, nem indexelhető és így tovább), amiket nagyon könnyű elkövetni.
95

Ez oké, de mi van akkor, ha

pp · 2013. Már. 27. (Sze), 11.24
Ez oké, de mi van akkor, ha nem szeretnék, hogy a commenteket indexelje a kereső?
96

Tényleg, akkor mi van?

Pepita · 2013. Már. 27. (Sze), 23.13
A rel="noindex" attribútum a comment(ek) div-jén nem lehet megoldás? (Komolyan kérdem, még csak linkről olvastam hasonlót.)
97

Megoldás lehetne, hogy a

Max Logan · 2013. Már. 28. (Cs), 08.10
Megoldás lehetne, hogy a keresőknek csak az indexelendő tartalmat jelenítjük meg, de eddigi információim alapján ha észreveszi a keresőbot, hogy mást kap, mint a user, akkor komoly bünti lehet a vége. Valamint úgy tudom, hogy nincsen egyértelmű és 100%-os megoldás egy bot detektálására.
99

Éppen ezért nem tenném

Pepita · 2013. Már. 29. (P), 11.42
Meg aztán lehet akkor 3 féle tartalomelőállítást csinálni (asztali-mobil-kereső). Illetve ha a Júzer a (kereső által) tárolt változatot nézi meg, akkor is gond.
Én is úgy tudom, hogy nem 100%.
98

két nem túl jó ötlet

zzrek · 2013. Már. 28. (Cs), 10.45
Lehet iframe-be tenni a kommenteket, valamint lehet js-sel is megjeleníteni (a display:none-t nem indexeli ha jól tudom, de ha mégis, akkor lehet utólag is betenni innerHTML-lel egy kvázi üres keretbe), ez ugye nem ajax, a kommentek pedig csak azoknak fog megjelenni, akiknél be van kapcsolva a js.
100

Száz

Gixx · 2013. Már. 29. (P), 14.22
...hogy ezt a témát kiveséztük :)
101

Túl sokmindenhez kell már érteni!

MoW · 2013. Okt. 12. (Szo), 13.07
Írok ide én is egy mikroblogot, mert szerintem forradalom kéne már a webre.
Mikor elkezdőtött az internet mánia HTML-ben írtuk a cikkeket. Később megtanultuk a CSS-t, hogy szép is legyen amit csináltunk. Ezután jött a PhP, hogy az oldalunk "gondolkodhasson". Ezután már kell ugye a JavaScript, hogy a kliens gépe se unatkozzon. Nem rég rájöttünk hogy utóbbi kettőt össze kell kötni, mert ugye nem jó ha a két platform külön dolgozik, így megalkottuk az AJAX-ot. Holnap megint jön valami, amit hozzátoldanak a sorhoz, így az embernek egyre több, egymástól külön fejlődő nyelvet kell megtanulni. Szerintem ugrani kéne inkább egy évet és ezt az egészet egy nagy nyelvé gyúrni. Egy teljesen új nyelvet alkotni, ami ha akarom kliens oldalon dolgozik, ha akarom, akkor szerveren; ha akarom, akkor egyszerű szöveges információt jelenít meg, ha akarom, akkor villog a szöveg miközben tótágast áll a képernyőn.
Persze tudom, ezzel kukába dobhatnánk a böngészőinket és a webszervereinket, na de mi van akkor? Gondolom nem egyszerű egy ilyet megcsinálni, de ezelőtt 200 évvel váltig állítottuk, hogy repülni se fogunk. Szerintem ez lesz majd egyszer a web 3.0 addig viszont be kell érnünk ezzel:
<HTML>
<style>
<script>
<?php>
102

éljünk abból ami van, ez a módi

Arnold Layne · 2013. Okt. 13. (V), 01.04
mert szerintem forradalom kéne már a webre.

Azért ha forradalom nem is, de egy szenzációhajhász újságíró valószínűleg eladná mint forradalom.
Szerintem ugrani kéne inkább egy évet és ezt az egészet egy nagy nyelvé gyúrni

Egy év kevés, még egy újabb nyelv csak ezért meg felesleges szerintem.
Egy teljesen új nyelvet alkotni, ami ha akarom kliens oldalon dolgozik, ha akarom, akkor szerveren; ha akarom, akkor egyszerű szöveges információt jelenít meg, ha akarom, akkor villog a szöveg miközben tótágast áll a képernyőn.

Háát kezdjük először a már létező technikákkal.
Odáig már eljutottunk, hogy JS tud szerveroldalon is futni (plö NodeJS), bár mintha lett volna ezelőtt is valami sovány próbálkozás rá. Bár asztali GUI-s alkalmazásokat (GTK, Qt, stb…) alkalmazásokat nem tudom lehet-e NodeJS-sel írni.
De ha nem a JS a barátunk, akkor még ott a Python, meg a Ruby. Létező nyelvek, lehet webes backendre használni őket, meg grafikus alkalmazások összehordására is. Ezen nyerhetnénk annyit, hogy kiszórhatnánk a webes alkalmazásfejlesztésből (pl youtube, soundcloud) a HTML-t és a CSS-t, mint dokumentumot leíró és formázó nyelveket. Ez az én vesszőparipám.
Persze tudom, ezzel kukába dobhatnánk a böngészőinket és a webszervereinket,

Nem feltétlenül. A webszerver maradhat, a böngésző a nehezebb eset, de lehet megúsznánk azt is egy kisebb átalakítással.
Szerintem ez lesz majd egyszer a web 3.0

Ez esetleg egy web 823.0 lehet, de elnézve a mostani verziószámozási trendeket (chrome, firefox) lehet nincs is olyan messze. :D
A web 3.0 pedig megint csak valami apróbb puki passzátszélnek kiáltása lesz szerintem, de ne legyen igazam.
103

MeteorJS

complex857 · 2013. Okt. 31. (Cs), 15.26
Egy teljesen új nyelvet alkotni, ami ha akarom kliens oldalon dolgozik, ha akarom, akkor szerveren;

Nézd meg mit csinál MeteorJS, alapvetően pontosan ezt a "ha akarom itt, ha akarom ott" -ot csinálja.
104

Nem egészen, ami az ő agyában

bamegakapa · 2013. Okt. 31. (Cs), 15.49
Nem egészen, ami az ő agyában megszületett, az valami HTML+CSS+JS+PHP Frankenstein, ami szerveroldali nyelv, kliensoldali nyelv, stíluslap és minden egyéb ömlesztve.

Máshol is láttam már embereket, akik valami ilyesmiről álmodoznak, de nem igazán értem, mire lenne ez jó, azonkívül, hogy kevesebbet kéne tanulni...
105

nem igazán értem, mire lenne

inf3rno · 2013. Okt. 31. (Cs), 17.25
nem igazán értem, mire lenne ez jó, azonkívül, hogy kevesebbet kéne tanulni...


Arra, hogy mindent lehessen ömlesztett spagettikódban írni, és ha összefutsz egy ilyen projekttel, akkor felköthesd magad... :D

Vannak olyan megoldások, hogy kliens oldali kódot úgy generáltatnak szerver oldalról, mintha egy sima GUI lenne. GUI komponensek kellenek hozzá, egy sereg sablon, ennyi. Működni működnek, csak baromi lassúak, mert nagyon általánosak...
106

+100

Pepita · 2013. Okt. 31. (Cs), 21.57
Arra, hogy mindent lehessen ömlesztett spagettikódban írni, és ha összefutsz egy ilyen projekttel, akkor felköthesd magad... :D
Ez legalább 100 WL Szakértői pont!...

És ahhoz, hogy valami értelmes végeredményt hozz létre vele (nincs lehetetlen), ahhoz már nagyon sokat kell tanulni, és min. 3x annyit dolgozni, mintha a meglévőket jól használod.
107

Jaja, én is kb. így értettem.

bamegakapa · 2013. Okt. 31. (Cs), 22.17
Jaja, én is kb. így értettem. Az ő agyukban ez valahogy úgy áll össze, hogy akkor csak egy nyelvet kell érteni és minden két kattintással pont úgy fog működni, ahogy ő azt elképzelte rózsaszín felhős álmaiban :).

ha akarom kliens oldalon dolgozik, ha akarom, akkor szerveren; ha akarom, akkor egyszerű szöveges információt jelenít meg, ha akarom, akkor villog a szöveg miközben tótágast áll a képernyőn

Ez jelenleg is elérhető egy busásan megfizetett webfejlesztő alkalmazásával :).
109

Hát végülis afelé halad a

inf3rno · 2013. Okt. 31. (Cs), 23.18
Hát végülis afelé halad a világ, hogy megmondod a szoftvernek, hogy milyen weboldalt szeretnél, aztán barbatrükk, és kész. Akkor legalább a szoftvert fogják szidni, hogy nem olyan, mint amilyenre gondoltak, és nem a fejlesztőt... :D
111

Egyszer nekem

Pepita · 2013. Nov. 1. (P), 02.13
- még windowsos desktopra - azt mondta valaki: "...és jó lenne egy mikrofon is, ahol megmondhatom a további elképzeléseimet!"

Persze viccnek szánta, de még ma is elgondolkodtató, mennyire igaz egyes esetekben... :)
108

Ez a Meteor is rajta van már

bamegakapa · 2013. Okt. 31. (Cs), 22.18
Ez a Meteor is rajta van már egy ideje a "must try" listámon :).
110

Elég kidolgozottnak tűnik,

inf3rno · 2013. Okt. 31. (Cs), 23.43
Elég kidolgozottnak tűnik, egyszer lehet, hogy én is kipróbálom...

Unpack it anywhere there's node.js, run one command, and you're on the air.


Nekem valahogy nagyon fura a hozzáállásuk a felhasználókhoz. Se nodejs verziót nem találtam eddig, se operációs rendszert nem írnak. Úgy kezdik, hogy egy platform, amiben mindent megadhatsz js-ben. Ennyi erővel java is lehetne alatta, vagy bármilyen más nyelv, ami tud js motort használni. A helyzet az, hogy amire support van, az csak a linux, és a cucc csak nodejs-el megy, és valszeg mongodb-vel. Ennek a dokumentáció első soraiban benne kellene lennie. Innentől nekem elég gáz a dolog. A security részéről egy csomó jót írnak, hogy nagyon könnyű kezelni, automatikusan szűr, stb... Az eddigiek alapján valahogy nem tudom elhinni, hogy nincs tele sebezhetőséggel, de majd ha lesz időm jobban belemászok...

szerk:

Helyesbítek: https://github.com/meteor/meteor/wiki/Supported-Platforms
Itt írják, hogy egyelőre csak linuxra van. Mondjuk egy 0.6-os verziójú cucctól nem várok többet. Azt írják, hogy majd lesz hivatalos windows support is nem sokára. Ha eléri az 1.0-át, akkor megnézem újra, hogy van e értelme foglalkozni vele.