. . .
JavaScript es duro. Se mueve tan rápido que con frecuencia es poco claro que es lo que "estas haciendo mal" en un momento dado. Hay días que parece que las partes malas superan a las buenas.Ya no hay lugar para luchar contra lo evidente. JavaScript se está comiendo el mundo. Asi que hagamoslo bien.
Aqui va una parte.
1. JS dentro de un archivo .js
"Hombre, son solo unas lineas..." Si, me refiero a *casi todo. ¿Por qué? Porque ayuda a la legibilidad, refuerza la estructura, y ahorra ancho de banda. El código JavaScript embebido debe ser descargado cada vez que la página es cargada. Por el contrario, el codigo separado en .js se alamcena en chaché. Como verás, esta regla es ayuda a mantener una larga lista de reglas por venir. Es por eso que es la regla #1.2. JS debería ser estático
He visto muchos hacks creativos para hacer que JavaScript sea dinámico. La gente usa lenguajes de entorno servidor como C#, Ruby o Java para escribir JavaScript dinámico en una cadena de texto. No lo hagas. Pierdes los colores de código, resaltado de sintaxis y soporte de autocompletado. Y recuerda, el JavaScript a un archivo .js (regla #1).En su lugar, usa JSON para introducir comportamiento dinamico. Lo llamo Configuración de Patrones de Objeto de JavaScript ( JavaScript Configuration Object Pattern). He aquí como: inyectar JSON en la cabecera de tu aplicación y utiliza estos datos para desarrollar la lógica como necesites. Puedes pensar "Oye, esto contradice la regla 1". Veo a JSON como datos, no código, por lo que hago una excepción aquí para soportar archivos estaticos y separados en JavaScript
StackOverflow uses this pattern. As does Google. So you’re in good company. Just view their source:
StackOverflow usa este patrón. También Google. Asi que estás en buena compañia. Echa un vistazo a su código:
 |
