ugrás a tartalomhoz

Enough with the JavaScript Already! with Nicholas Zakas

Hidvégi Gábor · 2013. Nov. 14. (Cs), 15.46
Arra kéne használni a JS-t, amire kitalálták
 
1

Ki: Most vettem csak észre,

Hidvégi Gábor · 2013. Nov. 14. (Cs), 16.07
Ki:
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.
2

Csak hogy más vélemény is

virág · 2013. Nov. 18. (H), 14.13
Csak hogy más vélemény is legyen itt: szerintem a "A JS túldimenzionáltsága egészen nyilvánvaló" egy jól hangzó dolog, de semmi igazságtartalma nincs. Ilyeneket könnyű állítani, főleg jelenleg, amikor egyre jobb és jobb JavaScript-es eszközök állnak a rendelkezésünkre. 5-6-8 éve emiatt sírtunk... Most, hogy szépen fejlődik minden, a nagy piaci szereplők felkaroltak egy csomó kezdeményezést és a JS végre elért egy használható szintet - mind sebességben, mind a nyelvi elemek fejlettsége terén, ott van szerveren (szerveren is már a kilencvenes évek közepétől... a Netscape segedelmével) és kliensen egyaránt - ilyenkor néhány embernek okvetlenül el kell kezdenie pampogni és tudálékoskodni. Ez csak a szokásos. Mindig megtörténik. + Nicholas Zakas véleményével sem értek egyet. Persze mindenki gondoljon amit akar ettől szép színes a világ... :)
3

Senki nem mondta, hogy ne

Hidvégi Gábor · 2013. Nov. 18. (H), 14.18
Senki nem mondta, hogy ne vegyük igénybe az új JS eszközöket. Nicholas Zakas csak arra hívja fel a figyelmet, hogy ha van olyan lehetőség, amivel hatékonyabban lehet elvégezni bizonyos feladatokat, mint javascripttel, akkor inkább használjuk azt.
5

PHP

Poetro · 2013. Nov. 18. (H), 17.13
Ugyanúgy nem értem, hogy egyesek miért használnak PHP-t, mikor ugyanazt megoldhatnák SSI-vel, vagy statikus HTML generátorral stb. Biztosan nekik így kényelmesebb, ezt ismerik stb.
6

Nicholas arra utal, hogy ha

Hidvégi Gábor · 2013. Nov. 18. (H), 21.06
Nicholas arra utal, hogy ha egy HTML kódot legenerálhatunk szerveroldalon, akkor tegyük meg ott, mert kliensoldalon drágább lehet.
7

Ne vedd zokon, de az

SecretName · 2013. Nov. 19. (K), 11.21
Ne vedd zokon, de az érvelésed elég gyenge lábakon áll.

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..
8

Kérdések

Hidvégi Gábor · 2013. Nov. 19. (K), 12.12
Egy tipikus webes alkalmazásnál a JS motor hány magot használ? Hogyan viszonyul egymáshoz az x86-os és az ARM processzoroknál a sebesség ugyanannyi megahertzen? Mik az eltérések a Windows és az Android és az iOS memóriakezelésében? Mennyi RAM van egy PC-ben és egy átlagos mobiltelefonban (nem a legújabban)? Melyik a gyorsabb: ha a böngésző natívan dolgozza fel a HTML-t, vagy ha JS-sel állítod elő a kódot (akár innerHTML-lel)?

In Smartphones and Tablets, Multicore is Not Necessarily the Way to Go
14

+10

Pepita · 2013. Nov. 19. (K), 15.41
Ha jól figyelem, egyedül az akksi maradt ki, ami még lényeges szempont.
18

Egyrészt vedd észre a

SecretName · 2013. Nov. 19. (K), 19.03
Egyrészt vedd észre a hozzászólásom arról szólt,
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.
19

plusz

blacksonic · 2013. Nov. 20. (Sze), 19.52
plusz ne felejtsuk el hogy a szerver eroforrasai vegesek, mig a kliens oldalt futtato eszkozoke szinte hatartalan a szerverehez kepest (osszmennyisegre)
20

Ajjaj

