Ajax vagy nem Ajax?

Web, mail, IRC, IM, hálózatok

Öt évvel az Ajax robbanása óta még mindig azt gondolom, hogy a javascriptet óvatosan kell csak használni a weben.
Szerencsére a html5 bevezetése magával hozza, hogy a CSS már közel egyformán néz ki mindenhol és a javascript értelmező is igen sokat fejlődött a böngészőkben. A félelmem az Ajax publikus felhasználásával kapcsolatban, hogy sokaknak ki van kapcsolva a javascript támogatás.

Van valakinek ezzel kapcsolatban tapasztalata/statisztikája?
Érdemes webshop-ot full Ajaxra átrakni? (nem akarok vásárlót veszíteni)

UPDATE
Arra a döntésre jutottam, hogy:
- minden olyan site-ot ami a keresők elől el van zárva (intranet) és érdekelt a felhasználó a felhasználásban, azt nyugodtan csinálhatom AJAXszal
- webshop teljes egészében felesleges és sok munkát adna, ha teljesen AJAX-ban lenne, ezért: csak olyan részeit érdemes átrakni, amit a keresőkkel amúgy sem kívánok megosztani (pl. kosárba rak, fizetés, számlázás, login, logout, regisztráció, hibaüzenetek)
- elkezdem loggolni a vásárlóim böngészőit és azok képességeit, hogy a jövőben könnyebb legyen döntenem :)
- csatlakozom az http://www.ie6nomore.com -hoz és nem fogok foglalkozni az ie6-os böngészővel, így minden AJAX kérés mehet XMLHttpRequest-en keresztül és nem kell megírnom ActiveXObject-re is.
- elkezdem használni a "< noscript >< / noscript >" tag-et

( kiuka | 2010. 09. 11., szo – 23:00 )

akinek tiltva van js is engedelyezi, ha akar valamit toled.

Így van, nálam is nagyon ki kell azt érdemelni, hogy be legyen kapcsolva egy oldalon a JS. Én is használom az FF-be beépített jelszókezelőt, így alapból ki van kapcsolva a JS, és NoScript is van fenn.

Botorság azt feltételezni, hogy intraneten kívül máshol is alapból be van kapcsolva a JS.

--
GPLv3-as hozzászólás.

( rootkit | 2010. 09. 11., szo – 23:08 )

Hát azt hiszem, hogy ezt nem lehet egyértelműen megválaszolni.
Én szeretek PHP-ban dolgozni, nagyon gyorsan tudok oldalakat összerakni, viszont a JavaScript mint nyelv sokkal jobb. A PHP eszközkészlete utolérhetetlen. Nem arról van szó, hogy melyik nyelv a jobb, vagy kliens illetve szerveroldalon végezzük a feldolgozást.
Csak úgy érdemes váltani, hogy teljes módszert váltunk. Egészen új munkastílust kell kidolgozni, megtanulni hozzá. Ha kialakítod a rendszeredet és ugyanolyan otthonosan fogsz mozogni benne, mint sima PHP-HTML-ben, akkor kinyílik egy teljesen új világ, a lehetőségek tárháza :)
Hogy a kérdésre is válaszoljak: én nem aggódok a JS támogatás miatt manapság. Mi működne JS nélkül? (gmail, facebook, stb.)
Fejlesztek és üzemeltetek oldal(aka)t napi 100000 egyedi felhasználó felett és még sosem volt bajom a JavaScript függőséggel. Nálam úgy van megoldva, hogy a főoldalon kap egy jó nagy egyértelmű figyelmeztetést, aztán ha továbbra sincs JS, akkor működik, ami működik.

Hát azért nem teljesen másra való. Ahol eddig a lapok teljes tartalmát PHP printelte, ott most JavaScript veszi át a helyét. Nálam legalábbis a JS-es oldalak ilyenek. A PHP csak egy keretet készít és minden tartalmat a JS formáz meg és "printel ki". Így a PHP szerepe az adatbázisműlevetekre, a jogosultságok és az input másodlagos ellenőrzésére korlátozódik (azért ez szükséges). A PHP oldali kód sokkal-sokkal kisebb, mint korábban és többnyire csak JSON változókat ad vissza, azt a kliens oldali JS kód dolgozza fel és építi fel az oldalakat.
Éppen erről próbáltam írni, hogy szerintem csak úgy van értelme váltani, ha az egész munkamódszert megváltoztatjuk. Az, hogy használok pár sor JS-t egy tooltip kirajzolásához, az még nem JS-es, Ajax-os oldal, nézz meg pl. egy gmail-t.
Azt hiszem, hogy ilyen szempontból egyáltalán nem másra való, mert az alapfeladat ugyanaz: le kell generálni az oldal forrását. Kérdés, hogy ezt melyik végzi.
Ja és köszi, hogy felnyitottad a szememet és már látom, hogy milyen buta vagyok :)

Nem butaság amit írsz, de azért nem kell feltétlenül JSON objektumokat küldözgetni minden egyes AJAX hívásnál. Attól még, hogy HTML-t küldesz, ugyanúgy AJAX-os lesz az oldal, csak a szerver oldalon generálod le a tartalmat, nem a kliens oldalon.

(Zárójelben jegyezném meg, hogy nem tetszik, hogy a szerver oldalról úgy beszélsz, hogy PHP, amikor az bármi más is lehetne: perl, java, ruby, akár még lisp vagy C is.)

( nevergone v | 2010. 09. 11., szo – 23:14 )

subscribe :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( greyow | 2010. 09. 11., szo – 23:16 )

szerintem a felhasznalok kevesebb mint 1% tudja mi az a javascript es hogy azt ki is lehet kapcsolni.

Ha van mar oldal, akkor ott le tudod kerdezni, hogy engedelyezve van-e a js, igy lehet belole statisztikat csinallni.

( asch v | 2010. 09. 11., szo – 23:17 )

Szerintem alapvetően jó dolog az Ajax, de jól kell használni.

Például nagyon idegesítő tud lenni, ha amikor megvan a termék, akkor nem tölti újra az oldalt a termék linkjével az ajaxos alkalmazás, mert így nem tudom elmenteni vagy elküldeni a linkjét.

Plusz probléma lehet, hogy a keresők sem tudják beindexelni az általad árult termékeket.

Úgyhogy ha átírod ajaxosra, akkor figyelj arra, hogy a rendszer aloldalai elérhetőek legyenek direkt linkeken és akkor engem nem fogsz elveszíteni :-).

( kicca | 2010. 09. 11., szo – 23:31 )

Csak akkor, ha nem használsz jquery és egyéb libeket. Mostanában egyre többen használnak netbookot, vagy éppen mobilról nézik az oldalakat. A processzort eléggé le tudja gyilkolni egy ilyen full jquerys vagy egyéb masszív sz*r kód.

Szerintem nem érdemes full ajax.
Inkább csak részben legyen ajax, de minden egyes ajaxos hívásnak legyen megfelelő sima nem-ajaxos megfelelője. Gondolok itt araa, hogy a href="/basket/add/432" onclick="return webshop.basket.add(432);". Tehát, ha esetleg nincs bekapcsolva javascript, akkor se legyen gondja.

Ezen kívül, ha használni akarsz pár funkcióra nagyobb libet, akkor legyen dinamikusan betöltött. Csak akkor húzza be, ha ténylegesen használod is.

Ha mindenképp szeretnél full ajaxos oldalt, akkor pedig érdemes a user sessionjében eltárolni, hogy lassú gépről nézi az oldalt vagy nem és az alapján választani, hogy full ajax vagy nem full ajax legyen az oldal.

Egy olyan oldalon, ahol számít neked, hogy mennyien vásárolnak tőled, ott érdemes olyan kódot készíteni, ami mindenki számára kényelmesen használható és egységesen működik.

nem a jquery a problema, hanem -- ahogy irtad is -- az arra epitett sz*r kod:)
ha libek nelkul akar cross-browser megvalositast, az jelentosen megnoveli a fejlesztesi idot -- foloslegesen.

azzal viszont tokeletesen egyet kell hogy ertsek, hogy a leheto legtobb funkcionak mukodokepesnek kell maradnia kikapcsolt javascript mellett is. ez kis odafigyelessel siman megoldhato.
nem utolso sorban SEO szempontbol is fontos hogy a termekek elerhetok legyenek kulon linken -- nem csak a human felhasznalok akarnak linkelni am :)

Nem. Nem _jó_ oldal az, hanem a tulajdonos pénzes. Vagy pedig elég kicsi oldal ahhoz, hogy gyorsan tudjanak hozzá mobil verziót is írni. Esetleg új oldal és már gondoltak mobil verzióra tervezésnél.

De a ugye ott vannak a netbookok is, ami alól nagyon lassú lehet az agyonbaszott jquerys oldal.

Meg egyáltalán milyen kényszert éreznek az új webfejlesztők? Megkeresik őket hardware gyártók és minden fejlesztő fejéhez fegyvert szorítanak, hogy kötelező sz*r/lassú kódot kihányni magukból?

Esetleg még extrának tölthetünk be pár javamikulást meg flash órát is, hisz telik rá a processzoridőből. Mindegy, ha emiatt kicsit szaggat a görgetés, belefér. De természetesen ezeket is jquery töltse be, hisz az nagyon szuppi.

A te szavaiddal másik oldalról nézve egy _jó_ oldal nem használ jqueryt.

De azok sem a jQuery miatt lassúak, hanem mert ész nélkül effektelték össze és lapátolták össze a pluginokat. Ugyanezeket sima javascriptben lefejlesztve is lassú lett volna, csak ki az az állat, aki balról jobbra 30 képet akar befadelni egyszerre.

Egyébként szerintem ide írva sem lett volna semmi, tanul belőle a fejlesztő és legfeljebb megköszöni. Az én oldalaimat pl beírhatod elrettentő példának, örülni is fogok neki :)

--
http://sandor.czettner.hu

De a lényeg, hogy ha egyszerűen valaki nekiáll és megírja jquery nélkül, akkor gyorsabb lesz.
Ennek egyrészt az az oka, hogy akkor valószínűleg ért hozzá az ember és nem fog szar kódot csinálni. Nem fogja lekért node minden lehetséges változóját kompatibilissé tenni minden böngészővel minden lekéréskor ráadásul(tehát éppen nem kell egy tulajdonság, akkor minek kérjem le és alakítsam át?). Ezen kívül többnyire, ha "saját magának" nem úgy kell fejleszteni, hogy a megírt libeket máshol is használják utána. Tehát lényegesen kevesebb kört fut a processzor.
+jQuery kényszerből hülye-biztos is, hogy kevesebb legyen a hibaüzenet, stb.

( nagy_peter v | 2010. 09. 11., szo – 23:45 )

Szerintem többen mennek lynks-el a webre, mint kikapcsolt javascripttel. Illetve aki kikapcsolja, az meg is érti, ha kiírod, hogy most engedélyezni kell, ha vásárolni akar.
Csak olyan szokta letiltani, aki ért hozzá.

( Aadaam v | 2010. 09. 11., szo – 23:51 )

Kezdjuk a targyi tevedesekkel, bocsi, de picit sok van belole:

  • A HTML5-ot nem vezettek be.
  • A CSS eddig is egyforman nezett ki mindenhol azoknal, akik tudtak, hogy hogyan kell a quirks - magyarul: 'javajozsi/phppistike' - uzemmodbol atvaltani standard compliantre a bongeszoket... Ettol meg mondjuk a grid tamogatas meg szar benne, de ez van.
  • A JS 99 ota egy tapodtat se fejlodott, talan annyi, hogy mar JIT-es az engine. Egyebkent egy nagyon jo nyelv, csak kevesen ertekelik.
  • Az emberek infidezimalisan kis szamanak van kikapcsolva a JS ertelmezoje, manapsag mar a google se mukodne nelkule. (Search complete, google instant, stb)

Tessek az adott webshopon statisztikat kesziteni arrol, hogy akik varhatoan humanoidok (nem keresobot, nem spambot), mekkora aranyban van kikapcsolva a javascriptjuk, es ezutan donteni.

Itt jeleznem, hogy bar az emberek nagyon jol kezelik az AJAX-ot, a google ettol meg nem fogja leindexelni az oldalt, mivel abban viszont le van tiltva a javascript.

Tovabba, a linkek kezelhetosege is korlatos lesz, mivel vagy oldalt valtasz, vagy hashtagekkel (shop.hu/oldal.php#allapot) tudod csak kezelni.

A mobilon torteno mobilinternetes forgalom 80-90%-at az iPhone-ok adjak, az androidokkal egyutt az arany 95% felett van joval, Magyarorszagon is. Ezekben a WebKit nokia altal lebutitott valtozata fut, meg van bennuk also hangon 600MHz, viszont feleannyi dolgot se csinalnak mint egy nagygep (kisebb kijelzo, kevesebb hattertaszk, stb). Ja, Nokiakra ugyanez igaz.

Amitol meg felhetsz: az IE5-8 JS engine volt olyan szives, es a tomboket lancolt listakent tarolja, a for-ciklusok igy hirtelen negyzetesre tudnak dagadni. Ettol tud lassu lenni egy oldal.

Ha nagyon nagy a felelem, akkor hijax, es akkor akinek nincs JS-e, ugyanazt az oldalt latja, csak oldalvaltasok lesznek benne. Google elso ket talalata elmagyarazza, mit es hogyan kell.

Köszi. Ez kimerítő volt.

HTML5-nél arra gondoltam, hogy az erősen támaszkodik a CSS-re már.
JS-nél pedig arra gondoltam, hogy végre ott tartunk, hogy a JS 1.2-t kezeli minden böngésző.
CSS+JS páros meg elkerülhetetlen az Ajaxhoz.

Szerintem 5 éve még nagyon meleg volt Ajax-ot használni fullra.

Azon keves ember koze tartozom, akik megtettek ezt a nagyon meleg dolgot 2006-ban:) (A szoviccek ellen: lanyokat szeretem :)

Az IE6 teljesen JS 1.2 kompatibilis. A bongeszok nem ebben kulonboznek, hanem a dokumentum-modellben (DOM). Ha nem kulonboznenek, nem beszelnenk kulonbozo bongeszokrol (es ossze is szoktuk oket mosni ha nem, pl. chrome-safari)

Van egy csomo mitosz a webrol, amikor igy egysegesitve megkapom oket, akkor visszaszolok :)

Eltavozasom elott tartottam egy 3 napos tanfolyamot az ujoncoknak CSS-JS-Ajax volt a 3 nap programja, minden napra egy. Gyakorlatilag vegig teveszmeket soroltam, napi 6 oraban (8 minusz szunetek). Egy eleg mely terulet, sok hulyeseggel, meg sok zsenialis huzassal, csak ez is olyan mint a foci, hogy mindenki ert hozza, mert a pofajaban van.

A hijax eloadasban latsz - szinten 2006-bol - egy shopping cart megoldast. Nem mondom, hogy a 2006-os kodot kene hasznalni, bar nem neztem bele, es 2006-ban ugyanugy az IE6 volt a minimum tamogatando bongeszo meg most is, szoval a technologia nem valtozott alapvetoen, csak egyszeruen - elterjedt.

Azt, hogy mit akarsz megirni, ne a technologia hatarozza meg, hanem a tervek. Frontendtervezes: use case folyamatok, ebbol lekovetkeztetni a szukseges adatmezoket, feluleteket, interakciokat.

Aztan 3 retegu kivitelezesi terv: bejovo adatok (backend) -> struktura (html) -> look(CSS) + behaviour (js)

En mondjuk nem feltetlenul dobnam ki a mar meglevo webshopot. Egesz jol lehet inkrementalis valtozasokat csinalni. Mondjuk ez attol is fugg, honnan jonnek a userek, ki a celkozonseg (pl. egy zenekar oldalan levo webshop lehet hogy jobb, ha cool, es nem kell kereshetonek lennie, de ha tejet-kenyeret arul, es az emberek ragugliznak, inkabb puritan, max gyorsitom a dolgokat az ajaxozassal).

Szoval picit kontextusfuggo.

Ha mar elojottek a teveszmek:
Egy ajaxos oldal nem feltetlenul lesz gyorsabb (nem feltetlenul hasznal lenyegesen kevesebb savszelesseget), mint egy hagyomanyos.
Az adatbazist kb. ugyanannyira terheli, az fuggetlen az atvitel modjatol. Ha sok adat valtozik (pl. termekeket listazo oldalon a lapozas), akkor ugyanazt az adatmennyiseget at kell kuldeni a halon, max. mas formaban. Akkor lenyeges a kulonbseg, ha keves, gyakran valtozo dolog van az oldalon.
Az ajax igazi elonye nem ez, hanem hogy kenyelmesebbe teszi az oldal hasznalatat, illetve hogy vissza tud szolni a server, ha valami tortent, ahelyett, hogy mondjuk folyamatosan pollozna. Ebben az esetben persze - a kenyelmesebb hasznalat mellekhatasakent - kisebb lesz az adatforgalom is.

