HTML5 local storage

Programozás

Bár a HTML5 “szabvány” 2011 májusa óta él és a böngészők egészen elfogadhatóan implementálták is, sok vetületét és újdonságát még csak most kezdik felfedezni, kihasználni. A “local storage” is ilyen feature, még csak nagyobb siteokon láttam használat közben, pedig nagyon hasznos jószág, sok mindent le tud egyszerűsíteni amit korábban cookie-k használatával oldottunk meg. Nézzük hát mi az a html5 local storage, hogyan használjuk és mire lehet jó.

A cikk folytatása

( locsemege v | 2012. 03. 12., h – 11:58 )

Ha jól értem ennek a szerepét, erre használtam adatutaztatós formában valami ilyesmit:

foreach ($_POST as $name => $value) {
        echo ("<input type=\"hidden\" name=\"{$name}\" value=\"{$value}\" />\n");
}

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én különösebb webfejlesztő múlt nélkül egy localhost-on futó picike webes alkalmazáshoz találtam ki azt, amit írtam. A cikket elolvasva szembeötlő volt a stateless kifejezés, s ébredtem rá, erre szükségem lett volna, s így csináltam. Összetett adatsruktúrát serialize() függvénnyel alakítottam át, majd base64-be enkódoltam, ezzel letudva például az idézőjelekből, speciális karakterekből fakadó problémát.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Aadaam v | 2012. 03. 12., h – 12:16 )

Ovatosan localStorage-dzsel, lasd Andrea cikket: http://webreflection.blogspot.com/2012/03/whats-localstorage-about.html

Roviden: szinkron az elerese, ergo amig olvassa az adatot, megfagy a bongeszo.

Nyilvan lehet ertelmes dolgokra is hasznalni (en az aktualis dokumentumot oda mentem es a szerverrel max verziot syncelek), de vigyazz.

Amire pl. jo lenne: HUP-on gyakran van olyan, hogy iPaden vagy OS X safarin egyik tabon irom a hozzaszolast, masik tabon megnezek vmi referenciat, emiatt az oldal ujratolt, es a felkesz hozzaszolas elveszik. ERRE jo a localStorage, van is erre jQuery plugin.

Félig off, de:

"HUP-on gyakran van olyan, hogy iPaden vagy OS X safarin egyik tabon irom a hozzaszolast, masik tabon megnezek vmi referenciat, emiatt az oldal ujratolt, es a felkesz hozzaszolas elveszik."

Most vagy valamit félreértek, vagy ha nem, akkor ott valami nagyon el van szúrva...

Firefoxon még ha a tab-ot bezárom hozzászólásírás közben, akkor sem veszik el a félig megírt komment. History -> Recently Closed Tabs -> tab és ott van a féig megírt komment. De ha kilépek a böngészőből, majd vissza, akkor is megmarad a kommentem. Reload-nál szintén nem veszik el semmi.

--
trey @ gépház

Probald iPhone-on, ott is megmarad?

Kezdj el irni egy kommentet majd nyomj egy refresh-t, vagy nyiss meg egy tab-ot es lookupolj valami heavy site-ot (pl. ha eloadast linkelek az illetonek, hogy nezzen bele, ott a megoldas, az ugye html5 video, kb. minden background tabot ol), es valts vissza.

Sajna a desktop safari ugyanezt csinalja es ott olyan is lehet hogy valaki chatben irt valamit, rakattintottam, az OS meg ugy gondolja, tul sok tabom van... :S

Igen, a szinkron tárolás a dolog hátránya, bár ez implementációfüggő és biztos vagyok benne hogy javulni fog idővel. Mindenesetre 1-1 kulcs elérése nem tragikus, lásd: http://jsperf.com/localstorage-vs-objects/19. Érdekes hogy pont IE8+ alatt aszinkron a kezelés :)

