69 komentářů k článku Proč považuji Google Closure za nejlepší javascriptovou knihovnu:

  1. Hmm

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

    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 :)

    1. Aleš Roubíček

      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ů.

      1. Hmm

        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.

      2. jozefyna

        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 :(

  2. suxi

    Paneboze

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

    1. Ondřej Kučera

      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.

      1. chleba

        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.

          1. chleba

            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.

          2. Jurkova

            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 :(

        1. Ondřej Kučera

          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 :)

          1. chleba

            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 :)

    1. Aleš Roubíček

      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é.

      1. Diskobolos

        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.

        1. Aleš Roubíček

          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.

          1. Diskobolos

            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í/aplika­ce/kódu.

            1. Aleš Roubíček

              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.

              1. lolobito

                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?

  3. A.S.Pergill

    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.)

    1. Jan Kuča

      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.

    2. Aleš Roubíček

      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.

      1. A.S. Pergill

        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.

        1. Aleš Roubíček

          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.

          1. alancox

            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.

            1. Aleš Roubíček

              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.

              1. alancox

                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.

          2. j

            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.

        2. blizz

          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.

        3. alancox

          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.

            1. alancox

              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. :-)

              1. Aleš Roubíček

                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.

                1. alancox

                  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.

        4. pravdokop

          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.

          1. j

            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

          2. A.S. Pergill

            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“).

            1. Nox

              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.

  4. Čelo

    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.

    1. alancox

      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).

    1. Daniel Steigerwald

      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.

  5. JanPal

    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

    1. Aleš Roubíček

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

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

      1. JanPal

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

        Opravdu Vam stalo za to psat takyto komentar ?

    2. Daniel Steigerwald

      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.

      1. JanPal

        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.)

        1. Aleš Roubíček

          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ář.

        2. Daniel Steigerwald

          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 ,)

  6. quarry

    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.

    1. Nox

      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.

      1. quarry

        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.

    2. jlx

      Re: jquery gc

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

  7. Mr. T

    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.

  8. kak

    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)

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3676