Přejít k navigační liště

Zdroják » JavaScript » Proč považuji Google Closure za nejlepší javascriptovou knihovnu

Proč považuji Google Closure za nejlepší javascriptovou knihovnu

Google Closure Library považuji za nejrobustnější, nejrychlejší a nejlépe navrženou javascritovou knihovnu, navíc doplněnou unikátním Google Closure Compilerem. Dlouho a aktivně jsem používal jQuery, Mootools i YUI, mám tedy s čím srovnávat.

jQuery je fajn, v čem je problém?

Knihovna jQuery je fajn, ale sama o sobě toho vlastně moc neumí. Základní DOM manipulace, animace, AJAX, trocha utilit a podpory pro pluginy. Těch existují myriády, valných i jiných kvalit. Každá je psaná trochu jinak, má či nemá dokumentaci, testy se vyskytují spíše sporadicky. Vytvořit webovou aplikaci s jQuery tak znamená strávit nemalou dobu hledáním, výběrem a zkoušením všemožných pluginů a utilit, namátkou:

  • podpora pro jmenné prostory
  • podpora pro třídy a dědičnost
  • dependency management
  • UI framework (např. jQuery UI)
  • komprese skriptů
  • šablonovací systém
  • dokumentační komentáře

Potřebujeme zpravidla vše výše uvedené, a nejen to. Dost možná naše webová aplikace dále vyžaduje JSONP, localStorage, HTML5 history, možná nějaké matematické funkce, wysiwyg editor, vektorovou grafiku. Chceme vyzkoušené, ověřené komponenty, již napsané a otestované někým jiným, protože Don’t repeat yourself < Don’t repeat others < Don’t repeat.

Vsuvka: Machr mezi čtenáři bude jistě oponovat: „Napsal sem mailovýho klienta pouze v jQuery, bez jediný třídy a kousku cizího kódu, holejma rukama.“

To jistě není nemožné. Podobně byl postaven i Bělomořsko-baltský kanál. Podobné hádám, budou ztráty i tragická kvalita výsledného díla.

Během svých školení jsem měl možnost nahlédnout do procesu vývoje webových aplikací v mnoha firmách. Až na výjimky jde vždy o velmi podobný příběh. Začne se s jQuery a pluginy. Nějak se píše dokumentace, ale spíše vůbec. Ještě méně se píší testy. Veškerý kód se nachází v několika souborech pojmenovaných jako ui.js, utils.js, ajax.js. Vše se vymýšlí a dodělává za běhu, každá nová app vypadá jinak než předchozí. Aby bylo jasno, tohle je regulérní cesta. Potíž je v tom, že vytvořit si a udržovat takový funkční ekosystém stojí nemálo času a peněz.

V čem je Google Closure knihovna jiná?

Google Closure knihovna je především rozsáhlá. V Googlu se napsalo hodně javascriptových aplikací, a je velmi pravděpodobné, že právě teď řešíte problém, který v Google vyřešili už v roce 2006. Namátkou: datové struktury, komunikace mezi frames, práce s objekty a polem, manipulace s barvami, šifrování, asynchronní operace, funkcionální programování, UI widgety a mnoho mnoho dalšího.

Google Closure je velmi dobře otestovaná a spolehlivá. Za dva roky v produkci jsem nezaznamenal jedinou breaking change, což se třeba o jQuery říct nedá. Google má totiž integrační testy dobře zautomatizované, výskyt chyby okamžitě vrátí změny v kódu zpět. Snad všechny třídy mají unit testy.

Google Closure je rychlá. Rychlost je pro Google důležitá, a na kódu je to znát. Neexistuje, aby se v knihovně objevila kupříkladu taková zhůvěřilost, jako je Mootools reset. Ani nehrozí, že by nějaká funkcionalita knihovny x-krát za sebou zlepšila svůj výkon o stovky procent, jako se pravidelně děje v jQuery (jak pomalá asi musela být ta fičura na začátku?). Naopak. Předkompilované šablony, minimální množství abstraktních vrstev, žádné element obalující třídy, důraz na šetření pamětí i prostředky. To činí mimo jiné knihovnu jako stvořenou pro vývoj mobilních aplikací.