Egyébként a szinkron-aszinkron kérdéskör könnyen megkerülhető ha queue-t építünk eköré és azon keresztül írunk pl. web workerek segítségével: http://www.sitepoint.com/javascript-threading-html5-web-workers/

Magyaran megint az van, mint az egesz szajbaturt webbel: sok kidolgozatlan felmegoldas szarul implementalva, ahelyett, hogy megterveztek volna rendesen.

Ezer eve ismert problemak ezek az adatbaziskezelok koreben. Ha tenyleg ez a modszer, amit itt leir... Hat nonszensz, megis minek bezarni a fajlt pl. a konzisztencia garantalasahoz?

http://www.nczonline.net/blog/2012/03/07/in-defense-of-localstorage/

Masik: web workerrel tutira nem fogja ugyanugy blokkolni az UI-t?

----------------
Lvl86 Troll

+1
Ez már csak ilyen és ilyen is marad szerintem, de legalább van munkánk :)
Web workerrel csak egy single instance-es queue-t gondoltam implementálni, amiben aztán lehet akár "sleepelni" ha muszáj. De nem, nem csináltam ilyet és nem benchmarkoltam még.
Viszont a web workers jópofa, már látom előre az DoS lehetőséget benne :) Szépen fogják a processzormagokat, ahogy kell: http://pmav.eu/stuff/javascript-webworkers/

Nem a tervezés és fejlesztés részével van bajom, hanem a hasonló gány és workaround hegyekkel. Akármi komolyabbat akar az ember, gyakorlatilag nem tudja megoldani trükközések nélkül.

Pl. egy .NET desktop appnál azért nem dirty hackokra van alapozva az egész fejlesztés, szemben a webbel, igaz, ott egész más jellegű kihívásokkal tud találkozni az ember. (Próbált már valaki jól többszálasítani úgy, hogy azért UX szempontjából maradjon valamennyire szinkron jellege a dolognak?*). Vagy akár egy Delphi VCL.

De ezt szerintem a Java-sok is ugyanúgy alá tudják támasztani. (Java + GUI-val eddig nem volt dolgom, hacsak a Minecraft klienst nem számítjuk annak. De az inkább NC. kategória, szóval ne számítsuk)

* Már látom előre, hogy rajzani fognak az Erlang fanok.

----------------
Lvl86 Troll

- HTTP, mint stateless, kliens-szerver protocol megerőszakolása kétirányú adatkommunikációra
- AJAX, mint olyan egy trükkből indult
- HTML, CSS, mint [web]alkalmazás-GUI-hoz leírónyelv
- webes dokumentumok alkalmazásként való használata
- JS evolúció minden szegmense és API különbségek.
- stb.

Egyiket sem erre tervezték, mindegyiket csak összefoltozták, hogy erre is alkalmas legyen, ami meg is látszik rajtuk.

----------------
Lvl86 Troll

- HTTP
Vannak websocketek, es a request-response protokollok hasznalata ketiranyu protokol wrappelesere hibaturo rendszerekben elegge elfogadott megoldas
(A HTTP pedig papiron nagyon stateless, a gyakorlatban nagyon nem - en is olvastam Fielding PhD-jat, ez a resze baromsag)
- AJAX
A modern (IE3.0+) bongeszok ketszalu bongeszok: van egy adatszal, es egy GUI-szal. A GUI-szal az 'esemeny-esemenykezelo-domparsolas-ujrarajzolas' negyszogben csinal egy vegtelen ciklust, regi bongeszo-forraskodokat ha nezel, akkor szo szerint is akar. Elotte egy kep letoltese szoszerint megfagyasztotta a bongeszot, helyette kitalaltak, hogy a kepet toltsuk le egy adatszalon, majd generaljunk egy esemenyt, ami miatt reflow + repaint lefut.
Az AJAX nem mas mint az adatthread (ill. nyilvan: adat threadek)-hez valo programmatikus hozzaferes (milyen szep szo, ugye? User Space API, nah)
- HTML, CSS as GUI
A CSS onmagaban szar. Amugy van GUI leironyelv is, XUL-nak hivjak, meg van a XAML, hat en neha inkabb HTML-ezek. Nem tokeletes, teny; nem a toltozgatas-foltozgatas miatt, hanem mert a CSS egy hibas alapfeltevesbol indul ki
- webes dokumentumok alkalmazaskent valo hasznalata
Van egy auto-deployos VM-ed, megjelenitovel. Megis mit kene vele csinalni? Mi annal az egyszerubb, minthogy beirsz egy URL-t, es elindul egy (tudom hogy lyukasan, de) sandboxolt alkalmazas? Plane ha minden gepen van ilyen VM?
- JS evolucio minden szegmense
A JS evolucio ES5 resze speciel hibakat javit foleg, meg egysegesse teszi a nyelvet (pl. hozza lehet ferni user space-bol olyanhoz amihez eddig csak modulokbol [setter, getter]). A HTML5 egy elfajzott borzalom, ebben egyetertunk, nade az nem JS evolucio.

