ugrás a tartalomhoz

JS Stack?

deejayy · 2013. Feb. 8. (P), 23.54
Sziasztok,

- erősen elméleti téma -
ma ütköztem bele egy érdekes olvasmányba: http://dailyjs.com/2013/02/04/stack/

Nem tartom magam gyakorlott javascriptesnek, alap dolgokkal vagyok tisztában, meg pár jquery shortcutot tudok, de alapvetően szerver oldalon kódolok. Úgy vettem észre, hogy a JS-nek napról napra egyre durvább szerepe van, és nagyobb figyelmet kellene rá fordítani (részemről legalábbis).

Szóval vannak a cikkben felsorolva 'stack'-ek, minden fontos 'funkcióra' egy js lib.

Nagyjából értem is, hogy melyik mire való, de nem sikerült olyan esetet elképzelnem, ahol ezeknek hasznát venném. Ez persze azért is lehet, mert főleg a php-vel vagyok szorosabb kapcsolatban, ez pedig vastagon a kliens oldal(nak tűnik).

Szóval egyáltalán mikor érdemes ezeket használni? Szokványos webes világban (weblapok, webshopok, portálok, blogok, etc.) mennyire szokták ezeket az eszközöket használni?

Esetleg valami feketeöves js-es tudna mondjuk egy bloatware refaktor step-by-stepet csinálni, hogy na ilyen volt ilyen lett, mit mivel lehet kiváltani, mire kell figyelni, mikor mit érdemes használni, van ennek értelme?

Egyáltalán jó kérdéseket teszek fel? :D
 
1

Szerintem szabadúszóként van,

Karvaly84 · 2013. Feb. 9. (Szo), 01.47
Szerintem szabadúszóként van értelme, főleg ha azt akarod h más ne tudjon a kódodhoz nyúlni :D
2

Ezek ránézésre asztali PC-n

Hidvégi Gábor · 2013. Feb. 9. (Szo), 10.20
Ezek ránézésre asztali PC-n futó webes alkalmazásokhoz valóak, átlag weboldalra feleslegesek. Poetro mondta a legutóbbi weblaboros sörözésen, hogy egy átlag mobileszköz már a jQuery-től köhög, hát még ennyi különböző keretrendszertől.

Ha ismered a rendelkezésre álló eszközöket, valószínűnek tartom, hogy gyorsan lehet bennük működő dolgot összehozni. Ahányat használsz, annyi helytől függsz, ki tudja, hogyan akadnak össze, milyen bugjaik vannak, mikor hagyják abba a fejlesztésüket és így tovább.

Használhatsz bármilyen külső eszközt, az alkalmazásod kódja mindig ugyanaz lesz, de az adott eszközökhöz fog illeszkedni. Ha jön egy új divat ("itt ez az új keretrendszer, sokkal jobb, mint a korábbiak"), akkor esetleg nehezebb lesz áttérni rá, és kényelmetlenül érezheted magad.

Ha jól működő rendszert szeretnél, ahol teljes mértékben a te kontrollod alatt van az egész, akkor szerintem a legjobb, ha te írod meg a dolgokat. Saját tapasztalatom az, hogy a karbantartás hatékonyabb, a kód kisebb (azon kívül, hogy kidobtam az összes keretrendszert, kevesebb, mint fele akkora lett), és átlagosan 10-20-szor gyorsabb lett.

Mindez azért van, mert a keretrendeszerek általánosan segítik a fejlesztést, azaz mindenre jók. Amikor pontosan ismered a problémát, akkor céleszközt tudsz készíteni, ami kisebb és jobb lesz.
9

reinvent

blacksonic · 2013. Feb. 10. (V), 12.05
Azért valljuk be ritkák az olyan rendszerek ahol létező eszközöket 0áról kell újraírni a teljesítménybeli szűk keresztmetszet miatt

A függőségekben viszont igazad van, nagyon fájdalmas tud lenni ha túl erős a függőség egy eszköztől
3

js

