Minimizzabilità o leggibilità?

In questo modo, stai riducendo sia la leggibilità sia la misura in cui il plugin può essere ridotto.

Prendiamo il tuo esempio della tua stringa HTML ottenendo un file HTML con alcuni tag <div> . Eseguendo qualche codice di esempio tramite un minificatore, otteniamo 380 byte prima di gzip per il primo: 174

var a="<div>a</div><br><div>bc</div><br><div>def</div><br><div>ghij</div><br><div>klmno</div><br><div>pqrsjt</div><br><div>uvwxyzA</div><br><div>BCDEFGHI</div><br><div>JKLMNOPQR</div><br><div>S</div>",b="<div>T</div><br><div>UV</div><br><div>WXY</div><br><div>Z'12</div><br><div>34567</div><br><div>890-='</div><br><div>!@#$%^*</div><br><div>()_+[]{</div><br><div>}|;':,./</div>";

Per il secondo, otteniamo 347 byte prima di gzip, un leggero miglioramento:

var c='replace',a="<!>a</!><br><!>bc</!><br><!>def</!><br><!>ghij</!><br><!>klmno</!><br><!>pqrsjt</!><br><!>uvwxyzA</!><br><!>BCDEFGHI</!><br><!>JKLMNOPQR</!><br><!>S</!>"[c](/\!/g,"div"),b="<!>T</!><br><!>UV</!><br><!>WXY</!><br><!>Z'12</!><br><!>34567</!><br><!>890-='</!><br><!>!@#$%^*</!><br><!>()_+[]{</!><br><!>}|;':,./?</!>"[c](/\!/g,"div");

Tuttavia, ciò che devi capire è che ciò che è importante la maggior parte delle volte è importante la dimensione del file dopo essere stato gzip, non prima. Questo perché molti server e browser supportano l'invio di file che sono stati compressi in questo modo, riducendo l'utilizzo della larghezza di banda.

Quando compresso, l'algoritmo DEFLATE (ciò che gzip usa per comprimere i file) fa già ciò che dovresti fare manualmente, comunque dovresti avere le dimensioni aggiuntive e la perdita di prestazioni associate al codice sostitutivo. Inoltre, è in grado di riconoscere gli schemi di corde che non sono facili da vedere con il codice normale senza rendere il codice completamente illeggibile.

Con questo esempio, quello che finiamo per trovare è che dopo aver eseguito la compressione su di esso (ho usato Zopfli per testare questo), il primo script in realtà comprime fino a 172 byte, mentre il secondo può essere compresso solo fino a 199 byte, che è peggio. La dichiarazione per var c="replace" e [c](/\!/g,"div") occupa byte in sé e dato che gzip pone già le sottorapporti nel file compresso, in realtà aumenta le dimensioni del codice.

Non solo, le prestazioni sono leggermente peggiori perché dovresti sostituire ciascuna di esse durante il runtime, che è peggio del tempo necessario per decomprimere il file gzipp in modo nativo.

In effetti, la maggior parte dei minificatori effettivamente fa l'opposto di quello che hai fatto, in modo che la dimensione gzip venga ridotta. Vedi questa discussione su il gruppo di discussione di Closure Compiler.

Una FAQ per il compilatore di chiusura copre anche questo:

Closure Compiler inlined all my strings, which made my code size bigger. Why did it do that?

Most people compare code size by looking at two uncompressed JavaScript files. But that's a misleading way to look at code size, because your JavaScript files should not be served uncompressed. It should be served with gzip compression.

Closure Compiler assumes that you are using gzip compression. If you do not, you should. Configuring your server to gzip your code is one of the most effective and easiest optimizations that you can possibly do. The gzip algorithm works by trying to alias sequences of bytes in an optimal way. Aliasing strings manually almost always makes the compressed code size bigger, because it subverts gzip's own algorithm for aliasing. So Closure Compiler will (almost) always inline your strings when it can, because that will make your compressed code smaller.

If you know your client doesn't support gzip, the Java API has an aliasAllStrings option on the CompilerOptions class. Turning this on will make the compiler alias all your strings in the global scope.

Se il codice fosse perfetto, non ci sarebbe bisogno di documentazione perché è semplice e diretto, quindi non ci sarebbe bisogno di ottimizzare per qualcosa di diverso dalle prestazioni.

Tuttavia, il codice non è perfetto, e se sei come me, avrai passato diversi giorni a strapparti i capelli cercando di risolvere un problema stupido con una libreria javascript. Penso che la soluzione migliore sia semplicemente non decidere per conto del programmatore che lo sta scaricando, ma offrire entrambe le versioni allo stesso modo. La versione leggibile è per coloro che desiderano modificare il codice esistente e la versione minificata sarebbe ottimizzare le prestazioni perché il codice che dipende da esso già fa quello che si suppone.

Raramente si vedrà un programmatore che desidera avere il codice leggibile per il debug, ma abbastanza veloce da essere messo in produzione. Se riesci a ottenerlo più velocemente riducendolo al di là dei livelli leggibili, vedrai invece quella versione utilizzata in produzione.

La versione minificata può essere semplicemente la tua versione leggibile che è stata minimizzata, quindi concentrati semplicemente sulla scrittura di codice leggibile poiché l'obiettivo è quello di rendere il tuo codice, beh ... leggibile. Facciamo un esperimento mentale per un momento.

Supponiamo di poter minimizzare il codice da 50kb a 10kb. Si tratta di una riduzione delle dimensioni dell'80%, e si potrebbe dire che, dal punto di vista della larghezza di banda, questo è l'80% più performante. Supponiamo ora di poter ridurre ulteriormente questa riduzione da 10k a 9k se si sostituiscono tutte le istruzioni if con operatori terziari. Ora anziché una riduzione dell'80% delle dimensioni, sei riuscito a ottenere una riduzione delle dimensioni dell'82%.

Detto questo, se si potesse valutare la leggibilità del proprio codice prima e dopo questa modifica, si ritiene che si sarebbe subita solo una variazione del 2% nella leggibilità? Forse, ma direi che hai perso di più. Anche se fosse solo una differenza del 2%, la leggibilità è lo scopo qui, non le prestazioni. La maggior parte delle differenze nelle prestazioni deriva da quella riduzione di 40k con l'uso di minified e molto poco è stato ottenuto per quel singolo cambiamento.

Detto questo, forse non creare grandi blocchi di codice che non verranno mai eseguiti.