Jaj, hagyjuk már, bullshit az egész. Websockets, SOAP* és mindenféle egyéb utólag beletoldozott hulladék miatt egy ordas nagy hakk az egész. Pont erre kívántam rávilágítani.

@AJAX: nem az volt a kérdés, hogy mi az AJAX, hanem, hogy egy ronda hack, amely nem más, mint az IE5.5 egyik featurejának általánosított megerőszakolása.

@XUL: Ja, meg a XAML, Delphi Forms (ok, nem egy kategória ma már), stb. De biztos 10 sornyi HTML körítést írni, hogy egy szépen formázott legördülő menüt csinálj ikonnal és mindenféle egyébbel, mint annyit, hogy &ltListBox /> és templateken keresztül vezérelni az egészet.

@auto-deployos VM: hagyjuk már.

* Hja, tegye fel a kezét, aki szerint nem ostobaság XML-t használni _hálózatra_ adatcseréhez, szoftverek között. Senki nem akar SOAP XML-eket írni, ne jöjjön senki az olvashatósággal, implementálni meg egyszer kell.

Az egész erőforrás-igényét meg szintén ne firtassuk.

----------------
Lvl86 Troll

Koránt sem vagyok expert, sőt, de én az XML-t a támogatottsága miatt szeretem. Parseolhatom JavaScipttel, ActionScripttel, Java, C#, stb. Elég jó a lib ellátottság mindenhez, nem mellesleg szabványos, így talán a legegyszerűbb megjeleníteni/feldolgozni.

Annak örülnék a legjobban, ha a HTML-t kiszorítaná az XHTML (sajnos nem erre halad a világ). Nem egyszer fordult már elő, hogy adatot kellett bányásznom HTML-ből. Szenvedhettem regexp-pel, meg manuális toldozgatással-fordozgatással ahelyett, hogy egyszerűen azt mondhattam volna, hogy ennek a node-nak az ilyen nodejának a childNodejainak az ilyen nevű attribútuma érdekel.

Ja igen, a legjobbat el is felejtettem: a mostani atomliberalizált "minden kókányt engedek" protokolok és leírónyelvek helyett írtó gyorsan át kellene állni valami "csináld helyesen, vagy dögölj meg" hozzáállásra. Megszűrné a hulladéktól és a full amatőröktől a netet, jól. (És sajnos tudom, hogy pont emiatt nem fog sose bekövetkezni.)

----------------
Lvl86 Troll

Szép álom, de sajnos csak álom.
Elmondom mi következne, ha XY cég / OS társulat kijönne az új ValidBrower nevű böngészővel ami egy nagy lóf.szt rajzolna ki a képernyőre az oldal renderelése helyett, ha lezáratlan/ismeretelen/rövidre zárt taget talál: pár nagyon geeken kívül senki sem használná. Az a pár geek is használna mellette hagyományos böngészőt hogy pl. facebookozni, gmailezni, stb. tudjon. A meglévő, elterjedt szolgáltatások nagy urak. Nekik pedig nem áll érdekükben soksok emberórát rászánni a refactoringra. Miért is tennék? Senki és semmi nem követeli meg tőlük.

