ugrás a tartalomhoz

You Might Not Need jQuery

retnek · 2014. Feb. 20. (Cs), 16.26
Nem minden esetben szükségszerű a jQuery-t használni
 ■
1

Amíg a böngészők nem követnek

inf · 2014. Feb. 21. (P), 01.54
Amíg a böngészők nem követnek közös szabványt szinte semmiben, addig egyszerűen muszáj. A képet még a visszafele kompatibilitás is bonyolítja, pl ie 6-7-8-9-10-11 mind eltérően viselkednek bizonyos helyzetekben...

Ahhoz, hogy sok böngészőben támogatott és DRY kódot írjon az ember szükség van egy közös API-ra. Ez lehet jquery, vagy bármelyik másik keretrendszer interface-e, de lehet használni a jelenlegi szabványt is, és polyfillezni.

Csak hogy egy jelenlegi problémát hozzak fel, ezer féleképp lehet kliens oldalon adatot tárolni, és általában, ha ilyet akarunk, akkor tényleg csak annyi kell, hogy legyen egy interface, amin keresztül le tudjuk tárolni és vissza tudjuk kérni az adatot. Az már egyáltalán nem érdekel minket, hogy mindezt hogyan csinálja a böngésző (Cookie, WebSQL, LocalStorage, IndexedDB, etc...)

Olyan speciális esetek előfordulhatnak, hogy csak egy adott böngésző egy adott típusára fejlesztünk mondjuk egy cég belső hálójára. Esetleg gyorsan összeszórunk valamit, hogy teszteljünk egy rest service-t, stb... Ilyen esetekben valóban nem kell jquery, egyébként igen.
2

Btw kerestem egy fél órát, de

inf · 2014. Feb. 21. (P), 02.18
Btw kerestem egy fél órát, de nem találtam olyan keretrendszert, ami a helyi adattárolást cross-browser támogatná. Tudtok ilyenről?

(Ha lesz egy kis időm lehet, hogy írok egyet.)
3

Tárolás

Hidvégi Gábor · 2014. Feb. 21. (P), 08.36
Keretrendszer? Minek? Legfeljebb egy kilobájtból megvan egy local/sessionstorage + IE behavior megoldás, amivel így mindenhol működni fog, kivéve az opera minit.

Milyen adatokat tárolnál ilyen módon a kliensen?
6

Keretrendszer?

inf · 2014. Feb. 21. (P), 13.17
Keretrendszer? Minek?


Keretrendszer azért, mert nem akarok alacsony szintű dolgokkal foglalkozni, és azt szeretném, hogy ie6+ működjön a dolog, ie, chrome, ff, safari, opera, stb...-ben.

Milyen adatokat tárolnál ilyen módon a kliensen?

Ez nyilván projekt függő. Lehet alap beállításokat menteni, pl hány sor legyen egy oldalon, milyen színvilágú skin-t szeret az illető, mi volt legutóbb a kosarában, milyen cikket kezdett el írni, stb...
10

Az én megvalósításom 50 soros

Hidvégi Gábor · 2014. Feb. 21. (P), 14.43
Az én megvalósításom 50 soros (és ebből lehetne faragni), működik minden alatt (kivéve opera mini), az általad linkelt jStorage meg egy csomó mindentől függ.

Nekem eszembe nem jutna bármi érdemlegeset a kliensen tárolni, hisz nem megbízható, amiket írsz, inkább a szerverre tenném külön bejegyzésbe, a kliensre jellemző dolgok (pl. felbontás) kulcsa pedig a felhasználó user agentje lenne. Így megmaradna minden kliensben, hogy mit szeret (például a lila hátteret), de az is, hogy mobilon három sort szeret egy képernyőn látni, PC-n meg tízet.

Kliensen én max. olyan adatot tárolok, amiért nem kár, ha elveszik, például a vágólap tartalma, de ilyen típusú adatból meg elég kevés van.

Arról nem is beszélve, hogy a localStorage-et a Mozilláék nem ajánlják komolyabb használatra, mert minden oldalbetöltődéskor plusz lemezhozzáférést igényel. Érdemes arra rákeresni, hogy "localstorage performance".
11

Minél több munkamenethez

inf · 2014. Feb. 21. (P), 15.22
Minél több munkamenethez tartozó adatot tárolsz a szerveren, annál kevésbé lesz skálázható a webalkalmazásod.

Arról nem is beszélve, hogy a localStorage-et a Mozilláék nem ajánlják komolyabb használatra, mert minden oldalbetöltődéskor plusz lemezhozzáférést igényel. Érdemes arra rákeresni, hogy "localstorage performance".


