Názory k článku
Zmenšujeme JavaScript

Jen bych doplnil pár informací z praxe.

JSPacker už dnes nikdo soudný nepoužívá. Dekomprese totiž probíhá v samotném Javascriptu, a pro takové Mootools, zabere klidně 300ms. Jediný důvod pro použití JSPackeru je situace, kdy není k dispozici GZIP (JSPacker má vysoký kompresní poměr), a v prohlížeči je nám ukradené, jak dlouho se kód rozbaluje. Nedovedu si takovou situaci představit ;)

Oproti tomu YUI Compressor ani Google Closure Compiler, žádnou vlastní kompresi (pomocí eval) neprovádí. Neexistuje tedy žádné zdržení při rozbalování. Dojo Shrinksafe snad ani nemá smysl zmiňovat, protože se dlouhodobě nevyvíjí.

YUI Compressor je nejlepší řešení pro ty, co chtějí kód bezpečně minimalizovat, a nechtějí u toho přemýšlet.

Google Closure Compiler je bomba. Takový kompresor sem si vždy přál =) Od YUI se liší možnostmi svého advanced módu. V článku se píše: „přejmenuje identifikátory“, což pro lokální proměnné YUI činí rovněž. Closure Compiler ale minimalizuje identifikátory všechny! Tedy i enumerace, jmenné prostory, klíče v objektech. Krom toho, že úspora je maximální, dostaneme dárkem i perfektní obfuskaci kódu.

Nástroj pro online porovnání účinnosti komprese.

Díky za doplnění technického úhlu pohledu. Closure Compiler je moc hezký, dokonce jsem zjistil, že i to window[‚SHA256‘­]=SHA256 změní na window.SHA256 = … :) A ten nástroj je v článku odkázaný – že tys to nedočetl? ;)

Jsi si jistý, že jsi tam ten link nedodal až po mém komentáři? (řekni prosím že jo) ;)

Musím tě zklamat: Jsem si jistý, že tam je od začátku… :)

Pro doplnění jeden kompresor z české dílny KJScompress

Někdy se může hodit i opačný nástroj – převést „zkrácený“ a „obfuskovaný“ kód na něco stravitelnějšího: http://jsbeautifier.org/ (via http://simonwillison.net/)

Jsme na rootu, takže nepřekvapí že se „vypustil“ MS Ajax Minifier :-) Každopádně výsledky nemá špatné a pokud by to někoho zajímalo trochu do hloubky může kouknout na http://www.coderjournal.com/2010/01/performance-optimizations-made-by-microsoft-google-and-yahoo-javascript-minimizers/

Ne, to není tím, že jsme na Rootu, to je tím, že o MS Ajax Minifieru slyším prvně – ani při shánění podkladů jsem na něj nenarazil (je tedy pravda, že jsem nechtěl jít příliš do hloubky a zmínit každý minifier). Každopádně díky za doplnění.

Jak je to s výkonem. Je minimalizovaný kód i výkonnější nebo je to jedno? Víte někdo?

Compilery vetsinou maji funkci, ze ti odstrani komentare, mezery, nove radky a dalsi znaky ktere neovlivni tvuj kod, kvuli redukci velikosti souboru pro rychlejsi nacitani souboru, tak docela tezko.

Trošku obšírnější odpověď:

U klasických kompilovaných jazyků (C, Pascal atd.) je víceméně jedno, jak dlouhý je zdrojový kód – kompiler ignoruje komentáře, a pokud je dobrý (většina je), tak dokáže do jisté míry napravit i programátorské zhůvěřilosti a „optimalizovat“.

U interpretovaných jazyků, které nepoužívají překlad do bytecode ani cache, se objem může projevit na rychlosti – přeci jen parser musí přeskákat mezery a komentáře při každém načtení.

Jazyky, které jsou na pomezí (tedy překládají do bytecode a ten pak interpretují, nebo implementace, která si cachuje rozparsovaný kód) jsou na tom podobně jako jazyky kompilované – zpomalí to pouze první načtení, po překladu do bytecode už pojede naplno (např. Python a jeho .py a .pyc).