Bocsáss meg, de én még emléxem, hogy ez az "atomliberalizált" és "minden kókányt engedek" elv tette az internetet azzá ami. Ezért vannak az rfck stb.
Amiről _te_ beszélsz az az, hogy pontosan van néhány _nagyobb_ cég aki jól felfogott üzleti érdekből, vagy csak simán időhiányból tökéletesen máshogy valósítja meg a protokoll-t.
Na ezzel van a baj. (azt gondolom ugyanarról beszélünk, de más kiindulásból)

Igazából a sok *ML-es technikával nekem az a kedvenc részem, mikor hirtelen jön egy olyan igény, hogy fel kellene dolgozni egy kisebb - alapvetően táblázat jellegű - adatmennyiséget, mondjuk 150+ megányi XML-t és akkor még nem mondtam sokat. Már azzal sokkal-sokkal-sokkal előrébb lennénk, ha CSV/TSV-ben lennének az adatok (mondjuk 150+ mega helyett 10-). De nem, most az XML/JSON & tsi a tuti.

----------------
Lvl86 Troll

Mondjuk mert a JSON vagy akár az XML jóval többet tud mint a *SV. Nyilván lehet azt is, ha egyszerű az adat, de az általános megoldásokhoz kellenek általánosan jól működő protokolok. a CSV nem ilyen. Persze nem fáj CSV-t parseolni javascripttel, de ha komplexebb adatszerkezetet kell feldolgozni, pont a CSV lenne a hack.

Szerintem rosszul állsz hozzá (és ugyanez a bajom a text-vs-binary vitában): végén mindig oda jutunk, hogy az "univerzális" eszközök addig jók, ameddig a feladat is "univerzális". És most adott volt a feladat: nagy mennyiségű táblázatos adatok továbbítása. (És akkor most tekintsünk el attól, hogy Gb-os mennyiségű szánadatok továbbítása hatékonyan, ahol a text based toolok szeretnek csődöt mondani, ha sebesség is kell). Ez egy nagyon általános feladat, mégis mindenki a rugalmas struktúrájú, alapvetően dokumentum-leíró nyelvekben keresi a Szent Grált. Minek?

Szvsz. elég rossz érv az, hogy "nincs hozzá tool alapból", az ilyenek miatt lesz bedrótozva egy-egy rossz eszköz egy olyan feladatra, amire lehetne egyszerűen, szebb, jobb eszközt készíeni.

----------------
Lvl86 Troll

Nem erre a konkrét példára értve, de:
érdemes mérlegelni hogy megér-e 10 millisecet vagy pár KByte-ot +N munkaórányi egyedi programozás. Néha igen, néha nem.
Pl. baromira örülnék ha a mobilról nézegetett webes api-k alkotói a Te hozzáállásodat követnék és nem játszanának a mobilos adatforgalommal :)

Beszelgess Andrea Giammarchival, meg Thomas Fischerrel.

Szerintem meg mindig szeretne nehany ember, hogy elveszunk toluk minden szuros eszkozt, mert kulonben kart tennenek egymasban, kapnak ket gepet amivel nem tudnak verekedni, es bezarjuk oket egy szobaba, addig ki nem jonnek, amig nem lesz meg a webkompatibilis mobilprotokol.

Andrea nagy JS-es, es mobil HTML5 orult (mobiloptimalizalas agyba-fobe, a kodja olyan mintha mar atment volna egy compileren), Thomas meg a TLV mogotti egyik agytroszt, aki akkor hasznal JSON-t ha fegyvert fognak ra.

Arra mar pl. rajottunk, hogy bzipelni nem szabad a JSON-t, mert hamar merul tole az akksi.