Pepita · 2013. Nov. 20. (Sze), 21.45
Ne haragudj, de ugye nem akarod a látogatók gépeinek a teljesítményét összeadni?! Ők ugye nem az összes gépükkel próbálnak egyetlen közös oldalt összerakni... Ezt szerintem gondold át mégegyszer, a szerver pont arra van kitalálva, hogy az összes látogatót képes legyen egyszerre kiszolgálni. Ha kicsi / gyenge, akkor komolyabb szolgáltatás kell. Akár egész szervertermet is bérelhetsz, míg a félbuta telefonos Júzer úgy ott hagy, mint a huzat, ha nem megy az oldal az ő kis telóján.

Kell spórolni a szerverrel is, nem mondom, hogy nem, de korántsem úgy, hogy átterheled a kliensre a szerver dolgát.
21

Pedig ez jó indok lenne az

deejayy · 2013. Nov. 21. (Cs), 07.24
Pedig ez jó indok lenne az környezetvédelem szempontjából, hiszen egy szerver idle állapotban is legalább 130-150W-ot fogyaszt, míg egy mobilproci csúcsterhelésnél is csak 2-3W-ot.
22

Összetettebb

Pepita · 2013. Nov. 21. (Cs), 08.59
míg egy mobilproci csúcsterhelésnél is csak 2-3W-ot.
És a mobilnak szinte minden alkatrésze veszélyes hulladék... Nem tudom, hogy ma hogy állunk újrahasznosítás terén, de pont az akksi az egyik legnehezebben hasznosítható.

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?
23

Vannak előnyei és hátrányai a

Hidvégi Gábor · 2013. Nov. 21. (Cs), 09.16
Vannak előnyei és hátrányai a kliensoldali renderelésnek, nem lehet egyértelműen rámondani, hogy rossz. Én magam is hajlok afelé, hogy az adatokat küldjük ki strukturáltan, és a kliens majd eldönti, miképp jeleníti meg őket.
24

Ez rendben is van,

Pepita · 2013. Nov. 21. (Cs), 09.41
én is igen hajlok erre, de összeadni a kliensek teljesítményét egy icipicit gázos megközelítés...
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.
25

Monománia

Hidvégi Gábor · 2013. Nov. 21. (Cs), 10.09
Én ezt az "összeadni a kliensek teljesítményét" dolgot nem igazán értem, kifejthetnéd.

viszont szerveroldali feladatot nagyon nem szabad kliensre terhelni
Mi a szerver feladata? Szerintem az, hogy egy kérésre állítsa össze a visszaküldendő adatokat. A fogadó oldalon több választási lehetőség van:

- 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).
30

Nagyjából

Pepita · 2013. Nov. 21. (Cs), 16.36
Én ezt az "összeadni a kliensek teljesítményét" dolgot nem igazán értem, kifejthetnéd.
Lásd 19 és 26.

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...
34

mas is

blacksonic · 2013. Nov. 21. (Cs), 21.34
Nem feltetlenul csak a penztarca halalja meg hanem pont hogy a felhasznalok is, ha cserebe olyan felhasznaloi elmenyt kap amit nelkule nem.
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.
39

Nem pepita :)

Pepita · 2013. Nov. 23. (Szo), 05.07
azok is akik megtehetnek (pl Google) weboldalakat kliens oldalon allitjak ossze, nem a kesz HTMLt kapod.
Nem csak kész HTML és kliens-túlterhelés van, hanem milliónyi középút is. Én csak amellett állok, hogy ami szerveren könnyen megoldható, azt oldd meg ott. Ez nem a teljes tartalom generálása, mert nyilván, ha csak egy kis részén kell változtatni az oldalnak, nem egy egész oldalt küldünk újra (pl. Ajax), és sok ellenőrzést is át lehet vinni kliensoldalra is, de ezt ne keverjük össze terhelés-megosztással. Azért ne vigyünk kliensoldalra feladatot, mert könnyedén megoldhatjuk a szerveren, már csak azért sem, mert szép kis támadási felületet is hagyhatunk így. De leginkább amiről valamiféle szolgáltatóként gondoskodni tudsz: a szerveroldali teljesítmény. Azt pedig nem tudod, hogy a kliensnél milyen erőforrások vannak. De hangsúlyozom: ez nem vagy fekete vagy fehér, hanem helyes mértéket kell tudni tartani. Mindkét oldalon.
47