V assembleru se dokonce dělal přesný opak – např. se rozepisovaly některé smyčky na rozbalený tvar a tím se ušetřil čas (jen ten strojový…)

Ale na webu to lehké zvýšení výkonu přinést může – ovšem hlavně v tom, že se skript výrazně rychleji načte (a pokud to, jak výše psal Daniel Steigerwald, není založené na extra pomalé funkci eval()).

Jde o to jakým způsobem minimalizovaný, (z PHP) určitě bude rychlejší zpracování echo ‚Čao světe‘; než $pozdrav = ‚Čao‘; $world=‚světe‘; $text=$pozdrav.' '.$world; echo $text; – sic nepatrně ale skus si představit že takto máš napsaný každý znak v proměnné a pak do proměnných poskládáš slova z proměnných a pak větu… Tak to napsaný web by byl už výrazně pomalejší(nepatrně ale při kompletních stránkách z proměnných by byl výrazný) a při návštěvnosti 100 000 uživatelů denně by to bylo znatelné! Napříč tomu zkracovat strukturu asi nemá smysl, nemyslím si že by funkce psaná:
if
(podmínka)
{
blok…;
}
elseif
(podmínka)
{
blok…;
}
byla pomaleji zpracována jak u příkazu: if(podmínka){blok;}el­seif(podmínka){blok;} (mezera je stejně znak stejný jako konec řádku(v zpraco­vání))
To se bavím ale o scriptu zpracovávaným na straně vytíženého serveru, na straně klienta v případě javascriptu, ač nejsem odborník tak usuzuji že to nebude mít absolutně žádný význam až na scripty o 100000 řádcích+ A když tu napíšeš jakým způsobem(je jich mnoho!) chceš zkrátit kód, tak ti povím zda to má citelný smysl, nebo ne…

obfuskator

Byt muze zmenseni kodu prinest uzitek, v pripadech kdy lze, _vzdy_ pouzivejte komprimovani poskytovane webserverem (pripadne vlastni aplikaci). Samozrejme se spravnymi hlavickami pro rozumne cachovani, at to prohlizec za par hodin/dni nemusi stahovat ze serveru znovu. Rozdil „gzipnuty nezmenseny/ori­ginalni kod“ vs „gzipnuty a jeste zmenseny kod“ neni prilis znatelny, gzip je relativne ucinna komprese.

Existuje totiz jedna nevyhoda zmenseneho kodu – pri neodladenem skriptu se tezko trasuje pricina chyby. V pripade GCC je moznost vystopovani bugu jeste o rad ztizena (vznika jiny zdrojak).

Samozrejme lze namitnout, ze zmensujeme jen odladeny produkcni kod, ale kdo je bez chyb, ze.. Takhle to v praxi nemusi prilis fungovat (a nefunguje). U beta verzi (v dnesnim pojeti ala Google) ostrych aplikaci bych proto mozna (kvuli pripadnym chybam) zvolil spise gzip originalniho zdrojaku. Velikost nebude o mnoho vetsi nez komprimovana verze a nebudu ztracet cas s preklapenim cisel radku a nazvu identifikatoru, coz sice jde, ale jedna se o zbytecny „opruz“ (navic, pokud se minifikace vmestna na jeden radek (yui), hlaseni o chybe na radku 1 a sloupci 14562 nikoho prilis nepotesi).

Existuji samozrejme i jine duvody k minifikaci, nekdo muze trpet obsedantni touhou obfuskace a nechce puvodni zdrojak zobrazit vubec – taky duvod, byt spise filozofickeho nez technickeho razeni :).

Souhlas. On si stejně prohlížeč ten skript stáhne jen jednou a pak se serveru jen ptá, jestli se nezměnil – a ten mu většinou odpoví 304 Not Modified, takže kromě těch HTTP hlaviček se už nic nepřenáší. Z tohoto důvodu má smysl spíš než skripty nějak „komprimovat“, spojit je dohromady*, protože pak se prohlížeč dotazuje jen jednou a ty HTTP hlavičky s 304 tam proběhnou jen jednou a ne třeba pětkrát pro pět skriptů.