De egyelore az van, hogy nagyjabol jol elvannak a termekek, aztan majd meglatjuk. Majd a google :) (Nem veletlenul csereltek le az XMPP-t a sajat kis binaris jatekukra...)

"Arra mar pl. rajottunk, hogy bzipelni nem szabad a JSON-t, mert hamar merul tole az akksi."

Attól nem merül, hogy stringeket kell ide-oda konvertálni? (int/float-string?)

"(Nem veletlenul csereltek le az XMPP-t a sajat kis binaris jatekukra...)"

;) Végül mindig oda jutunk, hogy a gépek csak-csak bitekkel működnek.

----------------
Lvl86 Troll

Udvozol 2012, ahol a hasznalt mobilok 100%-a C-ben intezi el egy memoriateruleten ezt a konverziot, relativ kib. gyorsan (nem csodalkoznek, ha lenne ra dedikalt CPU utasitas akar), es nem javascriptben ertelmezgetjuk a JSON stringet, csak elkerjuk a C apitol a structot (es a mai modern bongeszokben nem hash-t fog visszaadni, hanem tenyleg structot).

Masszivan attolom PNG-ben ha olyan kedvem van (hint: a PNG vesztesegmentesen tomorit, RGBA=> 4 byte = double)

De nyilvan ez a g.ci modszer, a JSON arra is van azert, hogy utana ne ulj orakig felette ha elveszik a doksi, hogy ez vajon most mi lehet, nem ugy mint amikor a nokia mondjuk TLV-ben ad neked oda adatot, ( http://en.wikipedia.org/wiki/Type-length-value ) amit, ha nincs neked ott a doksi, hat kriptografus se bogoz ki hogy mit akar (kezdve azzal, hogy nem hasznal byte-hatart...)

Viszont libbel teli van az internet, sot, versenyt tudnek kodolni, ki tud tetszoleges nyelven gyorsabban valid json-parsert irni...

Te még mindig nem látod a fától az erdőt: egyáltalán nem akarok én webböngészőkkel szívni, ha korlátozás nélkül megírhatom desktop appként is.

Néha nem ártana picit beülni a felhasználó helyére és végiggondolni, hogy ők azt a rendszert napi szinten használni fogják. És igen, zavarni fogja őket az a 0.5-2 sec várakozás is, ameddig mondjuk egy listában keresnek vagy nem reagál a cucc vagy akármi. Évek óta megoldott probléma desktopon egy 10k elemű lista kezelése. Weben vagy trükközöl, vagy belefulladsz a -betöltődéskori- folyamatos reflowtól. Az, hogy aszinkron módon hack nélkül nem lehet tölteni a listát (=> megint csak trükközöl) az további szépségeket okoz. És az ilyenek miatt jön elő újra és újra az a kérdés, hogy "de ezt nem lehet kiexportálni Excelbe, hogy kényelmesebben tudjam kezelni?". Csak néhány példa.

Tudod, a mostani felhősített világon kívül vannak még helyek, ahol dolgozni is szeretnének egy programmal, és a felhasználók/megrendelőket nem érdekelnek ilyenek, mint "nem kell telepíteni" - hisz kell a szerverre, "URL-lel megnyitható" - hisz ott az ikon az asztalon és más, hasonló "technoblablák" (számukra).

Érdemes picit kibújni a 100% sw fejlesztő légkörből és elmenni egy olyan helyre szoftvert fejleszteni, ahol használják is azt és a szoftverfejlesztés nem a fő profil, hanem mint egy másodlagos valami. Ahol látni lehet, hogy anyáznak, hogy miért kell várni, míg feltölti a képet, miért lassú a szerver, miért nem lehet egyszerűen keresni, miért cachelte már megint be...., miért nem látom az újítást..., miért..., miért..., miért...?

Egyébként, ha már böngészőknél tartunk, mi akadályoz meg abban, hogy lekérdezz egy - jelen esetben - n*m*4 byte hosszú bytekupacot? Hisz a HTTP alapvetően ilyeneket továbbít, nem? ;)