.. mert szép kis támadási

SecretName · 2013. Nov. 25. (H), 12.03
.. mert szép kis támadási felületet is hagyhatunk így

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.
50

Pont erre utaltam :)

Pepita · 2013. Nov. 25. (H), 19.55
Akkor veszed el a terhet a szervertől, ha az adott dolgot csak a kliensen végzed el. Ha ez az adatellenőrzés, máris ott a támadási felület. Ha szerveren is ellenőrzöl, nem vettél el terhelést. Pont ez a lényeg a középutak közt, hogy olyat ne vegyél le a szerverről, ami nem kliensre "való". Ezzel együtt van haszna annak, ha a kliensen is ellenőrzöl, mert adott esetben nem megy felesleges forgalom a szerverre és vissza.
51

Pont hogy leveszel

blacksonic · 2013. Nov. 26. (K), 20.59
Ezzel együtt van haszna annak, ha a kliensen is ellenőrzöl, mert adott esetben nem megy felesleges forgalom a szerverre és vissza.

Ezzel pont hogy leveszed a terhet a szerverrol.
52

Részben

Pepita · 2013. Nov. 26. (K), 22.00
Pontosan: ezzel lehet, hogy leveszek egy kis terhet a szerverről. De már nem értem, hogy mit nem értetek az álláspontomon, szerintem itt majdnem mindenki azt hiszi, hogy én mindent a szerveren csinálok, pedig már vagy 10x leírtam, hogy nem, pusztán olyat nem rakok ki kliensnek, ami nem oda való, és nem is ajánlom senkinek, azzal a felkiáltással sem, hogy a klienset terheljük, ne a szervert. Na, azt hiszem innentől én ide nem írok, mert csak még kuszábbra gubancoljátok.
36

Érdekes hozzáállás, hogy ha

SecretName · 2013. Nov. 21. (Cs), 22.26
Érdekes hozzáállás, hogy ha nem bírja a szerver több kell, több pénzért.. és hogy gond van az üzleti logikával.:-) A Zöldek meg forognak a sírjukban..:) Mintha nem számítana csak a pénz.. mégis akinek van a fogához veri és próbálja az üzemeltetési költségeket csökkenteni..

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..
40

Nagy túlzás

Pepita · 2013. Nov. 23. (Szo), 05.37
A Zöldek meg forognak a sírjukban..:)
Általában ugye a szervert nem dobálod el 2-4 évente, mint a telót
én vagyok az egyetlen idióta, aki 6 éves mobillal futkározik.. a legtöbben 2-4 évente cserélik.
Ugyanígy akár az asztali gépet is írhattad volna. Épp te, ha gerjeszted tovább a nagyobb és nagyobb kliensoldali erőforrásigényt, te vagy az, aki kikényszeríti a rengeteg veszélyes hulladékot. Itt most bele lehetne menni, hogy melyik volt előbb: tyúk vagy tojás, abból a szempontból érdektelen, hogy ha te túlterheled a kliensed gépét, már nem vagy zöld szemléletű. És a te egyetlen telód tökmindegy (az enyém 7 múlt... :)), ha pont miattad (is) cserélik a többiek. Mert a régi kukába megy, pont az akksik az egyik legnagyobb zöld probléma.
Mintha nem számítana csak a pénz..
Dehogynem számít. De ha a te weboldalad nem épp telókat árul, akkor azzal is csökken a bevétel-esélyed, amit a látogatóid új telóra költenek. :) Vagy más eszközre. Azzal meg pláne csökken a bevételed, ha mobilról nem látogatnak, mert nem bírja... Abból a szempontból igazad van, hogy így tényleg nem kell nagyobb szerver, sőt, elég hamar semmilyen szerverre nem kell költeni, mert lesz versenytársad, aki megcsinálja jól, neked meg nem lesz vevőd.

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.
A másik.. mi is a bankszámlaszámod?:-)
Miért, akarsz adni nagyobb vasra? :)
én csinálok egy ugyanolyan oldalt és megoldom
Igen, ez egy tipikus, rossz, nálunk elterjedt (magyar) hozzáállás: "majd én megoldom okosba'". Hát oldjad, nekem nincs gyomrom az ilyesmihez.

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.
csak ha valaki zöldfülű
Nem azért, nekem egyáltalán "nem megy jól" jelenleg, de mégiscsak van egy 12+ éve bejegyzett cégecském. Annyira csak nem vagyok zöldfülű; nem volt még egy éves a "mutatvány", mikor egy általam becsült, tapasztalt cégvezető azt mondta: "az első 10 év nagyon nehéz, utána vagy könnyebb, vagy még nehezebb lesz".