--
Always remember - correlation does not imply causation.
Since realising this, my life has been so much better.

Irtam peldat arra, hogy mikor szamit sokat, es arra is, hogy mikor nem.
Lapozaskor van egy nagy tablazatod benne a termek nevevel meg araval (meg esetleg egyeb adatokkal). Ha nem tomoritesz pluszban (mondjuk ezt mindket esetben be lehetne kapcsolni), akkor teljesen mindegy, hogy <td> a szeparator, vagy XML-kent valami mas, esetleg a JSON szintaktikajat hasznalod. Kb. ugyanannyi adatot fogsz atkuldeni, mert nem az a resze a sok, hanem az adat. Persze ha direkt elrontod egyiket vagy masikat, es redundansan tobb sallangot is atkuldesz, akkor mar mas a helyzet. Ahogy egykori DB tanarom mondta: az adatbaziskezelok kozt sebessegben nagysagrendi kulonbsegek is lehetnek, o keresre akarmilyen lassut tud irni. De a lenyeg a skala masik oldalan van.

DB terhelesnel mennyivel lesz jobb dolgod, ha (mondjuk az elozo lapozos tablazatnal) a SELECTet egy ajax keresbol futtatod, mint ha siman oldalletolteskor tenned ugyanazt a queryt?

--
Always remember - correlation does not imply causation.
Since realising this, my life has been so much better.

"DB terhelesnel mennyivel lesz jobb dolgod, ha (mondjuk az elozo lapozos tablazatnal) a SELECTet egy ajax keresbol futtatod, mint ha siman oldalletolteskor tenned ugyanazt a queryt?"

Mondjuk annyival, hogy a környező DOM -dzsungelt nem kell legenerálni...feltehetőleg nem 1 query lenne az is.,..

'lekene sslje'

azenoldalamponthu

Jo, a kornyezo DOM dzsungel vagy bonyolult, ebben az esetben valoszinuleg az ajaxos megoldasnak is el kell kuldened, hogy megis mit csinaljon a nyers adattal (az meg DB-bol jonne). Vagy valami egyszeru, elore adott dolog, ami mar ugyis ott van a kliensnel (pl. ugyanaz a szerkezete, mint az elozo oldalnak, aminek az adatait kicsereli), ebben az esetben valami server oldali cache-el ugyanazt a terhelest tudnad elerni, mint a kliens oldali cache-el (hogy az oldal szerkezete mar tkepp odaat van).
Teny, hogy egyszerubb elerni ugyanazt ajax hasznalataval, de server oldalon is nyujthato ugyanaz a terheles.

--
Always remember - correlation does not imply causation.
Since realising this, my life has been so much better.

"hogy vissza tud szolni a server, ha valami tortent, ahelyett, hogy mondjuk folyamatosan pollozna"

Na erre rakhatnál egy linket! Eddig csak olyan megoldást láttam, hogy pollozgatott, olyat még nem láttam, hogy pl egy új üzenet esetén küldött valamit a usernek kérés (poll) nélkül.

Nyilvan a webserver nem fog kifele kapcsolatot nyitni neked a kliens fele, a HTTP nem teszi lehetove. Azt viszont meg lehet oldani, hogy ha nincs uj adat, akkor az elonditott lekerdezest elhuzod amig lehet (sleepelsz mondjuk), es amikor van adatod, visszakuldod, es a kliens ujat nyit. Ha nem jon ertelmes adat, akkor timeout utan vagy ujat nyit, vagy visszauzensz, hogy nincs uj adat, es erre reagal uj kapcsolattal.
Keretrendszerrol nem tudok, de nem olyan bonyolult, mint amilyennek elsore tunik. Volt meg par hasonlo technika korabban (vegtelenitett weboldal), lattam mukodo oldalt, de nem hasznaltam ilyen keretrendszert.

--
Always remember - correlation does not imply causation.
Since realising this, my life has been so much better.

Pollozas az lenne, ha t idonkent lefuttatja, igy atlagosan t/2 ido amig atkerul a kliensre az adat. Itt ahhoz, hogy kelloen hamar frissuljon, t-nek kicsinek kell lennie.

Az ajaxos "visszaszol" abban az ertelemben, hogy pl. t idonkent nyit kapcsolatot (ahol a t lehet nagy, az a lenyeg, hogy t<timeout ideje), t ideig nincs semmi, akkor visszaszol, hogy nincs semmi, es ujra probalkozik. Ha van, akkor a server rogton visszakuldi az adatot a korabban felepitett kapcsolaton keresztul, es zarja a lekerest. (es a kovetkezohoz uj kapcsolatot nyit) Szoval amint van adat, at tudod kuldeni, nem csak amikor a t lejarna, es uj kerest kapnal, mint a sima pollingnal.
Ha a serveren kelloen nagyra allithato t, es a kliens sem turelmetlen, akkor meguszhato a tobb percenkenti pollozassal kesleltetes nelkul.

A vegtelenitett oldalas modszer persze jo enelkul is. Atmegy a html tartalmi resze, de nem zarja le a tageket, hanem nyit egy script taget, es var. Amikor at akar kuldeni valamit, akkor general egy olyan javascript parancsot, ami epp azt csinalja (mondjuk valtozonak erteket ad), lezarja a script taget, es ujat nyit a kovetkezo keresnek. Ha timeoutolna, akkor kikuld valami nop jellegu parancsot, hogy a bongeszo ne zarja le a masik oldalon.

szerk:
http://en.wikipedia.org/wiki/Ajax_%28programming%29
http://en.wikipedia.org/wiki/Reverse_Ajax
http://en.wikipedia.org/wiki/Push_technology

--
Always remember - correlation does not imply causation.
Since realising this, my life has been so much better.

Comet-nek is hivjak, es sok esetben szerver oldalon meg mindig van polling. (ok, van egy hosszu keresed a klienstol a szerver fele, de ott meg mindig pollolni kell a memcache-t, adatbazist, etc.)
es ugye altalaban comet elegge tudja terhelni az atlagos webszervert, leven hogy 1 socketet a rajta csungo apache worker/thread folyamatosan fog, meg ha nem is tortenik semmi a csatornan.

amivel viszont ez egy nagyon eros eszkoz tud lenni, az mondjuk egy node.js web/socket szerver, igy a szerver oldalon sem kell feltetlenul pollolnia a backendet.

comet helyett szemely szerint inkabb a websockets technologiat eroltetnem, manapsag az ujabb browserekben van ra nativ support, a tobbire meg fallback-nek ott a flash, es ezt mar le sem kell fejleszteni, mert kesz libek vannak ra.

Tyrael

"A HTML5-ot nem vezettek be."

Hivatalosan még nem, de gyakorlatilag a küszöbön van hogy az összes böngésző teljesen támogassa a stabil kiadásában is. Mire eljut oda, hogy kész legyen, szvsz pont időben lesz.

"A CSS eddig is egyforman nezett ki mindenhol azoknal, akik tudtak, hogy hogyan kell a quirks - magyarul: 'javajozsi/phppistike' - uzemmodbol atvaltani standard compliantre a bongeszoket... Ettol meg mondjuk a grid tamogatas meg szar benne, de ez van."

Kár hogy nem is olyan régen három böngészőben háromféle képpen jelent meg az oldal, ahol leginkább az IE6-ban volt elkeserítő az eredmény. Tény hogy lehet gányolni a CSS-ben, IE vagy Webkit "fixeket", de ez minden csak nem megoldás. Szerencsére ma már ha szabvány kódot gyártunk, az többé - kevésbé ugyanúgy jelenik meg mindenhol, közel sincsennek akkora eltérések mint régebben.

"Az emberek infidezimalisan kis szamanak van kikapcsolva a JS ertelmezoje, manapsag mar a google se mukodne nelkule. (Search complete, google instant, stb)"

+1, sokan azt se tudják micsoda az a JS.

@Oregon: Lehet ritka igény, de én szoktam elinks-el is böngészni, számomra jó pont ha így is jól használható marad az oldal.

Először is megköszönöm a linkeket és az információkat! :)

Nem gondoltam volna, hogy csak 2022-ben jelenik meg a HTML5, ahhoz képest hogy a legtöbb böngésző már implementálta egyes részeit, ~1-2 év múlva vártam volna a megjelenését.