Google Closure je bezpečná. Šablonovací systém Google Closure Templates, podobně jako Nette Latte, automaticky vše kontextově escapuje, což pomáhá předcházet XSS dírám z nepozornosti. I jiné šablonovací jazyky tak činí, zdaleka ne všechny, obávám se však, že ne s dostatečným důrazem na detail. To samé platí i pro samotný kód knihovny, potenciálně nebezpečný kousek kódu bývá náležitě dokumentován.

Čímž se dostáváme k tomu, jak je Google Closure dokumentována. Příkladně. Komentáře jsou umístěny v kódu, a pomocí tohoto nástroje, se z nich generuje HTML dokumentace. Velmi užitečné jsou dokumentační komentáře. K čemu jsou? Dodávají kódu typovost. Pomocí anotací lze určit, jaké typy mají mít parametry metod, kdo dědí od koho, lze deklarovat viditelnost a mnohé další. Anotace v podstatě dělají z JavaScriptu (volitelně) typový jazyk. To vše zásadně zlepšuje čitelnost kódu, a i jeho kvalitu. Schválně se podívejte na vygenerovanou dokumentaci k třídě CollectableStorage. Na školení jsem dostal podezřívavý dotaz: „No a jak udržujete konzistenci mezi kódem a komentáři? U nás ve firmě s tím máme docela problém.“ Odpovědí je Google Closure Compiler.

Closure Compiler

Google Closure Compiler, jediný nástroj svého druhu, a nesmírně užitečná součást ekosystému Google Closure Tools. Prostřednictvím anotací zajišťuje typovost kódu, kontroluje jeho správnost, upozorňuje na podezřelá místa. Nepoužitý kód se odstraní, a ten, co zbude, maximálně zmenší. Vedlejším efektem je účinná obfuskace.

Odstraňování kódu a nekompromisní minimalizace rovná se velkorysé programování. Co tím myslím? Dám příklad. Asi každý programátor má svou pomocnou třídu pro práci se stringy. Jakým způsobem ji znovu použije v novém projektu? Patrně celou, i když potřebuje jen jednu konkrétní metodu, musí vzít celý soubor. Pokud se rozhodne požadovanou metodu vykopírovat, ztrácí referenci na původní. Udržovat efektivně změny přes více závislostí je pak když ne nemožné, tak PITA.

To vede k tomu, že programátor si dvakrát rozmyslí, než rozšíří svou string utils třídu. Ne tak s Closure. Moje string utils třída může mít 20KB a aplikace ji používající 1KB. Asi nemusím vysvětlovat, jak moc dobré je tohle pro vývoj mobilních aplikací. Teď zrovna píšu mobilní e-shop podobný nativní aplikaci. Už toho umí docela dost, přesto je výsledný kód stále menší než kód samotné jQuery.

Jmenuji se Daniel Steigerwald a pomáhám firmám i jednotlivcům s vývojem webových aplikací. Pokud vás Google Closure zajímá, přijďte na školení, pokud chcete rovnou Closure nasadit (Closure, kompilace, testy, šablony, MVC), napište mi.

Závěr

Closure není všespásná knihovna a i v jQuery lze psát dobré aplikace, jen je to mnohem těžší. Closure není superinovativní, dnes už ne. Je to vyzrálá, léty odzkoušená knihovna. Budoucnost Closure je jmenuje Dart. Dart je logickým důsledkem evoluce Closure Tools, pro nasazení se však ještě nehodí. Co se týká HTML a manipulace s DOM, budoucností se zdá být AngularJS. Podívejte se na dema, a bude vám jasné, proč. Obousměrný databinding, mocné HTML šablony, náznak shadow dom. AngularJS je revoluce, jakou svého času bývalo jQuery. Pokud však potřebuje vyvíjet aplikace teď, zvažte Google Closure. Je to obrovská zásobárna vyzkoušených řešení, doplněná skvělými nástroji, do kódu zatavené penzum moudrosti webového vývoje, destilát design patternů a best practices. V článku sem rozhodně nezmínil vše, uvítám proto v komentářích další otázky.

