Komentáře k článku
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.
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
Ja som taky bezny konzument/webdesigner 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 :)
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
Nejsou, ale můžete si je robustně napsat s pomocí všech těch úžasných nástrojů.
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
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.
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
Takyto zakladny plugin pouzivany takmer na kazdej druhej stranke neexistuje? No to je dost zavazny problem :(
Paneboze
Len som to zacal citat a autor ma uplne znechutil svojimi blbymi hlaskami… mal by radsej pisat do Brava…
Re: Paneboze
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.
Re: Paneboze
:-))))
Re: Paneboze
:D :)
Re: Paneboze
Doufám, že se toho výroku Dan ujme a vloží do referenčních citací 8-)
Re: Paneboze
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.
Re: Paneboze
Nepropaguje vlastní famework, protože z toho už vyrostl.
Re: Paneboze
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.
Re: Paneboze
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 :(
Re: Paneboze
Ty co davas? Google ma tiez svoj vlastny framework a nemam pocit, ze by este nevyrastol.
Re: Paneboze
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 :)
Re: Paneboze
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 :)
Re: Paneboze
nejake argumenty? skus napisat, ktore hlasky su podla teba blbe a preco
Autore, Proactify pouziva jQuery,,,
Asi jsem neco nepochopil…
Re: Autore, Proactify pouziva jQuery,,,
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é.
Re: Autore, Proactify pouziva jQuery,,,
> „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.
Re: Autore, Proactify pouziva jQuery,,,
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.
Re: Autore, Proactify pouziva jQuery,,,
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í/aplikace/kódu.
Re: Autore, Proactify pouziva jQuery,,,
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.
Re: Autore, Proactify pouziva jQuery,,,
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
Re: Autore, Proactify pouziva jQuery,,,
Nedalo mi nevsimnut si v zdrojovom kode, ze mu tam napriklad chyba </body> alebo </html>. To je featura toho frameworku alebo neznalost html?
Re: Autore, Proactify pouziva jQuery,,,
To neni nic vic nez vase neznalost HTML 5.
js-dojo
Ja pouzivam dojotoolkit a uplne mi staci svojou komplexnostou…
To je zásadní a tak trochu "filosofický" problém:
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.)
Re: To je zásadní a tak trochu "filosofický" problém:
akoby si mi z duse hovoril…
Re: To je zásadní a tak trochu "filosofický" problém:
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.
Re: To je zásadní a tak trochu "filosofický" problém:
Rád bych znal tu vaši podstatu OOP, protože ta, kterou znám já, se s ním neslučuje.
Re: To je zásadní a tak trochu "filosofický" problém:
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.
Re: To je zásadní a tak trochu "filosofický" problém:
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.
Re: To je zásadní a tak trochu "filosofický" problém:
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.
Re: To je zásadní a tak trochu "filosofický" problém:
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.
Re: To je zásadní a tak trochu "filosofický" problém:
GC+JIT určitě z monster atlety neudělají. Pouze o něco zlepší situaci.
Re: To je zásadní a tak trochu "filosofický" problém:
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.
Re: To je zásadní a tak trochu "filosofický" problém:
este je tu tretia cesta – modularne programovanie + funkcionalna paradigma – idealne riesenie z pohladu znovupouzitelnosti.
Re: To je zásadní a tak trochu "filosofický" problém:
„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.
Re: To je zásadní a tak trochu "filosofický" problém:
Ještěže žijeme v jiném světě, než vy.
Re: To je zásadní a tak trochu "filosofický" problém:
Rozumím, v tom případě pro Vás platí ta poznámka, že dnešní programátory zkazilo OOP. :-)
Re: To je zásadní a tak trochu "filosofický" problém:
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.
Re: To je zásadní a tak trochu "filosofický" problém:
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.
Re: To je zásadní a tak trochu "filosofický" problém:
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.
Re: To je zásadní a tak trochu "filosofický" problém:
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
Re: To je zásadní a tak trochu "filosofický" problém:
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“).
Re: To je zásadní a tak trochu "filosofický" problém:
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.
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
Já děkuji za článek. Další nahlodání, že bych na Google Closure měl už fakt mrknout.
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
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).
backbone js nejde použít? proč?
Proč mám hledat náhradu backbone.js?
Re: backbone js nejde použít? proč?
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.
Díky za pěkný článek.
Díky za pěkný článek. Na tvé školení se chystám.
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
„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
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
Opravdu chcete hackovat transpiler? Já myslím, že to za to nestojí. :)
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
Opravdu Vam stalo za to psat takyto komentar ?
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
ked sme uz pri tom CoffeeScripte tak toto vyzera este lepsie: LiveScript http://gkz.github.com/LiveScript/#reference
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
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.
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
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.)
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
Je to mrtvý projekt. To je přesně ten důvod, proč mi stálo za to, psát předchozí komentář.
Re: Proč považuji Google Closure za nejlepší javascriptovou knihovnu
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 ,)
Galerie pluginů / doplňků
Existuje ke Google Closure nějaká galerie pluginů?
Díky
Re: Galerie pluginů / doplňků
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.
jquery gc
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.
Re: jquery gc
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.
Re: jquery gc
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.
Re: jquery gc
Cha! Prej pojmy.. Ne, jQuery opravdu neni framework, ale naopak je to pouze knihovna pro praci DOMem (+ nejaka omacka okolo).
Diky za clanek
Ukazal mi obzory, ktere jsem predtim nevidel.
Porovnání
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.
Výborné, ale co Grid?
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)