A CSS ilyen lehetőségéről nem tudtam, úgy gondoltam az [if lte ] megoldásra gondolsz.

"While I agree with Croft, the timetable is ridiculous given the history of rapid change in web development, that doesn’t mean the HTML 5 spec won’t be usable until 2022. In fact the far more important year is 2012, when HTML 5 will be finalized, if not official."

Szerk:
Lehet nem vezettek be, de peldaul a tobbek altal is emlegetett google sem veletlenul inditotta utjara a html5 tartalmat.

ettol fuggetlenul standard compliante modban sem egyforma minden, illetve ugye a browserek css1-2-3 supportja sem all azonos szinten(adott esetben 1-1 property nem ugyanugy mukodik, vagy csak reszlegesen van implementalva).
szoval hiaba rakod ossze a szabvany/ajanlas szerint a css layoutot, nem eleg a bongeszoket standard compliante modba allitani ahhoz, hogy egyforman jelenjen meg a layout.

Tyrael

Bakker! Milyen küszöbötök van?! A legtöbb még éppen nem támogatja szerintem...ráadásul eleinte igen érdekes lesz a html5 támogatás, mert ez nagy váltás, nem olyan, mint a html3-ról 4-re. Ahány böngészde, annyiféle csalafintaság kell majd szerintem. Érdekes lesz. Másrészt pedig, amit hivatalosan nem bocsájtottak ki, az nincs semmilyen módon, pláne nem gyakorlatilag kibocsájtva.

ugye tisztaban vagy vele, hogy a bongeszoket nem ugy fejlesztik, hogy megvarjak mig megirjak az okos emberek az elefantcsonttornyokban az ajanlast, es utana allnak neki implementalni a browserekben.
bar a regebbi mindenki maganak lefejleszt minden szart, ami aztan vagy bekerul az ajanlasba vagy nem jellegu fejlesztest tenyleg kezdi kicsit a hatterbe szoritani a "eloszor nezzuk mar meg hogy mire van szuksegunk, csinaljunk belole valami public draftot, es probaljuk meg osszehangolni a tobbi bongeszovel" jellegu fejlesztes.
ettol fuggetlenul a piacon levo bongeszok legfrissebb stabil verzioi mind tartalmaznak feature-oket a html5 ajanlas repertoarjabol, de valoban igaz.

Tyrael

( zoner | 2010. 09. 12., v – 00:13 )

jQuery: Szerintem pedig épp akkor érdemes AJAX-ot használni, ha azt jQuery-vel tesszük, egyszerűen sokkal jobban karbantartható lesz később a kód.

Fontos, hogy minden lényeges résznek működnie _kell_ javascript nélkül is. Tehát több oldalas listák lapozhatóak legyenek, a blokkok állapota (mondjuk egy naptár) URL-ből is átadható legyen, stb.

A lapozásra van egy olyan módszerem, hogy az URL-ben egy ilyet tárolok: ?page=0,1,5
Minden olyan blokknak, ami lapozható az oldalon van egy x-edik page értéke, tehát ha az 1-est kettesre váltom, akkor egyel lapoz a középső blokk. A lapozó linkek URL-je nem hash természetesen (SEO), hanem maga az url, de a lapozást bekapcsolt javascript-nél egy jQuery végzi. (return false; a click eseményben nem engedi, hogy az URL-re ugorjon a böngésző). Itt nagyon fontos, hogy ne töltse be az AJAX lekérés a teljes oldalt blokkostól, termékestől, menüstől, hanem csak azt, amire szükség van és amit lehet, JSON-al.

Tehát az AJAX-ot egy plusz kényelmi funkciónak kell tekinteni, ilyen tipikusan pl webáruházban az, amikor a "kosárba" gombra nem tölti újra az oldalt, csak a jobb oldali kosár blokkot. Javascript nélkül pedig ugyanúgy működik, csak a kosárba gomb újratölt vagy még a főoldalra is dob.

Ahol megengedett a full javascript az az admin felület és azok a dolgok, ahol nem lehet megoldani nélküle.

--
http://sandor.czettner.hu

Vagy észre sem vetted..
"Kis" (vagy bizonyos) oldal esetén nem biztos, hogy észre veszed..
Keress rá: jquery memory leak.. és láss csodát.
De érdemes simán a javascript memory leak-re rákeresned és olvasni.. utána ha megnézed a
jquery pluginokat szerintem elhányod magad Te is.. igaz én akkor is hánytam, mikor a jquery
forrását néztem át.

Honnan veszed, hogy nincs "igazi" tapasztalatom?
Elárulom van.. elárulom, hogy nem hülyeség egyik sem amit leírtam.. viszont az sokat elárul Rólad
"hozzáértés" szempontjából, hogy hülyeségnek tartod őket. Ajánlom böngéssz pár hónapig a neten a témában
hátha megvilágosodsz.
Érdekes, hogy nem szereted a frontrendeket.. de ebből az is következik, nem is ismered őket igazan, mégis
próbálod osztani az észt.

Igazabol mint mindennel itt is az a legfontosabb milyen ember kezd el dolgozni vele.
Neked eskuszom mumusod a memory leak, en hala istennek meg nem igazan talalkoztam vele, bar mondom nem szeretem es nem is dolgom, ezert abbol a kevesbol tudok kiindulni amit csinaltam es abbol a nagyon sokbol amit profi modon megcsinalt munkatarsam.

A hozzaertesed leginkabb a hozzaallasodbol vonom le. Rengeteg kezdotol hallottam mar ilyen mondatokat amig valaki helyre nem tette oket agyilag.
A kedvencem meg mindig az hogy a jquery-nek rakat szar a forraskodja. Erre megint csak annyit tudok mondani ha nem erted nem az o hibajuk.
De doszt sem fogok elkezdeni veled barmilyen erdeminek tuno vitat elkezdeni mert nem latom semmi ertelmet.

------------------
http://www.youtube.com/watch?v=Sf8cM7f6P2I

Talált, igen mumusom a memory leak, és ennek meg van az oka..
A jQuery forráskódja több okból szar.. de én sem látom értelmét Veled leállni
vitatkozni, főleg mivel gőzöd sincs témáról.
Majd akkor szólj, ha van mögötted is majd 2 év intenzív jQuery tapasztalat, fejlesztés, és mint én többször átnézted a forrását és vagy egy tucat pluginnak.

Es tobbszori atnezesre sem ertetted meg? Szegenykem, asszem ideje feladnod es munkat valtani...

Mumus alatt pedig azt ertettem hogy arra is rafogod hogy memory leak ami nem az, mert vagy nem tudod mi az a memory leak pontosan, vagy egyszeruen csak kenyelmesebb rafogni a szakmai inkompetenciadat a jqueryre.

Egyebkent egy dolgot magyarazz mar meg: Ha akkora fos a jquery, akkor mi tokomert hasznalod? Vagy csak felbaszta az agyadat par plugin aminek koze nincs a jqueryhez magahoz, es az azokban talalt hibakat frocsogod ra a jqueryre is?
Es ha mar itt tartunk a masik kedvencem a: "Fos az osszes, ezert megnezem a kodjukban hogy is kellene es megirom magamnak joval kevesebb kodbol".
Itt mar tisztan latszik hogy egyszeruen kevered a szezont a fazonnal.
Ez kb olyan mintha en elkezdenem anyazni mondjuk a Zend Frameworkot azert mert mennyi felesleges kod van mar benne aminek felet sem hasznalom (bar egyaltalan nem hasznalok ZF-et), csak mert nem tudom felfogni hogy mas teszta altalanos vagy specialis celra kodot irni.

De ne is vitatkozzunk tenyleg mert egyszeruen nem tudok versenyezeni a hatalmas 2 eves tapasztalatoddal. Behuzom filemfarkam inkabb es hallgatok rad.
Jovo heten asszem JQuery Suxx os poloban kimegyek a varosban hirdetni az iget. CSak meg azt nem tudom milyen alternativata ajanljak helyette a jarokeloknek. Milyen nev keruljon a polom hatuljara?

------------------
http://www.youtube.com/watch?v=Sf8cM7f6P2I

Jo az extjs, de licensz ugyileg eleg ingovanyos mostansag, szoval csak sikertelen(99.9%) vagy nagyon nagyon sikeres(0.01%) siteoknak ajanlott ;)
Amugy jo muri a public-ot jquery-ben, mig az admint extjs-ben irni, igy elkerulhetoek a jogi problemak.

Kell itt neked hulyeseget terjesztened, bizva abban, hogy valaki nem guglizik utana...