Předpokládané otázky

Jak dlouho zabere naučit se Closure?

Já byl produktivní zhruba po dvou měsících. S Closure jsem začal hned po jeho zveřejnění, kdy ještě neexistovala pořádná dokumentace. Dnes už mohu doporučit skvělou knihu Closure: The Definitive Guide – Tools for adding power to your JavaScript.

Docela nedávno sem zaváděl Closure (i s Coffeescriptem) do Proactify. Kolega se zorientoval velmi rychle, commitoval už druhý den. Stačilo jen nastavit workflow a vysvětlil, jak Closure funguje.

Existuje pro Closure něco jako http://backbonejs.org?

Ano, PlastronJS nebo este.mvc.

Existuje nějaký boilerplate pro Closure dev stack?

Komentáře

Subscribe
Upozornit na
guest
69 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Hmm

Ja som taky bezny konzument/web­designer a pokial existuju v GC pluginy typu slideshow galeria a podobne a veci ako show/hide alebo slide boxov sa daju robit jednoduchsie nez v jquery, tak som ochotny dat GC sancu a celkom rad na nu prejdem :)

Aleš Roubíček

Nejsou, ale můžete si je robustně napsat s pomocí všech těch úžasných nástrojů.

Hmm

Az na to bude cas, tak mozno niekedy. Ale ked je potrebne spojazdnit stranku do niekolkych dni, tak je lepsie pouzit to co uz raz niekto iny vymyslel.

Tym nezhadzujem Google Closure, ani nic podobne. Len hovorim o svojej situacii.

jozefyna

Takyto zakladny plugin pouzivany takmer na kazdej druhej stranke neexistuje? No to je dost zavazny problem :(

suxi

Len som to zacal citat a autor ma uplne znechutil svojimi blbymi hlaskami… mal by radsej pisat do Brava…

Ondřej Kučera

Daniel Steigerwald je legenda javascriptové komunity v ČR! Jeho projekty jsou naprosto geniální a zůstanete na ně zírat v němém úžasu. Je škoda, že řada některé jeho výtvory vůbec nejsou online!

Můžete být rád, že jste se vůbec dozvěděl, co člověk jeho formátu používá! On vám to vnucovat nebude.

Aleš Roubíček

:-))))

Hmm

:D :)

Martin Hassman

Doufám, že se toho výroku Dan ujme a vloží do referenčních citací 8-)

chleba

Wow … tady je do nej nekdo opravdu zamilovanej :D Daniel je format, souhlas, google closure a google closure compiler sou totalne super veci dalsi souhlas.
Daniel je legenda ? … Ano … taky tak trochu souhlas. Je o nem trochu slyset. Podle me ale Onřej Žára je ta prava ČR legenda uz jen kdyz porovnate aMapy.cz vs. mapy.cz.
Jen se divim ze Daniel nepouziva vlastni framework a propaguje google closure.

Aleš Roubíček

Nepropaguje vlastní famework, protože z toho už vyrostl.

chleba

Propagovat a pouzivat je neco jineho ale souhlasim ze si clovek jenom pridelava praci udrzovat vlastni framework a treba jeste dodrzovat zpetnou kompatibilitu kdyz uz ma hotovy nastroje.

Jurkova

Nerozumiem, preco sa mu tak strasne pchate do riti. Propaguje nieco, co je sice uz dlhsie na verejnosti, ale trosku to zlyhava na absencii zakladnych pluginov, ktore sa pouzivaju takmer vsade.
Mam na vyber dve moznosti – bud pouzijem jquery, ak mam problem, za par sekund najdem riesenie, ak potrebujem plugin, za par sekund najdem riesenie.
A ak pouzijem google closure, vsetko si musim nakodit sam. Sice na uzivatelovej strane trosku setrim browser, ale miniem vela casu a tym padom aj penazi.