[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]
42

Szerintem ezt a harcot a

SecretName · 2013. Nov. 23. (Szo), 13.41
Szerintem ezt a harcot a "végtelenségig" folytathatnánk..:))
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..:))
43

Szevasz!

Pepita · 2013. Nov. 23. (Szo), 15.04
Ne bízz meg...
28

Nem nagyon lehet megmondani

inf3rno · 2013. Nov. 21. (Cs), 15.58
Nem nagyon lehet megmondani manapság, hogy mi a szerver feladata és mi a kliensé. Attól függ, hogy mi a projekt célja és hogy döntenek a fejlesztők. Pl mondhatom azt, hogy szerver oldalon én egy rest service-t vagy soap webservice-t csinálok, és csak adatot küldök a kliens felé, a többit oldja meg maga. A másik véglet, hogy minden szerver oldalon csinálok és kész html-t küldök a böngésző felé. Projektje válogatja, hogy melyik hol renderel...
26

Ne kövezd meg.. biztos, csak

SecretName · 2013. Nov. 21. (Cs), 10.47
Ne kövezd meg.. biztos, csak rosszul fogalmazta meg.

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.
31

Lásd Gábornak adott válaszom,

Pepita · 2013. Nov. 21. (Cs), 16.43
(30) ott kb. neked is válaszoltam.

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.
32

Ha szerveroldalon renderelsz,

Joó Ádám · 2013. Nov. 21. (Cs), 19.48
Ha szerveroldalon renderelsz, akkor az adat mellett a teljes felhasználói felületet is kiküldöd minden válasszal.
41

Egy szóval sem állítottam,

Pepita · 2013. Nov. 23. (Szo), 05.43
hogy mindent a szerveren csinálj. Pont ezért, l. fentebbi válaszom, itt két szálon ugyanarról vitázunk. Annyit mondtam: amit megtehetsz szerveren, ne hárítsd a kliensre azért, hogy a "szervert kíméld". Nem pepita :).
35

Nos, utána mértem.. ..

SecretName · 2013. Nov. 21. (Cs), 22.05
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.
33

Koszonom

blacksonic · 2013. Nov. 21. (Cs), 21.25
Koszonom a hozzaszolast pont ezt akartam megfogalmazni :)
10

Nicholas egyáltalán nem mond

inf3rno · 2013. Nov. 19. (K), 14.25
Nicholas egyáltalán nem mond ilyeneket. Kezd kicsit irodalom órás, mire gondolt az író jellege lenni ennek a beszélgetésnek.
11

Szerencsére ennek könnyű

Hidvégi Gábor · 2013. Nov. 19. (K), 14.46
Szerencsére ennek könnyű utánajárni, mert a pdf-ben le is van írva minden.

the web now is basically just a JavaScript delivery mechanism. That’s where we want to do everything. That was what I was rallying against in my talk, is that when you’re just using a thin slice of what the web has to offer, you’re actually missing out on opportunities, not just for improved performance but for improved maintainability, improved index-ability by search engines, having a more logical way of thinking about the problems that you’re trying to solve. We’re missing all of that when we say JavaScript has to be the only way of doing things.

One of the most common things is, on initial page load, using the JavaScript to render the HTML for that page. It turns out that the browser and the server have actually figured that whole thing out really well, and by us trying to insert into the middle of it, we’re actually introducing complexity where there doesn’t need to be complexity.