Meg lehetett volna úgy is csinálni, hogy ne igényeljen, szóval ez egy szimpla bug. Én személy szerint nem izgatom magam miatta...
12

Minél több munkamenethez

Hidvégi Gábor · 2014. Feb. 21. (P), 16.06
Minél több munkamenethez tartozó adatot tárolsz a szerveren, annál kevésbé lesz skálázható a webalkalmazásod.
Miért? Meg aztán minek optimalizáljak előre?
13

Miért?Mert minden egyes

inf · 2014. Feb. 21. (P), 16.42
Miért?


Mert minden egyes oldal lekérés érinteni fogja a szervert munkamenet írás vagy olvasás formájában.

Meg aztán minek optimalizáljak előre?


Ez gondolom költői kérdés volt. Elég sokszor esel ebbe a hibába. De nyugi, nem vagy egyedül, String-nek pl minden második mondata ilyen, amikor vitatkozik...
14

Mert minden egyes oldal

Hidvégi Gábor · 2014. Feb. 21. (P), 17.23
Mert minden egyes oldal lekérés érinteni fogja a szervert munkamenet írás vagy olvasás formájában.
És akkor mi van? A legtöbb oldal használ munkamenetet, és nincsenek sebességgondjai.

Ez gondolom költői kérdés volt.
Nem költői kérdés volt. Érzésem szerint a weblabor olvasói között elenyésző számban vannak olyanok, akiknek a skálázódás problámájával kell küzdeniük, mert olyan népszerű szolgáltatáson dolgoznak. A legtöbbünk átlagos produktumot készít, ahol egy EXPLAIN-nel csodákat lehet művelni, de erre is ritkán van szükség.

Innentől kezdve a kliensre kihelyezni adatokat pont az előreoptimalizálás kategóriája. Vagy tedd hozzá, hogy valamilyen REST-szerű szolgáltatáson dolgozol mostanában, (félig) vastag klienssel, és akkor megértem, miért gondolkozol így.

Az, hogy akár száz változót szerveroldali munkamenetben tárolunk, nem csökkenti a szerver teljesítményét észrevehető mértékben, de ha kliensoldalon, akkor meg azt kockáztatjuk, hogy adatokat vesztünk. Tehát akkor miért is jó ez utóbbi megoldás?
15

Én annyit mondtam/írtam, hogy

inf · 2014. Feb. 21. (P), 18.07
Én annyit mondtam/írtam, hogy a kliens oldalon tárolt munkamenet jobban skálázható szerver oldali kódot eredményez, ami általánosan igaz is.
17

egyáltalán nem mindegy milyen

blacksonic · 2014. Feb. 22. (Szo), 20.34
egyáltalán nem mindegy milyen mennyiségű adatot tárolsz a munkamenetben, erre teljesen valid dolog kliensen tárolni nem érzékeny adatokat
16

Az én megvalósításom 50 soros

blacksonic · 2014. Feb. 22. (Szo), 20.32
Az én megvalósításom 50 soros (és ebből lehetne faragni), működik minden alatt (kivéve opera mini), az általad linkelt jStorage meg egy csomó mindentől függ.


Akkor ez remek alkalom arra hogy open sourceold és felrakd Githubra, és mindenki örülni fog hogy milyen kis mérettel meg lehet ezt oldani

Arról nem is beszélve, hogy a localStorage-et a Mozilláék nem ajánlják komolyabb használatra, mert minden oldalbetöltődéskor plusz lemezhozzáférést igényel. Érdemes arra rákeresni, hogy "localstorage performance".


Ettől még kis mennyiségű adatot ha nem sokszor olvassuk írjuk simán lehet használni például hogy ne vesszen el az eddigi szerkesztés egy oldalon
7

jstorage ilyen, userdata-t és

inf · 2014. Feb. 21. (P), 13.37
jstorage ilyen, userdata-t és localstorage-et használ, key-value elven ment...
18

keretrenszerek arra

blacksonic · 2014. Feb. 22. (Szo), 20.36
keretrenszerek arra tökéletesen hogy ne találd fel mindig újra a kereket...mert ha mégis, akkor
este a Google szerverek összegyűlnek és rajtad nevetnek
19

Az nevet, aki a végén nevet

Hidvégi Gábor · 2014. Feb. 22. (Szo), 21.52
Nos, az szerintem nyilvánvaló, hogy máshogy gondolkodunk. Én helyből úgy kezdtem, hogy megnéztem a caniuse-t, a localstorage mennyire használt, egy perc alatt kiderült, hogy IE8-tól fölfelé szinte minden böngészőben ott van. Ez után passzióból megírtam a régi IE-kre a dolgot, összesen fél óra alatt megvolt az ötven sornyi program.

