Molnár András

Google: JavaScript eszközkészlet fejlesztőknek

Napjainkban több millióan használnak JavaScript-et is használó alkalmazásokat. Ilyen például a Gmail, Google Docs, vagy a Google Maps. Viszont JavaScriptben fejleszteni, debuggolni (rejtett hibákat keresni), és optimalizálni nem könnyű feladat, néha még a tapasztalt fejlesztőknek sem.

A helyzetet tovább bonyolítja, hogy egy adott JavaScript szkript különböző böngészőkön másképp viselkedik, más-más eredményt adva. Jó hír, hogy a Google saját fejlesztőeszközeinek egy részét nyílt forráskódúvá teszi. A Closure Tools néven elérhető eszközkészlet több hasznos programot is tartalmaz, mely nagyban megkönnyítheti a fejlesztést, rövidítheti a fejlesztési időt és növelheti a hatékonyságot.

Az első ilyen eszköz, a Closure Compiler, mely segít a fejlesztőnek optimalizálni a megírt JavaScript kódot a fölösleges kódrészletek eltávolításával. Emellett a szintaxist, változó-hivatkozásokat és a típus-helyességet is ellenőrzi. A Compiler-hez készítettek egy Firebug plugint is (Inspector), amivel az optimalizált kódot egyből a böngészőben nézheti meg a fejlesztő. Egy másik hasznos Firebug kiegészítés a Page Speed, mellyel a szkript sebességét lehet mérni, így több különböző megoldást is összehasonlíthatunk.

Az eszközkészlet része még a Library, melyben rengeteg gyakran használt funkció megvalósítása található, kezdve a magasabb szintű, felhasználói felület elemektől egészen az alacsonyabb szintű DOM eszközökig, szerver kommunikációig, köztük az animációkhoz, adatszerkezetekhez, modulteszteléshez gyakran használt eljárásokkal.

Végül, de nem utolsósorban a Closure Templates egyszerűsíti a dinamikus HTML generálást. Egyszerű szintaktikájával könnyen használható, és az eddig megszokott megoldásokkal ellentétben, ahol egy nagy template-et (sablont, ha úgy tetszik) használt a fejlesztő az egész oldalon, a Closure Template-eknél kisebb komponensekből lehet összeállítani a felhasználói felületet. A Closure Templates JavaScript és Java nyelven is elérhető, így mind szerver, mind pedig kliens oldali fejlesztésekhez elérhető.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • Sanyix #23
    az ami az óra mellett megy az max az updater... megnézel egy oldalt ami javat használ, az sem a zokszigénbül veszi ki a programot, hanem letölti.
  • Sanyix #22
    rolikának nem az kell, ő az os processzeit akarná belőle kilőni ;)
  • johnsmitheger #21
    Simán lehet :) nyomtam is benne egy forgó kockát. Az eredeti feladat az volt, hogy html oldalon ábrázoljunk folyamatokat, de a szuper html-ben ugyen nem lehet meghúzni egy kurv@ ferde vonalat, ezért mozdultam rá az SVG-re. Ott például egy standard sor egy lekerekített sarkú téglalap kipakolása, de nagyon zabázza az erőforrásokat. Teljes oldalt nem kockáztatnék meg vele :) Hamar le is szoktam róla, de máshol biztosan beválik.
  • Praetor #20
    Igen, de ki mondta, hogy nem azt?
    Elvégre az sql egy önálló szerver alkalmazás, és nem feladata kezelni a szerveren futó más processzeket.
  • Robi000001 #19
    Mert a flash oldalakkal nem szórakozik a gép, míg betölti? :)

    Amúgy meg a Java != JavaScript
    A hasonló név ellenére még csak nem is ugyanazok kezdték el a fejlesztést, valamint nem is ugyanazok a csoportok fejlesztgetik tovább.
    (Mellesleg van JS is, amit a microsoft fejlesztett... na az se JavaScript :) )

    Annyi közük van egymáshoz, hogy bizonyos feltételek mellett a Java-t el lehet érni JavaScriptből, a JavaScriptet meg Java-ból. Ja, meg a névrokonság :)

    Ami a JavaScriptet illeti, kicsi a valószínűsége, hogy behalljon, mindig is kell majd egy szkriptnyelv, ami nem a szerveren fut hanem a kliensen. Erre pedig ez a legszabványosabb megoldás jelenleg.

    (Azt tudjátok-e, hogy az SVG grafikában is lehet JavaScript kódot futtatni? :)
  • w32blaster #18
    Sanyix lehet mas hulye de te akkora paraszt vagy, hogy a boltban panaszt teszel mert nincsen fokhagymás túrórudi!
  • passatgt #17
    nálam ha java runtime megy(ott van az óra mellett) és megnézek egy oldalt, amin van java, szüttyögni fog vele, míg betölti
  • Sanyix #16
    de mondok én egy jó kis példát. Tudod hány adatbázislekérdezésre, és objektummá alakítására képes(mindegyik lekérdezés, egy darabb 400 oszlopos sort ad vissza varcharokkal, charokkal, intekkel), egy igen egyszerű java-s program, egy core2 alapú xeon 1 darab magján futva, úgy hogy alig van ramja? percenként ~22000 darabot, úgy hogy egy fos erőforráspazarló ibm által gányolt, közutálatnak örvendő alkalmazásszerveren fut, szintén ibm által gányolt java runtime-al...
    Az tény, hogy a java bizony jóval gyorsabb a kis cégeknél nagyon elterjedten használt php-nál, sőt sok helyen a natív, c-s kód sebességét is közelíti. (ugye nem állt le a fejlődés, évek alatt a java nem csak egyre többet tudott, hanem egyre gyorsabb is lett, a futtatott kódba nyúlás nélkül is).
  • Sanyix #15
    Ha énis kötekedni akarnék, azt mondanám itt csak az adatbázisszerver belső processzeit(lekérdezés, feltöltés, stb) lehet kilőni :)
  • Sanyix #14
    Te is hülye vagy, vagy csak simán nem olvasol?

    Milyen 3-4 mp-ről beszélsz? Nemt tűnt fel még mindig hogy JAVA nem egyenlő a JAVAScripttel? Kb a neve ugyanaz.

    "Napi 2100 oldalletöltést másképp nem tudok generálni, mert akkor 8000mp em csak a script futásokra menne el. és igen ha hiszed ha nem biza a runtime minden java indításnál elszütyköl, de mind1 is."

    Nem érted? Egyszer betölt runtime, utána a ha nem állítod le a gépet, márt többé nem kell.

    Ha hiszed ha nem, a C# (.net) is elszüttyög vagy 5 sec-et első induláskor.

    "de most tényleg sql el kell bezárni a folyamatot? vagy java scriptel fájlba írni? igen mind a kettőre igen a válaszom, mindent érdemes használni amire lehetőséget kaptunk."

    Hát ez nagy hülyeség... milyen jó lenne, ha lehetne használni :D felmész józsi hack oldalára, töröl mindent a vinyóról, és kilövi az os-t, viszlát... hát kva jó lenne tényleg.