36 komentářů k článku Javascriptaření: nejen jQuery živ je JavaScriptař:

  1. asdasd

    Re: Javascriptaření: nejen jQuery živ je JavaScriptař

    Pěkné shrnutí. Backbone vypadá zajímavě, v nejbližší době ho vyzkouším. Akorát místo underscore bych spíš doporučil jLinq(http://www.hugoware.net/Projects/jLinq) – je o dost propracovanější a pokud někdo umí linq, tak práce s jLinq pro něj bude hračka. Co se týče testů, tak ty se hodí spíš na středně velké až velké projekty, u těch menších asi většina lidí odpoví, že je to zbytečně zdržuje(a podle mě oprávněně). No a emscripten mi přijde jako nouzovka, osobně bych pomocí něj aplikace určitě nedělal, to je radši přepíšu ručně.

    1. Martin MalýAutor příspěvku

      Re: Javascriptaření: nejen jQuery živ je JavaScriptař

      Underscore a Linq nejsou moc příbuzné. Takříkajíc skoro vůbec ne. jLinq řeší výběr dat a la Linq, Underscore je servisní knihovna pro *obecné operace* s datovými strukturami a funkcemi(!). Tedy každé je určeno pro něco trošku jiného, a od toho se odvíjí i použití. Rozhodně to není „místo Underscore jLinq“.

      S tím testováním myslím, že nemáte pravdu. I stořádková knihovní funkce se vytváří líp s testem, nehledě na to, že se líp upravuje, když k ní za tři roky přijdete, ve chvíli, kdy ji máte narvanou v deseti webech, a potřebujete „jen lehce něco přidat…“ Zase to neberte jako binární možnost: netestovat nic vs testovat všechno. Když si napíšu jednorázový ad hoc kód, na testy kašlu, ale když počítám s tím, že bych některé části mohl použít v dalších projektech (a takové jsou i u malých projektů), tak by sada testů měla být samozřejmostí.

      Emscripten není nouzovka, rozhodně bych v něm nedělal nic. Je to kuriozita; zajímavost, hříčka… Takové to tvrzení o JS coby webovém assembleru, dotažené do důsledků. :) Víc v tom nehledejte

      1. asdasd

        Re: Javascriptaření: nejen jQuery živ je JavaScriptař

        No při pohledu na seznam funkcí jsem našel jenom pár, co by nebyly právě v jLinq nebo přímo v jQuery. Navíc underscore má celkem hnusný zápis, osobně se bez něj obejdu(tím netvrdím, že je k ničemu, někdo pro něj určitě využití najde). Testování jako binární věc neberu, jen mi přijde zbytečné dvě hodiny psát test pro aplikaci, která se dá ručně otestovat za dvě minuty, u větších aplikací už to opodstatnění má. Jinak pokud mám stejnou funkci na deseti různých webech, tak se dá taky očekávat, že jeho změna může mít na každém z nich různé důsledky z hlediska webu jako celku, takže by se testy stejně musely po nasazení doladit(pokud nejde o deset identických webů).

        1. Martin MalýAutor příspěvku

          Re: Javascriptaření: nejen jQuery živ je JavaScriptař

          „jen mi přijde zbytečné dvě hodiny psát test pro aplikaci, která se dá ručně otestovat za dvě minuty“ – psal jste někdy testy, nebo jen „máte dojem“, že „to je nějak takto“? Protože – nezlobte se, ale nevěřím tomuto poměru.

          Popíšu to znovu a použiju váš příklad: Pokud mám stejnou funkci na deseti různých webech, tak když ji píšu poprvé, napíšu ji jako knihovnu (řekněme převod geolokačních souřadnic z desetinného zápisu stupňů na stupně+hodiny+ vteřiny). Tuhle knihovnu pokryju testama, které ověří, že knihovna dělá přesně to, co dělat má, a nemá jiné postranní projevy. V tu chvíli je to černá skříňka, která dělá přesně jednu věc (převádí jednotky). Mohu ji tedy použít na deseti webech, a na všech bude dělat tutéž věc.

          (Ba co víc: pokud mám testy napsané dobře, tak teoreticky mohu použít jakoukoli „černou skříňku“, která jimi projde!)

          Hypoteticky pak přidám, kvůli webu 11, převod na nějaké interní souřadnice. Dopíšu do testů (jsou inrementální!) testování pro tyto souřadnice a otestuju opět celou knihovnu. Pokud testy projdou naprosto stejně, bude se knihovna dál chovat i na předchozích deseti webech stejně. Pokud bude mít taková změna někde „důsledky z hlediska webu jako celku“, tak jsem něco udělal špatně v tom webu, pravděpodobně jsem spoléhal na to, že knihovna má nějaký vedlejší efekt, to znamená že jsem ji špatně otestoval.

          Jednotkové testování testuje jednotky (knihovny), nikoli případy použití (jejich fungování v aplikaci).

          1. asdasd

            Re: Javascriptaření: nejen jQuery živ je JavaScriptař

            Máte pravdu, kapitolu o testování jsem přeskočil, myslel jsem, že vám jde o testování aplikace jako celku.

            „Pokud testy projdou naprosto stejně, bude se knihovna dál chovat i na předchozích deseti webech stejně.“

            To záleží na okolnostech – jak moc je daná knihovna univerzální, jestli spolu s ní uživatel nepoužije knihovnu, která ovlivní funkci té mojí(nebo rovnou základní prvky jazyka), atd. Sama o sobě může fungovat skvěle, jako součást celé aplikace už ale fungovat nemusí, spoléhat na jednotkové testy bez prověření celé aplikace taky není zrovna výhra.

            1. Martin MalýAutor příspěvku

              Re: Javascriptaření: nejen jQuery živ je JavaScriptař

              To je pravda – pokud si „rozbiju stroj“, tj. použiju něco, co „rozšteluje“ základní prvky jazyka, tak mi opravdu není pomoci :) Jednotkové testování není všespásné, to určitě ne; na druhou stranu používat něco, co ovlivní fungování „blackboxed“ knihoven (tedy razantně zasáhne do „předpokladů“), je ryzí hazardérství. (Na druhou stranu lze takový případ zpětně zabudovat do testů a udělat svou knihovnu odolnější i vůči takovým věcem…)

          2. Michal Kára

            Re: Javascriptaření: nejen jQuery živ je JavaScriptař

            > „jen mi přijde zbytečné dvě hodiny psát test pro aplikaci, která se dá ručně
            > otestovat za dvě minuty“ – psal jste někdy testy, nebo jen „máte dojem“, že „to
            > je nějak takto“? Protože – nezlobte se, ale nevěřím tomuto poměru.

            Podle popisu bych tipoval, že se někdy pokoušel v praxi použít testování, protože to přesně tak je :-D Ano, občas jsou věci typu konverze geolokačních souřadnic, typu „pár čísel tam, pár ven, žádný vnitřní stav“. A ty jsou pro automatizované testu velmi vhodné, jenže v praxi (alespoň té mojí) tvoří naprostý zlomek funkcí.

            Naopak spousta funkcí nemá zdaleka tak jednoduchý výstup a hlavně závisí na velmi rozsáhlém stavu (databáze). Takže člověk hodinu píše funkci a pak dvě hodiny definuje stav databáze a kritéria, podle kterých se pozná, že funkce proběhla správně. No a pak přijde nějaká změna v zadání a může to definovat celé znova…

            1. Martin MalýAutor příspěvku

              Re: Javascriptaření: nejen jQuery živ je JavaScriptař

              Jestli ony to nebyly takové ty praktické zkušenosti „trvalo nám to dlouho, tak jsme se na to vykašlali“ – tam chybí jen dodat „trvalo vám to dlouho, protože jste to ještě neuměli a/nebo jste to dělali blbě“, ovšem to odborníci neradi slyší, tak vymýšlí „dobré důvody“.

              Když dovolíte, tu vaši „výtku“ poupravím:

              – nejprve byste měl definovat vstupní stavy a očekávané výsledky
              – nezapomeňte testovat nejen to, že funkce proběhla správně, ale i to, že dopadne špatně, když špatně dopadnout má! (nejčastější chyba – to, že funkce nedělá co má, to vidí každý, ale to, že dělá když nemá, vidět na první pohled není!)
              – pak teprve píšete funkci.

              Automatické testování vám usnadní i například to úvodní uvedení databáze do požadovaného stavu.

              Tedy mezi testováním „vaší“ funkce nebo jednoduchého přepočtu není principiální rozdíl. Ovšem pokud „testujete“ tak jak jste naznačil, tj. že nejdřív smolíte funkci a pak se obtěžujete s psaním testů… :)

              A teď zpátky k tomu, s čím nesouhlasíte: Můžete mi uvést příklad, kdy trvá řádné napsání testů dvě hodiny, A ZÁROVEŇ je možné vše, co testují tyto testy, otestovat „ručně během dvou minut“? (protože to je to, s čím nesouhlasím) Váš příklad to zjevně nebude – nastavit „velmi rozsáhlý stav databáze“ a zkontrolovat, zda vše proběhlo jak má, asi nebude práce na dvě minuty…

              1. Michal Augustýn

                Re: Javascriptaření: nejen jQuery živ je JavaScriptař

                To já věřím tomu, že existuje funkce, pro kterou trvá test napsat 2 hodiny (i více). A to proto, že je ona funkce blbě napsaná.

                Není třeba hned psát nejprve testy a až pak kód (TDD puristi, klidně si mě sežerte), stačí mít trošku disciplíny a při implementaci myslet na to, že se pro to bude muset napsat test. To přirozeně vede k tomu, že funkce bude mít minimum závislostí, takže testování bude snadné, a navíc bude aplikace krásně decoupled (jednotlivé části pěkně oddělené).

                1. Michal Kára

                  Re: Javascriptaření: nejen jQuery živ je JavaScriptař

                  Jenže ty závislosti často vyplývají ze zadání / povahy věci. Takže můžete mít skvěle otestovanou funkci – která ale tvoří jen část kódu a závislosti otestované nemáte. A přitom v nich bývá nejvíc problémů.

                  1. Michal Augustýn

                    Re: Javascriptaření: nejen jQuery živ je JavaScriptař

                    Pokud je součástí zadání špatný design aplikace, pak může být testování skutečně utrpení…
                    Testují se samozřejmě i závislosti – na to jsou integrační testy.

              2. Michal Kára

                Re: Javascriptaření: nejen jQuery živ je JavaScriptař

                Jen krátce: Ručně víte že je DB OK, takže vyplníte formulář, odešlete, ono to zahlásí požadovaný výsledek. Automaticky musíte řešit, jestli je DB v požadovaném stavu (jsou tam objekty co tam být mají, nejsou ty, co tam být nemají).

                Další problémy vyplývají z toho, že v praxi máte nějaký proces s X kroky, ale aby to bylo rozumně testovatelné, musíte testovat dílčí kroky. A jelikož jednotlivé testy jsou na sobě nezávislé, tak musíte definovat přesně stav DB v jednotlivých mezikrocích… Přitom při ručním testování prostě jen vyplníte pár formulářů. A to nemluvím o případu, kdy se něco změní a všechno tohle musíte definovat znovu, zatímco ručně to prostě zadáte trošku jinak.

                Prostě, šedivá je teorie, zelený strom praxe, asi tak.

                Neříkám, že automatické testování je úplně nanic, ale praxe není zdaleka tak růžová, jako v pečlivě vybraných učebnicových příkladech, to jsem tím chtěl říct :-)

                1. Michal Augustýn

                  Re: Javascriptaření: nejen jQuery živ je JavaScriptař

                  Nejsem TDD purista, takže mi nedělá problém v popisovaném případě naplnit databázi do správného iniciálního stavu a otestovat jednotlivé kroky v jednom testu.

                  Upřímně – přijde mi to, že máš hokej v tom, co jsou unit-testy, integrační testy, testy uživatelského rozhraní, akceptační testy, …

                2. jos

                  Re: Javascriptaření: nejen jQuery živ je JavaScriptař

                  jak píše Michal:

                  „máš hokej v tom, co jsou unit-testy, integrační testy, testy uživatelského rozhraní, akceptační testy“

                  protože unittest používající databázi není unittest, musíš v něm pracovat výhradně s podvrženejma ( => předem známejma) datama

              3. František Kučera

                testování

                Ad „Můžete mi uvést příklad, kdy trvá řádné napsání testů dvě hodiny, A ZÁROVEŇ je možné vše, co testují tyto testy, otestovat „ručně během dvou minut“?“

                Třeba takové generování grafu. Úplně primitivní graf, klidně sloupcový, dva sloupečky, dva vstupní parametry (hodnoty), na výstupu obrázek – ať už SVG/XML nebo třeba PNG.

                Ručně otestovat se to dá během těch dvou minut hodně krát – stihnou se vyzkoušet krajní možnosti, nesmyslné hodnoty i běžné/průměrné hodnoty. Prostě několikrát „kouknu a vidím“.

                S automatizovaným testem je to o dost horší – pokud má fungovat obecně a nebýt závislý na konkrétní implementaci (tzn. nezadrátuji tam přímo to jedno výstupní XML nebo pole bajtů PNG dat – protože kdybych to dělal, tak stačí zmrazit ten kód a říct, že na něj nikdo nemá sahat). Test by měl být obecný a fungovat, i když se změní implementace a graf najednou bude mít jiný odstín zelené nebo tlustší čáry. Tohle neotestuješ ani za dva dny, natož za dvě hodiny :-)

                To byl trochu zvrhlý příklad, protože tam figuruje GUI, ale pracné testy můžou být i jinde. Stačí něco víc než jen obyčejné funkce (jednoduchý vstup/výstup), trochu toho OOP. Objekty mají vnitřní stav, může záležet na pořadí metod, např. při pořadí volání metod a,b,c,d bude chování objektu správné, ale při volání v pořadí b,c,a,d se už objekt bude chovat jinak než má. Nebo parametry metod – i taková „drobnost“ jako že některé parametry jsou null – z toho plyne velké množství kombinací, které by se měly teoreticky otestovat. A nemusí to být jen null, k chybě může docházet i při jiné kombinaci hodnot… A ani při 100% pokrytí (při testech se vykonají všechny řádky kódu) nemusíme otestovat všechny kombinace, které můžou nastat a způsobit chybu.

                1. Martin MalýAutor příspěvku

                  Re: testování

                  Někdy mám pocit, že někteří diskutující mají binární uvažování: Buď všechno, nebo nic. Jejich argumentace extrémními případy je občas úsměvná, ale po delší době spíš jen únavná.

                  Takže Franto: Budu-li mít knihovnu pro kreslení grafů, tak použiju unit testy na to, abych ověřil, že knihovna dokáže přijmout sady hodnot, že odmítne hodnoty špatné, že správně přijme barvu „red“, ale vyhodí barvu „světlemeruňkovou“, že pro trojrozměrný graf přijme právě a pouze dvojrozměrné pole hodnot… atakdál. To jsou věci, co jaksi nespadají do tvého „kouknu a vidím“, resp. je mnohem jednodušší a rychlejší, když „koukne a vidí“ stroj.

                  Samosebou nebudu testovat STROJOVĚ to, co okem uvidím rychleji, takže se podívám až na výsledky té sady testů a uvidím, jestli se nakreslilo to, co se nakreslit mělo. POKUD strávíš čas tím, že budeš v testech implementovat rozpoznávání obrazců, tak nejsi programátor, ale jsi tupý demagog.

                  Dtto druhý příklad: Stěžuješ si na to, že je spousta možností, které „bys měl“ otestovat. Ano, je jich spousta, a ano, od toho máš stroj, aby je vyzkoušel za tebe a ověřil. Remcat, že „to testy neodhalí“ je chabá výmluva – tak to do nich napiš! mimochodem testy nejsou od toho, aby odhalovaly něco, o čem ty sám nevíš, testy jsou od toho, aby sis jima kryl vlastní postup, aby se ti nějakou banalitou nezřítilo to, cos už postavil.

                  1. Franta

                    Re: testování

                    Ad „Budu-li mít knihovnu pro kreslení grafů, tak použiju unit testy na to, abych ověřil, že knihovna dokáže přijmout sady hodnot,…“

                    Pokud testujeme program tak, že nám stačí, aby nespadl, ale výsledek může vrátit libovolný, tak bych se to netroufal nazývat jednotkovým testem.

                    Ad „POKUD strávíš čas tím, že budeš v testech implementovat rozpoznávání obrazců, tak nejsi programátor, ale jsi tupý demagog.“

                    Kdybys napsal „hlupák“, tak bych tu větu chápal, ale demagoga v této souvislosti nechápu. Samozřejmě že v testech nerozpoznávám obrázky.

                    Ad „Stěžuješ si na to, že je spousta možností, které „bys měl“ otestovat.“

                    Já si nestěžuji :-) Jen jsem chtěl říct, že v praxi to není zdaleka tak růžové a skvělé jako v učebnicových příkladech (kde se testuje jednoduchá funkce, třeba sčítání nebo převod souřadnic). Tahle diskuse se rozvinula pod větou: „Protože – nezlobte se, ale nevěřím tomuto poměru.“ A ono to tak skutečně může být. Teď zrovna tu mám třídu s implementací s 553 řádky a k tomu test s 643 řádky a pořád by ještě šlo otestovat některé další kombinace.

                    Ad „testy nejsou od toho, aby odhalovaly něco, o čem ty sám nevíš, testy jsou od toho, aby sis jima kryl vlastní postup, aby se ti nějakou banalitou nezřítilo to, cos už postavil.“

                    To co sám vím, si můžu sám opravit a nemusím to testovat. Jasně že testy mají zkontrolovat to, co mne nenapadlo (jinak bych to opravil sám bez nich). Navíc v TDD se píší před implementací a taky je může/má psát někdo jiný než implementátor — takže při psaní nevíš, jak to druhá strana (nebo ty později) zprasí a jaké chyby udělá, nejde se spoléhat na to, že to bude dělat správně (to bychom nemuseli testovat).

                    Aby to nevyznělo špatně, nejsem proti jednotkovým testům. Teď zrovna jsem na projektu, kde se unit-testuje opravdu všechno a věřím tomu, že to má smysl. Ale nelze zastírat tu druhou stranu mince — vynaložený čas (a tím pádem peníze). Rozhodně si to nelze představovat tak, že budu X hodin programovat a pak za půl hodiny spíchnu testy, do kterých napíšu, že 1+1 má dát výsledek 2 a hotovo, jdu domů — není to takhle zadarmo. A dost dobře si dovedu přestavit projekty, kde dává ekonomický smysl nepoužívat jednotkové testy, bouřlivě se vyvíjí a mění zadání a nakonec se to utáhne pomocí ručních testů nebo nějakých automatických ale komplexních — netestovat malé jednotky, ale celé komponenty, části systému, z jednoho konce na druhý. Záleží na druhu projektu, TDD není nějaká svatá kráva, ale jedna z mnoha metodik.

                  2. anonymous

                    Re: testování

                    ackoliv jste oba totalne offtopic, rozjela se zde velmi zajimava diskuze na tema unit testu… tak ja to zkusim s krizkem po funuse

                    martine, franta je zvykly na argumentaci ad absurdum http://encyclopediadramatica.com/Strawman v obci programatorske celkem bezna vec.

                    jsou ale pripady kdy testy zaberou extremne hodne casu, konkretne jedna-li se o mix closed/open kodu (extenduje se nejaka komplexni closed trida s mizernou/outofdate dokumentaci).

                    v takovem pripade je nutne napsat jeji mockup ekvivalent _a_ k tomu funkcni unit test, ktery nepozna rozdil mezi nativni a mock implementaci.
                    pote lze inkrementalne extendovat mock a unit test a vsechny 3 veci udrzet pohromade. to vse jenom aby se odladila nejaka odnoz pridrzle closed tridy.

                    v takovychto pripadech kazdy normalni clovek to nejdriv naprasi co to de a k vyse uvedenemu se uchyli az kdyz se nakupi jemne bugy jez uz nejdou resit hackama na schovani nasledku, ale je potreba najit priciny.

                    (priklad takove hruzy – pro Flexare http://opensource.adobe.com/svn/opensource/osmf/trunk/libs/testing/NetMocker/org/osmf/netmocker/MockNetStream.as)

          3. František Kučera

            Re: Javascriptaření: nejen jQuery živ je JavaScriptař

            Převod souřadnic je krásný příklad – jednoduchá funkce, vstup, výstup, hotovo. Tohle je radost testovat. Ale zdaleka ne vždy je to tak jednoduché – někdy můžou být testy větší než samotná implementace (co do počtu řádek i času stráveného jejich psaním), když už se má tedy testovat všechno…

            1. Martin MalýAutor příspěvku

              Re: Javascriptaření: nejen jQuery živ je JavaScriptař

              Na to je jediná odpověď: No a? Pokud ti vadí, že komplexní testy komplexních knihoven píšeš dlouho, jdi si sednout ke kase v supermarketu, tam testování spočívá v sečtení peněz v kase.

  2. joey

    Jakou používáte výmluvu pro to, že nepíšete testovací kód?

    8. Je to dražší než dodat chybový kód / Chyby nám nevadí.

    1. Martin MalýAutor příspěvku

      Re: Jakou používáte výmluvu pro to, že nepíšete testovací kód?

      Máte ji tam :)

      1. Martin Soušek

        Re: Jakou používáte výmluvu pro to, že nepíšete testovací kód?

        Testovat je hloupé, protože když odevzdám chybný kód a klient si toho nevšimne a podepíše akceptační protokol, tak až si chyby všimne, naúčtuju mu to jako vícepráce!

        Něco jako silničáři v ČR. K čemu je silnice, která vydrží neporušená deset let, když se to může firma opravovat jednou za tři měsíce a jednou za dva roky frézovat a dělat komplet nový povrch?

        Takže má výmluva: „Testování snižuje HDP!“. Prosím přidat.

        1. jos

          Re: Jakou používáte výmluvu pro to, že nepíšete testovací kód?

          co je mi do HDP? když ti někdo přebere zákazníka, protože ve stejným čase (takže klidně i za stejný prachy) mu dodá kód s menší chybovostí, tak ti taky bude HDP ukradený

        2. olin

          Re: Jakou používáte výmluvu pro to, že nepíšete testovací kód?

          To je blbost. Software má také záruku a klasické chyby funkčnosti jsou řešeny jako záruční opravy a zdarma (alespoň by mělo). Neznám zákazníka, který by nerazil hlavní požadavek, a to že „software má fungovat“. Odírání zákazníka za vlastní (vývojářovu) blbost je hnus. Ještě pochopím, když se u každé chyby ohodnotí závažnost a ty středně vážné (ovlivňují funkčnost) a horší se opraví, zatímco lehké (kosmetické) se neopravují.

      2. MilosNemec

        Re: Jakou používáte výmluvu pro to, že nepíšete testovací kód?

        V anketě mi chybí odpověď: „Netestujeme, protože když jsme si udělali podrobnou analýzu chyb reportovaných od zákazníka, zjistili jsme, že žádnou z nich by neodhalil jednotkový test.“ Čímž rozhodně nechci nijak snižovat význam jednotkových testů, minimálně z pohledu kvality návrhu (loose coupling) nebo náročnosti případných úprav. Jen takové povzdechnutí z praxe.

        1. Martin MalýAutor příspěvku

          Re: Jakou používáte výmluvu pro to, že nepíšete testovací kód?

          Připomnělo mi to: „Nebudu používat sluneční brýle, protože mě neochrání před rakovinou kůže!“ ;)

          Nic ve zlém, ale jednotkové testování slouží k něčemu jinému než k „odhalování chyb, co reportuje zákazník“. Tento argument je na stejné úrovni jako říct „Nepoužíváme verzování zdrojáků, protože zákazníci dostávají vždy nejnovější verzi.“ Jednotkové testování přeci není pro zákazníky, ale pro vývojáře!

          1. MilosNemec

            Re: Jakou používáte výmluvu pro to, že nepíšete testovací kód?

            S tím naprosto souhlasím. Nevyjádřil jsem se dobře – v praxi jsem se setkal s odmítáním jednotkových testů s argumentací „Chyby které jsme tam nasekali, jednotkové testy stejně neodhalí.“ Proto mi ta varianta v anketě chybí. Osobně proti jednotkovým testům nejsem, naopak.

            1. Martin MalýAutor příspěvku

              Re: Jakou používáte výmluvu pro to, že nepíšete testovací kód?

              Aha, takhle… OK, to máte pravdu, tak už si rozumíme. Aneb „Naši programátoři jsou tak kreativní, že jejich chyby ani unit testy neodhalí“ :)

  3. Radek

    LLVM

    Jen upřesnění k LLVM: nejedná se o žádné virtuální běhové prostředí (nic jako JVM), ale o modulární překladač. Zdroják (obvykle v C/C++) se překládá do mezikódu nezávislého na architektuře, který je vhodný pro optimalizace. Z toho se potom generuje kód pro cílovou platformu. Napsáním vhodného generátoru (backendu) lze tedy generovat jak kód pro libovolný procesor, tak i zmíněný javascript. Spouštění mezikódu není primárním účelem, i když nějaké experimenty v tomto směru existují.

  4. Jakub Bouček

    Head JS

    Velmi zajímavá knihovna je Head JS (http://headjs.com/), která má ambice být ještě nad jakýmkoliv jiným frameworkem a nabízí velmi zajímavé funkce. Myslím, že by si v článku místo zasloužila a to i přesto, že je tak trochu někde jinde.

    1. Martin Soušek

      Re: Head JS

      Pro produkční nasazení se nehodí, protože je tam ještě řada bugů, které fakt ztrpčí život.

    1. backup

      Re: Smartclient

      – jak to vypada s rychlosti (velikost knihoven)?
      – rychlost pro generovani treba 50 edit-elementu, 10 buttonu …ca 400 elementu
      – jak to vypada, kdyz chci delat data-handling ve vlastni rezii bez tech jejich prostredku.
      – priklad nejake aplikace
      – licence je LGPL , jak si to vyklada isomorphic, jaky vsechen objektovy kod musim k me aplikaci pribalit?

      1. Djax

        Re: Smartclient

        Knihovny jsou dělené samostatně v souborech, použijete co potřebujete, pro komplexní web aplikaci cca 700 KB.

        Rychlost okamžitá i pro stovky elementů.

        Data handling ve vlastní režii je samozřejmostí, na výběr je několik možností.

        Maji na webu bohate demo priklady i aplikace.

        Nic se nemusi pribalovat, staci ty JS knihovny.

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=3448