Nevidim v tom nejaky zmysel :(

somarik

Ty co davas? Google ma tiez svoj vlastny framework a nemam pocit, ze by este nevyrastol.

Ondřej Kučera

No tak Ondřej Žára je taky třída, to je jasné. Těžko je oba srovnávat.

Když jsem viděl Ondřeje, jak sype program z rukávu rychlostí, kterou běžný člověk ani nestíhá myšlenkově sledovat, tak to byl opravdu životní zážitek!

Je to krása pozorovat, ale na sebevědomí to má neblahé důsledky, protože co on píše víkend, to je moje celoměsíční práce :)

chleba

Souhlas :) Kdyz jsme zacali psat hry tak sem Ondru nesnasel. Ja sem bastlil nejaky kokotinky tamhle tejden a on si napsal brutalni hotovou hru za 2.hodiny cestou vlakem. Co dodat … Ondra :)

blizz

nejake argumenty? skus napisat, ktore hlasky su podla teba blbe a preco

Diskobolos

Asi jsem neco nepochopil…

Aleš Roubíček

Nepochopil jste rozdíl mezi webovou prezentací a webovou aplikací, ale to nechápe většina lidí, co chce zkusit nasadit GC. Pro webové prezentace je GC absolutně nevhodné.

Diskobolos

> „Docela nedávno sem zaváděl Closure (i s Coffeescriptem) do Proactify.“.

Tys to asi nepochopils, co? Nevadí, vysvětlím – byla to ironická narážka na výše uvedenou větu.

Aleš Roubíček

Děkuji za vysvětelní narážky.

Proactify má prezentační web na kterém používá jQuery. Proactify má jednu část aplikace v podobě scriptu, který si vkládají zákazníci do svých stránek, ta je napsaná/píše se v Google Closure.

Diskobolos

Tak ještě jednou. Znám gmail, potud ono mé chápání/nechápání. Ju? Narážel jsem na to, že když už si autor zapropaguje svou práci a školení, tak bych očekával i veřejnou (!!!) ukázku JEHO použití/aplika­ce/kódu.

Aleš Roubíček

Můžete se podívat třeba na Webmium.com, jestli vás to tak láká, ale venku je stejně jen zkompilovaný kód, který vám nic neřekne. A ano, taky je tam i jQuery v prezentační části. Na kterých e-shopech zrovna Proactify běží vám takhle z hlavy neřeknu, možná Dan bude vědět.

Daniel Steigerwald

Z veřejných projektů třeba http://www.webmium.com/, nicméně jak psal Aleš, ze zkompilovaného projektu moc kódu nepřečtete. Proto sem dal odkaz na svou repository https://github.com/Steida/este

lolobito

Nedalo mi nevsimnut si v zdrojovom kode, ze mu tam napriklad chyba </body> alebo </html>. To je featura toho frameworku alebo neznalost html?

Tom

To neni nic vic nez vase neznalost HTML 5.

dmkil

Ja pouzivam dojotoolkit a uplne mi staci svojou komplexnostou…

A.S.Pergill

Buď budu sám programovat, nebo se budu týdny prohrabávat v naprosto nelogické až nesmyslné dokumentaci něčeho, co napsali jiní, a nakonec vytvořím zplácaninu, kdy do svého programu importuji desítky tříd s desítkami až stovkami metod, abych z každé využil jednu dvě metody. (Konec konců, to je podstata OOP, a proto jsou takto vytvořené programy pomalá monstra.)

suxi

akoby si mi z duse hovoril…

Jan Kuča

Proč by měla být taková aplikace pomalá? Closure Compiler odstraní nepoužívané části importovaných tříd a zbylé zanese do výsledné kompilace, takže se ve výsledku stahují jednotky JS souborů (často jen jeden).

Navíc rozhodnutí používat Closure tools vůbec neznamená, že musím striktně využívat komponenty Closure Library místo vlastních.

Aleš Roubíček

Rád bych znal tu vaši podstatu OOP, protože ta, kterou znám já, se s ním neslučuje.

A.S. Pergill

Protože vytváření kompletních „objektů“ v paměti počítače bude mít vždy větší systémovou režii než zavedení procedur.
Se zavedením OOP obecně poklesla kvalita programů i OS, mimo jiné proto, že se do programování pouštějí lidé, kteří by v procedurálním programování neměli šanci (o psaní strojového kódu nebo assembleru ani nemluvě). Většinou jsou jejich výtvory monstra, zatěžující systém a mnohdy neuzvládající ani to, co uměly jejich ekvivalenty ještě na nebožtíkovi DOSu.

Aleš Roubíček

Nadruhou stranu jsou tato monstra i přesto snáze pochopitelná a udržovatelná i méně odbornou pracovní silou. ;)

GC i JIT jsou dobré, ale potřebujete asi trochu víc levného železa.

alancox

Rád bych připomenul, že OOP není jenom Java a .NET.

OOP se dělá také v C++, D, Adě, Simule, Object Pascalu, atd.

OOP a garbage collector jsou dvě různé věci.

OOP a JIT jsou dvě různé věci.

Pokud si někdo, jako pan Pergill, nebo pan Roubíček myslí, že OOP a Java jsou synonyma, pak něco těžce nepochopili.

Aleš Roubíček

Nikde jsem rovnítko mezi GC+JIT a OOP , pane Ponkrác, nevkládal.

Psal jsem to kvůli poznámkám o mostrech zatěžujících systém. GC+JIT dokáží z monster udělat mnohdy atlety. Což je celkem podobné s, v článku zmiňovaným, Google Closure Compilerem, který dělá něco podobného s JavaScriptovým kódem.

alancox

GC+JIT určitě z monster atlety neudělají. Pouze o něco zlepší situaci.

j

Ani bych nerek, mel sem tu cest nekolikra upravovat po nekom objektove psanou vec a najit v tom cokoli znamenalo se v tom prehrabavat nekolik dnu.

Totez v prodeduralni verzi jineho autora bylo na nekolik minut.

blizz

este je tu tretia cesta – modularne programovanie + funkcionalna paradigma – idealne riesenie z pohladu znovupouzitelnosti.

alancox

„Protože vytváření kompletních „objektů“ v paměti počítače bude mít vždy větší systémovou režii než zavedení procedur.“

Objektové programování není o plýtvání pamětí ani o větší režii, než procedurové.

Prozradím Vám sladké tajemství, bude to pro Vás velká novinka: I procedurální programátoři pracují s daty a datovými strukturami – tedy to co dělají objekty.


„Se zavedením OOP obecně poklesla kvalita programů i OS, mimo jiné proto, že se do programování pouštějí lidé, kteří by v procedurálním programování neměli šanci“

Ale houbeles.

OOP může samozřejmě i za snížené znalosti lidí z matematiky, horší sloh, jak se ukázalo u maturit, atd.

V Česku se už nic nevyrábí, chápete? Tady se živí právníci, pojišťováci, získávači EU dotací, obchodníci, dělníci na pásu.

K čemu technici, programátoři? Kdo je zaplatí?

Noviny, firmy a média kňučí, jak je nedostatek techniků. Zkuste se ovšem v nějaké firmě pozeptat, kolik se technikům platí mzdy a příčinu máte okamžitě na světě.

Programátoři vznikají v Číně, protože tam se něco dělá. Tady se max. servisuje, je tu už taková bída, že dokonce i klepači HTML, nebo bouchači formulářů GUI myší se nazývají programátoři.

Zde se ještě masivně programovalo před 20 lety, to je starší generace.

