ugrás a tartalomhoz

Ultimate JavaScript minification

Török Gábor · 2009. Júl. 10. (P), 12.32
Tippek a jobb minifikáció eléréséhez
 
1

Hibás cím

yaanno · 2009. Júl. 10. (P), 13.47
A helyes inkább ez lehetett volna: "How to write unmaintainable JavaScript code". Néhány megfontolandó és jó tanács mellett olyan borzalmak is bekerültek, mint a beszédes függvénynevek lecserélése valami egykarakteresre. Másutt is rengeteget találkozni ilyen kóddal, így pl.
HashMap hm = new HashMap();
Ó igen? 20 sorral lejjebb már nem fogod tudni mi volt az a hm. Öngyilkosság bevinni ilyesmit a kód fejlesztői változatába, mert amit nyersz a sávszél megtakarításán, azt elveszíted a fejlesztési időn, ami azzal megy el, hogy megértsd és kövesd ezt a módit.

Nem tudom, a srác milyen fat client projekteken dolgozott, de szerény tapasztalatom szerint ezek esetében a kiküldött adat mennyisége a kritikus, attól lesz fat.

Ezzel nem állítom, hogy nem kell optimalizálni, csak azt, hogy nem minden a sávszél megtakarítás.
2

Vegyük sorban

Török Gábor · 2009. Júl. 10. (P), 13.57
Kiemeltél egy hülyeséget, de hol a többi? :) Azért a javaslatai igen csak egybecsengnek Nicholáséival.

Concatenate static strings with +

Felhívja a figyelmet, hogyha máshogy nem, akkor a YUIC-cal tömörítés végett inkább konkatenációval fűzd össze a stringeket, és ne a tömb/push útat kövesd.

Variable declarations at the beginning of the function

Crockford/JSLint ajánlás.

This as local variable

Érthetetlen, hogy miért pont az x-hez köti a this-t, azonban ez még önmagában nem ront az olvashatóságon. Illetve ahogy a következő tanácsoknál is, t.i. nem azt javasolja, hogy az x-hez kösd, hanem hogy a fenntartott kulcsszavak, hosszú elérési láncok, globális elérhetőségű objektumok helyett helyi kötéseket használjunk. A helyi kötés neve viszont – és erre valóban nem tér ki – lehet ugyanúgy beszédes, mert a tömörítő ezt ugyanolyan jól tudja majd egy rövid névre cserélni.

Shorten numbers, Common strings, Repeating access to object members, Shorten object’s member access, Shorten object’s member names

Ld. előző pontban írtakat.
3

Sorban

yaanno · 2009. Júl. 10. (P), 14.33
Stringösszefűzés: OK, változódeklaráció: OK, használjunk slot jellegű dolgokat: OK.

A this-t én nem bántanám. Nem azért mert nem lehet, hanem mert a this egyrészt "vezeti a szemet", másrészt konvenció, amit nem feltétlenül érdemes felrúgni csak azért, hogy spórolj néhány bájtot a kódban. PHP-t is írhat az ember, ahogy akar, de mégsem teszi (egy idő után).

Ugyanígy a tagnevek esetében fokozottan, ld. a fenti Java "példakód" esetét.

Az ismétlődő szövegelemek esete annyiban okés, hogy a logika ne tartalmazzon ilyet; vastagkliensnél viszont épp az adat, ami rengeteg ilyent tartalmaz, már ha JSON-t küldesz, amit nem is nagyon lehet kiküszöbölni.

Az én fő szempontom a fenntarthatóság; nem azért, hogy a fejlesztő élvezzen kódolás közben, ami néha nem árt végülis, hanem mert végül súlyos árat kell fizetni a követhetetlen, merev kódért. Ha valaki "egy termék - egy kódhalmaz" körben dolgozik, akkor kevesebb gondja lehet, ha viszont szerteágazó vastagklienses projektekben, amelyeket többféleképp kell/lehet felhasználni, öngyilkosság

Kicsit off: egy másik szempont lehet a debugolás - hogy a jó életbe derítsem ki a munge-olt szövegből, hogy mi is a probléma? Ebből az okból (ha munkahelyen nem is), de másutt csak minify-t használok, ahol azonnal látom, hogy ez és ez a gond, nem kell a fejlesztői kód és a prod kód közötti lehetséges eltéréseken agyalnom.

Összefoglalva: első a fenntarthatóság, utána jön az extrém optimalizálás.

Persze senki nem hallgat rám :)
4

Teljes mértékben elfogadom az

Török Gábor · 2009. Júl. 10. (P), 14.44
Teljes mértékben elfogadom az álláspontod, de akkor a részedről semmilyen eszköz nem fogadható el, amelyik „rejtjelezi” a kódot. A poszt alap feltevése pedig az volt, hogy ha te ezt akarod, akkor mutatok néhány módszert, miként teheted még hatékonyabbá.
5

Touché

yaanno · 2009. Júl. 10. (P), 15.06
Ez így kerek.

Szerk.: Ha jól láttam, még nem volt, itt is vannak jópofa tippek a Google háza táján.
6

Volt (:

Török Gábor · 2009. Júl. 10. (P), 15.38
Volt (: