Új hozzászólás Aktív témák

• #46 floatr veterán julius666 #45

  Új Válasz 2012-02-21 13:40:27 #46

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  floatr

  veterán

  válasz julius666 #45 üzenetére

  Ez a kommentes dolog is csak akkor lenne jó, ha standard lenne, de nem az. Amúgy azért hoztam fel a java típusosságát is, mert az is egy mókolt dolog, és mégis milyen gyakran hozzák fel példaképpen

• #44 floatr veterán julius666 #43

  Új Válasz 2012-02-21 12:01:41 #44

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  floatr

  veterán

  válasz julius666 #43 üzenetére

  Én meg úgy gondolom, hogy ha valakik, akkor ők igazán megtettek mindent annak érdekében, hogy a lehető legjobban optimalizálják a JIT működését, és ha ezt a megoldást VM/JIT barátnak mondják, az a minimum h ezt fenntartás nélkül elhiszem.

  Más kérdés, hogy ki mit tekint gánynak. Én pl az erősen típusosnak mondott java-ban a generics és tsai megoldását tartom annak, amihez képest ez a szintaxis öröm és boldogság. Ezen már régóta vitatkozik a sok fejlesztő, hogy mi a gány (szvsz a c++ makró is az), de sosem lesz világbéke ebben a témában sem.

• #41 floatr veterán julius666 #40

  Új Válasz 2012-02-21 11:16:53 #41

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  floatr

  veterán

  válasz julius666 #40 üzenetére

  Ezt eddig objektum-alapúként ismertem, mivel az OOP alapelvei közül elég sokat nem teljesít ahhoz, hogy akként lehessen emlegetni. De nem veszünk össze a definíción, a lényeg h már vagy 5 éve lehetnének komolyabb struktúrák a JS-ben, ha a ms nem a SL preferenciája miatt véli túl veszélyesnek a biznicére a fejlesztések irányát. Mire meg a JS.next beérik, addigra már a dart is elterjed, vagy bármi más, ennyit a ES munkacsoportok munkájáról.

  Egyébként ha van felesleges időd, meg lehet nézni az ES4/next tervezetet. Nem gányolás.

  BTW: ha az ie böngijében elfért még egy nyelv (VBS), akkor a gugliéban is elfér a dart.

• #35 FTeR addikt julius666 #10

  Új Válasz 2012-02-21 09:17:35 #35

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  FTeR

  addikt

  válasz julius666 #10 üzenetére

  nem a js-sel van gond és még csak nem is implementációkkal (habár azzal vannak rendesen bajok*), hanem a DOM API-val. A jQuery azért tarol, mert a DOM API-t elrejti egy CSS jellegű megoldással.

  *kezdve azzal, h gyak egy alpha verzió került a netscape-be, ami a natscape-el együtt el is tűnt volna a történelem süllyesztőjében, ha ms nem menti át ie-be. A nyűg abból ered, hogy túl jól sikerült az átmentés, a bugok is 100%-ra implementálva lettek.

• #28 SlipOne csendes tag julius666 #20

  Új Válasz 2012-02-20 23:30:46 #28

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  SlipOne

  csendes tag

  válasz julius666 #20 üzenetére

  jQuery-t addig használsz, míg nem egy komolyabb, nagyobb, erőforrás igényesebb alkalmazáson dolgozol, amit pl mobilon futtatsz. Természetesen elég beteg dolog, de mi írtunk egy keretrendszert alá, mert a jquerymobile és a sencha touch is csont lassú.
  Saját kerettel, direkt figyelve az optimalizálásokra úgy 5-30x gyorsabb alkalmazásokat tudtunk vele előállítani. Nem mellesleg tudod, hogy nem megy bele felesleges láncokba semmi, csak abba, ami szükséges.

• #15 cucka addikt julius666 #10

  Új Válasz 2012-02-20 19:14:39 #15

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  cucka

  addikt

  válasz julius666 #10 üzenetére

  Jelenleg is jelentősen jobb a helyzet mint pár éve csak mivel rengeteg funkciót a régebbi böngészők nem támogatnak
  Izé, most a html/css funkciókról van szó, vagy az ECMAScript-ről? Az általában egy kezelhető dolog, ha egy böngésző nem tud valamilyen html/css funkcionalitást, ha viszont a nyelvek különböznek, az keményebb dió, emiatt nem érdemes gyors sikerre számítani.

  illetve a JS annyira mostohán van kezelve hogy a programozók jó része szarik ezekbe magasról, úgyis csak kopipasztázik valami template-t amit neten talált,
  Ez legfeljebb azok a programozókra igaz, akiket te ismersz.

  Házi ökörködéshez lehet jó, éles projekthez én biztosan nem használnám.
  Ha van egy nyelv, ami mondjuk a Javascript-nél jobb (valamilyen metrikák szerint) és lehet belőle javascript-et fordítani, akkor mi a probléma? A programok többsége lefordul valamilyen más nyelvre, mielőtt azt a számítógép le tudná futtatni.

  normális környezetben használva (pl. node.js) kiválóan működik.
  A node.js-ről mindig a klasszikus mondás jut eszembe: "XML is a giant step towards no direction at all".

  Lásd jQuery, azt szokták már szeretni a programozók mert az értelmes API-t ad.
  És miért nem adnak a böngészők hasonló API-t? Lehet, első körben ezen kéne dolgozni, nevetséges, hogy mennyire rá vannak szorulva a javascript fejlesztők a 3rd party könyvtárakra.

• #11 emvy félisten julius666 #10

  Új Válasz 2012-02-20 18:49:25 #11

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz julius666 #10 üzenetére

  Nem webbel foglalkozom, de a node.js az egy vicc, az utobbi idok egyik legnagyobb szemfenyvesztese.

  > Házi ökörködéshez lehet jó, éles projekthez én biztosan nem használnám.
  Azert a GWT-t hasznaljak production kornyezetben is.

  Szoval en nem a Darts mellett kardoskodtam, hanem annyit mondtam, hogy a 'kozos' szabvanyfejlesztes altalaban semmit se er.

Új hozzászólás Aktív témák