Nem hittem volna, hogy Johnt az eletbe egyszer vedeni fogom, egy rettenet arrogans ember, jopar elszallt - es neha veszelyes - gondolattal.

De ha valamire b.szottul figyel, az a memoria, meg egyaltalan az eroforrasok.

Video itt: http://www.yuiblog.com/blog/2009/02/02/video-resig-2/

Namost az IE-ben van egy memory leak, ami akkor jon elo, ha egy DOM elemet leveszel, de maradnak meg ra referenciak, pl. esemenykezelok. Sokaig nem ertettuk, mi ez egyaltalan, most mar tudjuk, es a jQuery igyekszik is lepakolni az esemenykezeloket. Hogy a kezzel felrakottakat is le tudja-e szedni, nem tudom.

Beta jQuerykben persze neha van memory leak, de az azert beta.

A kodjaval - no nem mintha szeretnem a stilust - valoszinuleg az a bajod, nem erted a javascriptet, es egyszeruen mast varnal - vegulis ez egy LISP implementacio, a Self-bol atvett oroklesi modellel, nem hagyomanyos imperativ nyelv.

Johnt lehet szidni, sok fassagot mond. A jQuery se akkora vilagmegvaltas, mint a fanjai beallitjak, sot, a koncepcioja baromira nem skalazodo szerIntem. A pluginjei jelentos reszet felhulyek irjak, ez is stimmel, igaz ez a javara is, meg minden platformra.

De amit mondasz az netto hulyeseg ettol meg, felinformaciok felreertesebol.

A JS nyelv ismeretehez erdemes vegighallgatni crockfordot, ha a jQuery kodstilusat kifogasolod, ajanlom a "function the ultimate" cimu videot.

Guglizz te is picit.

(diszklemer: nem szeretem a jQueryt)

Nem talált.
A kódjával mint írtam több probléma is van.. csak pár hirtelen:
- függvény halmozások: size() kontra length, trim kontra String trim(), stb..
- nem moduláris.. a szar fx réteget is beletolta mindenhová..
- extend-et használ ott is ahol lehetne prototype-t.. ezt írták többen is neki.. válasz: nem a legfontosabb
- tele van szeméttel: browser és társai
- hihetetlen amatör hibák is vannak benne.. fölösleges változó létrehozások..
- az ajax megoldása az 1.4.0-ban is egy is bughalom volt, ami már ciki 2010-ben. 0-as http code == Success?
- stb.
Mielőtt azt hinnéd ezek csak az én téveszméim.. elég sokan vannak még ebben a téveszmékben..
Ami a google keresést illeti.. nem járatni kell a szádat, hanem beütni a keresőbe.. nem nekem kell hinni.. olvass! talán értelem is költözne Beléd.
Igen.. valóban nem értem a JS-t.. de legalább nem irok olyan, hogy IE van egy memory leak.. mert
a) nem egy van:)
b) itt a javascriptel létrehozott leak-ekről van szó, ami néha valóban böngészőfüggő, de többnyire nem az.
c) az általad szagszerűen (lepakolni, felpakolni) megfogalmazott leak, alapvetoen igaz tobb nyelvre is.. (pl.: java),
ha élő referencia marad valamire az nem fog egykönnyen menni a levesre.. nem IE függő.. kapizs?
Látszik, hogy Te se foglalkoztál a jquery-vel, csak próbálsz védeni valamit, amihez nem értesz..

Nezd, en beirtam a keresobe, hogy jquery memory leak, ezeket az ismert hibakat kopi vissza, ezutan irtam a kommentemet.

A nem ertek hozzat kikerem magamnak. Nemeth Adam vagyok, az orszag egyik elso js intenziv weboldalanak vezetofejlesztoje, tobb nagy ceg frontend szakertoje. Teged hogy hivnak hogy ennyire mgmondod a tutit?

Az, hogy leragadsz az első oldalnál, amit a google visszad, az a Te problémád.

"az orszag egyik elso js intenziv weboldalanak vezetofejlesztoje"
Mi lenne megpróbálnál/megtanulnál magyarul fogalmazni első körben?
Amúgy ne haragudj.. de nem fogok hasra esni attól amit írtál.. és még mindig azt mondom, hogy nem értesz hozzá..
mint az a másik aki mint pár sorra feljebb ki is derült konyítani sem konyít a témához, de felháborodott azon, amit írtam.

A nevemhez pedig semmi közöd, tépj sorszámot, most nincs időm, több nagy cég frontend szakértőjével és az orszag egyik elso js intenziv weboldalanak vezetofejlesztojével értelmetlen szócsatát vívni, főleg mivel mint írja: (diszklemer: nem szeretem a jQueryt).. nyilván akkor nagyon ismerheted!. Szólj, ha átnézted a kódját..
Egyébként ha már ekkora a mellényed.. dobd már be ide légy szíves azt az intenzív micsodát, szerintem sokan kíváncsiak a mester művére.. főleg a js intenzív miatt, akármit is jelent..:))

Nem fogok vele troll-t feedelni, de az adatlapombol rajohetsz, melyik az :)

2006-ban az az oldal nagy szam volt... ma mar nyilvan sokan kozolnek, hogy ket het alatt irnak jobbat, ami nyilvan nem igaz, de jol hangzik. Mondjuk ma mar en is sokkal jobb UI-t terveznek, akkortajt az egyszerusegen volt a hangsuly.

Aztan persze jottek a JS demok, chatkliensek, zenelejatszo js-ben (utobbi mogott a site mar csodbement sajnos), ismerem es hasznaltam a Prototype-ot, a YUI2-t, az Ext JS-t, mikor epp mi volt a site-ban, utobbi idoben jQuery-t is, nyilvan.

Es en is nagy flamer voltam, ezert allok le a fiatalokkal vitazni :D

Csak tudnam, mi a mogottes tartalom, amire ennyire fel van, arra szoktam figyelni, hogy ne nagyon flame-eljem tul magam a tartalmon :)

en mostanaban regeltem csak, mert megy ki cikkem, es nem hiszem, hogy a phpnuke-os adatbazist atmentettek volna a 90-es evekbol, meg aztan mas is volt a nickem akkortajt.

widget van, pici:

http://jo-hely.hu/~aadaam/Panorama.html

Ebben egy betu lib nincs, nyilvan emiatt nem is megy IE alatt. Bar elvileg ha rahuzod a canvas wrappert megy, de ez megiscsak egy picike, parszaz soros widget, nem teljes oldal.

Meg van meg olyan, amit az iPadomra irtam, amiben nincs lib, mert egy device-ra lesz, minek.

Az IE event kezelese miatt erdemes behuzni libeket pl., mar csak szintaxis miatt is.

A nagyobb oldalakat orultseg lenne byte-rol byte-ra 0-rol megirni, olyat lehet, hogy sajatot fejlesztunk egy mar letezo fole (igy lett a prototype-bol kb. YUI a vegere, tobb mint 6000 sor javascripttel - ennek mondjuk tobbsege business logic), de az, hogy akkor en most lecserelem az MSIE wrappereket tartalmazo libeket, ezt idokidobasnak erzem.

Varja', intranet, annal sincs masik browser :)

Ott sokan beszivtak azzal, hogy az IE specko technologiait hasznaltak a 2000-es evek kozepen, sz'al inkabb a lib... :)

(Az IE6 2002-ben a vilag legjobb bongeszoje volt, pl. szinte az egyetlen, ami tudott "ajax"-ot; ezt hajlamosak az emberek elfelejteni)

Az eletrajzom ki van linkelve a hup adatlapomon.

Csak napi szinten foglalkozom Javascript fejlesztessel, es ismerem ezeket az embereket, ezeknek az embereknek a munkajat, ezeknek az embereknek a prioritasait.

Lattam en mar a jQuery forraskodjat, nem szeretem azt a nyakatekertseget, es minden mindennel osszefuggoseget, amit oda csinalt, de ez egy DOM library, azt az egyszeru api-t, amit ad, mashogy nehez kivitelezni.

De tudodmit, dobj egy levelet nekem vagy yaano-nak, es az oktoberi budapest.js -en szerintem szivesen meghallgatjuk azt, hogy megis milyen ertelmes indokaid vannak, egy 5-10 perces prezentacio formajaban.

BTW, az ehelyett ezt kene reszhez: ilyenkor azt felejted el, hogy ez egy trace-based forditasu nyelv, igy ezeket kioptimalizaljak a bongeszok. Szemben a struktura alapu forditasuakkal, ott ezt nem lehet megtenni.

