Koas.dev

En ocasiones hay elementos que tienen scroll y en iPad / iPhone va como a saltos. Para evitar esto hay que ponerle este estilo al elemento:

-webkit-overflow-scrolling: touch;

Microsoft ha lanzado sonarwhal, un analizador de páginas web que detecta errores y posibles fallos de seguridad. Es parecido al PageSpeed Insights de Google, pero con la ventaja de que podemos instalarlo en nuestro equipo para hacer el análisis en local.

Una cosa sobre la que avisa y que no conocía es que cuando tenemos links que se abren en una ventana nueva y que tienen como destino páginas externas debemos añadir el atributo rel=”noopener noreferrer”; haciendo esto evitamos que la página a la que enlazamos tenga acceso a nuestra ventana mediante window.opener y también que esa pestaña tenga su propio proceso. Aquí lo explican con detalle.

Hace unos días estuve investigando los web components, que nos permiten crear elementos HTML que tengan sus propias etiquetas e incluirlos en una página web de la misma forma que usamos cajas de texto o desplegables.

Los estándares van despacio, y de momento Google Chrome es el único navegador que implementa todas las funcionalidades por defecto, pero existen polyfills para el resto de navegadores, así que ya se puede ir haciendo algo. Estuve mirando Polymer y X-Tag, y al final me decidí por este último porque no requiere instalar nada en el equipo para trabajar, basta con incluir un fichero JS con la librería y el polyfill.

Para probar hice un componente que es una valoración en estrellas, como las que usan muchas páginas para valorar productos o películas. Puede verse el resultado final con demos aquí.

La forma de crear el componente me recordó bastante a la de crear un plugin para jQuery. A partir de ciertos valores (atributos en el caso del componente, parámetros de inicialización en el caso de jQuery) se construye un código HTML (el que contiene las estrellas) que se inyecta en el componente padre (el elemento koas-star-rating en el caso del componente, el elemento sobre el que apliquemos el plugin en jQuery). Adicionalmente se responde a eventos del ratón modificando ese HTML (para colorear las estrellas correspondientes) y se pueden emitir eventos a los que el usuario que esté usando nuestro componente / plugin pueda engancharse y ser notificado cuando el valor cambie.

Incluso la forma de hacer que el componente se pueda usar dentro de un formulario y contenga un valor cuando el formulario se envíe (creando un campo input oculto cuyo valor se modifica cada vez que cambia el valor de las estrellas) es la misma que usaríamos si estuviéramos haciendo un plugin de jQuery.

Por este motivo, una vez terminé el componente y lo probé en todos los navegadores y vi que funcionaba bien me pregunté: bueno, vale, has hecho un componente pero, ¿compensa hacer esto en vez de hacer un plugin de jQuery? Esta es la pregunta a la que me gustaría dar respuesta con las siguientes reflexiones.

• Lo primero que se me viene a la cabeza es que los componentes tienen una gran ventaja: para usarlos no es necesario conocer jQuery. Bien, de acuerdo, es difícil que a día de hoy haya programadores de JS que no conozcan jQuery, pero puede pasar. Y aunque no fuera así, aunque todos los programadores del mundo usaran jQuery, creo que es mucho más elegante tener una solución que no dependa de una librería externa. Esto ya es una opinión personal, soy partidario del Vanilla JS y si bien uso jQuery (y me encanta) hasta ahora nunca he usado (ni he sentido la necesidad de hacerlo) ningún framework ni nada parecido para ningún desarrollo personal ni profesional. Punto para los componentes.
   
• Respecto a dependencias, si bien es cierto que los componentes no requieren de una librería como jQuery sí que necesitan el polyfill, al menos hasta que todos los navegadores implementen todas las tecnologías necesarias. En este sentido componentes y plugins tienen el mismo “coste”: incluir el polyfill si queremos usar un componente y jQuery si queremos usar el plugin. Sin embargo los componentes tienen una ventaja añadida, porque al usar la tecnología HTML Imports (que nos permite importar un fichero HTML) podemos incluir tantos ficheros JS y CSS como queramos con una única línea de código (el fichero HTML que importemos incluirá las referencias necesarias a los ficheros JS y CSS). En el caso de jQuery si el plugin tiene un fichero CSS deberemos cargarlo también. Por lo general todos los plugin de jQuery tienen su fichero CSS, lo que hace que el número final de ficheros que deberemos cargar en la cabecera (o pie) de nuestra página será de 2 para un componente (el polyfill y el fichero HTML que a su vez cargará el resto de ficheros necesarios) y de (al menos) 3 para un plugin (la librería jQuery, el fichero JS con el código y el fichero CSS con los estilos). Punto para los componentes.
   
• Supongamos que el componente / plugin es muy muy sencillo y solo consiste en un fichero de código. En ese caso, y si solo tenemos en cuenta el peso de las dependencias, estaríamos añadiendo 69,4 KB en los componentes (el peso del polyfill minimizado) y 84,6 KB (el peso de jQuery 3.2.1 minimizado). Punto para los componentes.
   
• Respecto a cómo desarrollar el código necesario para la funcionalidad que queremos las dos opciones están igualadas, ya sea usando jQuery o JS a pelo podremos implementar todo lo que necesitemos.
   
• Finalmente está el asunto de la claridad del código. A la hora de leer el código HTML de una página es mucho más claro ver una etiqueta que diga <koas-star-rating> que ver un div y luego, al final de la página, ver un código JS que hace una llamada al plugin sobre ese div. La etiqueta propia del componente nos dice claramente qué hace ese elemento, esto ya es una gran ventaja, pero además no necesitamos hacer ninguna llamada JS para que “arranque”. Aunque hay plugins en los que esto no es necesario (el código del plugin ya se ocupa de ejecutarse sobre los elementos que tengan por ejemplo una clase determinada) la arquitectura de los componentes es más simple e intuitiva. Punto sin duda para los componentes.
   

En resumen, los plugins de jQuery seguirán teniendo su utilidad en muchos casos, pero si lo que queremos es crear un elemento de interfaz de usuario creo que los componentes web son mucho más interesantes y reutilizables. Espero que el resto de navegadores se pongan las pilas y pronto podamos disfrutar los web components de forma nativa.