Természetesen lehet mindenre ilyen-olyan keretrendszereket használni, de nézzük a hátrányaikat:
- általában jóval nagyobbak és többet tudnak, mint amire az embernek szüksége van
- soknak függőségei vannak
- ha valami nem úgy működik, ahogy szeretnéd, elsőre nem feltétlenül fogod átlátni
- a kód átnézése nélkül nem fogod tudni, hogyan oldották meg a problémát, azaz enélkül nem tanulhatsz belőle
- ha mindenre keretrendszert használsz, a kontroll csak részben lesz a te kezedben, ráadásul nagy valószínűséggel el fog szállni a processzor- és a memóriahasználat
4

Lista

Poetro · 2014. Feb. 21. (P), 11.15
Ezeket nézted?
5

Persze, de általában csak 1-1

inf · 2014. Feb. 21. (P), 13.08
Persze, de általában csak 1-1 rendszert támogatnak, nem pedig facade-elnek sok fölé.

Eleve úgy vettem észre, hogy nem túl nepszerű opensource js projekteknél a laza csatolás, úgyhogy még arra sem igazán jók, hogy kiindulási alapként használjam őket.

Van több probléma, amit meg kell oldani az ilyen jellegű keretrendszerrel. Nem mélyedtem túlságosan bele, de az egyik biztosan a véges tárhely lesz. Eltérő mennyiségű adatot lehet tárolni pl cookie-ban és localStorage-ben. Lehet, hogy ezzel kapcsolatban kellhet tömörítés, adat feldarabolása több cookie-ra, stb... A másik az aszinkron működés lesz, amit interval-al szoktak megoldani cookie-nál. A harmadik az intertab communication lesz (pl: localstorage-nál). Esetleg még kellhet valamilyen szintű titkosítás is stb, stb... A negyedik, hogy közös nevezőre kell hozni az sql-t, és a key-value storage-t. Erre mindre már nem egyszerű átfogó megoldást írni...

Keresgéltem js local orm témakörökben, de eddig semmi.
8

Közben találtam

inf · 2014. Feb. 21. (P), 13.43
Közben találtam egyet:
yathit/ydn-db

Ez userdata, websql, localstorage, indexeddb, amiket használ. Cookie-t nem, de úgy néz ki az nem is szükséges széles körű böngésző támogatás kialakításához.


Van egy másik is, ami korábbi technológiákkal dolgozik, ebben van cookie fallback is.

jeremydurham/persist-js

Van még egy, ami szintén nem teljesen ugyanazokat a technológiákat használja.
amplifyjs.com/api/store/
9

Ha én csinálnám, akkor

inf · 2014. Feb. 21. (P), 13.59
Ha én csinálnám, akkor localstorage interface-t kapna, és polyfill lenne. Úgy lehetne használni intercom.js-el.


Itt van rá cookie-s megoldás:
developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage
20

Egységesség

complex857 · 2014. Már. 2. (V), 02.09
Amíg a böngészők nem követnek közös szabványt szinte semmiben, addig egyszerűen muszáj. A képet még a visszafele kompatibilitás is bonyolítja, pl ie 6-7-8-9-10-11 mind eltérően viselkednek bizonyos helyzetekben...

Nos úgy tűnik a jQuery csapata is ezen az állásponton van. Bár 2.x szériában már nincs ie6-9 support, cserébe van régi webkit (mint android 2.3.x ami sokszor szintén nem egy leányálom).
21

Az ie9-et támogatja a jquery

inf · 2014. Már. 2. (V), 04.36
Az ie9-et támogatja a jquery 2.x. http://jquery.com/browser-support/

Tök érdekes, hogy a böngésző statisztikák teljesen ellentmondóak:

http://www.w3schools.com/browsers/browsers_explorer.asp
http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

Nagyon nem reprezentatív, hogy egy-egy oldalt milyen böngészővel néznek gyakran... Átlag azért az ie8- sajnos még mindig 5% körül mozog...

Sok a tanulatlan látogató...
22

Sizzle

Poetro · 2014. Már. 2. (V), 10.00
Csak azt nem tudom, hogy a Sizzle-ben (a jQuery kiválasztó motorjában) miért hagyták meg az IE 6-7-8 támogatást, illetve miért nem csináltak belôle egy modernebb változatot. Akkor a jQuery ténylek korszerû lenne.