Ui.: a példák a való életből valók.

----------------
Lvl86 Troll

Olyan helyen dolgozom epp, ahol a szoftverfejlesztes masodlagos tevekenyseg, a fo tevekenysegkent telefonos kiscsajok piszkalgatnak egy adatbazist es hivogatnak fut-fat.

A 0.5 sec nem fog senkit zavarni (attol fugg, mi a muvelet), alapvetoen 3 muveleti kategoriat kulonboztetunk meg:
- 0.2 sec: megnyomtam egy gombot,es nem gondolom azt hogy a szoftvernek gondolkoznia kell, auto kiegeszites, menu megjelenes
- 1 sec: keresesi talalatok megjelenitese, egy e-mail kikuldese
- 30 sec: barmi amin emberileg gondolkozni kene (pl. fajlfeltoltes, az osszes havi szamla nyomtatasra elokeszitese)

Itt is erdekli oket hogy nem kell telepiteni, mert ha tonkrevagnak egy gepet (leontik kakaoval, tudomisen), akkor 10 percen belul ott folytatjak ahol abbahagytak (igaz, roaming profiljuk is van), meg otthonrol is tudnak dolgozni (mondjuk ezeket a szamokat belso halon garantaljuk, a 3g modemre nem lehetek tekintettel)

Ahhoz, hogy ez menjen, olyan szinten kell erteni a HTTP-t meg a javascriptet, hogy mar nem igazan panaszkodsz, csak megcsinalod.

10k elemu listat ne jelenits meg, merthogy ember nincs aki atlassa, es akkor rogton megszunnek a reflow problemaid is.

Nekem alapvetően nincs bajom a webes programokkal ha jól meg vannak írva. Én viszont bonyolultabb cucc megírását gyakorlatilag semmi pénzért nem vállalnám. (értsd: úgysem ajánlana senki annyit amennyiért ilyet kezdenék el gányolni)
Nem azzal van a baj, hogy szakértelem kell hozzá, hanem hogy szakértelem nélkül is lehet működő, de szar dolgot gányolni benne. Igen, ez más nyelvekre is igaz, de a webes technológiák összetettsége sokkal nagyobb hibalehetőséget hagy.

Az pl. tök jó, ha ti így figyeltek a fejlesztett eszköz használhatósára. Azonban rengeteg helyen nem törődnek vele és csupán azért használnak webes cuccokat, mert éppen az a menő, ráadásul abból is azonnal a legcsicsásabbat. Példa: taninform. A tanárok utálják, mert kényelmetlen és tulajdonképpen még mindig papíron kell vezetniük a jegyeket, mert arra alkalmatlan, hogy közvetlenül oda jegyezzenek fel mindent. (A diákok gyakran a létezését is utálják, mert a szülők is hozzáférnek, de ez más kérdés.) Viszont nagyon szép csicsás web2-es, Google Web Toolkit-es felülete van...
...aminek indokolatlanul hatalmas sávszélesség igénye van. 2G-s mobilhálózatról el lehet felejteni. Jah igen, mobilról is el lehet felejteni...
A lényeg: alapvetően az ilyen programokkal és azok fejlesztőivel van a gond.

"10k elemu listat ne jelenits meg, merthogy ember nincs aki atlassa, es akkor rogton megszunnek a reflow problemaid is."

Legyszi szolj a saleseknek, hogy ne akarjak a 13000 cikket arazni, beszerzest csinalni, fogyasokat figyelni, szurni, keresni kozottuk, stb, mert nem lehet atlatni!!! (Kar, hogy Excelben ezt meg tudjak tenni jelenleg gyorsan, weben meg nem.)

"Itt is erdekli oket hogy nem kell telepiteni,"

Es minden mast a gepen ok telepitettek a webes bizgentyudon kivul? Na ugye, hogy nem. Ha meg romaing profil van, AD is van, ott meg megoldod a kozponti telepitest. Linuxon csomagkezelest.