Dnes už se v Česku téměř neprogramuje. 99 % lidí, kteří profesně jsou programátoři dělají něco, co programováním není. HTML, klikání GUI formů, instalace programů a systémů, konfigurovači hotových programů, …

Až tu bude potřeba programovat a bude se to patřičně platit, budete tu mít mnoho dobrých programátorů. A až se bude platit u firem to, že si pohrajete s efektivitou, budete takové mít i programy.

Aleš Roubíček

Ještěže žijeme v jiném světě, než vy.

alancox

Rozumím, v tom případě pro Vás platí ta poznámka, že dnešní programátory zkazilo OOP. :-)

Aleš Roubíček

Zkazilo mě asi hodně věcí, ale nejsem si jist, že zrovna OOP. Kdybyste znal moji práci nikdy byste tohle napsat nemohl. Mě zkazilo FP.

alancox

Ach jo.

Tohle vlákno reaguje na jeden konkrétní příspěvek, na který jsem původně reagoval.

Byl jsem v odpovědi trochu ironický, protože původvní příspěvek k tomu dával hodně důvodů.

Buďte tak laskav, podívejte se trochu výše na původní můj příspěvek a ten nad tím a ukončete tohle hloupé nedorozumění, ve kterém si hrajete na uraženého. Děkuji.

Existuje taková věc, které se říká kontext. Když do toho střelíte mimo kontext, je lépe diskusi ukončit a to já právě teď v tom vlákně činím.

pravdokop

1. Tak např. v C++ je vytvoření objektu a jeho (VOLITELNÁ) inicializace v konstruktoru už z principu (kompilátor C++ má minimálně stejné vstupní a výstupní informace jako v C) stejně rychlá jako alokace místa pro data v C a následné zavolání funkce pro případnou inicializaci. Pokud si myslíte opak, napište proč, ale předem je jisté, že nebudete mít pravdu.

2. Argument, že s OOP klesla kvalita programování je asi tak relevantní pro posouzení kvality konceptu OOP, jako že díky kvalitnějším horolezeckým prostředkům se na Everest dostalo více nemehel, co neumí pořádně horolezit.

j

Jednoducha fakta:

OOP je pro spoustu mensich projektu naprosto nevhodne – zbytecne zeslozituje kod, zhorsuje pametove i vykonostni naroky. OOP ma smysl u projektu, na kterych pracuji desitky nebo stovky lidi, ale z hlediska vysledneho kodu neposkytuje zadnou relavantni vyhodu. Pokud se to pouzije spravne, bude kod mozna ponekud prehlednejsi, ale totez plati pri rozdeleni procedur do modulu.

Fak miluju lidi, kteri proto aby vypsali do shellu „nazdar“, inicializujou objekt a jejich app ma 10MB … lol

A.S. Pergill

ad 1. Řekněme, že v C++ (ale taky třeba v Perlu) se můžete bez objektů obejít. V Javě to jde s potížemi (a jen někdy), v Pythonu v podstatě nikoli (a v řadě dalších výlučně objektových jazyků taky ne).

ad 2. Změnila se koncepce tvorby programů. Zatímco dřív programátor sedl a program napsal (případně použil standardní knihovny procedur apod.), dnes programátor prohrabává dokumentace ke standardním (i nestandardním) objektům a hledá vhodné procedury.
Je to asi stejný rozdíl jako mezi malířem, který maluje štětcem a barvami, a výtvarníkem, který vytváří koláže vystřihováním a lepením (dneska tedy spíš ve Photoshopu). A obojí vyžaduje trochu jiný typ osobnosti (a málokdy se mezi výtvarníky najdou tací, kteří zvládnou na špičkové úrovni obojí, a zřejmě tohle bude platit i pro programátory).
A že to programátory kazí? Když se daly školním dětem kalkulačky, tak přestaly umět počítat. V běžném životě to jistě není problém, kalkulačka je ve snad každém mobilu, ale v momentě, kdy jim dojdou v tom mobilu baterky, tak jsou v … A tam je i „programátor“, který prostě nenajde vhodné hotové řešení pro svůj program a programovat vlastně neumí.