Co se týče „obfuskace“, jsem proti – IMHO na web patří otevřenost a taková tvůrčí spolupráce – inspirace**. Ale když se někdo úzkostně bojí, že by jeho úžasně kvalitní*** Javascript „ukradl“, tak ať, je to jeho věc.

*) když už člověk chce za každou cenu optimalizovat (často to ale bude předčasná optimalizace).

**) nemyslím tím nějaké sprosté kradení skriptů nebo designů, ale prostě inspiraci, vidím na webu nějaké zajímavé řešení, tak se podívám, jak uvnitř funguje a můžu si napsat podobný javascript… příště se třeba zase někdo inspiruje na mých stránkách. Ostatně různé „layouty“ nebo CSS triky mezi sebou webdesignéři taky sdílí.

***) „Na mém systému jsem pracoval již zhruba 10000 hodin. Při sazbě 1.500 Kč/hodinu, kterou si firemně účtuji…“ :-)

Javascript je interpretovany jazyk, takze skor ako o zmensenie suboro kvoli prenosu zo servera ide o zmensenie suboru z dovodu rychlejsieho spracovavania interpreterom Javascriptu.

Omyl, za a) se to týká jen IE < 9, za b) nedá se to ani změřit

Ja sice z javou pracuju, ale do scriptovani moc nevidim.
Rozhodne chci ale autora pochvalit za ten obrazek :)
Sedi k tematu a pripomina mi pani fotografku :D

Trochu mě vytáčí, jak pořád všichni píší „tabelátor“ místo „tabulátor“. Je to odvozeno od slova tabulka. Když stiskneme tabulátor tak tím vytváříme tabulku. Žádnou tabelku čeština nezná.

Zaujima ma ako webdeveloperi v praxi riesia, ze na developer masine je vhodne mat plnu verziu JS suboru a na ostrom srv sa nasadi komprimovana. Hlavne teda v sucinnosti s verzovacim systemom. Pretoze ak mam na developer aj na ostrom srv tzv. working copy (bavme sa o SVN), tak mi hlava nebere ako tieto dve verzie pomocou verzovacieho systemu spravovat.

Idealne by bole, keby sa na ostrom srv okrem toho spojili vsetky JS/CSS do jedineho suboru pre minimalizaciu HTTP rqs.

Vdaka za akykolvek napad.

Dávat ty komprimované javascripty do SVN (nebo jiného verzovacího systému) je prasárna.

1) na kompresi bych se asi vykašlal, viz můj příspěvek výše. Pokud ale musí být:

2) dá se dělat nějakým skriptem – při nasazování nové verze spustíš skript, který ty JS zkomprimuje a nahraje na správné místo.

3) nebo by to šlo dělat „online“ – např. servlet, který si po nasazení aplikace načte ty JS to paměti, zkomprimuje nebo spojí do jednoho a pak je posílá klientům

Hm, buď viz níže, používat na ostrém serveru jiný zdroj (v závislosti třeba na konfiguraci se použije js_dev nebo js_mini).

Druhé řešení je náročnější, ale o řády lepší – v závislosti na uživatelských právech posílat buď původní nebo on-the-fly minifikovanou verzi, tak lze třeba i na ostrém serveru použít debug verzi pro vybrané uživatele (developery).

To druhé řešení používáme a pohodlí / ušetřený čas se nedá ocenit. Výše popsané je asi 1/10 věcí, mj. se js upravuje v rámci lokalizace, řeší drobné nekompatibility s IE (např. čárky za posledním prvkem pole či hash), dynamický class-loader atd.

Pokud máte deployment řešet jinak než ručním kopírováním souborů přes ftp, tak skriptem všechny JS (případně i CSS) soubory concatnete a proženete KJSCompressem, jak jsem odkazoval výše. Na ostrém serveru musíte mít konfigurací zajištěno, že se budou vydávat tyto soubory a ne nekomprimované, tedy v šablonách bude nutná nějaká podmínka dle konfigurační direktivy.