Multi-target bundling : Porque tenemos que pensar en el presente
Una de las tareas que normalmente realizamos en nuestros procesos de construcción de proyectos es la transpilación de código. Herramientas como Babel nos permiten escribir código usando los nuevos estándares como ES6, ES7, ESN y traducir esto a un estándar inferior que entienden la mayoría de los browsers.
Hace algunos años parte del estándar todavía no había sido implementado así que la transpilación a ES5 era obligatoria y tenía sentido, pero en la actualidad ya tenemos navegadores que soportan el estándar y a la fecha seguimos entregando código transpilado a los navegadores que ya tienen soporte.
Esta afirmación nos deja las siguientes interrogantes: ¿Es realmente necesario transpilar? ¿Entregar código ES5 a todos causa un problema? ¿Goku realmente dominó el ultra instinto?
Las respuestas a estos cuestionamientos son un … depende :)
Depende de tu target y que navegadores utilicen, pero como buenos desarrolladores debemos optar por seguir un enfoque progresivo y entregar la mejor experiencia posible al usuario aprovechando las características implementadas por el navegador.
Definitivamente tenemos una gama de navegadores web limitada en cuanto a proveedores pero muy variada en versiones, obviamente no vamos a hacer deployment por cada variación existente pero podemos agruparlos en 2 grandes grupos que la web entiende y nos permite identificar usando los estándares actuales: Soporta módulos o no lo hace.
Esto lo podemos hacer usando las propiedades type y nomodule.
El atributo nomodule previene que un script sea ejecutado si nuestro navegador soporta módulos. Con este podemos indicarle a nuestro navegador que cargue un script si no soporta módulos.
Por otro lado el atributo type nos permite indicar que tipo de script se esta cargando, debe tener un tipo válido para el browser, en caso de no tenerlo hará caso omiso del script.
Recuerda revisar a nuestro buen amigo canIUse.
/*
Los browsers modernos cargarán el recurso module.bundle.js, los que no soportan módulos no lo harán
*/
<script type="module" src="module.bundle.js"></script>/*
Los browsers que no soportan módulos cargarán el recurso nomodule.bundle.js, los browsers modernos no lo harán
*/
<script nomodule src="nomodule.bundle.js"></script>
Los navegadores que tienen soporte para módulos ya tienen incorporadas la mayoría de las características de ES6 por lo que no es necesario transpilar, aquellos que no tengan este soporte le entregaremos el código transpilado en ES5.
Ahora, el incluir esto a nuestro proceso de desarrollo viene con cierto costo ya que incrementa su complejidad, esto debido al hecho de que no tenemos una herramienta estándar para hacerlo, aunque puede esta funcionalidad puede estar incluida en algunas CLI como Polymer CLI, pero esto nos casa con una herramienta lo cual puede estar bien para un proyecto pero no siempre tenemos esa opción. Para mostrar como podemos hacer esto, cree un ejemplo de como construir múltiples bundlings usando webpack.
Bájalo, haz un build y revisa los archivos, si buscas la palabra class veras que el archivo bundle.nomodule.js no usa la palabra class mientras que en el archivo bundle.module.js si.
Otro inconveniente es que no todos los browsers tienen soporte usando el atributo nomodule o puede haber algun issue, en esos casos lo que debemos hacer es tener un script en el html que nos diga si el atributo nomodule esta disponible, si este no esta disponible en el DOM la elección es simple, usamos el bundle que no tiene soporte para módulos. En caso contrario podemos insertar 2 elementos en el DOM uno con el script con soporte para módulos y el que no tiene, el navegador se encargará de lo demas.
En conclusión, hacer múltiples bundlings puede ser difícil pero es lo ideal para poder aprovechar al 100% el engine JS de los navegadores de tus clientes.