3. OOP má podsatatně méně přehlednou a méně logickou syntaxi než procedurální. Vyžaduje zcela odlišný typ myšlení (takzvané „šejdrem“).

Nox

Vaše asociace mi osobně připadají dost exotické:

* člověk programuje procedurálně = píše kód sám, zná vše nazpaměť, nemusí (z nějakého důvodu) znát dokumentaci procedur

* člověk programuje v oop = používá co už existuje, musí se dívat na dokumentaci procedur

Dále to když někdo píše kód zapsaný tak, že se data a přidružené metody dají do jedné identifikovatelné krabice a ty spolu komunikují znamená, že neumí programovat … a ten kdo píše kód tak, že má zvlášť data a metody kterými je mění znamená, že umí programovat.

… to mi nejde na rozum.

Čelo

Já děkuji za článek. Další nahlodání, že bych na Google Closure měl už fakt mrknout.

alancox

Přidávám se s díky. Je to velmi kvalitní a dobrý článek (tedy až na ty přiblblé bonmoty typu, že kdo něco napíše bez knihovny, tak čeká výsledné tragické dílo).

Ondřej Kučera

Proč mám hledat náhradu backbone.js?

Daniel Steigerwald

V zásadě lze použít Closure s čímkoliv, i s Backbone. Ale proč? MVC frameworky jako je Backbone, doplňují k jQuery něco, co Closure má. M jako model, Closure má třídy i s dědičnostmi, rozhraním atd. V jako View, Closure má super šablony. C jako controller, můžete si napsat controller s využitím všeho co Closure obsahuje. I bez Closure si lze postavit podobný dev stack. Smůla je trochu v tom, že nejlépe využiteje Closure Compiler, tedy kompilaci v advanced módu s verbose, právě jen s kódem pro Closure psaným.

RDPanek

Díky za pěkný článek. Na tvé školení se chystám.

JanPal

Docela nedávno sem zaváděl Closure (i s Coffeescriptem) do…“ Mohol by nas autor nasmerovat, ako spravne spojit Closure a CoffeeScript ? Nejaky clanok, blog, … Vdaka

Aleš Roubíček

Opravdu chcete hackovat transpiler? Já myslím, že to za to nestojí. :)

JanPal

Opravdu Vam stalo za to psat takyto komentar ?

blizz

ked sme uz pri tom CoffeeScripte tak toto vyzera este lepsie: LiveScript http://gkz.github.com/LiveScript/#reference

Daniel Steigerwald

Ale jistě. V článku odkazuji na svůj Closure projekt https://github.com/Steida/este Jak lze vidět, všechny třídy apod. jsou psané v Coffeescriptu. Držte se stylu, který sem zavedl. V https://github.com/Steida/este/tree/master/assets/js/dev jsou nástroje pro vývoj.
Předně start.js, což je nodejs script, který kompiluje coffee do .js, soy do js, stylus do .css. Také spouští unit tester mocha, všechny výstupy vidíte přehledně v jedné konzoli.
Pak build.js, který vám vykompiluje všechny scripty do jednoho minimalizovaného .js, včetně různých options atd.

Struktura adresáře je jasná, dev pro dev nástroje, app – vaše aplikace, closure (google closure), este – projekt kam dávám vše, o čem předpokládám, že to znovu použiji.

JanPal

Diky. Este otazka. Nestalo by za to pouzivat nejaky klon CoffeeScriptu, aby som mohol pouzivat CS sposob pisania tried a pod. ?

Napr:


class este.dev.Monitor extends goog.ui.Component
...

namiesto


...
goog.inherits este.dev.Monitor, goog.ui.Component