" akkor 10 percen belul ott folytatjak ahol abbahagytak (igaz, roaming profiljuk is van), "

Nem ertem, a Microsoft meg tudta oldani, hogy ha atulok egy masik gephez, ott van az osszes levelem Outlookban. BLACKMAGIC!

----------------
Lvl86 Troll

Nem azt mondtam, ne kezelj, azt mondtam, ne jelenits meg!

Attol meg, hogy paging, vagy rejtett paging (http://ui-patterns.com/patterns/ContinuousScrolling) van, attol te meg nyugodtan nyomhatsz select all, meg filter search meg egyeb dolgokat, ez nem kell hogy megakadalyozzon. A proxy pattern a baratod, a bongeszok a kepekre kezelik, tablazatokra sajnos nem, mig az excel igen, ez van.

Amugy ha nagyon nagy bajod van, atvaltasz webgl modba, meg elkezdesz int32 tomboket hasznalni, es rogton pixeleket tologathatsz, mint az excel alatt fekvo WinAPI, nem kotelezo HTML-t hasznalni mar a weben se :P

Felhivnam a figyelmedet az "otthonrol is hasznaljak neha" kifejezesre, es itt bukik az ervelesed tobbi resze azzal kapcsolatban, miert webes. Eloszor volt az otthonrol hasznalat 10 embernek, es utana letesult csak iroda, ahova bejohetnek, miutan ebbol volt mar eleg penz. Ma mar sokkal tobben vannak.

Az outlook pedig egy talan meg a HTTP-nel is primitivebb kliens-szerver protokollon kommunikal a kiszolgaloval, ha valasztani lehet az exchange MAPI (volt hozza is szerencsem), es a JSON kozt, hat nem sokat gondolkoznek.

"tablazatokra sajnos nem, mig az excel igen, ez van."

"atvaltasz webgl modba",

Köszi, nagyon jól leírtad, miért rühellem az egész webes "taknyoljuk meg, erőszakoljuk bele, trükközzünk, jaou lesz ez valahogy" mentalitásával, ahelyett, hogy terveznének egy rendes eszközt. ;)

"Felhivnam a figyelmedet az "otthonrol is hasznaljak neha" kifejezesre, es itt bukik az ervelesed tobbi resze azzal kapcsolatban, miert webes."

1 előny a sok hátrány mellett, amiben valóban jobb a web. (Bár éppenséggel ezt is meg lehet oldani, de mindegy.)

----------------
Lvl86 Troll

En se ertem, miert kell beletaknyolni egy PC-be jatekokat. Mi a fenenek egy jatekgepre billentyuzet (aka. Amiga 500)? Miert nem jatszik mindenki dedikalt gepen?

Sot, miert kezdunk el kaland-jatek-kockazatot nyomni szamitogepen (pl. infocom)? Nem jo erre a papirkonyv?

Mi a fenenek kell minden tranzisztort sziliciumbol gyartani, amikor a germanium sokkal jobb ra? Ellenallasra is van sokkal jobb anyag.

A HUP-nak miert nincs egy kulon desktop appja, HUP(T)roller neven, amiben kommentezunk, mi a fenenek kell itt mindenfele textboxokba irogatni? Egyaltalan, a HUP-ot miert nem valami rendes Desktop appban szerkesztunk, tudod mekkora hekk egy atlagos CMS, plane a Drupal? HTML-t allit elo szerveroldalon, aztan ugy tesz mintha az egy fajl lenne ami mindig olyan volt, pedig dehogy, kozbe beletrollkodtak sokan!

Egysegesito platform, the web is the new PC.

