2012-06-11 5 views
7

Mi chiedo se sia davvero necessario includere lo "use strict" quando ho terminato di programmare e rilasciare il mio documento JavaScript a chiunque. Mi piace usarlo perché per verificare che ho codificato in un buon modo."use strict" solo nel debug?

Quindi, dovrei includere o semplicemente rimuovere utilizzare "use strict" quando rilascio il mio file JavaScript per il pubblico?

Il motivo per cui chiedo è di risparmiare spazio nel mio file JavaScript.

+7

"* risparmiare spazio nel mio file JavaScript *" - sul serio, quanto grande sono i tuoi file JavaScript –

+2

@TomaszNurkiewicz Deve essere praticamente pieno (anche dopo la compressione?): P – Paulpro

+4

Se il disegno di legge di larghezza di banda è così alta che il 10 byte di 'use strict' rompere la banca, potresti voler cambiare ISP ... –

risposta

2

La riga "use strict"; costituisce 13 byte del file. Suggerirei che è improbabile persino avvicinarsi all'1% delle dimensioni del file.

Utilizzare uno dei molti minifi ci per ridurre le dimensioni del file, insieme alla combo gzip sul lato server, se si è preoccupati della larghezza di banda. La rimozione manuale di 13 byte è una falsa economia.

Esattamente quale minificatore può dipendere dal codice, ma here are some suggestions.

9

Ho trovato due pareri sull'uso strict mode nella produzione:

Non v'è alcuna ragione per la spedizione “use strict” nel codice di produzione. Non c'è alcun guadagno in termini di prestazioni (verificato con il team V8 e Brendan qualche tempo fa) e non ho bisogno che anche le VM dei miei utenti eseguano i controlli extra. Mantieni solo lo sviluppo, eliminalo durante la compilazione. In questo modo eviti anche il problema di concatenazione a cui fai riferimento.

E:

Non ci può essere un guadagno di prestazioni, ma non c'è anche una perdita di prestazioni. Nella produzione, ancor più che nello sviluppo, è dove vuoi essere sicuro di notare gli errori. Ridurre al minimo le modifiche tra le versioni di sviluppo e di produzione del codice è fondamentale per poter eseguire il debug dei problemi in modo rapido ed efficiente. Sì, aiuta durante lo sviluppo, ma non c'è motivo di estrapolarlo dal codice di produzione.

The source is in the comments at the bottom

E naturalmente quelli 12b peso di "use strict" non cambierà nulla.

+0

Fa parte di molte cose nel mio JavaScript. – user1431627

+0

Citazioni interessanti. Per quanto riguarda la domanda, sembra che OP abbia già deciso che i 12 byte salvati valgono la pena. Trovo difficile crederlo, soprattutto se deve essere rimosso manualmente anziché essere parte di un processo di compilazione. Esistono alcune modifiche rigorose della modalità che non sono compatibili con le versioni precedenti, pertanto la rimozione del dichiarativo potrebbe interrompere il codice in tali situazioni. Ma se vengono implementate implementazioni non rigorose, è probabile che tali modifiche (si spera) non vengano utilizzate in un modo non compatibile. –

+0

@amnotiam. Quali funzionalità in modalità rigorosa non sono supportate in modalità non rigida? O ti ho completamente perso lì ...? Usi 'strict-mode'? – gdoron

2

Sicuramente è una micro-ottimizzazione, ma se si concatenano (diciamo 25) moduli JS insieme, questo è tutto l'improvviso 250 byte.

di andare in produzione in un'applicazione ad alto traffico, con dire 1000 colpi al minuto, questo è 130+ Gb un anno di traffico è possibile evitare se il vostro costruire rimosso il 'use strict'; s

Sono sicuro che sarebbe risparmiare un pochi dollari su AWS ...

Non ho visto un argomento convincente per tenerlo in produzione diverso dal suo non vale il tempo. Probabilmente non lo è, ma se hai già un sistema di build e il know-how per ottenerlo con il minimo sforzo, perché no?

+1

Sarà molto meno di 250 byte a causa di gzip – Adria

+0

mi chiedo se ci sia qualche motivo per cui i molti minimizzatori JS non ci sono (offrono la possibilità di) spogliarlo? – simon

+0

Questo è un argomento piuttosto fallace. Supponendo che la larghezza di banda della rete fosse di $ 1/GB (estremamente alta), non è come se il proprietario di un sito web che servisse __Miliardi di richieste all'anno fosse in grado di preoccuparsi di $ 130 all'anno. –

0

Attualmente raccomando di rimuovere "use strict" in qualsiasi codice destinato alla produzione (e usarlo solo nel debug).

Tuttavia, non lo rimuovere solo per rendere il file (s) più piccolo.Il motivo per cui lo rimuovere è perché attualmente sembra avere un impatto negativo sulle prestazioni effettive di JavaScript quando viene eseguito. Spero che questo cambierà alla fine, ma per ora lo ometterei per motivi di prestazioni.