Bármelyik "tényleg jó".. ha jó az adott feladatra és Neked megfelelő.
A jQuery alapja szerintem az egyik legjobb a többihez képest (prototype, mootools, gwt, ..), (ezért használom) ép azért mert az alapja a DOM "manipuláció". A probléma ott jön elő vele, ha egy valóban komplex oldalban gondolkodsz, akkor előjönnek a korlátai.. komplex oldalban teljesen ajax alapú, oop-s megvalósítást értek.. de nem fejteném ki jobban.
Viszont erre jön rá, hogy szar a kódja, szerintem/nekem.. felsoroltam párat feljebb, hogy miért.. ami fontos lemaradt: nekem alap, hogy ha írok valamilyen nyelven egy függvényt, akkor a kódban is dokumentálom.. a paramétereket, a változókat.. szinte mindent.
Valószínű jövőre több időm lesz és részben kényszer miatt is nekiesek átírni a jQuery-t.. de az legalább pár hetes munka, addig maradnak a patchek..
Szóval, hogy valami tényleg jó-e, az a attól függ mi a célod, mit akarsz vele megcsinálni..

Attol, hogy valakinek mas velemenye van, attol nem kene elassa magat. Inkabb orulj hogy sokfele velemeny van, itt ugyis az szokott a mantra lenni hogy az jo, nem ?

Egyebkent a negativ dolgokbol is lehet tanulni, en pl ertekelem hogy ha valaki elmondja szerinte mi miert nem jo (o elmondta), attol fuggetlenul hogy mit tett le az asztalra vagy hogy eppen nincs kedve jobbat irni vagy eppen anonim akar maradni. Irrelevans.

Pár sorral fentebb írtál ezt azt.. pár "válasz"..
1) nem mutatok semmit, mert nem is ígértem olyat, és megnéztem ugyan az oldalt amit linkelt.. de nem fikáztam.. és nem azért mert elájultam tőle.
2) nem vagyok/leszek fent se az iwiw, se a facebook se egyéb oldalon, nincs fent sehol életrajzom és egyebek: részben paranoia, részben más okból
3) ha ez egy szakmai oldal lenne, szívesen felraknék "csámcsogni" valókat, de ez nem az a hely.. és elvből nem tolom más szekerét.. szájkarate helyett az lenne az igazi
4) nem mondtam, hogy fikázta, de neki is volt pár negatív véleménye a jQuery-ről
5) Előző életemben vakond voltam, szóval szeretek ásni:-)
6) ha ez az az oldal lenne, azt mondanám, üljünk le egy pofa sörre és essünk szakmailag egymásnak.. elfogadom, ha valakinek igaza van.. de ez még mindig nem az a hely.:)

Csak saját pluginnokkal érdemes használni, mivel az összes ami fent van az egy rakás szar.
Régóta csak azért töltök le pluginokat, hogy megnézzem belülről, hátha van benne valami browser függő okosság.. de utána megy mindegyik ahová való: a szemétbe, mert hihetetlenül szar implementációk.
Eddig minden esetben legalább a harmad akkora plugint tudtam írni az adott feladatra.. és memory leak menteset,
merthogy az összes pluginban hemzsegnek.
A kibaszott jó keretrendszerhez meg annyit, hogy a 1.4.0-ban hónapokig, volt egy akkora bug mint ide Jeruzsálem.. és baszták javítani.. úgy hogy tőlem bekaphatják, de tövig.

( wladek1 | 2010. 09. 12., v – 09:10 )

Ajax, illetve méginkább: JSON. Sokkal optimalizáltabb; könnyebb kezelni, s rögtön ott van pl a jQuery getJSON metodusa; callbackban meg pofonegyszerü a feldolgozás és nem kell csak emiatt event observer sem.

'lekene sslje'

azenoldalamponthu

( sunmao v | 2010. 09. 12., v – 14:05 )

Üdv!

Örülök hogy pont most nyílt egy ilyen topic, ugyanis éppen most írom a szakdolgozatomat. A feladat egy olyan webes alapú rendszer készítése, amelyen keresztül hallgatókat lehet felvenni egy adatnázisba (mysql adatbázis). A rendszernek a lényege, hogy azokat a hallgatókat akik elkezdték/befejezték/leadták stb... a szakdolgozatukat tudjuk kezelni elektronikusan, illetve nyomon tudjuk követni ki hol tart, valamint statisztikát lehessen készíteni pl hány PTI-s hallgató írt szakdogát 2010 második félévében. A lényeg, hogy az egésznek az alapja php, de mivel ez egy admin felület lesz (értsd: localhoston megy és csak jelszóval lehet bármilyen funkcióját is elérni) ezért úgy érzem, hogy itt megengedhető a js. A jquery libet kezdtem el használni, elég jónak tűnik sok pluginnal jó apival és példákkal. Ettől függetlenül szeretném kikérni a véleményeteket a dologgal kapcsolatban, hogy ez szerintetek jó lesz-e így. Mert például egy link-et divbe megnyitni (php/html oldalt a "contentbe" targetolni) nem tudtam máshogy csak ezzel a jqueryvel. Illetve van nagyon sok hasznos pluginja, pl most a validation-t nézem és ezzel szeretném majd a bekért adatot (form-ot) ellenőrizni. Rakjak mellé még php check-et is vagy nem szükséges. Illetve szerintetek nem gond, hogy variálom a js-t meg a php-t?

Bár még most a "felvesz" részt csinálom, de van egy prototípus amibe már van listáz/szűr is, mivel elég sok adatot tárolok a hallgatóról ezért nem fér ki a táblázat (széltében) az egész oldalra ezért azt gondoltam, valami filteres megoldással (szintén jquery) majd lehet checkboxokat pipálgatni és akkor bővül a táblázat. Illetve ha a hallgatók számát nézzük, akkor egy oldalon töltődjenek be és egyre menjen össze a scroll vagy page-eket csináljak, ha page-eket akkor azt milyen megoldással csinálnátok?

Ja, a témavezetőmnek volt még olyan kérése, hogy lehessen olyat, hogy ha például statisztikát készít akkor egy tulajdonságon belül lehessen több dolgot is megadni, mondjuk a 2010-ben szakdolgozatát leadott PTI-s ÉS MI-s hallgatók. Na most itt ugye nem mindegy a kapcsolat, hogy ÉS/VAGY van köztük, ezt én úgy gondoltam, hogy dinamikus frame el oldom meg (szintén jquery). Alapból lehet választani hogy milyen hallgató legyen, mellette egy alapból üres legördülő select ahol van ÉS és VAGY opció, ha innen választunk valamit megjelenik még egy select amiben megint tudunk MI-s vagy PTI-s hallgatót választani, illetve megjelenik hozzá megint egy ÉS/VAGY select is. Persze minden variációt nem lehet előállítani így lesz lehetőség saját SQL parancsok írására is. Mivel nem Marika néni fogja használni ezért ez nem okoz majd problémát, mármint ezt a rendszert a témavezetőm akarja élésbe használni, ő pedig tud SQL utasítást írni.

Nagyjából ennyi, ha valami nem világos szóljatok.

( Madman | 2010. 09. 13., h – 13:58 )

a bongeszokben levo JS motor meg mindig eloszeretettel leakel, kb a vegtelensegig, amig aztan lelovod mert haldoklik es 1 giga ramot zabal

( uid_194 | 2010. 09. 13., h – 17:51 )

En ket lehetoseget latok:

1) AJAX, fallback nelkul. A usernek ilyenkor adsz egy "javascript kell, vagy tunj el, koszi!" jelzest.
2) AJAX, fallback-el. Kis elorelatassal a webes applikaciok (jajj, de szep szo!) tobbseget szerintem meg lehet ugy oldani, hogy ha JS ki van kapcsolva, akkor is valamennyire mukodjon. Legfeljebb nem lesz olyan szep es szines-szagos. Ez extra munka, ellenben nem vesztesz latogatot.

A magam reszerol en a masodik megoldas hive vagyok. A te esetedben szerintem nem kerulne sokkal tobb meloba ha JS-el es anelkul is meg lenne oldva a dolog. Igy a JSt bekapcsolok orulnek, mert hudejo modern a dolog, akiknek meg nincs, azok is tudjak hasznalni a webshopod.

( Ajnasz v | 2010. 09. 13., h – 19:40 )

