"use strict" solo en depuración?

Me pregunto si es realmente necesario incluir el "use strict" cuando termine de programar y liberar mi documento de JavaScript para que cualquiera lo vea. Me gusta usarlo porque para verificar que he codificado de una buena manera."use strict" solo en depuración?

Entonces, ¿debería incluir o simplemente eliminar el uso "use strict" cuando publico mi archivo JavaScript para el público?

La razón por la que pregunto es para ahorrar espacio en mi archivo JavaScript.

Fuente

2012-06-11 user1431627

"* guarde espacio en mi archivo JavaScript *" - en serio, ¿qué tan grande son sus archivos JavaScript (incluso después de la compresión?) –

@TomaszNurkiewicz Debe estar casi lleno: P – Paulpro

Si su cuenta de ancho de banda es tan alta que los bytes de 'use strict' rompen el banco, es posible que desee cambiar los ISP ... –

La línea "use strict"; compone 13 bytes de su archivo. Sugeriría que es poco probable que esto se acerque al 1% del tamaño de tu archivo.

Utilice uno de los muchos minificadores disponibles para reducir el tamaño de su archivo, junto con la compensación de gzip en el lado del servidor, si le preocupa el ancho de banda. La eliminación manual de 13 bytes es una economía falsa.

Exactamente qué minificador puede depender de su código, pero here are some suggestions.

Fuente

2012-06-11 20:02:27 Dancrumb

me encontré con dos opiniones sobre el uso de strict mode en la producción:

No hay razón para enviar “use strict” en su código de producción. No hay ganancia de rendimiento (verificado con el equipo V8 y Brendan hace un tiempo) y no necesito que las máquinas virtuales de mis usuarios realicen las comprobaciones adicionales también. Consérvelo solo de desarrollo, despréndalo durante la compilación. De esta forma, también evitará el problema de concatenación al que hace referencia.

Puede que no haya una ganancia de rendimiento, pero también no es una pérdida de rendimiento. En la producción, incluso más que en el desarrollo, es donde desea estar seguro de que está notando errores. Minimizar los cambios entre las versiones de desarrollo y producción del código es clave para poder depurar los problemas de manera rápida y eficiente. Sí, esto ayuda durante el desarrollo, pero no hay razón para sacarlo del código de producción.

The source is in the comments at the bottom

Y, por supuesto, los 12b peso de "use strict" no cambiará nada.

Fuente

2012-06-11 20:04:57 gdoron

Es parte de muchas cosas en mi JavaScript. – user1431627

Cotizaciones interesantes. En cuanto a la pregunta, parece que OP ya ha decidido que los 12 bytes guardados valen la pena. Me resulta difícil de creer, especialmente si debe eliminarse manualmente en lugar de ser parte de un proceso de compilación. Hay algunos cambios de modo estrictos que no son retrocompatibles, por lo que eliminar el declarativo podría romper el código en esas situaciones. Pero si se soportan implementaciones no estrictas, es probable que (afortunadamente) no se utilicen de manera incompatible. –

@amnotiam. ¿Qué características de modo estricto no son compatibles en el modo no estricto? ¿O te perdí por completo allí ...? ¿Usas 'modo estricto'? – gdoron

Sin duda es una micro-optimización, pero si está concatenando (digamos 25) módulos JS juntos, de repente es de 250bytes.

Implementación en la producción en una aplicación de alto tráfico, con decir 1000 golpes por minuto, eso es 130 + Gb de un año de tráfico que puede prevenir si su acumulación retira el 'use strict'; s

Estoy seguro de que ahorraría pocos dólares en AWS ...

No he visto un argumento convincente para mantenerlo en producción, aparte de que no vale la pena el tiempo. Probablemente no lo es, pero si ya tiene un sistema de compilación y los conocimientos para llevarlo a cabo con un mínimo esfuerzo, ¿por qué no?

Fuente

2013-07-19 17:55:07

Será mucho menos de 250 bytes debido a gzip – Adria

me pregunto si hay alguna razón por la cual los muchos minimizadores JS no ofrecen (ofrecen la opción) quitar esto? – simon

Este es un argumento bastante falaz. Asumiendo que el ancho de banda de la red era de $ 1/GB (extremadamente alto), no es como si el propietario de cualquier sitio web que atendiera a __ames por millón de solicitudes por año__ se preocupara por $ 130/año. –

Actualmente, recomiendo que elimine el "uso estricto" en cualquier código que esté destinado a producción (y solo utilícelo en depuración).

Sin embargo, no lo eliminaría solo para hacer los archivos más pequeños.La razón por la que lo eliminaría es porque actualmente parece tener un impacto negativo en el rendimiento real de JavaScript cuando se ejecuta. Afortunadamente esto cambiará eventualmente, pero por ahora lo omitiría por razones de rendimiento.

Fuente

2016-02-09 18:50:50

Respuesta

Cuestiones relacionadas