Inkabb oruljunk annak, hogy
- ma mar nem kell 1-pixeles tablazatokkal varialni, ha rajzolni akarsz, hanem van rendes rajzeszkoztar;
- nem interpreterben fut a user space kod, hanem rendesen leforditja, sot, kioptimalizalja.
- hozza lehet ferni az adatszalhoz rendesen (az AJAX nem hekk, akkor se ha a ket bongeszo mashogy hivta, emiatt JJG irt egy wrappert), nem kell iframe-eket nyitogatni
- tudom azt mondani, hogy @font-face url('valami.ttf'), nem kell egyesevel kepekre cserelni oket.

Meg lehet ezt ugy is elni, persze, hogy egy dedikalt tablazatkezeloben C-ben szepen megirtak a tablazatkezelo rutint amiben van proxy,mig ami a WinAPI-val jon gridwidgetkent (nem tudom, jon-e benne gridwidget de asszem igen), az brute force megjelenit mindent, es a HTML beepitett is igy tesz, igy kenytelen vagy megerteni a Viewport fogalmat es megirni.

Nyilvan fel lehet telepiteni user gepere C/C++-t, inkabb mint Java-t, de ott meg lehet azon sirni, hogy a Qt nem olyan mint a WinAPI, pedig a klienseink 99%-a windowsos, meg tudomisen.

Mindegy, egysegesito platform, jelen pillanatban ez a szolgaltatas, hogy el tudom kuldeni havernak linkben a komplett programot, amit azonnal tud hasznalni, ez ficsor, akkora, hogy nem szamit, mire lett eredetileg kitalalva, ez van, sajnalom.

Ezek mind rendben lennének, csak azabaaaaj h sok gyártó sokféleképpen implementálta a dolgokat, amik aztán el is terjedtek sajnos. Ha egy .net-es, javas, flex-es, bárakármilyenes kódot nézel ott azért nem lesz ilyen, mert a runtime egyetlen gyártó terméke.

Amúgy ez a "nem erre tervezték" elég sok esetben elmondható más dologra is, aztán mégis a gyakorlat alakítja a felhasználást, nem a szépen ívelő elméletek.

JVM-ből többféle is van, .NET-hez is ott van részlegesen a Mono, más kérdés, hogy az open source közösség nem fogadja el.

"Amúgy ez a "nem erre tervezték" elég sok esetben elmondható más dologra is, aztán mégis a gyakorlat alakítja a felhasználást, nem a szépen ívelő elméletek."

Aztán a gyakorlat keményen meg is bosszulja és - köszönhetően, hogy szépen bebetonozza mindenki - 10-20 évig fog szívni miatta az ipar. Pl. olyan telco-st nem láttam még, aki ne szidta volna végig a SIP-et egészen az IETF-ig.

----------------
Lvl86 Troll

Persze van többféle. Épp az egyik bubi fórumon szopik vele egy sereg önjelölt bróker, hogy az openjdk megdöglik ott, ahol a sun jdk megy. De ugyanez tarkában a monóval/silverlight-tal, bár én amondó vagyok, hogy itt jóval nagyobb a dominanciája a platformot meghatározó runtime-nak, mint a html/css/js esetében.

A gyakorlat meg olyan, hogy szívat, meg bosszul, de a végén mindig ott köt ki minden anyázó, hogy minden megy tovább az eredeti medrében. A dart egy próbálkozás ebből kitörni, de sokan joggal kételkednek a sikerében. Te meg, ha "finnyás" vagy :) akkor nagy eséllyel szintén szívni fogsz, mert ritkán adatik meg, hogy az ember sokat válogasson az eszközökben.

Annyit még hozzátennék, hogy egy jól karbantartott framework csodákra képes, pláne ha más tartja karban neked.

( asch v | 2012. 03. 13., k – 00:26 )

Csodálatos, hol tart a tudomány. Kulcs érték párokat lehet perzisztensen tárolni személyi számítógépeken? És akkor is ott marad az adat, ha kikapcsoljuk és bekapcsoljuk?

Engem már szédít ez a rengeteg újdonság, legjobb lesz, ha nyugdíjba megyek.