ugrás a tartalomhoz

Progressive Enhancement: Zed’s Dead, Baby

Hidvégi Gábor · 2014. Szep. 20. (Szo), 13.59
Kell-e még foglalkozni a JavaScriptet nem futtató kliensekkel?
 ■
1

Fejlődés

Hidvégi Gábor · 2014. Szep. 19. (P), 16.29
Amit a szerző is kiemel, szerintem is nagyon fontos megállapítás:
the browser transformed from being an awesome interactive document viewer into being the world’s most advanced, widely-distributed application runtime
Ez igaz, de a megrendelők többségének nincs sem szüksége, sem pedig pénze alkalmazásra. Továbbá az Android/iOS/WP "appok" terjedése is azt igazolja, hogy a webes technológiáknak van még hova fejlődniük.

Az is nagy kérdés, hogy a webes alkalmazásokban megosztott adatokat hogyan találják meg az emberek. HTML-re már van kidolgozott eljárásunk, mindent megesz a google, de ahány JS alkalmazás, annyi szokás. Mivel az alkalmazások oldalai nem linkelhetőek, így a keresőkben sem fognak jó helyezéseket kapni, azaz jóval többet kell költeniük hirdetésre, hogy megtalálják őket.

Alkalmazásfejlesztőknek érdemes elolvasni a témában az Endyl által korábban beküldött Offline First: Your Next Progressive Enhancement Technique? című blogmarkot.
2

Továbbá az Android/iOS/WP

inf · 2014. Szep. 21. (V), 14.25
Továbbá az Android/iOS/WP "appok" terjedése is azt igazolja, hogy a webes technológiáknak van még hova fejlődniük.


Imho azt igazolja, hogy utálják a javascriptet, mert nem típusos, és lövésük sincs hogyan írjanak benne színvonalas kódot.

Az is nagy kérdés, hogy a webes alkalmazásokban megosztott adatokat hogyan találják meg az emberek. HTML-re már van kidolgozott eljárásunk, mindent megesz a google, de ahány JS alkalmazás, annyi szokás. Mivel az alkalmazások oldalai nem linkelhetőek, így a keresőkben sem fognak jó helyezéseket kapni, azaz jóval többet kell költeniük hirdetésre, hogy megtalálják őket.


Az oldalak linkelhetőek, a technológia meg létezik, amivel kereshetővé lehet tenni őket, RDF-nek hívják.

Elméletileg google már tud kezelni js kódot. Mondjuk, hogy ezt hogyan teszi, annak sosem néztem utána.


A progressive enhancement szerintem is egy jó dolog.
3

Imho azt igazolja, hogy

Hidvégi Gábor · 2014. Szep. 21. (V), 15.10
Imho azt igazolja, hogy utálják a javascriptet, mert nem típusos, és lövésük sincs hogyan írjanak benne színvonalas kódot.
Szerintem ez ennél egy picit bonyolultabb, vegyük például a memóriafoglalást. JS-hez egyelőre nem találtam cikket, de PHP-hoz igen, szerintem annak nagyjából hasonlóan működik a menedzsmentje a böngészőkéhez.

JS-ben a grafikánál is többszörös absztrakción keresztül jutsz csak el a grafikus processzorig, míg arról biztos olvastál, hogy az iOS 8-ban vezetett Metal API szinte közvetlen hozzáférést nyújt hozzá.
4

Szerintem ez ennél egy picit

inf · 2014. Szep. 21. (V), 17.51
Szerintem ez ennél egy picit bonyolultabb, vegyük például a memóriafoglalást. JS-hez egyelőre nem találtam cikket, de PHP-hoz igen, szerintem annak nagyjából hasonlóan működik a menedzsmentje a böngészőkéhez.


Ezek nem jók?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management

https://developer.chrome.com/devtools/docs/javascript-memory-profiling

http://www.smashingmagazine.com/2012/11/05/writing-fast-memory-efficient-javascript/

Ha valakit nagyon érdekel, akkor belenézhet pl a v8 forrásába, elvileg nodejs alatt is valami hasonló megy.

Ettől függetlenül lehetséges, hogy nehezebb optimalizálni js-ben, mert kevesebb a cikk a témában, meg lehet, hogy minden js motor kicsit máshogy működik.

JS-ben a grafikánál is többszörös absztrakción keresztül jutsz csak el a grafikus processzorig, míg arról biztos olvastál, hogy az iOS 8-ban vezetett Metal API szinte közvetlen hozzáférést nyújt hozzá.


Egyikben sem vagyok kifejezetten otthon. Nem tudom, hogy baj e, hogy csak absztrakción keresztül érhető el a grafikus motor. Sokaknak nincs szüksége mélyebb ismeretre, hogy fejlesszenek benne valami használhatót. Legalábbis ez lenne az absztrakciók lényege...
5

többszörös absztrakción

Poetro · 2014. Szep. 21. (V), 21.02
többszörös absztrakción keresztül jutsz csak el a grafikus processzorig, míg arról biztos olvastál, hogy az iOS 8-ban vezetett Metal API szinte közvetlen hozzáférést nyújt hozzá

Az utóbbi 7 évben megvoltak többszörös absztrakció mellett is (iPhone OS 1.0 2007 - iOS 7 2013), szóval valószínűleg nem ez lesz a kulcs.
6

Kevés

Hidvégi Gábor · 2014. Szep. 21. (V), 22.16
Úgy látszik, ez mégsem volt elég, ezért adtak a programozók kezébe egy ilyen lehetőséget.
7

Játékok