Szerintem rossz a kerdes. Mi a legmegfelelobb eszkoz a problema megoldasara? Ahhoz, hogy egy statikus weblapot kipakolj felesleges JS-t hasznalni. Ha ezzel megkonnyited a weblap hasznalatat, esetleg egy webalkalmazast keszitesz, akkor egyertelmuen erdemes JavaScripttel megsegiteni az oldalt.
--
HUP Firefox extension

( Kormoraan | 2010. 09. 14., k – 20:53 )

Hm... most az jutott eszembe, hogy végre rendesen bugmentesre megcsinálnák az XSLT támogatást a böngészőkben, nemigen gondolkodnék a js-sel összeállított oldalakon.

Konkretan az, hogy ma mar az uzleti eletben tevekenykedo cegek nem foglalkoznak azokkal a felhasznalokkal, akiknel ki van kapcsolva a js. Egyszeruen nem eri meg penzt es energiat forditani egy max 1%-os penetracioju csoportra, akik raadasul jo esellyel nem is target audience.
Amugy igazad van, a cikk sok allitasa (aka best practices) meg termeszetesen ma is all, de a cime, azaz, hogy diszkret js mar tulhaladott.

Én értem miről beszél és részben osztom is.

Nekem sincs kedvem két engine-t írni egy ajax verziót és egy a nélkülit. Aztán jöhet külön verzió a kézi eszközökre is amikor lassan már mindegyik eléri vagy meghaladja a 800px szélességet.
A processzorok is egy bivalyabbak a kézi készülékekében.

Speciel en olyan honlaponokon melozok ahol az az 1% szamit.
Igazabol az a nem mind1 hogy mekkora szamnak az 1%-arol beszelunk.
Napi 1000 felhasznalonal nyilvan nem erdemes torodni vele, viszont napi x millio egyedi latogatonal mar elegge nagy szam az 1% is.

------------------
http://www.youtube.com/watch?v=Sf8cM7f6P2I

Pont, hogy mindegy mekkora szam az 1%! Mikor egy technologia eljut arra a szintre, hogy altalanosan hasznaltta valik, onnantol egyszeruen nem eri meg eroforrast pazarolni arra, hogy mi van ha megsem all rendelkezesre. Es itt most altalanossagban beszelek, nem specifikus kivetelekrol! (pl repulogep es terkepek, mint backup)

De mashonnan kozelitve: van-e nalad mindig egy gyertya szukseg esetere, hatha nincs epp se aram se elemlampa?

Ne haragudj de feligazsagokat mondasz.
Nagyon konnyen szamszerusitheto a dolog. Meghatarozod mennyi plusz munkaoraba kerul a cegnek az hogy tamogassa a JS nelkulieket, meghatarozod mennyit koltesz el ezekre a munkaorakra havonta, valamint nezel egy statisztikat mennyit koltenek nalad vagy mennyi beveteled van az adott userekbol.

Konnyen belathato hogy az az 1% boven kitermeli a munkaorat es meg nyereseget is, akkor megeri foglalkozni vele. Plusz mellette ott van a presztizs is.

------------------
http://www.youtube.com/watch?v=Sf8cM7f6P2I

Nezd, nincs se idom se kedvem vitazni veled a vegtelensegig. En a mai valosagrol beszelek, te pedig elkepzelt specialis esetekrol.

Ha egy ebay, ami specifikusan netes ertekesitessel foglalkozik (es naluk ugye eleg nagy az az 1%) funkcionalitasanak jo reszet elveszti js nelkul, akkor nem hiszem, hogy ez az egesz diszkret js problema relevans lenne 2010-ben.

Akkor megismetlem hatha ezelott nem ertetted meg, nem elkepzelt, viszont valoban specialis.
Plane magyarorszagon felfoghatatlan es hihetetlen, de itthon is lehet olyan munkaheleyt talalni ahol tobb millios egyedi latogatottsagu oldalt fejleszthet az ember (en 2-t tudok, de tuti van tobb is).
Es direkt mint ellenpeldat hoztam fel hogy van olyan helyzet amikor igenis figyel ra az ember.
Most nem foglak bombazni annak az oldalnak a pontos latogatottsagaival amit fejlesztek sokad magammal, de itt mar nagyon is erdemes figyelni arra a par % userre akinek nincs JS, sot egy reszenek meg Cookie sem.

------------------
http://www.youtube.com/watch?v=Sf8cM7f6P2I

Szerintem picit elbeszelunk egymas mellett, mert ugy erzem van metszete a mondandonknak.
Egyezzunk ki abban, hogy a kozegben ahol en dolgozom az a jelen trend, hogy a js ma mar ugyanolyan alap, mint a telefon vagy a bankszamla. Tudjuk, hogy vannak emberek akiknek nincs, de kulon energiat mar nem pazarlunk az o minnel jobb kiszolgalasukra. Ez nem azt jelenti, hogy juszt is hasznalhatatlan egy oldal js nelkul, hanem azt, hogy nem garantalt a 100%-os funkcionalitas. Ennel jobban azt hiszem nem tudom leirni.

Ahol az 1% felhasználó annyira számít, hogy akár csak reálisan felmerjüljön a gondolata, hogy talán megéri a hatalmas plusz munkaigényt, ott szerintem elég nagy csapat dolgozik az egész projekten és sok-sok irányból gyűjt mindenféle titkos adatokat (forgalom, fejlesztési idő, fejlesztők száma és fizetése stb.) hogy maguk hozzanak döntést és ne a hup szedett-vedett hallgatóságától kérjenek tanácsot.

Konkretan van egy elegge ismert felhasznalo (googlebot), "aki" kikapcsolt JS-el netezik. Lehet, hogy a latogatoknak csak 1%-at teszi ki a letoltesei szama, de azert nem art kiszolgalni.
Persze nyilvan valamennyit engedhetsz a kovetelmenybol, de ha csak JS-el mukodik az oldalad, akkor ne szamits sok latogatora (mar ha technikailag nem indokolt a JS).

--
Always remember - correlation does not imply causation.
Since realising this, my life has been so much better.

minden kotekedes nelkul:
- milyen celcsoport?
- milyen terulet? (weboldal, intranet alkalmazas, mobil, stb)

igen, igazad van abban, hogy atlaguser atlag gepen 99%-ban engedelyezve van a js

... aztan csinalsz - a peldanal maradva - egy hupos webshopot, rengeteg ajax hivassal es csodalkozol, hogy miert nincs tobb 5 latogatodnal havonta ;)

szoval adott helyen igenis van letjogosultsaga, es jobb ha tud rola a fejleszto, hogy _lehet_ igy is, mint ha nem :)

[szerk: eliras]
--
x-plane :: hu

( sunmao v | 2010. 09. 16., cs – 11:56 )

Ha már úgyis ilyen aktív a topic. Lenne egy konkrét kérdésem! Így nyitok meg divben php oldalt js el:

$(document).ready(function() {
$(function() {
$('.link').click(function() {
var $this = $(this);
var cim = $this.attr('href');
$("#content").load(cim);
return false;
});
});

});

class="link" href="alma.php">ALMA class="link" href="barack.php">BARACK class="link" href="korte.html">KORTE

Ez eddig nagyon jó. Csak, minden php oldal elején levizsgálom, hogy be van e loginolva a user, teszem ezt az alma.php elején is. Na most ha user valamiért, már nincs be loginolva, akkor kidobja a kezdő lapra a linkre kattintás után, igen ám de a js közben végzi a dolgát ezért az fog történni, hogy ahelyett, hogy vissza töltődne a kezdő oldal teljesen, a kezdő oldal a content részbe fog betöltődni... Erre kéne valami megoldás. A click metódus elejére próbáltam ilyen berakni, hogy location.reload(); De akkor viszont nem tölti be az alma.php-t a div-be.

Egyik lehetőséged, hogy 


$.get("alma.php", function(data) {
 if ( data.indexOf('loginolvavagyok') != -1 ) {
  $("#content").html(data);
 } else {
  $("#content").html("Nem vagyok loginolva");
 }
});

Lényeg, hogy olyan stringre keresel lekért oldalon, ami csak akkor jelenik meg, ha be vagy loginolva.

( Tyra3l | 2010. 09. 16., cs – 16:40 )

sajat tapasztalatok alapjan kozossegtol fuggoen 0-5%
itt hupon lehet hogy inkabb az 5%hoz van kozelebb, mint a 0hoz.

Tyrael

( egmont | 2010. 09. 16., cs – 19:35 )