And I think it’s unfortunate because the web is a really balanced system between HTML and CSS and JavaScript, and each of those parts are good at very specific things. I think that it’s a shame when we don’t use it for that. Like if you had a child who is really good at violin and said, “You know what? You’re going to play baseball instead.” You’re missing out on what could potentially be something incredible.

I personally still would rather go back to the server and get fully rendered HTML and insert it into the web app.
12

Van egy videoja progressive

inf3rno · 2013. Nov. 19. (K), 15.09
Van egy videoja progressive enhancement 2.0 címen, amiben ezeket mondja el, mármint amit lentebb írtam, hogy a szerver oldal is adjon HTML-t, a kliens oldal meg js-ben segítsen rá, ha tud, akár ajax-al pushState-el is, ha ilyesmire van lehetőség. Így a js minden előnyét ki lehet használni, illetve a csak HTML-t nézőknél vagy ie6-os böngészővel rendelkezőknél is működni fognak bizonyos funkciók.

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.
13

Mindkét alkalommal ugyanazt

Hidvégi Gábor · 2013. Nov. 19. (K), 15.18
Mindkét alkalommal ugyanazt mondja el, csak más szavakkal.
15

Hát én nem mosnám össze a

inf3rno · 2013. Nov. 19. (K), 15.58
Hát én nem mosnám össze a kettőt, inkább végihallgatom ezt a riportot mielőtt erről állást foglalnék.
16

Tényleg ugyanazt mondja

inf3rno · 2013. Nov. 19. (K), 16.31
Tényleg ugyanazt mondja mindkettőnél, de nem ugyanazzal érvel, mint te, hogy "mert kliens oldalon drágább lehet", hanem azzal, hogyha lehetőség van arra, hogy egy funkciót mindenki számára elérhetővé tegyél (pl szerver oldali html generálással), akkor csináld úgy ahelyett, hogy js-el generáltatnád a html-t, ami már az emberek x%-ának nem eléhető, és így tovább...

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...
17

Természetesen mindkét esetben

Hidvégi Gábor · 2013. Nov. 19. (K), 16.42
Természetesen mindkét esetben mással támasztja alá a mondandóját, de én sem állítottam ennek az ellenkezőjét (én a lényegre írtam, hogy ugyanaz).
4

Zakasnak sok mindenben igaza

bamegakapa · 2013. Nov. 18. (H), 15.00
Zakasnak sok mindenben igaza van. Tényleg elég híg a fejlesztői közösség és sokan használják rosszul az eszközöket, például a Javascriptet is. Egyszerűen nem veszik a fáradságot, hogy megtanulják.
9

Elég jól össze tudom

inf3rno · 2013. Nov. 19. (K), 14.22
Elég jól össze tudom foglalni, hogy Zakas mit mond, láttam már pár videoját.

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?
  1. Akik nem használnak js-t, vagy régi böngészővel nézik, azok is használhatják az alkalmazás azon részeit, amire azt mondtuk, hogy érdemes szerver oldalon is megvalósítani. Néhány % lehet az ilyen látogatók száma, de egy 100 milliós látogatottságú oldalnál az is néhány millió embert jelent...
  2. Az első oldal betöltés lényegesen gyorsabb így, és ha új felhasználóról van szó, akkor egyáltalán nem mindegy, hogy 1 vagy 5 másodpercet vár az oldal betöltésre.
  3. Az esetek egy kis részében (kevesebb, mint 1%), valamiért nem érkeznek meg a js fájlok a böngészőbe. Ilyenkor egy hibrid prezentációs réteg ugyanúgy működik a szerver oldali HTML generálás miatt, egy single page js kliens viszont csak egy fehér ablakot mutat.
  4. Ha bármit hibásan írtak meg js-ben, akkor az eltörheti a teljes kliens oldali alkalmazást. Egy hibrid prezentációs réteg esetében jó esély van rá, hogy ilyenkor is használhatóak maradnak bizonyos funkciók.
  5. A hibrid prezentációs réteg által adott HTML feldolgozható a keresőbotoknak, a single page javascript kliens viszont nem. (Bár manapság már ki tudja.)

