HTML5 platform fejlesztése javascripttel
2011-11-25T21:59:00+01:00
2011-12-04T22:53:37+01:00
2022-07-19T05:02:55+02:00
  • már én is kíváncsi lettem

    Mutasd a teljes hozzászólást!
  • A Sencha létezéséről tudtam, de nem kezdtem el még komolyabban nézegetni. (De nagyon elől van a TODO listámon, mert azt már láttam, hogy a Javascriptes komponensrendszer területen ők nagyon jelentős szereplők.)
    Mutasd a teljes hozzászólást!
  • Nem tudom, használtad-e már az extjs-t, sencha touch-ot, de az extjs4 és sencha touch2-ben megvalósított class system, és mvc módszer elég ütős:

    http://docs.sencha.com/ext-js/4-0/#!/guide/class_system

    Innentől: 1.2) The New Way


    http://docs.sencha.com/ext-js/4-0/#!/guide/application_architecture

    Érdemes megkukkantani.
    Mutasd a teljes hozzászólást!
  • :) Hát nem is tudom miről írjak. Talán az event kezelésről nem írtam még. Itt jól látszik, hogy ugyan a rendszerben sok helyen lászanak a Java-s gyökereim, azért ahol érdemes, ott megpróbálom a Javascript nagyon erős dinamizmusát az előnyére használni. Itt szvsz. sikerült egy olyan event API-t készíteni, amelyhez jóval kevesebb boilerplate-el lehet programozni mint egy tipikus Java-s API-hoz.

    A Component osztály (így minden komponens) is az EventTarget osztályból származik. Az EvenTarget forrása mindent elmond:


    /* * class EventTarget * * Represents anything on which an event can be fired. * Listener functions can be registered to listen on those events. */ CCUI.EventTarget = function() { this._listeners = {}; // map of arrays } // Adds a listener function 'listener' which will be called when an event with 'event.type === eventType' is fired. CCUI.EventTarget.prototype.addListener = function (/*string*/ eventType, /*function(event)*/ listener) { var lArr = this._listeners[eventType]; if(!lArr) { lArr = []; this._listeners[eventType] = lArr; } lArr.push(listener); } // Removes the listener function 'listener' from listening to events with 'event.type === eventType'. CCUI.EventTarget.prototype.removeListener = function (/*string*/ eventType, /*function(event)*/ listener) { var lArr = this._listeners[eventType]; if(lArr) { CCUI.remove(lArr, listener); } } // Fires the event 'event'. // Two things happen during fireing the event: // - The 'handler' method is called on this EventTarget if defined. // The naming convention is the following: For an event with event type 'xyz' the following method is called: onXyz(event). // - The added listener functions are called. // 'event' can be any object with a string member named 'type'. CCUI.EventTarget.prototype.fire = function (/*{type: string}*/ event) { event.target = this; var handlerMethodName = 'on' + CCUI.firstCharUp(event.type); if(this[handlerMethodName]) { this[handlerMethodName](event); } var lArr = this._listeners[event.type]; var length, i; if(lArr) { length = lArr.length; for(i=0; i<length; i++) { (lArr[i])(event); } } }

    A lényeg az, hogy egy EventTarget-en fire-olhatunk egy eventet. Bármi eventnek tekinthető, aminek van string típusú 'type' nevű memberje. Listenereket lehet feliratkoztatni egy adott EventTarget-re adott eventype-ra (pl. mousemove, mouseout, mouseclick, stb...). De a listenerek mellett van más mechanizmus is: pl. 'kutya' type-ú event esetén ha az adott EventTarget-nek van 'onKutya' nevű metódusa (convention over configuration), akkor az automatikusan meghívódik (vagyis nem kell olyan más rendszerekben gyakori boilerplate-t írni, hogy az EventTarget saját magában fire-olódó eventre listeneljen valamely metódusával. Tehát a komponensekben az onMouseover, onClick, stb... metódusok mágikusan meghívódnak csak azért, mert valahol fire-olódtak a megfelelő type-al ellátott eventek.).

    (Amúgy pár nap, és tényleg publikálom a teljes cuccot.)
    Mutasd a teljes hozzászólást!
  • A .net jó alternatíva lehet, ha van windowsos szerver. Azt lehet programozni c#-ben és gyors vele a fejlesztés. A böngészőket is egész jól kezeli. Bár az előre legyártott megoldások az egyediség és a sebesség rovására mennek.

    egyébként a javascripttel nincs különösebb probléma szerintem, egy okosabb könyvtárral (pl) elég sok dolgot meg lehet benne valósítani. Amit meg nem (pl .komolyabb autentikáció cross-browser és biztonsággal) az meg nem is biztos, hogy kliens oldalra való. inkább a html-lel kell kezdeni valamit, mert azt anno arra találták ki, hogy az 56kbps kapcsolaton is pikk-pakk letöltse az userhez amire kíváncsi. csak ma már a 30-40 megabites kapcsolatokon inkább arra lenne igény, hogy minél több funkció legyen elérhető a programozóknak (pl. hardveres gyorsítás kihasználása kliens oldalon) és ne úgy kelljen összetákolni az oldalt logikátlan css megoldásokkal (pl. text-align ie-ben) és lassú js kódokkal. flashről nem is beszélve
    Mutasd a teljes hozzászólást!
  • akkor legalább valami infó morzsát kérünk :)
    Mutasd a teljes hozzászólást!
  • Abszolút alábecsültem a dokumentálásra/websitekészítésre szánt időt. Vannak a rendszernek olyan részei, amelyet tovább tart dokumentálni, mint tartott megírni. Már nem merek igérni konkrét határidőt, de pár nap kérdése, és készen leszek.
    Mutasd a teljes hozzászólást!
  • csütörtök van
    Mutasd a teljes hozzászólást!
  • Egyébként egy érdekesség:

    Javascriptben nincsenek még opcionális típusannotációk sem. Nincs private keyword, nincs abstract keyword, nincsenek default paraméterek, stb...

    Én azt a startégiát követem, hogy fent említett dolgokat bizony elnevezési konvenciókkal jelzem (privát metódus underscore-al kezdődik) és kommentben beírom (típusannotációk), ahol szükségét érzem.

    Ok, nincs compiler ellenőrzés, de a legfontosabbat viszont megkapom így: számomra és a libem felhasználói számára átlátható a kód.

    Előnye is van:

    1. élvezem a dinamizmus előnyeit, kommentjeimmel csak annyira statikusítom a dolgokat, amennyire szükségét érzem.
    2. A típusannotációimnál annyira lehetek kreatív, amennyire csak akarok. Jelenleg olyan típusannotációim vannak, amelyek messze túlmutathatnak egy Java-s típusannotáción. Pl. lazán olvasható ilyen property deklaráció a doksimban:

    (function(Component) or {style: function(Component)}) stylesheet

    Vagyis a stylesheet az egy komponenset átvevő függvény vagy pedig egy ojjektum mely rendelkezik egy style nevű metódussal, amely komponenst vesz át.

    Másik:


    {x: num, y: num} translateRootCoords(num rootX, num rootY)

    Ez azt modja, hogy az adott metódus olyan ojjektumot ad vissza, aminek van szám típusú x és y memberje.

    Persze legtöbbször a típusannotációim simán class-ok vagy array of class-ok.

    Én így rendelkeztem be túlélésre Javascriptben.
    Mutasd a teljes hozzászólást!
  • Köszi!
    Mutasd a teljes hozzászólást!
  • sok sikert, csak így tovább
    Mutasd a teljes hozzászólást!
  • Jövő csütörtökön kijön a 0.1-es verzió. 6500 sor nagyon tömény kód. Már 2 hete szinte csak dokumentálok, meglepően nagy munka igényesen dokumentálni egy libet.
    A 0.1-es verzió tartalmazni fogja az alaprendszert: dinamikus stylesheetek, dinamikus layout, optimalizált painting (dirty rectangles, area-caching, smooth scrolling).
    Ezen kívül a legproblémásabb komponensek vannak benne (itt ott egy-két feature hiánnyal): Window, ScrollPanel, TexEditor, StaticDoc (read only rich text), Button.

    A 0.1-es demóval már egész részletes dokumentáció is jön, szóval lehet majd mit olvasgatni.

    Ezen kívül még hátra lesz még jópár egyéb komponens, néhány magasabb szintű feature (data binding, ilyesmik), és végül egy UI editor. Ez igazán ütőssé reálisan csak 2012 közepén válhat, vagy még később.
    Mutasd a teljes hozzászólást!
  • grat

    hogy halad? Bele lehet lesni?
    Mutasd a teljes hozzászólást!
  • Én nem a Dartról írtam. Sting linkecskéje 'elmagyaráztam' labellel elvezet az én topikomhoz, amiből kiderül, hogy min vitáztunk Stinggel. (Egy HTML5 Canvasra rajzolt komponensalapú UI rendszert írok pure Javascriptben kb fél éve szabadidőmben.)
    Mutasd a teljes hozzászólást!
  • mondj egy valamit, amit érdemesebb Dartban megírni
    Mutasd a teljes hozzászólást!
  • Ne kezdjük el ezt most, de annyira ideillik Paul Graham egy írása, hogy kénytelen vagyok bepastelni:


    Don't be discouraged if what you produce initially is something other people dismiss as a toy. In fact, that's a good sign. That's probably why everyone else has been overlooking the idea. The first microcomputers were dismissed as toys. And the first planes, and the first cars. At this point, when someone comes to us with something that users like but that we could envision forum trolls dismissing as a toy, it makes us especially likely to invest.


    Mindenestere nem a fórumon való vitázásra, hanem a fejlesztésre optimailizálom a szűkös erőforrásaimat/szabadidőmet.

    Jövő csütörtökön végre jön a 0.1-es demó (már kizárólag a website összedobásával foglalkozom), a sebessége elég kényelmetlen lesz számodra.:) Aztán, hogy lesz-e ennek nagyobb sikere vagy nem, az svsz. inkább 2012 második felében derül ki, hiszen sok még a teendő. Mindenesetre egy technológiai startup túlélési esélye statisztikailag 10% alatt van a világban. Szóval aki nagyhangon 'elmagyarázza', hogy valami miért nem lesz sikeres, azt 'Captain Obvious'-nak becézik ha a startup becsődöl, ha meg véletlen sikeres lesz, akkor meg azért elég nagy égés. Ezért praktikus okokból is érdemes az embernek nem túl arrogánsnak lennie.
    Mutasd a teljes hozzászólást!
  • Gondolkodj már el, (ne vagdalkózz egyfolytában).

    Érvelek. Attól, hogy te nem tudsz ellenérvelni az én érvelésem még nem lesz "vagdalózás".

    - A Chrome néhány fontos és ismert alkalmazásnál (akár a Google által tulajdonolt vagy presszionáltak) KOMOLY sebességi előnyt produkál.

    Egyrészt nem produkál, mert hogy egy átlagos weboldal - ha nem rohangálnak rajta rosszul megírt Flash animációk - jelenleg is kb. 1%-os processzorterhelést okoz egy mai átlaggépen; mármint a weblap működtetéséhez szükséges JS-kódok ennyi procit esznek. Az, hogy a DART segítségével esetleg csak 0.5 vagy 0.1%-os terhelést fog okozni, nem szempont - emiatt senki nem fogja utóbbit választani, pláne nem fogja meglévő megoldásait rá átváltani, átállítani.

    Másrészt, ha esetleg tényleg olyan komoly lenne a sebességkülönbség az úgymond natív DART és a fallback JS-kód között, akkor meg a kompatibilitási része bukik meg a DART-nak. Ti. hogy ha használhatatlanul lassú a JS-változat, akkor hiába is képes az formálisan futni a régi böngészőkben, mert ugye használhatatlanul lassú lesz benne. Innentől kezdve meg akkor ez a DART nem jó eszköz annak biztosítására, hogy a legacy böngészőkben is elérhető legyenek (használható módon és sebességgel) a benne megírt funkciók, hanem akkor erre más megoldást kell keresni.

    Harmadrészt abból, hogy a Google beteszi néhány alkalmazásába, nem következik az, hogy bárki más bármi másra fel fogja használni. Márpedig ugye itt erről beszélgetünk, hogy ti. mire fog menni úgy általában ez a DART.

    - Ingyen adja bárkinek a technologiát, aki a böngészőjébe beteszi.

    A JavaScript is tök ingyen van. Sőt, az összes többi elbukott Google-technológiai is tök ingyen volt. Mégse használja őket senki.

    - Ezután majd a felhasználók dobják azokat a böngészőket, amelyeknél a levelező listákon rendre azt a választ kapják: 'csak az IE esetén használhatatlan az a cucc, egyébként egy álom a használata, sajnálom, hogy kimaradsz belőle'.

    Már egy évtizede vannak ilyen üzenetek itt-ott (arról most itt ne beszéljünk, hogy mennyire az illető oldatulajdonos, webfejlesztő dilettantizmusáról, mint sem tényleges technikai szükségszerűségről árulkodnak ezek). Ehhez képest az IE-ket még mindig kétszer többen használják, mint az utána következő két legnépszerűbb böngészőt együtt. Szóval ez se úgy működik, ahogy Móricka gondolja...

    Ehhez meg csak annyit kell elérnie, hogy legyenek dart-os honlapok. Mivel a fejlesztők nemhogy vesztenek, de valóban nyernek a Dartra átállással

    Idáig még egy példát nem mondtál arra, hogy miben nyernének. Ellenben én elmondtam, hogy mit vesztenének. Pl. rengeteg fejlesztőeszközt, komponenskönyvtárat, stb. - mert hogy a DART támogatottsága jelenleg nulla. Ezen kívül tesztelhetnék a DART programjaikat a DART-ot futtatni képes és a DART-ot futtatni nem képes böngészőkben/módokban is, megduplázva a munkájukat.

    Persze már csak az kell, hogy ez ne egy legyen a Google-s fellángolások közül, hanem építsék ki a technologiát és lépésről lépésre, de folyamatosan nyomják azt. De főként adjanak többletet (pl. egy jó keretrendszert) a dart mellé.

    Bármit csinál is a Google, egyszerűen nem tud versenyképes lenni a meglévő JavaScript-ekoszisztémával az utóbbira épülő, gigantikus már meglévő kódbázis mérete és a platform támogatottsága miatt. Ti. hogy minden webes fejlesztőeszköz képes ha mással nem is, legalább szintaxis-kiemeléssel támogatni a JS-fejlesztést - míg a DART esetében még ez sincs meg, maximum elenyésző részükbe kerül bele, most és ezután. Akkor a fejlesztői tudásbázisról még nem is beszéltem (ti. hogy hány fejlesztő lenne képes DART-ban és hány JS-ben megoldani egy adott problémát).

    ...és fontos. A Dart nem a honlapba ágyazott 100 JS kódsor (nagyobbrészt így is jQuery) kiváltására hivatott. Inkább a nagy osztálykönytárak építésében kap szerepet.

    Akkor erre még százszor igazabbak a fentiek, és az, hogy először ezeket a nagy alap-osztálykönyvtárakat - ill. ezekkel ekvivalens megoldásokat - újra kellene írni DART-ban ahhoz, hogy versenyképes legyen a JS-sel. Azaz, hogy DART-ban ne kelljen alacsonyabbról elindulni egy program írásakor, mint ha ugyanazt JS-ben (vagy más JS-re fordító platformon) tennéd. Mert egy 100 soros programnál nem számít, hogy a kód 90 vagy csak 10%-át kell neked megírnod - de egy 1 millió soros programnál már nagyon nem mindegy. Azaz, minél nagyobb egy projekt, annál fontosabb, hogy már bejáratott, elterjedt, népszerű technológiákra épüljön, már csak pusztán a kódolással közvetlenül összefüggő költségvonzatok miatt is.
    Mutasd a teljes hozzászólást!
  • "alapvető érdeke, hogy a JavaScript versenyképes maradjon"


    Na én befejezem.

    A Dart is a JS versenyképesség növeléséről szól!
    A natív bővítésről leszállt, mert nem egyértelmű a sikere. Az hogy egy cégnek zsákutcái és későbbi üzleti megfontolásai vannak, nem gond (talán csak nem kellene idő előtt kikürtölnie - de ez már egy ilyen világ)
    Ezzel szemben a Dart egyszerre Javascript és technologia váltás.
    Ha nem tolja el a Google, ez potenciálisan lehet paradigma váltás laza-elnyújtott váltással.

    A JS egy vicc. Zsákutca. Ezen nem kellene háborogni, tény.
    Egyszerűen nem arra találták ki, amire ma használni akarjuk.
    Ugyanakkor a JS megkerülhetetlen alaptechnologia.
    A Google talált egy módszert, amivel fájdalom mentesen lehet elszakadni a JS betegségeitől. Úgy lehet bevezetni egy új technologiát, ami lecserélheti a JS-et, hogy nem kell erőszakkal leváltani, mindent lecserélni.
    Úgy lehet egy Java/C# motor alternatívát építeni, hogy a továbbra is natív internet a technologia, vagyis a Google terepén marad a labda, tehát anyagilag érdekelt.
    Mutasd a teljes hozzászólást!
  • "viszont szenvedhetsz egy új nyelv megtanulásával, parancssorból fordíthatod (mert annál magasabb szintű fejlesztőeszköz nincs hozzá)"


    Azért ez így, ebben a formában...

    http://www.dartlang.org/docs/getting-started/editor/index-win.html

    Csak egy-két example futtatásig jutottam (hogy tudjam már miről is beszélek). Ez alapján nem akkora 'kínzás' ez,

    Ha fejlesztik és bővítik, akkor jó lehet ez.

    Mondjuk ha már hipeolják, akkor fontos lenne a bytekódra fordítás és a debug beépítése.
    Na azért néhány hónap alatt kiderül: ha hónapról hónapra megjelennek új dolgok a dart editorban, akkor OK, ha így marad, akkor profi munkára ez kevés.
    Mutasd a teljes hozzászólást!
  • "A Google nem kényszeríthet semmit rá semmit azokra, amik felett nincs közvetlen anyagi befolyása"


    Gondolkodj már el, (ne vagdalkózz egyfolytában).
    Már hogy a francba ne tudná rákényszeríteni. Leírtam. [csakhát közvevetten, a felhasználók felhasználásával]

    - A Chromba beteszi.
    - A Chrome néhány fontos és ismert alkalmazásnál (akár a Google által tulajdonolt vagy presszionáltak) KOMOLY sebességi előnyt produkál.
    - Ingyen adja bárkinek a technologiát, aki a böngészőjébe beteszi.
    - Ezután majd a felhasználók dobják azokat a böngészőket, amelyeknél a levelező listákon rendre azt a választ kapják: 'csak az IE esetén használhatatlan az a cucc, egyébként egy álom a használata, sajnálom, hogy kimaradsz belőle'.

    Ehhez meg csak annyit kell elérnie, hogy legyenek dart-os honlapok.
    Mivel a fejlesztők nemhogy vesztenek, de valóban nyernek a Dartra átállással, így nem kérdéses.
    Persze már csak az kell, hogy ez ne egy legyen a Google-s fellángolások közül, hanem építsék ki a technologiát és lépésről lépésre, de folyamatosan nyomják azt. De főként adjanak többletet (pl. egy jó keretrendszert) a dart mellé.

    ...és fontos. A Dart nem a honlapba ágyazott 100 JS kódsor (nagyobbrészt így is jQuery) kiváltására hivatott.
    Inkább a nagy osztálykönytárak építésében kap szerepet.
    Mutasd a teljes hozzászólást!
  • Na, de akkor most döntsd el, hogy fényes jövőt jósolsz a DART-nak vagy sem! Mert egyik hozzászólásban azt mondod, hogy amellett szól minden, hogy a DART leváltsa a JavaScript-et - aztán meg jössz azzal, hogy de hát a Google-nak alapvető érdeke, hogy a JavaScript versenyképes maradjon; amely esetben nyilván semmi ok nem lesz a leváltására. Mert normális ember csak akkor vált le valami bejáratottat, ha az a továbbiakban már nem versenyképes, nem adekvát megoldás a felmerülő problémák megoldására.

    Egyébként meg a JavaScript kapcsán sem megkerülhetetlen a Google, hiszen nem ő találta ki és nem ő tartja irányítása alatt ezt a platformot - de még csak bővítéseket sem javasolt hozzá, szemben pl. a MS-tal. Tehát ennek kapcsán sem igazán értem mit akartál mondani.
    Mutasd a teljes hozzászólást!
  • "Ezzel most épp' azt igazoltad, hogy a JavaScript leváltása mellett semmilyen érv nem szól, még a Google részéről sem."


    Hát ha nem is akarod érteni

    Pont hogy az az alapvető érdeke a Googlinak, hogy a Javascript (vagy bármi még hatékonyabb, de továbbra is platformfüggetlen pure netes eszköz) kellően versenyképes maradjon, mert ha nem hoz eleget, akkor a piac megszüli a maga párhuzamos technologiáját, amiben már nem biztos hogy olyan megkerülhetetlen a Google.

    Mutasd a teljes hozzászólást!
  • Ahogy én látom, a Googlet nemigen érdekli melyik technologia a nyerő, csak hogy hagyományos netes legyen az.
    Ilyen szempontból még a saját technologia előre nyomása sem érdekli. Akárkié jó, ha a Java/.Net/erőskliens stb, (pl. Silverlight/JavaFX) nem kap életteret.

    Ezzel most épp' azt igazoltad, hogy a JavaScript leváltása mellett semmilyen érv nem szól, még a Google részéről sem. Hiszen a JS nem Java/.NET/Silverlight/JavaFX. És bár igaz, hogy nem sajátja - de szerinted ez se probléma.

    Rákényszeríthet egy jobb technologiát a többiekre, amiben kulcsszerepe van.

    Dehogy kényszeríthet. A Google nem kényszeríthet semmit rá semmit azokra, amik felett nincs közvetlen anyagi befolyása (pl. a futtatóoldalon se az IE-re, se a Safari-ra, de a felhasználókra és a fejlesztőkre sem) - márpedig jelenleg ilyen termékek, felhasználók és cégek (pl. Facebook) uralják a webet. Utóbbiakat csak a webfejlesztők és a felhasználók kényszeríthetnék rá akármire - a felhasználókat és a fejlesztőket viszont nem tudja a Google kényszeríteni. Innentől kezdve bukott az egész elmélet, ami szerint a Google - közvetve vagy közvetlenül - bármit rákényszeríthetne "a többiekre".

    Hát pont ez a Dart.

    A DART nem ez. A DART azért tud JavaScript-re is fordulni eleve, hogy - elméletileg - megélhessen a webnek azon a részén is, ahol natívan nem támogatják. De ahhoz, hogy JavaScript-be keresztfordítsunk és futtassunk programokat, nem kell DART, hiszen ezt meglévő, sokkal régibb, jobban befutott és magasabb szintű nyelvekből is megoldhatjuk. Ruby-ból, Python-ból, Java-ból, Scala-ból, de még C#-ból és .NET-ből is (lásd JSIL). A JavaScript-re fordított DART-tal ezekhez képest nem nyerünk semmit, max. vesztünk - akkor meg minek dolgoznánk vele?

    De a Dart annyiban több, hogy a dupla target és a bytekód (kezdetben csak Chromra) még több töbletet ad.

    Ez nem dupla target, hanem redundáns target. Hiszen nem két különböző platformon fut általa, hanem ugyanazon az egyen (a weben, a böngészőkben), csak két különböző módon is. Többletnek pedig ez így nem többlet, csak munkában, karbantartásban, stb. Mert pl. két platformon kell tesztelni, két példányban kell tudni feltölteni a szerverre, onnan kiszolgálni, stb. Amiért cserébe igazából semmi effektív előnyt nem kínál az esetek 99.9%-ában.

    "a mostani is bőven alkalmas a weben reálisan felmerülő igények 99%-ának"
    Hát azért a HTML5/Canvas kiterjeszti a 'nem szokványos' bővítés/technologia készítők fantáziáját.

    Köszi, hogy megerősited amit írtam, hogy ti. a mostani webes technológiák is bőven alkalmasak a weben reálisan felmerülő igények 99%-ának adekvát kielégítésére.

    Itt a listán is van valaki, aki komplett elemgyüjteményt épít canvason rajzolva. Egyre összetettebb dolgok várhatóak a JS-re építve, ami felveti a tervezés, biztonság és sebesség problémákat.

    Ez a lehető legrosszabb példa volt, amit csak mondhattál, hiszen erről már elmagyaráztam, hogy ez miért fából vaskarika, és miért rossz koncepció, úgy ahogy van.

    Erre, mint releváns példára majd akkor térjünk vissza, ha a weben mindenhol elkezdik hype-olni ezt a keretrendszert, mint az új megváltót, és a Google meg a MS elkezdik hozzáigazítani a JS-motorjaikat, hogy minél jobban fussanak vele.

    Az meg hogy jelenleg a Chrome sem tudja a Dart bytekódot futtatni nem kérdés.

    Persze, hogy nem. Ki a fenét érdekel az, hogy nem fut sehol a kódod, ha viszont szenvedhetsz egy új nyelv megtanulásával, parancssorból fordíthatod (mert annál magasabb szintű fejlesztőeszköz nincs hozzá), és írhatsz benne mindent nulláról (mert még egy közepes komponenskönyvtárt sem írt benne senki)? Vágyhat ennél többre egy programozó, aki haladni és akar a munkájával és keresni is akar vele, nem csak az idejét vesztegetni a legújabb mesterségesen hype-olni próbált divathóborttal? Én csak egyetérteni tudok veled.

    Már maga a környezet előnye is indokolhatja az elterjedést (lásd a ScriptSharp igényt), ráadásul egy nagyhatalmú, tőkeerős cég igéri mellé a bytekódos extrát a jövőbe.

    Ugyanez a cég nyomatja már mióta is az LLVM-et és a Native Client-et is, szintén bájtkód alapon? És mire is jutott vele? És a már befutott bájtkód-alapú platformok (.NET, Java) nem szintén totális bukásra állnak a dinamikus technológiákkal szemben (mint pl. a JS) a weben? Akkor miről is beszélünk?
    Mutasd a teljes hozzászólást!
  • A gugli lényegében tényleg bármit meg tud csinálni, ha akar - max. abban kell óvatosnak lennie hogy mit akar. Pl. ha elhintik hogy azok a weblapok kerülnek előre a gugli keresőjében akik fenn vannak a google+-on is, pár hét alatt drasztikusan meg tudják növelni a G+ forgalmát. Más kérdés, hogy ezzel könnyen a nyakukba hozhatnak egy antitröszt pert.

    Ezek szerint megint két mondaton belül cáfoltad saját magad.

    Az már egy másik kérdés, hogy a gugli erősen próbálja befolyásolni a webes technológiákat - és nem is kevés sikerrel. Elég arra a fegyvertényre gondolni, hogy a mozilla megfinanszírozásának segítségével sikeresen megtörte a pár éve még egyeduralkodó IE dominanciáját

    A Firefox jóval azelőtt kezdte megtörni az IE dominanciáját, hogy a Google erőből elkezdte volna finanszírozni. Ráadásul az utóbbi időben a Firefox zuhan, mint egy kőbalta, annak ellenére, hogy a Google - még - finanszírozza. Szóval a jelek szerint a Google-finanszírozás és az IE-dominancia-megtörés között még csak korreláció sem figyelhető meg, nem ám, hogy ok-okozati viszont.

    Ráadásul semmifelé paradigmaváltás nem történt a Firefox által és miatt. A HTML5 kora is csak az IE7/8/9 révén jött el, nem a Firefox-nak köszönhetően, ami igazából csak kullog a konkurencia (főleg az IE és a Chrome) után, gyakorlatilag minden téren.

    A ChromeOS pedig ugyan (még) nem átütő siker, de Pl. az Android már igencsak az.

    Az Androidnak semmi köze a webhez, tehát teljesen irreleváns. Ráadásul azért sikeres, mert egy fizetős piacra tört be ingyenesen - az eleve ingyenesen használható internetes protokollok piacán azonban éppen ennél fogva hasonló stratégiával nem lehet hódítani.

    És szvsz hosszú távon a Chrome OS is az lesz.

    Akkor nagyon meglepetésbefutó lesz, mert jelenleg éppen úgy haldoklik, mint az összes egyéb, korábban felsorolt reform-projekt a Google-tól, és már a hype is teljesen kezd leülni körülötte.
    Mutasd a teljes hozzászólást!
  • "a DART kapcsán hány különböző, azzal részben konkuráló "vasat" tart párhuzamosan a tűzben a Google"

    Ahogy én látom, a Googlet nemigen érdekli melyik technologia a nyerő, csak hogy hagyományos netes legyen az.
    Ilyen szempontból még a saját technologia előre nyomása sem érdekli. Akárkié jó, ha a Java/.Net/erőskliens stb, (pl. Silverlight/JavaFX) nem kap életteret.

    Persze szeret saját technologiát tolni, hiszen az előnyt jelent. Nem véletlen, hogy a MS kitalálta a C#-ot.
    A Chrome azért bejött neki, és ezt mint trólai lovat használva nyomja be most a dart-ot. Akár be is jöhet.
    Hiszen csak többletet tesz a Chrome-ban, amit a többiek vagy követnek, vagy nem.
    Ha sikerül dart fejlesztőket toboroznia, akkor bejöhet. Rákényszeríthet egy jobb technologiát a többiekre, amiben kulcsszerepe van.

    "a JavaScript nyelv mennyire furcsa vagy alacsonyszintű, önmagában érdektelen.... jóval magasabb szintű paradigmákat megvalósító nyelveken írjuk a programokat,... generáltatjuk a ténylegesen futó... végül JavaScript-té forduló, JavaScript motoron futó kódot."

    Hát pont ez a Dart. Egy jobb nyelv ami két targetbe fordul. Bytekódot és JS forrást IS generál, minden böngésző azt használja, mait tud.
    Ha tud bytekódot akkor gyorsabb és biztonságosabb (fordítási időben ellenőrzött és kompaktabb, "összeszedettebb" (összecsomagoltabb) a kód).

    Én csak a ScriptSharp-ot ismerem még hasonló, JS-re fordító komolyabb eszközként. Kérdés a MS mennyire fogja felkarolni, hoiszen ebben is van potenciál.
    De a Dart annyiban több, hogy a dupla target és a bytekód (kezdetben csak Chromra) még több töbletet ad.

    "a mostani is bőven alkalmas a weben reálisan felmerülő igények 99%-ának"

    Hát azért a HTML5/Canvas kiterjeszti a 'nem szokványos' bővítés/technologia készítők fantáziáját.
    Itt a listán is van valaki, aki komplett elemgyüjteményt épít canvason rajzolva. Egyre összetettebb dolgok várhatóak a JS-re építve, ami felveti a tervezés, biztonság és sebesség problémákat.

    Az meg hogy jelenleg a Chrome sem tudja a Dart bytekódot futtatni nem kérdés. Először a Google inkább Dart csapatot akar toborozni.
    Már maga a környezet előnye is indokolhatja az elterjedést (lásd a ScriptSharp igényt), ráadásul egy nagyhatalmú, tőkeerős cég igéri mellé a bytekódos extrát a jövőbe.
    Mutasd a teljes hozzászólást!
  • Mostanában egyre több vállalati project ott köt ki, hogy cégen belül is a legkisebb közös nevező a böngésző, egy ott futó program kliens részét pedig alapvetően JS-ben lehet fejleszteni. Főleg olyan helyeken előnyös, ahol a gépek fele mac, a fele pc és a fejlesztők egy része meg linux alatt dolgozik. Gondolom nagyobb cégeknél ez elég általános felállás. Aztán jön a menedzsment, hogy az iPad-ján is szeretné látni az aktuális eredményeket. Cégen belül ráadásul még csak az sem követelmény, hogy IE-n is fusson a program,ami nagyban egyszerűsíti a folyamatot.

    Az tuti, hogy egy jól kialakított HTML5/JS platform elég erős alapja lehet minden ilyen irányú fejlesztésnek. A csapatmunkában fejlesztett JS programoknál viszont valószínűleg komoly hátrány lehet a típusmentesség, egyéni fejlesztések esetében pedig egyén függő. Egyszerűbb feladatoknál (1-2 hét fejleszetés), se az OOP-t se a típusok használatát nem látom feltétlenül szükségesnek.

    Amit inkább veszélyesnek látok az a sok js library összeakadása. Illetve a HTML box modeljének a sokszor illogikus megoldásai.
    Az olyan fontos részfeladatok kaotikus megvalósítása, mint amilyen a contenteditable, ami önmagában az egyik leghasznosabb elképzelés, ami rögvest csődöt mond, amint drag-and-drop-al egy fél weboldalt berángatunk egy ilyen mezőbe. Ezt az esetet minden böngésző más módon kezeli, és elég sok fejlesztési idő kell, hogy egységes megoldást találjunk rá. Miközben még az egész HTML5 változóban van.

    Mutasd a teljes hozzászólást!
  • A gugli lényegében tényleg bármit meg tud csinálni, ha akar - max. abban kell óvatosnak lennie hogy mit akar. Pl. ha elhintik hogy azok a weblapok kerülnek előre a gugli keresőjében akik fenn vannak a google+-on is, pár hét alatt drasztikusan meg tudják növelni a G+ forgalmát. Más kérdés, hogy ezzel könnyen a nyakukba hozhatnak egy antitröszt pert.

    Az már egy másik kérdés, hogy a gugli erősen próbálja befolyásolni a webes technológiákat - és nem is kevés sikerrel. Elég arra a fegyvertényre gondolni, hogy a mozilla megfinanszírozásának segítségével sikeresen megtörte a pár éve még egyeduralkodó IE dominanciáját - majd a mozilla finanszírozásának megszüntetésével szépen megszerzi majd a vezető pozíciót a böngészőpiacon. A ChromeOS pedig ugyan (még) nem átütő siker, de Pl. az Android már igencsak az. És szvsz hosszú távon a Chrome OS is az lesz.
    Mutasd a teljes hozzászólást!
  • A Google elég erős ahhoz, hogy rákényszerítse az akaratát a többiekre, ha jól fog hozzá.

    Na, persze. Jól láttuk ezt a Wave, Buzz, a Google+, a ChromeOS, a Chromebook kapcsán is. De mondhattam volna a WebP-t vagy a WebM-t, amiket bár elvileg a böngészők egy része támogatja, de ennek ellenére is totális bukások, senki nem használja őket a valós életben, a kirakat-projekteken kívül. A SPDY protokoll szintén már hány éves, de még nincs stabil böngésző ami támogatná, és ha lesz, akkor is vélhetően kb. hasonló arányban és módon fog felhasználásra kerülni, mint a fentiek.

    Én igazából egyetlen olyan Google projektet, protokollt, specifikációt nem tudok mondani, ami sikeresen váltott volna le ha nem is mindenhol, de legalább jelentős területeken már korábbi szabványokat, paradigmákat - olyan súlyosan "vérző" területeken sem, ahol pusztán technológiai szempontból aztán tényleg minden újítás csak jobb lehet annál, ami van, mert utóbbi mára minden szempontból elavult, ineffektívvé vált. Te tudsz ilyenről?

    Arról már nem is beszélve, hogy konkrétan a DART kapcsán hány különböző, azzal részben konkuráló "vasat" tart párhuzamosan a tűzben a Google, amik mind egymás elől kannibalizálják a potenciális célpiacot. Pl. a folyamatos JavaScript-motor optimalizáció (amit ő indított el anno) is nyilván nem arra ösztözni a fejlesztőket, hogy más technológia után nézzenek, de a HTML5-ös új API-k erőltetett ütemű integrációja (pl. sokszor még azelőtt is, hogy egyáltalán draft állapotba érnének) is nagy mértékben megszünteti az alternatív, új technológiák iránti keresletet, mert eliminálja a szűk funkcionális és teljesítmény-keresztmetszeteket a böngészőben. Akkor meg minek új, ha a mostani is bőven alkalmas a weben reálisan felmerülő igények 99%-ának adekvát kiszolgálására?

    Az meg, hogy maga a JavaScript nyelv mennyire furcsa vagy alacsonyszintű, önmagában érdektelen. A gépi kód is furcsa és alacsony szintű, mégse érdekel ez senkit, mert jóval magasabb szintű paradigmákat megvalósító nyelveken írjuk a programokat, és a géppel generáltatjuk a ténylegesen futó, amúgy alacsony szintű és furcsa műveletek sokaságából álló kódot. Ennek mintájára nyilván semmi akadálya nincs annak, sőt, ma is bevett, hogy így írjuk a végül JavaScript-té forduló, JavaScript motoron futó kódot. Ami megint csak feleslegessé, irrelevánssá teszi utóbbi lecserélését valami magasabb szintű nyelvre, hiszen ilyen felhasználási modellben ezzel nem nyerünk semmit se a kódbiztonság, se a fejlesztési sebesség, se semmi egyéb vonatkozásában. Egyébként ezen a téren is van egy DART-kannibálja a Google-nak a Web Toolkit révén.

    Szóval a Google-nak nem, hogy nincs elég befolyása ahhoz, hogy ráerőltesse mindenkire a saját technológiáit (kivéve akik felett közvetlen anyagi befolyással bír, pl. Mozilla), de mivel azok sok téren nem kiegészítik egymást, hanem egymásnak is konkurensei, ezért - a piac megosztása, fragmentációja révén - valójában egymás ellen dolgoznak, és már csak pusztán ezért is esélytelenül indulnak csatába a bejáratott technológiákkal szemben. Függetlenül attól, hogy egyes megfontolások és vélemények szerint mennyivel "jobbak" azoknál ilyen vagy olyan téren.
    Mutasd a teljes hozzászólást!
  • csakhogy a dart-ot egyelőre még a chrome-ban sem lehet futtatni

    majd meglátjuk mi lesz

    A JS az biztos hogy soha nem fog eltűnni a böngészőkből. Inkább azt kellene fejleszteni, nem pedig újakat létrehozni.
    Mutasd a teljes hozzászólást!
  • "nem értem miért lenne jobb a dart mint a JS"


    Hát ahogy (csak rápillantás alapon) látom ez egy valódi programnyelv kíván lenni.
    Ez már egy jópont.

    Aztán ahogy olvastam, bytekód fordítót akarnak csinálni hozzá.
    A Chrome böngészőbe meg beépítik az interpretert (a javascript interpreter mellé).

    Tagadhatatlanul hatékonyabb a bytekód interpreter: remélem ez eddig nem vita kérdése.

    A gond persze, hogy csak a Chrome böngészőben megy a dart kód... vagyis mégsem, hiszen ha nem Chrome, akkor az azonos funkcionalitású JS fut.

    Mi a jó ebben?

    - Hát a Googlenak jó, az biztos.
    Ha másoknak nem is, de legalább a Chrome használóknak gyorsabban fut a kódja. A többi böngésző gyártó meg dönthet, hogy akarja e beépíteni a bytekód interpretert.
    Ha nem akarja, az ő dolga, legfeljebb a felhasználók elpártolnak a gyorsabb és biztonságosabb Chromhoz.

    - Hát a felhasználóknak jó, mert ha Chromot használ, gyorsabb a honlap futása, ha meg nem Chromot, akkor nem is lát az egészből semmit.

    - A fejlesztőknek is jó, mert hatékonyabb és jobban tesztelt kódot adhatnak ki a kezükből, nagyobb típusbiztonsággal, valamint várhatóan a Google valamiféle sandard könyvtárakat is készít mellé.

    A Google elég erős ahhoz, hogy rákényszerítse az akaratát a többiekre, ha jól fog hozzá.
    Ez meg úgy tűnik nekem, egy működöképes modell...
    Mutasd a teljes hozzászólást!
abcd