szabo.b.gabor · 2014. Szep. 22. (H), 22.25
Ez valószínűleg az 'erős grafikával' rendelkező játékok miatt jelent meg. 2D-s felhasználói felületű ide nyomok az történik appokhoz senki nem fog Metal API-t használni. Szerintem.
8

A kiindulási alap a következő

Hidvégi Gábor · 2014. Szep. 23. (K), 07.14
A kiindulási alap a következő volt:
»Továbbá az Android/iOS/WP "appok" terjedése is azt igazolja, hogy a webes technológiáknak van még hova fejlődniük.«

Imho azt igazolja, hogy utálják a javascriptet, mert nem típusos, és lövésük sincs hogyan írjanak benne színvonalas kódot.
Mint írtam, vannak a memóriaproblémák. Típusnélküli nyelvekben minden változónak eleve van overhead-je, másrészt pl. elindítottam most egy Firefoxot kikapcsolt addonokkal, és 110 megabájt memóriát eszik egy darab üres lappal. Már nem is olyan vidám a helyzet, pedig még nem is csináltunk semmit. Ha az átlagtelefonban van egy gigabájt memória, amiből levonjuk még az operációs rendszer 2-300 megabájtját, nagyon kevés erőforrással tudunk gazdálkodni, viszont natív programban mindenképp többel.

Korábban már beküldtem blogmarknak ezt az írást, amiben kifejtik, miért tértek át facebookék például iOS-en a natív fejlesztésre böngésző helyett.

Azt már csak zárójelben jegyzem csak meg, nem igazán értem, miért ragaszkodnak annyira a végtelen görgetéshez. Egyrészt nincs semmilyen hozzáadott értéke a "felhasználói élményhez", hisz egy oldalnyit érdemes vele görgetni, így viszont rengeteg plusz memóriát és processzoridőt igényelnek, a hozzávaló scriptek, az animáció és a növekvő adatmennyiség kezelése. Értem én, hogy ez a menő, de innentől kezdve öncélú. Ennyi erővel betehettek volna egy iframe-et, aminek a tetején és az alján van egy előre-hátra gonb, és azzal lehetne lapozni.
9

elindítottam most egy

inf · 2014. Szep. 23. (K), 09.17
elindítottam most egy Firefoxot kikapcsolt addonokkal, és 110 megabájt memóriát eszik egy darab üres lappal


Ha még azt is belevesszük, hogy nem egyszerű js-ben memory leak nélküli alkalmazást írni, akkor elég világos, hogy miért előnyös a natív megoldás

Azt már csak zárójelben jegyzem csak meg, nem igazán értem, miért ragaszkodnak annyira a végtelen görgetéshez.


Én sokszor görgetek le több oldalt. Nem mondom, hogy ez a kánaán, de nem tudok olyan megoldást, ami többféle felbontáson is ugyanolyan jól használható lenne. Én pl most úgy döntöttem, hogy elforgatom a monitorom, és 1080x1920-ban nézek oldalakat. Weblabor pl csúnyán szétesett, facebook ugyanúgy használható maradt, és általában cikk olvasáshoz sokkal jobb így, filmet meg úgyis tv-n nézek nagy ritkán.
10

Ha még azt is belevesszük,

Hidvégi Gábor · 2014. Szep. 23. (K), 09.25
Ha még azt is belevesszük, hogy nem egyszerű js-ben memory leak nélküli alkalmazást írni, akkor elég világos, hogy miért előnyös a natív megoldás
Ha teljesen különválasztod az adatokat és a rajtuk munkát végző függvényeket, azaz igyekszel a funkcionális paradigmának megfelelni (például nem használsz closure-öket), akkor szerintem meg lehet oldani könnyen, hogy ne legyen szivárgás.
11

Lehetséges, bár az is baj

inf · 2014. Szep. 23. (K), 09.37
Lehetséges, bár az is baj szokott lenne, ha a globális névtérhez (amihez a DOM fa is hozzátartozik) kötsz valamilyen objektumot. Szóval van 1-2 dolog, amire így is úgy is oda kell figyelni. A closure-t csak modulok definícióknál érdemes használni, esetleg olyan általános mintáknál, mint a bind, ahol nincs benne komplex logika. Egyébként arra alapozni bármi komolyat nem túl kedvező sem olvashatóság, sem memória kezelés szempontjából (na legalábbis úgy tudom).
13

Korábban már beküldtem

complex857 · 2014. Szep. 23. (K), 10.45
Korábban már beküldtem blogmarknak ezt az írást, amiben kifejtik, miért tértek át facebookék például iOS-en a natív fejlesztésre böngésző helyett.

Majd erre válaszul jött sencha (akik egyébként html+js fejlesztő eszközök készítésével foglalkoznak) demonstralandó, hogy nem megoldhatatlan a feladat mobil böngészőben sem: Demo videó.
Bővebb kifejtés blogbejegyzésben.
15

Ismerem a sencha termékeit,

Hidvégi Gábor · 2014. Szep. 23. (K), 12.21
Ismerem a sencha termékeit, az Ext.js-sel már az 1.0 óta foglalkozom. Te használtad már a sencha touch-ot?
16

Hallomásból

complex857 · 2014. Szep. 23. (K), 13.56
Harctéri tapasztalatom nincs vele, egyszer régen építettem egy "Hello world!"-öt, szóval nem tudok tapasztalatokról beszámolni.
12

Is Native Still Beating

Poetro · 2014. Szep. 23. (K), 10.20
Is Native Still Beating HTML5?
14

Nagyon jó a beszélgetés, kár,

Hidvégi Gábor · 2014. Szep. 23. (K), 12.07
Nagyon jó a beszélgetés, kár, hogy ilyen rövid.