Enough with the JavaScript Already! with Nicholas Zakas
Arra kéne használni a JS-t, amire kitalálták
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
gerzson:
assert() - mesél a forráskód
Hodicska Gergely:
DAO - Adatbáziskezelés picit másképp
tiku I tikaszvince:
Hibanapló Zend Framework alkalmazásokhoz
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 25 | 26 | 27 | 28 | 29 | 30 | 1 |
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | 1 | 2 | 3 | 4 | 5 |
Ki: Most vettem csak észre,
Most vettem csak észre, hogy van ezeknek a beszélgetéseknek írt, pdf formátuma is, ami szerintem azért jóval használhatóbb, mert gyorsabban át lehet olvasni.
Be:
A JS túldimenzionáltsága egészen nyilvánvaló, nagyon jó, hogy egy ilyen híres ember is foglalkozik a témával, és felhívja erre a fejlesztők figyelmét.
Csak hogy más vélemény is
Senki nem mondta, hogy ne
PHP
Nicholas arra utal, hogy ha
Ne vedd zokon, de az
A probléma az, hogy mind a "hatékonyság", mind a "költség" egy nagyon relatív fogalom, főleg egy hálózati "alkalmazásnál". Nagyon sántít az az érv, hogy mert "drágább" ez meg az, mikor jelenleg egy okos telefonban is 4-8 magos CPU-k vannak, és az asztali gépek is lassan erőművek.. 5-10 évente ezek duplázódnak.
De ez csak az erőforrás rész.. ezenkívül tudnék párat mondani, ami legalább ilyen súlyú..
Megjegyzem, nem olvastam és hallgattam meg a cikket, mert már a cím is komolytalan..
Kérdések
In Smartphones and Tablets, Multicore is Not Necessarily the Way to Go
+10
Egyrészt vedd észre a
hogy a rendelkezésre álló erőforrások 2-5 évente duplázódnak,
nem kellene leragadnod a mobil/pc viszonylatban.
Másrészt a mai PC-k, már kellően erősek egy tipikus kliens oldali JS alkalmazáshoz.
De válaszolok..
1) egy tipikus alkalmazás 1 core-t használ, PC-n, ha tudsz jó kódot írni ez elég,
ha béna vagy 4 is kevés (lenne). Mobilon is elég, nem feltétlenül ez a szűk
keresztmetszet.
2,3,4)
Mobil.. nincs értelme belemenni, pláne ilyen mélységben.
Egy szóval sem állítottam, hogy mobilra jó a JS-el generált oldal..
sőt szerintem se.. majd úgy 5-8 év múlva. Viszont pár szempontból, az amit
állítottál, hogy jó kliens oldalon generálni, szintén vitatható itt is, hisz ha
csak strukturált adatok közlekednek, azt teljesen mindegy, hogy egy JS motor,
vagy egy mobil app dolgozza fel.
5) Igazad van a natív feldolgozás gyorsabb.. sajnálatos tény, hogy elfelejtettél
egy tucatnyi dolgot, ami árnyalja a képet és teszi nem egyértelművé az előnyt..
többek közt, de nem teljes igénnyel: hálózat és/vagy csomagok és/vagy méret,
szerver oldali erőforrások és/vagy tartalom előállításának ideje.
plusz
Ajjaj
Kell spórolni a szerverrel is, nem mondom, hogy nem, de korántsem úgy, hogy átterheled a kliensre a szerver dolgát.
Pedig ez jó indok lenne az
Összetettebb
Abból indulj ki, hogy
- a hálózati áram a legkörnyezetbarátabb;
- azért a 150 W-ért is kiszolgál pl. 100 db. 2 W-os klienst, akkor ki a jobb?
Vannak előnyei és hátrányai a
Ez rendben is van,
A kliensoldali renderelés épp azért lehet jó, mert akkor nem olyan nagy gond többféle mobilverziót csinálni, illetve másképp. Ott van helyben a kijelzőméret, orientáció, stb., ezért ez egy jó ötlet, viszont szerveroldali feladatot nagyon nem szabad kliensre terhelni, és ezt a kliensoldali renderelést is igen csínyán kell kezelni a kicsi teljesítmény miatt.
Monománia
- egy buta kliens (pl. általános kereső) számára HMLT-t küldünk
- egy félbuta kliensen (böngésző) megnézzük, hogy mire képes, és ennek megfelelően küldünk HTML-t, ha buta, egyébként pedig a strukturált adatokat, amit ő maga alakít át azzá, amit ért
- egy értelmes kliens, ami tudja, mit szeretne (például egy olyan kereső, amely meghatározott adatok után kutat (például ingatlanok, barkácseszközök, bármi), annak meg kiküldjük a nyers adatokat
Ha így szemléljük a dolgokat, az XML+XSLT párossal mind a háromfajta klienst ki tudjuk szolgálni (persze lehet akár JS-sel is, csak sokkal korlátozottabban).
Nagyjából
Már többször jeleztem, hogy van mikor látom értelmét az XSLT-nek, de a mai webappok korában az emberi látogatóknál szinte kötelező a js, innentől sok értelme nincs az XSLT-vel is bajlódni. Ugyanazt az XML-t js-el is feldolgozhatod, szerintem ez nem nagy erőforrás-különbség.
Szerintem - ez a legfrissebb, még "tanulatlan" véleményem - a microformats(2) megközelítés a legjobb, azt nem túl nehéz szerveren generálni, kliensen sem sok feldolgozást igényel, keresők meg egyenesen buknak rá. És nem írtál 3+ XSLT-t...
Ezzel együtt még mindig elkülönítheted szerveroldalon a mobileszközt, bumm, akkor 2 template.
26-ra: megkövezni nem akarom, de főleg mobilnál figyeljetek az akksira, mert legjobb tudomásom szerint ez probléma, nem várható nagyobb fejlődés ezen a téren. Úgyhogy felejtős, hogy "most kicsit túlterheljük, mert holnap vesz jobbat" - nem tud. Lehet jobb procit, több ramot tenni pl. a tabletekbe, de azt éred el vele, hogy ki se húzhatod a töltőt... Máris csináltál egy "pórázzal ellátott" mobilt.
Azt az oldalt nem fogják látogatni, amelyik nem műxik jól és gyorsan mobilról, szerintem ennyit lehet biztosan állítani a jövőről.
És igen: ha nem bírja a szervered, nagyobb kell, több pénzért. Ha azt nem bírja a pénztárcád, akkor az üzleti logikával van baj. Pont.
Azt pedig igencsak felelőtlen, sőt, kissé "átverős" hozzáállásnak tartom, hogy "hárítsuk a költséget a látogatóra". Jó, hogy nem a bankszámláját nyúlod le mindjárt. :) A köztudatban az Internet ingyenes. Legalábbis ami az informális tartalmat jelenti. Ennek költségét butaság a látogatóra terhelni, amint megérzi, az életben többet nem látod.
Az azért elég téves elképzelés, hogy a szervered sávszélességét / adatforgalmát félted. Akkor küldj kevesebb médiát. Viszont megint csak a mobil: próbáld ki pl. vonatról (nem wifin, rendesen 3G-n, vagy akár GPRS-en!) azt az oldaladat, amelyiken gondod van a szerver sávszélességével. Nagyon meg fogsz lepődni...
mas is
Ha az uj tartalom generalasaert el kell menni mindig a szerverig, de ezt meg tudna oldani kliens oldalon is, miert ne tegye? User orulni fog hogy villam gyors az oldal a masikhoz kepest, nem az aksija miatt fog aggodni, hanem hogy gyorsan eskenyelmesen megkapja amit akar.
A nem birja a penztarcad vegyel tobb szervertre csak annyit tudnek mondani, hogy azok is akik megtehetnek (pl Google) weboldalakat kliens oldalon allitjak ossze, nem a kesz HTMLt kapod.
Nem pepita :)
.. mert szép kis támadási
Ez nem igaz.
A támadási "pont", minden esetben a szerver-kliens adatcserére/feldolgozásra korlátozódik, akármilyen webes alkalmazás esetén a szerver oldalon kell szigorúan ellenőrizni az input/output adatokat.
A kliens oldal alapértelmezetten minden esetben meghekkeltnek kell tekinteni.. mivel tényleg bárki megváltoztathat ott bármit.
Pont erre utaltam :)
Pont hogy leveszel
Ezzel pont hogy leveszed a terhet a szerverrol.
Részben
Érdekes hozzáállás, hogy ha
Nincs ott semmi féle "Pont", csak ha valaki zöldfülű.
Tegyük fel van egy weboldalad.. év 30 millát költesz kiszolgálókra a felhasználókat meg lehúzod valamiképp + hirdetések, én csinálok egy ugyanolyan oldalt és megoldom 6 millióból üzemeltetést és nem kérek semmit a felhasználóktól csak a hirdetésekért, és még jobb is.. szerinted meddig bírja majd az "üzleti logikád"? Kinek lesz több felhasználója? Ki fog talpon maradni?
A másik.. mi is a bankszámlaszámod?:-)
Egyébként nem érted.. a költséget a felhasználok így-is úgyis kifizetik..
pölö. csak a társaságomból én vagyok az egyetlen idióta, aki 6 éves mobillal futkározik.. a legtöbben 2-4 évente cserélik.
De egyébként nem akarok én vitázni senkivel, lehet májer ez a Nicholas Zakas.. csak szerintem az egész sántít egy kicsit. Egyébként meg pár év és kiderül igaza volt-e..
Nagy túlzás
Nyilván akkor tudsz többet költeni, ha több a bevételed is, addig nem. Ahhoz viszont látogatók / vásárlók kellenek, nem a telefonjukat / tabletüket földhöz vágó soha vissza nem térő dühkitörők.
Egyébként tök egyszerű: elindítod a szolgáltatásod egy kicsike vason, és ahogy nő a látogatottságod (és a bevételed), úgy rakod alá is a többet. A legtöbb szolgáltatónál felfelé bármikor válthatsz, nem kell itt mindjárt 30 millás üzleteket emlegetni, nem abból van sok, hanem az 1-2 millásból. Ezt szépen elindítod akár egy shared hoston, aztán lesz belőle nagyobb tárhely, VPS, saját szerver. Ha kell. De addigra van is miből, vagy tényleg rossz volt az üzleti logikád.
[Off]
A max 5 éve alapított cégek ritkán érik meg a 3 évet is... Nem jó az én üzleti logikám sem, mert gazemberkedni, meg lehúzni-átverni "kell", akkor megy jól. Meg adócsalásba, fiktív dolgokba menni és gyorsan megszüntetni a Kft-t...
Akkor jól megy.
[/Off]
Szerintem ezt a harcot a
Idővel kiderül majd, hogy melyikünk járt közelebb az igazsághoz..
Egyébként.. ne vedd zokon, de mivel nem ismerlek én a weboldalad alapján
tudom csak megítélni, hogy mennyire értesz a dologhoz.. és az alapján, bizony
(http://pepitaweb.hu) nem vagyok benne biztos, hogy elég kompetens vagy a
témában. Az oldalad megnézése után.. nem hiszem, hogy bármi webfejlesztéssel megbíználak..:))
Szevasz!
Nem nagyon lehet megmondani
Ne kövezd meg.. biztos, csak
Amire gondolhatott az az, hogy míg hagyományos HTML oldal esetén
1 millió látogatóra kell 150 szerver, addig a kliens oldali renderelés
esetén csak 10 (csak példa). Azért ez a nagy különbség, mert nem kell külön
output a céleszköz típusától (többnyire).
De ez igaz az összes "erőforrásra", azaz a hálózati forgalomra is.
A másik, hogy ez pénzről szól.. a kisebb fenntartási költség versenyelőnyt
jelenthet.. arról nem is beszélve, hogy szerver oldali kód sokkal tisztább ezért biztonságosabb. A költségek jelentős részét a felhasználók "viselik", akik többsége igyis-ugyis X idő után lecseréli az eszközt.. sokkal jobbra.
Az meg, hogy mi a szerverek feladata nehéz terep.
"Régen" a többrétegű alkalmazások korában is csak az adatok közlekedtek a hálózaton, sokszor bináris formában.. mert a szerver feladata az adatszolgáltatás volt, és nem az adatok megjelesítés céljából való rendérélese.
Lásd Gábornak adott válaszom,
Szerk.: az arányaid biztosan nagyon rosszak, mert ha nem HTML-t, akkor XML-t, JSON-t, de mindenképp valamilyen formázott adatot adsz ki, ezek között ha 15szörös méret / előállítási különbség van, akkor valamit nagyon elrontottál az egyiknél... Még kétszeres sincs.
Ha szerveroldalon renderelsz,
Egy szóval sem állítottam,
Nos, utána mértem.. ..
.. tömörítés esetén ~ 4x nagyobb
.. tömörítés nélkül ~ 10x nagyobb a szerver oldalon előállított html kód a strukturált
adatokhoz képest, azaz a "tiszta" hálózati forgalom
Ebből szerintem adódik, anélkül, hogy belemennénk a "de"-kbe, hogy nyugodtan mondhatok "tisztán" 10x különbséget a szerver oldali erőforrásokra.. de felezzük, legyen "csak" 5x a különbség.
A kétszeres.. na az az arány ami teljesen rossz.
Koszonom
Nicholas egyáltalán nem mond
Szerencsére ennek könnyű
Van egy videoja progressive
Nem tudom, hogy melyik a korábbi, melyik a későbbi, de abban több értelmet látok, mint a teljes visszaállást szerver oldali HTML-re.
Btw én lennék a legboldogabb, ha lenne egy natív js api-t, saját media type-al, amivel GUI-t lehet építeni a böngészőben, és örökre elfelejtenénk a HTML-t webalkalmazásoknál. Sajnos ez nincs így, és a felhasználói élmény + böngésző kompatibilitás miatt muszáj szerver oldalról is HTML-t generálni.
Mindkét alkalommal ugyanazt
Hát én nem mosnám össze a
Tényleg ugyanazt mondja
Az átlag webes programozó ebbe nem gondol bele, hanem mindent összeszór létező js libekből, pl beszúrja a teljes jquery-t, amikor a töredékére van szüksége abból, amit az a könyvtár tud, stb... Ennek az egyik oka, hogy elég nagy a nyomás az embereken határidő szempontjából, a másik, hogy esetleg nem ismernek más fejlesztési módszert. Ha valakinek kalapács van a kezében, akkor hajlamos mindent szögnek nézni...
Természetesen mindkét esetben
Zakasnak sok mindenben igaza
Elég jól össze tudom
Jobb hibrid prezentációs réteget csinálni, mint single page js klienseket. A hibrid prezentációs réteg alatt azt értem, hogy a szerver oldal generálja a HTML-t az első betöltésnél, és ha van js, akkor utána az elintézi az összes többi betöltést, animálást etc..., ha meg nincs, akkor marad a HTML, linkek, űrlapok az alkalmazás használatára. Miért jobb ez, mint mindent eleve js-ből csinálni?
Miért rosszabb?
Ezen kívül még azt mondja, hogy úgy érdemes a prezentációs réteget megcsinálni, hogy nem töltünk túl sokat időt azzal, hogy pl ie6-ban is működjön az a funkció, amit ie10-re terveztünk. Helyette elkezdjük HTML-el csinálni a prezentációs réteget. Aztán ha megvan a HTML, akkor arra ráépítünk egy js réteget. Arra a következőt, ami már fejlettebb js supportot igényel, és így tovább... A felhasználók általában a tartalommal törődnek, és nem azzal, hogy a keret az kerek vagy szögletes, így pl ie6-ban direkt erre berántani egy css3 libet marhaság...
Szóval Zakas egyáltalán nem sír amiatt, hogy a js fejlődik, egyszerűen csak az nem tetszik neki, hogy az emberek rosszul használják, nincs HTML only fallback, ie6 fallback, stb... , hanem mindent megírnak ie10-re, aztán akinek nem támogat bizonyos funkciókat a böngészője, azok dögöljenek meg. Én egyet tudok érteni vele, bár fél éve még én is inkább az utóbbi módon gondolkodtam. Valamivel nagyobb erőfeszítés így megírni egy alkalmazást. Szükség van pl egy olyan sablon rendszerre, ami kliens és szerver oldalon is megy, de a felhasználói élmény szempontjából mindenképp jobb, mint egyáltalán nem törődni az olyan emberekkel, akik nem frissítik a böngészőjüket, vagy megpróbálni minden funkciót böngésző függetlenül megvalósítani.
Zakas-nak van egy nagyon jó analógiája erre az egészre. A tv fejlődésénél először volt a fekete fehér, utána a színes, utána hd, fullhd, 3d, stb... Érdekes módon a fekete fehér tv ugyanúgy működik manapság, mint egy fullhd tv, de egyáltalán nem ugyanazt az élményt nyújtja. A fekete fehér tv fekte fehér képet ad, a fullhd meg tűéles részletes képet. Ha a fullhd tv-n is fekete fehér kép menne, akkor az emberek fel lennének háborodva, hogy minek dobtak ki ennyi pénzt egy új tv-re, amikor semmivel sem nyújt jobb mozi élményt... Ha a tv szolgáltató azon fáradozna, hogy fekete fehér tv-n is sikerüljön fullhd adást megjeleníteni, akkor a részvényesek lefejeznék a cégvezetést... Ehhez képest a weben böngésző kompatibilitás néven ez a két dolog volt az utóbbi években a standard megoldás. Az egyik, hogy vagy csak HTML oldalt csináltunk, hogy minden böngésző értse, és mindent szerver oldalról generáltunk. A másik, hogy megpróbáltuk ie6-ra is összetákolni js-ben ugyanazt az élményt, amint mondjuk ie10-ben biztosítunk.
Több dologgal nem értek
1) Nem biztos, hogy igaz, hogy egy sok milliós látogatottság esetén 1-2 százalék
számít, mert árnyalja a képet, hogy több erőforrást kell biztosítanod a
kompatibilitásra és visszafogja a fejlődést. Nem véletlenül dobja (örömmel) a
google kémgyár is a régi böngészők támogatását.
3) Single page js esetén igaz amit írsz.. de miért kell leragadni a single page
js-nél?
Alkalmazás szintű js esetén, minden hibát le tudsz kezelni.
4) Szerver oldali hibás kód estén ugyanez igaz. De hozzáteszem, tényleg nagyon nehéz
jó és biztos kódot írni javascript-ben.
5) Megoldható.. és nem is annyira trükkös.
Kifejtenéd ezeket? Leginkább
Az egyszerű.. .. le kell
.. le kell generálni egy minimalista html tartalmat, amit a kereső motorok tudnak értelmezni, abba be kell ágyazni egy javascript-et, ami a logikát viszi a történetbe,
azaz, ha böngészővel kérik le, akkor mondjuk berántja a "rendszert", amit persze fel kell készíteni, hogy már van tartalom az oldalon.
Igazából egyik keresőnek sincs jó, használható de legfőképp egységes megoldása ajax-os rendszerek indexelésére, ezért kell html-t generálni a keresők számára, mert azt mind megeszi.
Egyébként sokkal nagyobb problémák vannak, mint ezek.. pl.:
- hogy adsz át "linket" dinamikus tartalomra egy másik dinamikus rendszernek..
- hogy tudsz elmenteni böngészőben linket egy dinamikus előállított tartalomra..
Persze ezek is megoldhatók, csak ezeket nem lehet erővel megoldani..
le kell generálni egy
Ugyanerről beszélek, azt hittem van valami spa-re is.
- hogy tudsz elmenteni böngészőben linket egy dinamikus előállított tartalomra..
Nem igazán értem, hogy itt pontosan mire gondolsz.
A google tud AJAX-szal
Egy lehetséges kiút olyan alkalmazások írása, amik akár a szerveren, akár a böngészőben tudnak futni; manapság ennek nagyjából egy életképes módja van, a node.js (esetleg valamilyen transpilerrel párosítva - CoffeeScript, ClojureScript stb). Erről viszont jelenleg azt hallani, hogy nem elég érett még, nehéz benne igazán nagy alkalmazásokat karbantartható, jól strukturált módon megírni.
Én is inkább azon az
Nem feltétlenül ide, inkább általános feljegyzés a hajónaplóba: sokszor látom sok helyen, és sokszor magam is bedőlök neki és részt veszek benne, hogy szakmainak tűnő viták zajlanak, de valójában nem szakmai, hanem érzelmi alapon. Mindenki amellett érvel inkább, ahogy ő csinálja, amit megszokott, vagy ami éppen lelkesíti. Persze ebből is születhetnek érdekes dolgok, és néha olvasni amúgy hasznos érveket, még ha hibás célra is használják őket. Sokszor elfelejtjük, hogy nincs Szent Grál a szakmánkban.
+1
Hajónaplóba: igenis, számomra az én véleményem a legfontosabb. :) (Ha valaki eddig nem vette volna észre. :)) De ez azt hiszem sokunkra igaz...
Ez jobb
https://support.google.com/webmasters/answer/174992?hl=en
Sajnos a google megoldása elég használhatatlan, több problémás pont van benne,
más keresőknek meg tudtommal még nincs semmi megoldása erre. Egyébként ez is html
indexel (dinamikusan előállítottat), ezért nincs is sok értelme, sokkal értelmesebb statikusan legenerálni az oldalakat, mert azt minden böngésző megeszi.
Lehet rasszista vagyok, de engem nem érdekelnek azokra akiknek "nincs" JS,
egyszerűen egy tucat olyan dolog van, amit nem lehet csak HTML-el meg csinálni,
vagy sokkal rosszabbul, amin értem a felhasználói élményt is.
Senki nem mondta, hogy