A JavaScript arányára kíváncsi lennék, ha nem titkos. Azon gondolkozom, hogyan lehet értelmesen megoldani. Mert ugyebár az nyilván nem megy, hogy if (javascript_enabled()) log_this() else log_that()... ha a JavaScript kód visszapingel (mondjuk ajaxosan), és ezt az összes oldalletöltés számával veted össze, akkor nagy lesz a hiba (például user-nek van JavaScriptje, csak becsukta a tabot mielőtt letöltődött volna az oldal). Azon gondolkozom, hogy lehetséges-e valami szerveroldali forgalmat generáló akciót (például átirányítást) előidézni csak abban az esetben, ha nincs JavaScript...

Ezzel pont az a baj, hogy tévesen JS-mentesnek fogod hinni, ha valaki idejekorán (a letöltés közben, az ajax lefutása előtt) becsukja a böngészőjét. Olyan megoldáson töprengtem, ami nem számol tévesen semmit (legfeljebb annyi történhet, hogy egyáltalán nem számolja némely félbeszakadt letöltést).

Közben valaki súgott egy jó megoldást: <noscript><img src=...></noscript> és logolod a kép letöltést (persze mindig egyedi url, avagy cache paraméterek okosan beállítva).

legegyszerubb szerintem a <noscript> tag hasznalata.
<script>tagbe beleraksz egy ajax hivast, ami jelzi a js letet, <noscript>-be meg beleraksz mondjuk egy <img> taget, ami linkeli a logolo php scriptedet.
de persze ez csak egy lehetoseg a sok kozul.

edit: elnezest nem gondoltam, hogy ilyen buta a default drupal comment modul.

Tyrael

( Tyra3l | 2010. 09. 17., p – 14:03 )

van manapsag meg valaki, aki direktben jatszik az XMLHttpRequest-tel, es nem valami js frameworkot hasznal?
a js framework fejlesztok kivetelevel.

Tyrael

Ezzel csak megnehezited a sajat dolgod. Vannak nagyon lightweight libek is, pl underscore.js. Mar evek ota dolgozom ezen a teruleten, meg igy is ernek eleg nagy meglepetesek. Akkor erdemes sajat lib fejlesztesebe kezdeni, ha tanulni szeretnel, arra nagyon jo alapanyag, viszont ha elesben es gyorsan van szukseged valamire, akkor mindenkeppen fontold meg valaminek a hasznalatat.
--
HUP Firefox extension

Az a bajom a külsős _szerveroldali_ libekkel, hogy:

1. Sechole hosszútávon, ha az ember nem frissíti őket.
2. Frissítést követően előjöhet, hogy nem megy az oldalad.
3. Nem az adott nyelvet tanulom meg, hanem az adott libet. (függőség)
4. Nem kell az adott lib minden ficsőre.
5. Tanulok közben.
6. Van időm.

1. a sajatodban valoszinuleg elobb talalna valaki biztonsagi hibat, ha keresne (security-by-obscurity)
2. ez barmelyik sajat modositasod eseteben is megtortenhet
3. so-so, igazabol nyugodtan lehet valtogatni a nativ es a lib eszkozei kozul (C-ben is lehet asm beteteket hasznalni :P), viszont nem __kell__ megtanulnod az osszes browser osszes kulonbseget, vagy hogy a XMLHttpObject callback eventjeben a 4es statusz kod jelenti a sikeres ajax hivast (ha jol emlekszem, eleg reg volt, amikor meg direktben hivogattam).
4. mostanaban szinten az osszes lib plugin jelleggel mukodik, annyit hasznalsz fel belole, amennyit kell.
5. az biztos, de mostanaban kevesebb js(vagy barmilyen) framework fejlesztot keresnek a munkaero piacon, mint alkalmazasfejlesztot.
6. ezt te tudod, de lasd 5.-os pont

Tyrael

+
De fejlesztésnél nálam az az elsődleges, hogy bármilyen gépen gyorsan fusson. 2 monitort csak arra használok, hogy ie6,ff,chrome kimenetet lássam és teszteljem egy 800Mhzes P3on.
Külső libek amiket használok az az "excanvas" és az ie6 transparent png fix.

Hosszú távon saját script nekem jobb, mert ha előjön később vagy akár "fejlesztés" közben valami hiba, akkor tudom mit és hol keressek.

amig emlekszel ra, vagy amig egyedul fejleszted, addig lehet elonye a sajatnak.

viszont ha mondjuk jonne az igeny, hogy akkor most drag&drop kell, akkor sajat libbel megneznem, amig megcsinalod szepre, gyorsra, cross-browserre, 3rd party lib eseten viszont eloszor nyomsz egy keresest a google-n, es az esetek nagy reszeben betolt-mukodik-orul.
manapsag nagyon gyorsak a javascript motorok a bongeszokben, es vannak direkt lightweigth libek is.
ie6 transparent png fix pont nem a gyorsasagarol hires: egyreszt az AlphaImageLoader alapbol lassu, masreszt a kulonbozo fix js-ek meg tudjak tetezni a dolgot (behavior-rel huzzak fel a fixet, ami lassu, vagy filter css property-vel, az meg nem valid css property, etc.).

persz ez ebben a szalban offtopic.

Tyrael

jo de ie6 ~0.4% csak ez húzza be a pngfixet. (havi 300-400k hit), ami ie6ról jön. (Meg azért elég sok kép kell ahhoz, hogy lassú legyen)
ie7+ = ~12%

Bármit amit írok, szabályosan, megfelelően beszédes változónevekkel látom el.
Semmilyen funkciót nem teszek ki lógni a semmibe, mindnek van egy szülő objektuma.
Bárki be tud kapcsolódni a fejlesztésbe, akibe szorult egy kis józan paraszti ész és minimális logika.
Ezen kívül szét van szedve mindig az összes js. És az oldaltól függően loadolja be a fő objectbe az adott libet.
Ezzel igazából a fejlesztés is egyszerű, mert nem ömlesztve van az egész.
Mellesleg egy drag&drop, amit említettél gyerekjáték cross-browserre megírni. Nagyon kevés dolog van, ami külső lib használatát indokolná. De egyik sem programozási akadály. Csak lustaság indokolhatja egy oldal tönkretételét.

"Csak lustaság indokolhatja egy oldal tönkretételét."
ha kiforgatjuk egymas szavait/altalanos bullshitet puffogtatunk irok en is egyet:
- az esetek nagyreszeben az a fejleszto, aki szarozza a libeket nem tud jobbat irni.
- az esetek nagyreszeben a jo es a state of art megoldas kozti fejlesztesi ido nem all aranyban a ket megoldas altal hozott hasznossaggal.

kivancsi lennek milyen dokumentaciot vezetsz a sajat libjeidrol.
gondolom a jquery fejlesztoje is trivialisnak gondolja a sajat kodjat, megis lehet hogy rosszneven venned, ha azt mondana, hogy nincs doksi, mert magatol ertetodo a kod, es aki nem erti, annak nincs meg a minimalis logika vagy jozan paraszti esz.

Tyrael

Az biztos, hogy jelenleg nem tudnék jobb frameworköt írni, mint pl egy jquery, ez nem is vitás.
Úgy beszélsz, mintha itt mindenkinek js framework fejlesztőnek kellene lennie.

Természetesen a jquery használatához is elég lenne józan paraszti ész. Ha van mellé example, akkor még az sem kell.
Természetesen ha egy ilyen "komoly" cross-browser libet fejlesztenék, akkor csak úgy használnák az emberek, ha komoly dokumentációt is adnék mellé. Különben nem érné meg vele foglalkozni. De mint írtam nem olyan javascript kódokat írok, amit később több millió ember fog használni a saját oldalán, hanem olyat ami teljes egészében, többnyire csak az adott oldalon használható, de azt legalább gyorsan.

Egyszerűen nyilvánvaló igazságokat írtam le az ilyen libekről. De gondolom arra egyedül is rájössz, hogy 1 funkció gyorsabban lefut, mint 2 vagy 10-20. Ez a helyzet az ilyen frameworkökkel. Tele van hülye-biztos 2x leellenőrzöm, hogy a hülye júzer jól írta-e be a paramétereket és felépíti egy adott node összes tulajdonságát leellenőrizve, hogy ievel van e dolga, akkor is ha nem is használnád az adott only ff/ie/etc funkciókat.

De ha te ebből élsz, hogy webfejlesztő vagy, akkor biztos, hogy neked kifizetődőbb egy jQueryt használni, mert rövid idő alatt több funkciót produkálsz.

De fölösleges ilyen hülyeségekbe belemenni mindennek meg van a maga helye és mindenki azt használja amit akar és ott, ahol úgy érzi szüksége van rá.