Nepoznas nejaky vhodny a udrzovany klon ? (Ja som nasiel tento https://github.com/bolinfest/coffee-script ktory pridava -google prepinac. No uz takmer rok ziadny commit. Pricom samotny CS sa neustale vyvyja. Tak sa obavam aby to nebol mrtvy projekt.)

Aleš Roubíček

Je to mrtvý projekt. To je přesně ten důvod, proč mi stálo za to, psát předchozí komentář.

Daniel Steigerwald

Nevím o žádné. Taky sem byl chvíli smuten, že to nejde dohromady. Asi by to šlo fixnout… ale s goog.inherits se dá docela dobře žít ,)

Marty

Existuje ke Google Closure nějaká galerie pluginů?

Díky

Daniel Steigerwald

Pluginy z dílen Google – http://closure-library.googlecode.com/svn/trunk/closure/goog/demos/index.html

Pro ty, které jsou odjinud, žádnou galerii neznám. Ale lecos se dá najít na githubu.

quarry

no takze najprv si ujasnime pojmy a dojmy. JQuery je framework a GC je kniznica. Osobne frameworky neznasam a nepouzivam. hlavna a podstatna nevyhoda frameworku je ze je to ako ucenia sa noveho jazyka. Co sa tyka jquery – premna jquery uz neni javascript, jquery je s prepacenim svinstvo. GC som nikdy neskusal a zatial sa ani nehodlam. mam rad javascript taky ako je jeho syntax strukturu logiku atd. a pokial sa v nom vyznam tak viem spravit vsetko a nepotrebujem taketo „blbosti“. toť moj nazor.

Nox

Byl by v té změti dojmů i nějaký pojem? :) dal jste jeden fakt a potom píšete že X nesnášíte, X je vám zatěžko se učit, Y je svinstvo, Z se vám nechce zkoušet a že si píšete vše sám a kódy ostatních (jakkoli znalých) jsou blbosti.

* Proč je učení se problém? – Nechce se vám učit, ale nedělá vám problém trávit čas znovuprogramováním milionkrát řešeného problému…
* Proč je jQuery svinstvo? – Kromě toho že „lidi to říkají“
* Které konkrétně vlastnosti těchto nástrojů, u GC popsaného zde v článku, z nich dělají „blbosti“? – Pokud zjistím, že daná věc za mě řeší nějaký problém a výkonnostní daň a další kritéria jsou adekvání, proč to nepoužít? Navíc získám již proběhlé testování v produkci, optimalizace, bugfixy a to i do budoucna

Mj. logika a syntaxe jazyka se týká jen reprezentace řešení v tom jazyce, ale programátor to řešení nejdřív musí vymyslet, tudíž že někdo zná syntaxi neznamená, že hned umí cokoli perfektně vytvořit.

quarry

Ucit sa ako ucit. Je rozidel napr. ked chcem urobit tak slide close. neviem ci pokladas za u cenenie nejaky sprosty prikaz v jquery alebo to ze tomu programator rozumie a vie ze ma postupne znizovat velkost a sirku.

preco je jquery svinstvo ? Pozri sa na kod jquery a „normalneho“ javascriptu dufam ze to pochopis.

jlx

Cha! Prej pojmy.. Ne, jQuery opravdu neni framework, ale naopak je to pouze knihovna pro praci DOMem (+ nejaka omacka okolo).

Vláďa Macek

Ukazal mi obzory, ktere jsem predtim nevidel.

Mr. T

Byl by někdo schopen porovnat Closure s Ember.js?

Předně co se týče vhodnosti pro malé a střední aplikace, a pocitu, jestli není Closure více java než javascript.

kak

Vypadá to velmi slibně. Díky! Pouze nevím jak bych jednoduše psal obchodní aplikace, kde se pracuje na prezentační vrstvě s MNOHA záznamy v tabulkách (firmy, zákazníci, třídění, master-detail, virtual scrolling …), něco jako je jqGrid v jQuery http://www.trirand.com/blog/

Existuje něco takového? (Dopátral jsem jen Table z Google chart API)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.