Hidvégi Gábor · 2013. Feb. 9. (Szo), 13.36
Egyébként ezt az aktuális Javascript-felhajtást érdemes egészséges szkepticizmussal figyelni, több jel mutat arra, hogy nem eszik olyan forrón a kását:

1, a HTML 5 fejlesztésének (és ezzel együtt a JS API bővítésének) egyik elindítója, az Apple a saját üzleti modelljében szinte egyáltalán nem használja, eszközein natív kód fut, nem véletlenül

2, az API-k nem egységesek, a Mozilla operációs rendszere mást használ például a szolgáltatások elérésére, mint a Microsoft a Windows 8-ban

3, a JS komoly hiányosságokkal küzd, nemrég volt szó arról, hogy a Budapestre hozott MLOC.JS konferencia neves előadóinak fele ezek áthidalásáról értekezik, vagy ott van például a Google-féle Dart, amely pont emiatt jött létre

Hacsak nincs valami aktuálisan futó projekt, szerintem nem érdemes a fentiek miatt nagyon beleásnia magát senkinek, mert ebből az egészből még bármi kisülhet. Persze, ha egy blogon valaki megosztja a témában a tapasztalatait, nem árt elolvasni, de ki tudja, még az is lehet, hogy akár két-három év múlva már más lesz a divat.
4

Nem értem, hogy mi a kérdés.

inf · 2013. Feb. 9. (Szo), 17.40
Nem értem, hogy mi a kérdés. Egyébként a felsorolt keretrendszereknél elég egy csomagot kiválasztani, és azt megtanulni, egyáltalán nem kell minddel foglalkozni. Csak olyan környezetben érdemes használni őket, ahol szabályozni tudod, hogy a felhasználónak meglegyen a megfelelő böngészője és a bekapcsolt javascript-je. Mondjuk egy átlag weblapnak az admin oldalát szerintem sokkal könnyebb és gyorsabb REST service-el és vastag js klienssel megírni. Amit ajánlani tudok az backbone és az extjs. A backbone-nál sok kis keretrendszert kell összerakni, és ezek közül mindegyiknek megvan a specifikus feladata a projektben, az extjs-nél meg egy nagy keretrendszerben van benne minden. Mindkét megoldásnak vannak előnyei és hátrányai. Én személy szerint a backbone-t preferálom, mert ott össze tudom válogatni azok a könyvtárakat, amik nekem tetszenek, az extjs-nél meg adott a felület, nincs variálás. De az is egy szempont, hogy mivel az extjs fizetős, ezért sokkal jobbak nála a support lehetőségek. Ha esetleg valami problémába ütközöl extjs-el kapcsolatban, akkor általában még aznap kapsz használható választ...

Szerver oldalról ha továbbra is PHP-zel, akkor a SLIM-el érdemes megismerkedni, de gondolom nagyobb keretrendszereknél is vannak REST service megoldások, ha esetleg már hozzászoktál egy ilyenhez...
5

ext

Hidvégi Gábor · 2013. Feb. 9. (Szo), 18.08
Az extjs-ben régen össze lehetett válogatni a komponenseket az 1.0-ig bezárólag, nekem is hiányzott belőle ez a lehetőség, amíg használtam.
6

Most is lehet

gabesz666 · 2013. Feb. 9. (Szo), 21.38
A 4-es extben is lehet olyat, hogy csak a használatos komponensekből csinálsz egy saját ext buildet, erre való a Sencha Cmd.
7

Sőt!

T.G · 2013. Feb. 10. (V), 11.25
Nem csak build,de loader is van, azaz dinamikus betöltésre is van lehetőség: http://www.sencha.com/blog/using-ext-loader-for-your-application/
8

Dinamikus betöltés

Hidvégi Gábor · 2013. Feb. 10. (V), 12.00
És ezt mikor érdemes használni?
10

Re: Dinamikus betöltés

T.G · 2013. Feb. 10. (V), 19.25
Ha a (nagyobb) komponenseket nem akarjuk előre betölteni, de szeretnénk, hogy mégis bármikor elérhetőek legyenek.