Miért rosszabb?
  1. Ugyanazt a megjelenítéssel kapcsolatos logikát meg kell csinálni a kliens és a szerver oldalon is. Ezek nem feltétlen teljesen ugyanazok, mert bizonyos funkciók kimaradhatnak szerver oldalról, amiket túl nagy erőfeszítés lenne ott is megcsinálni. Ilyenre példa a facebook chat, ami hiányzik, ha js nélkül nézzük az oldalt.


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.
27

Több dologgal nem értek

SecretName · 2013. Nov. 21. (Cs), 11.12
Több dologgal nem értek egyet, abban amit leírtál.

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.
29

Kifejtenéd ezeket? Leginkább

inf3rno · 2013. Nov. 21. (Cs), 16.01
Kifejtenéd ezeket? Leginkább a js kereshetőség érdekel...
37

Az egyszerű.. .. le kell

SecretName · 2013. Nov. 22. (P), 08.40
Az egyszerű..
.. 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..
38

le kell generálni egy

inf3rno · 2013. Nov. 22. (P), 09.01
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

Ugyanerről beszélek, azt hittem van valami spa-re is.

- 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..

Nem igazán értem, hogy itt pontosan mire gondolsz.
44

A google tud AJAX-szal

tgr · 2013. Nov. 24. (V), 12.12
A google tud AJAX-szal felépített oldalakat indexelni, bár hogy pontosan mennyire megbízhatóan, azt csak találgatni lehet. Amúgy nyilván a valódi kérdés az, hogy megéri-e kétszer lefejleszteni egy alkalmazást azért, hogy a JS-t nem használó 1-2% is tudja használni (esetleg a keresők, de azok egy SPA-nál jellemzően eleve nem jönnek szóba), és az is nyilvánvaló, hogy erre nem lehet általános választ adni. Egy hivatásosoknak szánt, drága, viszonylag kis forgalmú appnál például nyilván nem (próbáld meg mondjuk a New Relic-et javascript nélkül használni, már a belépés gombjuk se működik).

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.
45

Én is inkább azon az

bamegakapa · 2013. Nov. 24. (V), 12.34
Én is inkább azon az állásponton vagyok, hogy nincs általános igazság. Sok függ a projekttől, célközönségtől, büdzsétől meg számtalan más dologtól. A jó fejlesztő nem csak egy bizonyos elképzelés/eszköz/nyelv/metodológia szerint tud dolgozni, hanem ki tudja választani, az adott követelményekhez melyik lesz az ideális.

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.
46

+1

Pepita · 2013. Nov. 25. (H), 01.04
A jó fejlesztő ... ki tudja választani, az adott követelményekhez melyik lesz az ideális.
Ez mondjuk jó nehéz is, mert a kör csak szélesedik és témakörönként is igen bővül, hamar elérhetjük agykapacitásunk határait is... Mert szerintem az is ugyanannyira fontos, hogy amilyen módszer, stb. szerint fejlesztek, abban profi legyek, nem csak "megnéztem pár tutorial-t".

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...
48

Ez jobb

SecretName · 2013. Nov. 25. (H), 12.24
Ez jobb link:

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.
49

Senki nem mondta, hogy

inf3rno · 2013. Nov. 25. (H), 17.45
Senki nem mondta, hogy mindent meg kell csinálni HTML-el is. Amit lehet, azt megcsinálod, amit meg csak tákolással meg workarounddal lehet, azzal nem foglalkozol. Pl Zakas a facebook-ot hozza föl példának, ott a fő funkciók, wall nézése, kapcsolatok nézése mind meg vannak oldva HTML-el is. Van kb 3-4 ilyen fő funkció, ami a lényegi felhasználói élményt adja, és amire az egész üzleti modelljük épül. Ezeket megcsinálták, a maradékkal meg csak akkor foglalkoztak, ha egyszerű volt megoldani HTML-ben. Pl a chat csak js-ből elérhető, mert teljesen mellékes funkció.