| Tenga en cuenta la parte de JSON. Esto es simplemente una clase del lado del servidor que se ha serializado a JSON y se ha inyectado en la página. |
Como puedes ver, StackOverflow está inyectando configuraciones personales como isNoticesTabEnabled. Este simple snippet de JSON provee de los datos necesarios para proveer comportamientos a medida usandose archivos estáticos de código JavaScript. Para que esto funcione, serializa una clase del lado del servidor a JSON y coloca el resultado en <head>. Luego podrás referenciar estos datos estructurados cuando se necesiten en tu código JavaScript, sabiendo que está disponible al estar inyectado en <head>
3. JS debería ser Minified
Minimizar el código reduce el tamaño del archivo, lo que incrementa la carga de la página. Recuerda, el rendimiento es una rasgo. Y, por supuesto, para minimizar, necesitas colocar JavaScript en un archivo aparte (de nuevo, la regla #1). Hubo un tiempo en el que minimizar el código era algo molesto. Hoy, es un proceso automático y simple. Existen docenas de maneras de hacerlo, pero Gulp con su gulp-uglify es una manera facil y automatizada forma de hacerlo.4. JS va al final
Si colocas la etiqueta <script> dentro de <head>, esto provoca que se bloquee el renderizado. Los scripts deben de ser cargados después de que el cuerpo sea mostrado. Asi que coloca las etiquetas <script> en el fondo, justo antes de <\body>, permitiendo que se carguen los elementos visibles sin tener que esperar a que se descarguen los scripts. Esto ayuda a mejorara la percepción de rendimiento al dar a tus usuarios una pronta vista. Si vas a escribir JavaScript que deba estar en <head>, considera usar algo como $(document).ready de jQuery, por lo que no se ejecutará hasta que el arbol DOM no esté listo.5. JS debería ser depurado (Linted) en tiempo real
Depurar refuerza las guias de estilo, encuentra erratas, y ayuda a prevenir errores. Hay una variedad de depuradores, pero la sugerencia es ESLint. Puedes ejecutarlo vía Gulp con gulp-eslint. Gulp revisa todos tus archivos JS y se ejecuta cada vez que pulsar guardar. Oh, otra vez, necesitas tus JS en archivos .js separados para depurar. ¿Empiezas a ver por qué puse "JS dentro de un archivo .js" como regla #1?6. JS debería tener test automáticos
Entendemos que testar era importante en el servidor hace años. Pero esto ha sido ignorado en JavaScript hasta hace bien poco. Una aplicación típica de JavaScript de hoy en día es más extensa de lo que podrías probar a mano regularmente. Usar asistentes de JavaScript es mucho más que lógico, es critico tener tests automatizados.Puedes realizar la integración automatizada de testing automáticos con herramientas tales como Selenium. No obstante, estos tests suelen ser bastante delicados, así que sugiero centrarnos en testing unitario. Existe una variedad de opciones para realizar testing unitario automatizado. Sugiero Jasmine si eres nuevo en JavaScript testing y Mocha con Chai si quieres lo último en opciones de configuración.
7. JS deberia estar encapsulado
Hace años que hemos aprendido los riesgos de las variables globales. Afortunadamente, hay muchas maneras de encapsular en JavaScript hoy en día:- Immediately Invoked Function Expressions (aka IIFE)
- Revealing Modules
- AMD (Tipicamente vía RequireJS)
- CommonsJS (usado por Node.js, usando en navegadores como Browserify o Webpack)
- Módulos ES6
Este último apartado, los módulos ES6 son el futuro. La buena noticia es, a pesar de no estar soportado todavía en los navegadores, puedes usar los módulos ES6 transcompilas a traves de Babel (y los verás más abajo, o deberías).
Si no quieres transcompilar, CommonJS es tu mejor opción. Desde que Node usa el patrón CommonJS, puesdes usar npm para lanzar hasta 1000 paquetes. CommonJS no se ejecuta sin una librería ( shim), así que tendrás que usar estos paquetes para navegadores como Browserify, Webpack, o JSPM.
8. Las dependencias JS deben de ser explícitas
Esta regla está íntimamente relacionada con la de arriba. Una vez que has empezado a encapsular tu código JavaScript, necesitas una forma fácil de referenciar a otros módulos. Esto es lo bonito de los sistemas de módulos modernos como CommonJS y ES6. Simplemente especificas tus dependencias en las `rimeras lineas del archivo, casi como una importación o declaraciones en Java o C#. JavaScript se nos ha hecho mayor.
//CommonJS
var react = require('react');
//ES6 Modules
import React from 'React'
var react = require('react');
//ES6 Modules
import React from 'React'
9. Transcompila (transpile) el código JS
La última versión de JavaScript, EcmaScript 2015 (más conocida como ES6) fue oficialmente publicada en junio. Los navegadores aún carecen de soporte de la mayoría de características nuevas, pero no importa. Puedes disfrutar de la larga lista de nuevas características hoy usando Babel. Babel transcompila ES6 a ES5. Y asumiendo que podrás vivir con algunas peculiaridades de rendimiento, podrás difrutar de las nuevas caracterisitcas hoy. Se espera que se publiquen una nueva versión de JavaScript una vez al año a partir de ahora, asi que probablemente nos toque transcompilar más a menudo. Transcompilar es el futuro a día de hoy.¿O quizás te encanta el confort del tipado fuerte? Entonces considera TypeScript como compilador JavaScript.
Aquí la última linea:
Ya no tienes que escribir ES5. Considera usar una abstracción que te dé una potencia extra
10. JS debería tener uan versión automátizada
Ya hemos hablado de depuración, minimizado, transcompilación y testing. ¿pero cómo hacemos todo esto de forma automática? Simple: con un software que lea los archivos. De nuevo, Gulp es una herramienta popular que reune todas las anteriores a través de su función de revisión, pero Grunt junto a Webpack son otra opción a considerar. O, si eres un genio en Bash, simplemente usa npm como editor de JS. La cuestión: no esperes que la gente recuerde como ejecutar esto manualmente. ¡Automatiza y disfruta del resultado!11. Usa un Framework o librerías
Empieza a usar código ya desarrollado. ¿Necesitas luz? Prueba Backbone o Knockout. O quizás jQuery en plano sea suficiente. ¿O quizas algo mas completo funcionalmente o dogmático? Prueba Angular, Ember o React junto a Flux.El punto de esto es :
- No intentes empezar de cero. Somos enanos a hombros de gigantes
Independientemente del framework que elijas, asegúrate de separar sus funcionalidades. Lo que nos lleva al siguiente punto...
12. JS debería separar funcionalidades
Es fácil caer en el hábito de colocar todo el código JavaScript en un solo archivo, o seguir a ciegas las indicaciones del framework. No olvides lo que has aprendido del lado del servidor cuando te muevas al lado cliente.Por separar funciones, no me refiero exclusivamente a separar modelos, vistas y controladores en estilo de framework MV* como Angular o Knockout. Me refiero a:
Piensa como un desarrollador de lado del servidor cuando escriba JavaScript. Separa la presentación de la lógica de negocio y del acceso a datos.
Bueno, eso fue abrumador.
Si, ciertamente.
Hemos entrado en una era en las que el front-end es lo suficientemente complicado que necesitamos especialistas en front-end.
Del original en Medium: 12 Rules for Professional JavaScript in 2015
Texto original de Cory House
Independent Consultant, Pluralsight Author, Microsoft MVP, Telerik Dev Expert, Speaker, Clean Coder, Aspiring Outlier.
Interested in improving your front-end development process? I offer on-site consulting on clean coding practices and modern web application development.
Interested? Let’s chat.
Muy bueno, lo único que no habia tenido en cuenta era el patron CommonsJS.
ResponderEliminarSaludos.